December 23, 2010 at 9:34 am
SUbscriber is stopped for 2 days due to SAN problem & restarted.Unable to catch up replication ,as undisributed commands are more than 20000000.I'm using sql server 2008
Getting error message(DIStributor to subscriber history)
Error messages:
The replication agent has not logged a progress message in 10 minutes. This might indicate an unresponsive agent or high system activity. Verify that records are being replicated to the destination and that connections to the Subscriber, Publisher, and Distributor are still active.
Any help is highly appreciated
December 23, 2010 at 8:06 pm
The message you are getting is a warning message. If everything is operating normally, you would tend to expect that a replication agent (the distribution agent in this case) would do everything it needs within 10 minutes.
However, you don't have a normal situation.
This is a warning message that should prompt you to check what is going on. Check on your subscriber - is the distribution agent still applying changes to the subscriber. It probably is - otherwise you would, most likely, see errors happening.
There are some options that you can change so that you get more information logged. These are normally managed using agent profiles. Have a look at "Replication Distribution Agent " in Books OnLine. It has more info that I can type here. However, to change an agent's profile, you will need to stop it. If it is part way through a large transaction, it will be rolled back and you start over.
And finally, I wouldn't change the profile unless you need more info on what the agent is doing. I generally find that I can get enough info by checking using sp_who2 and the other normal checks you use to see what a server/application is doing
December 24, 2010 at 5:15 am
as happycat says this is just a warning message and the data should be replicating away in the background
Run the following on the distributionDB to see how much data is queued and for what tables
if exists (select * from tempdb.sys.tables where name = '##msdstatus')
drop table ##msdstatus
if exists (select * from tempdb.sys.tables where name = '##msdagents')
drop table ##msdagents
if exists (select * from tempdb.sys.tables where name = '##msdarticles')
drop table ##msdarticles
use Distribution
go
select * into ##msdstatus from msdistribution_status
select * into ##msdagents from msdistribution_agents
select * into ##msdarticles from msarticles
select ag.name, ar.article, s.undelivcmdsindistdb, s.delivcmdsindistdb
from ##msdstatus s,
##msdagents ag,
##msdarticles ar
where s.agent_id = ag.id and s.article_id = ar.article_id
order by undelivcmdsindistdb desc
Running this periodically will give you a good idea of how much data is being processed at given intervals and try and estimate how much time it might take.
There are lots of things to consider though.
1. Is your replicated database being hammered with more updates continually. Maybe you can pause this or ask the users to reduce the load to allow the replication to catch up?
2. What's the current database size and autogrowth growth settings of the Distribution database and its Data and Log files? If growth increments settings are quite small them maybe increase the size to minimize overhead of automatic growth.
3. As stated look at your Distribution Profile settings you can tweak values such as increasing the commitbatchsize and commitbatchthreshold but do some reading up on these options and make sure you fully understand the consequences of doing so. Upping these will make cause bigger batches of changes to replicate through as bigger transactions but if one of these transactions were to fail then a much bigger batch will get rolled back
4. Look at your subscriber activity using sp_who2 etc. Are there many reads happening on these replicated tables causing intermittent blocks to the distribution agent
As stated already get as much info as you can before deciding to make any configuration changes and make sure you fully understand what's going on in the background to cause the latency
December 26, 2010 at 10:59 am
Thanks for your replies
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply