Clarification required on WSB and MSA Replication methods

[DilipVoora]

Hi Experts,

All these days I have little understanding on Sybase Replication Server methods at database level but now I planned to look deep into those details. So, I would like to seek your help in understanding the below.

1. What are the major differences between WSB and MSA in particular apart from the genral things like WS is for 1-1 and MSA is for one source to multiple targets. How to interpret the statement "through MSA sitch over and switch back require less down time"?Isn't it the same with WSB using switch active command?
2. MSA is bi-directional Replciation method is what I read. This means transactions can flow from source_>target and vice-versa. Is this a correct understanding or am I missing something other here?
3. On what factors we have to choose between WSB and MSA for a dataserver (all user defined database are to be replicated) that has a load of 35million records and with the largest databae of size 3TB(1.8TB actual data)?
4. What could be minimum network bandwidth required for both methods and from where we can check it? Is it from sp_sysmon or from any other procedure in RSSD or through RS commands? Are there any OS level things we need to look into along with this?
5.How SQM and SQT works internally?
6. In WSB method, I read that Replciation Server always consider the active and standby databases as a "single database" and standby database is an exact copy of the primary. How to undertand this in detail?
7. I understand from the documentation related to WSB, logical connection is just a symbolic representation of the "active/standby_dataserver.active/standby_database name" but how it works internally with Replication Server and why it should exist and where it comes into action during the data flow in Replication Server?
8. Do we need to turn off DIST for WSB or it will be default disabled? If it has to be enabled, please tell me why we should enable it as we have only one target (which is identified as an exact copy of the primary)?
9.How to check the lag in replication agent and lag in DSI?
10. If we opt for WSB are there any particular parameters we need to configure? Is there any SAP notes that talks abou stadard configuration?
11. If we opt for MSA are there any particular parameters we need to configure? Is there any SAP notes that talks abou stadard configuration?
12. Will there be any data loss in Sybase Replication methods?
13. Data into target database will be applied in the form SQL statements by RS thus there is no chance for data corruption even though data in primary is corrupted. Can anyone explain this please?
14. Configuring parallel DSI just increases he speed of replication alone or any other benefits with this?
15. Through MSA we can access the function strings fully, what does this exactly mean?

NOTE : I referred multiple documents but no where I came across the exact answers and the internals.

Regards,
Dilip Voora

[Mark_A_Parsons]

If you're familiar with table-level replication then WS and MSA are just ways to reduce the amount of setup work the DBA has to perform to get all tables in a database added to replication; otherwise RS functionality and performance issues are going to be the same for table-level replication vs WS vs MSA.

As for the laundry list of questions ...

1 Question is too broad; high-level view ... WS requires less commands to setup, is limited to 1-to-1 db replication, and the switch active command is rather finicky (ie, can break part way through a switch and there's no real/good documenation on how to recover so DBA needs good understanding of what switch active is doing under the covers in order to recover in a timely manner) ... MSA takes a little more time to setup, supports 1-to-1/1-to-many db replication, DBA must perform all steps to switch direction of replication (typically scripted to speed up the process and make sure no steps are missed); time to switch is (relatively) comparable for a single db pair while trying to switch multiple db pairs (managed by the same RS) is typically faster with MSA (assuming DBA has scripted the process); one other big difference ... WS limited to a single repserver instance while MSA can make use of multiple repservers (ie, routes)

2 MSA (aka db repdef/subscription pair) is one-way replication; if the intent is to simulate a WS environment then you setup 2x MSA/repdef/subscription pairs (one in each direction)

3 Question is too broad and depends heavily on individual site requirements; MSA offers more granular control of what is (not) replicated; size of the database doesn't matter as much as the volume and size of replicated transactions

4 Question is too broad and depends heavily on individual site requirements; network bandwidth will depend on volume (MBytes) of transactions in a given period of time as well as an assortment of repagent/repserver configs that will determine how quickly the repagent/repserver can process transactions (eg, if memory/cpu starved then repagent/repserver delays will reduce the volume of network activity); keep in mind that if using repserver to materialize tables then the network requirements may need to be increased (especially if running multiple materializations in parallel)

5 See Repserver internal processing for starters.

6 The generic WS definition assumes at some point there may be a need to run the switch active command, which in turn means moving all user/application activity to the standby database, which in turn means the users/applications will expect to see no differences when connecting to the standby database, hence the mention of the active/standby db's being exact copies; in practice it is possible to have the two databases out of sync by design (eg, don't replicate scratch tables) as long as the users/applications can function properly (ie, without data loss) if they are switched to the standby database

7 The logical connection is what you reference when you run the switch active command; it's also what you reference if you were to hang a MSA repdef (or sub) off of the logical connection (eg, replicate out of a WS/logical into a 3rd db via a WS-MSA setup; replicate into the a WS/logical connection from a 3rd db via a MSA-WS setup)

8 [off the top of my head] I want to say the DIST is not enabled for the generic WS/logical connection setup (you can verify by running admin who to see if there's a DIST thread running for the WS/logical connection and related active/standby dbs); the DIST does need to be enabled for some (advanced) setups (eg, replicating out of WS to Oracle/UDB/SqlServer)

9 If by 'lag' you mean 'latency', you can get a high-level view by comparing the current time with the datetime stamp in the replicate db's rs_lastcommit.origin_time column; for more granularity you should look at generating (from the primary db) rs_ticket on a regular basis and then reviewing the datetime stamps in the replicate db's rs_ticket_history table.

10 Question is too broad and depends heavily on individual site requirements; ultimately it comes down to transaction profiles (size/volume of transactions) and cpu/memory resources available to repserver

11 Question is too broad and depends heavily on individual site requirements; ultimately it comes down to transaction profiles (size/volume of transactions) and cpu/memory resources available to repserver

12 Generally speaking: no, repserver does not lose data (otherwise no one would use the product, right?); if the question is 'Can data loss occur?' then the answer is 'yes' (as with any database and/or replication setup) but the severity of a data loss will depend on why the data loss occurred (eg, improperly defined repdef/sub, DBA accidentally skipping/deleting transactions from repserver queues, someone disabling replication of a (primary db) transaction, hardware/software error that trashes a repserver queue, etc); if the primary database has not suffered any data loss then it should be possible to resync replication though that's a topic that could span a few days of instruction/discussion

13 disk/device/block replication (from primary db to replicate db) will drag along any corruption in said disk/device/block; transactional replication (assuming no issues with the primary db transaction log) sends the DML statements (and/or stored proc invocations) which means the replicate db engine must parse/compile/execute said DML commands before updating the replicate db's disks/devices/blocks (net result is that disk/device/block corruption is not copied from the primary db to the replicate db)

14 Parallel DSI can speed up processing but depends on the actual configuration; higher throughput is typically obtained through more advanced methods (eg, DML statement replication, stored procedure replication, multipath replication setup/configs, etc)

15 Depends on the context of whatever documentation you're referencing; if the objective is to modify default function strings, and depending on which function strings you wish to modify ... this can be done for WS and MSA, though with table-level (and stored proc) replication you can also modify repdef-level function strings