Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Snapshot agent and deadlocking Expand / Collapse
Author
Message
Posted Tuesday, March 15, 2005 8:20 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, December 10, 2014 1:06 PM
Points: 9, Visits: 328

I am trying transactional replication on a single database between server A and server B, both of which are running Sql Server 2000.  Server B is configured as the distributor and subscriber and is pulling a subscription from Server A, the publisher.  On Server A in Publication Properties on the Snapshot tab under the heading “Concurrent access during snapshot generation” I have checked “Do not lock tables during snapshot generation.”  After I start the snapshot agent and it has run for a while, it indicates that it deadlocked with another process and was chosen as the victim.  It then retries, runs again for a while, and deadlocks again.  The time to deadlock varies.  Eventually, the agent stops, reporting failure.  I have looked at the locking activity on this one database in Sql Profiler while the snapshot agent is running.  It shows that the snapshot agent is acquiring and releasing locks on tables despite my having turned locking off.  Has anyone encountered this problem and, if so, do you have any thoughts about how to fix it?  Thanks.

 

Craig

 




Post #167779
Posted Tuesday, March 15, 2005 9:57 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 10, 2011 11:04 AM
Points: 124, Visits: 10
I have received locking errors while creating snapshots for merge replication.  I don't know if there's a good way around it, but as a rule of thumb, I generally try to stay away from big processes like this during production hours.  Good luck.


Post #167820
Posted Tuesday, March 15, 2005 10:25 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Wednesday, December 10, 2014 1:06 PM
Points: 9, Visits: 328

Unfortunately, this database sees heavy activity most of the time so there's no really good time to run the snapshot agent.  Thanks for your reply.

Craig




Post #167829
Posted Tuesday, March 15, 2005 10:28 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, May 10, 2011 11:04 AM
Points: 124, Visits: 10
well, for the initial snapshot then, I'd recommend running it at a time when there's going to be very little activity... perhaps the middle of the night.  I'm not sure how transactional replication really affects the tables, but merge actually has to modify tables.  Good luck with getting this to work.


Post #167830
Posted Wednesday, March 16, 2005 2:32 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, November 11, 2014 2:59 PM
Points: 197, Visits: 154

By having concurrent snapshot processing you are being deadlocked as you cannot obtain the exclusive lock. Maybe to improve performance you can increase maxbcpthreads and do not use concurrent. Thsi will cause more grief from a locking/blocking perspective but the snapshot should generate - run it during your lowest activity period.

Another suggestion would be to create a number of smaller publications that you can snapshot independantly.




Post #167966
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse