The Curious Case of… random failing log shipping restores

(The Curious Case of… used to be part of our bi-weekly newsletter but we decided to make it a regular blog post instead so it can sometimes be more frequent. It covers something interesting one of us encountered when working with a client, doing some testing, or were asked in a random question from the community.)

A quick one this time… Jonathan was working with a client recently who was experiencing weird, random failures on a log shipping secondary server. The log backups were set to restore and put the database in STANDBY mode and the option ‘Disconnect users in the database when restoring backups’ was enabled. Every so often the restore process was failing with the error ‘Exclusive access could not be obtained’ – how could that happen?

Jonathan was able to reproduce the failures in our test lab using a constant, high rate of connection requests to the database. It turns out that the log shipping executable sets the database to SINGLE_USER mode to kick out any connections and then starts the restore, but as two separate batches. This means there’s a tiny race condition where another connection can be made to the database which will prevent the restore from being able to run, so with a high rate of connection requests, it’s only a matter of time until the race condition is met.

It’s unclear whether any changes will be made to the way log shipping works, but in the meantime, this is a scenario to be aware of.

2 thoughts on “The Curious Case of… random failing log shipping restores

  1. Ha! Nice one. Kinda funny how the developers of this feature didn’t see it coming, single user can always be tricky.

Leave a Reply

Your email address will not be published. Required fields are marked *

Other articles

Imagine feeling confident enough to handle whatever your database throws at you.

With training and consulting from SQLskills, you’ll be able to solve big problems, elevate your team’s capacity, and take control of your data career.