October 20, 2009 at 2:09 pm
^^^Thanks for the script.
FYI- I did more research and found that it appears the subscriptions will be marked inactive if nothing is replicated in 48 hours. To resolve this, I have an update script running every 12 hours that updates a users lock status to unlocked or something similar. Just update something that's replicated and so far I have not had any subscriptions marked as inactive for a few weeks now. Hope this helps.
July 26, 2010 at 11:34 am
Tanks for this script 🙂
November 24, 2010 at 3:47 am
Threre are many reasons when a subscriptions becomes inactive. I too got into similar situation. Microsoft says
"If a subscription is not synchronized within the maximum distribution retention period (default of 72 hours) and there are changes in the distribution database that have not been delivered to the Subscriber, the subscription will be marked deactivated by the Distribution clean up job that runs on the Distributor. The subscription must be reinitialized."
This means that if you have some changes in the distributor that has to be propagated to the Subscriber and if that retention period exceeds the maximum retention period 72 hours by default, then the job Distribution clean up will make your subscriptions inactive. You can configure this retention period through right click Replication -> Configure Distributor -> Retention Period
October 11, 2011 at 11:49 am
Whenever there is an error as mentioned above then, you can try to update the status column in the MSsubscriptions table in the distribution database. The status column for the expired subscription indicated a value of 0 meaning inactive. The value of 2 in the status column means Active.
Try the following steps:
1. Select * from MSsubscriptions to locate the expired subscription.
2. Use the query below to reset the status in MSsubscriptions table. Fill in the values for the publisher_id, publisher_db, publication_id, subscriber_id and subscriber_db in the query below with the values from the expired subscription in the MSsubscriptions table.
update distribution..MSsubscriptions set status=2 where publisher_id='x' andpublisher_db='x' and publication_id='x' and subscriber_id='x' and subscriber_db='x'
Status of the subscription:
0 = Inactive
1 = Subscribed
2 = Active
This steps wil give you the solution to above problem, i fixed it through the following steps only
Avinash
June 15, 2012 at 12:16 pm
If you don't watch the errors (or the alert fails in our case) for a few days then the subscription will be marked inactive.
Issues with the login account used will prevent a subscription from being active. It will simply fail to log on.
Also, if it has been inactive for a while then the subscriber will be out of sync - as in the case with updatable transactional subscriptions.
Finding the cause of the inactivity is best viewed from the Job history, not replication monitor (which says it is inactive, not why). Find the job, check the history out to identify the cause.
Resolution steps...
1. Stop the job. (or all replication jobs for the database (including from other publications eg 2 way upd...trans...repln))
2. Apply fix: Change the subscription properties to use a different account (if this was the cause).
3. Apply workaround: Use the preferred update script or sp mentioned before to set the status = 2 (applies to each articles in the publication) in MSsubscription
4. Restart the job. Watch the Job Activity as well to make sure it is running OK. If not, find the cause, repeat steps.
If you are still getting a failure caused by undistributed transactions failing to get through then you may have to clear the MSrepln_commands and manually sync changes using RedGate SQLCompare before restarting the job.
Simply reinitialising a subscription isn't always practical when the publication database is over 20Gb, the subscriber has a crap connection on the other side of the world and has only a small maintenance window to get the job done.
Good luck.
December 27, 2012 at 10:14 am
This sets your article back to active. :w00t:
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply