Prevent lock timeout thrown by sp_msforeachdb #3180
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the current behavior?
When setting up sp_BlitzFirst in an agent job on a few dozen SQL 2019 with AGs, I was seeing very random periodic job failures caused by lock timeouts. I traced it down to the section where you SET LOCK_TIMEOUT 0 and then look for modified statistics.
You catch the lock timeout error inside the statistics section, but it turns out that sp_msforeachdb is also susceptible to exiting with a lock timeout. By wrapping that in a further try/catch block, I'm able to prevent the job step from failing unnecessarily.
This is nicer than having the job fail randomly, or having to set the job step to exit with success on failure.
If the current behavior is a bug, please provide the steps to reproduce.
I couldn't force the behaviour to happen, even wrapping sp_msforeachdb in a GO 10000 loop and failing over servers everywhere. It's something else. For reference on ~20 servers and running every 15 minutes, one execution would fail every few hours.
What is the expected behavior?
Not throwing that error.
Which versions of SQL Server and which OS are affected by this issue? Did this work in previous versions of our procedures?
SQL 2019 Windows 2016. Unsure if it worked previously.