Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Log Reader Agent
The log reader agent is implemented by three steps, much like its snapshot counterpart. The first step records the startup of the log reader agent and updates performance counters; the second step actually runs the log reader agent. The sample execution of the log reader agent is as follows:
-Publisher [D10ZF411] -PublisherDB [pubs] -Distributor [D10ZF411] -DistributorSecurityMode 1 -Continuous
Again, the parameters are very similar to those of the snapshot agent. The only difference is the Continuous parameter, which specifies that the log reader agent should run at all times instead of on a particular schedule. If you specify a schedule for running the log reader agent, the Continuous parameter is simply dropped.
The third and final step of the log reader agent job executes sp_MSdetect_nonlogged_shutdown, which attempts to detect a problem that prevented the log reader agent from succeeding and then reports any findings.
The following table explains the parameters specific to the log reader agent profiles:
|
Parameter Name |
Default Value |
Meaning |
|
Polling interval |
10 |
Number of seconds the publisher database's transaction log is queried for replicated transactions. |
|
Read Batch Size |
500 |
Number of transactions read in a single batch. |
|
Read Batch Threshold |
100 |
Number of replicated commands to be read before being issued to the subscriber(s). |
Default values typically work well for the log reader agent. However, you might have to adjust the read batch size parameter at times. If UPDATE commands executed on publisher database affect multiple rows and change the columns of a UNIQUE constraint or clustered index, the log reader agent will fail and report an error. The resolution is to set the read batch size to 1 and restart the log reader agent.
You are also likely to receive an error, stating that the log reader agent couldn't execute sp_replcmds on the publishing server. This usually means that the log reader agent couldn't read the number of transaction log records within the time limit you set with QueryTimeout. The resolution is to increase the query timeout limit or decrease the read batch size. Note that decreasing the read batch size means that the log reader agent will take longer to move transactions to the distribution database; therefore replication latency will increase.