Replication Server Performance Tuning
Here are some rules of thumb to tune a replication server. They may not always be suitable for your environment, but it can be used as a starting point for further improvements.
- "scan batch size", set to "10000"
- "scan timeout", set to "5" (seconds) (not really a performance booster)
- "send buffer size", set to "16k"
- Check if "batch ltl" is set to "true".
With the sp_help_rep_agent stored procedure you can see if the RepAgent can keep up with the activity in the transaction log. Output of this procedure (with the "scan" option") shows the current and the end marker. The end marker is the last page/row number of the transaction log, and the current marker is the page/row number currently being scanned by the RepAgent. In the output of sp_help_rep_agent the markers are shown like this (example): (2954283,4). The first number is the page number and second one the record number on the page.
The most important configuration parameter for the SQT is "sqt_max_cache_size". To check if this parameter has been set too low, run an "admin who,sqt" at regular intervals and check if the columns "removed" or "full" contain a non-zero value. Be aware that the output of "admin who,sqt" also shows the DSI threads. So when "removed" or "full" are non-zero for a DSI thread, change the memory setting at the connection-level using "alter connection to <dataserver.database> set dsi_sqt_max_cache_size to '<new-value>'". Otherwise change the "sqt_max_cache_size" configuration parameter using "rs_configure" or (better!) "configure replication server".
It's best to start increasing "sqt_max_cache_size" before changing settings at the connection level.
For RepServer 12.6 do not increase "sqt_max_cache_size" to much. Oversizing the cache will in fact decrease performance. SQT cache is sufficiently sized if you do not observe, or observe only infrequently, transactions being flushed from cache because there is not enough room to store more in cache.
Replicating Stored Procedures
Using stored procedure replication can greatly improve the performance of a replicated environment. Before using this feature check if the tables that are modified through the stored procedure are also marked for replication. For warm standby environments this is usually done with the sp_reptostandby stored procedure. Since data at the replicate site is now modified through a stored proc, some side effects can occur.
- Tables using identity columns will have a different value in their identity column on the primary and replicate site.
- Inserted/Updated values from global variables (like @@spid), various system functions like getdate() will also differ between primary and replicate, causing a difference in data between sites.
- You cannot use nested stored procedure replication (stored procedure a executes b, and a and b are both marked for replication). See http://www.sybase.com/detail?id=1039889 for recovery instructions when you got "RepAgent(n): Nested replicated stored procedure detected. Transaction log may be corrupt. Please contact SYBASE Technical Support.". It might be neccesary to run the recovery steps twice.
Check if this applies to your situation before using stored procedure replication.
Usually a stored procedure is marked for replication like this: sp_setrepproc "<procedure name>","function" There is no need to create anything else (like subscribtions or other stuff).
Modifying the RSSD using sql scripts
(from sybase.com): Every time you run a SQL script that modifies the Replication Server System Database (RSSD), you must shut down Replication Server before running the script, then restart it after running the script. This is because of changes to the way heterogeneous datatype information is cached.