patternsqlMinor
Process attempted to unlock a resource it does not own
Viewed 0 times
attemptedprocessresourceowndoesunlocknot
Problem
SQL Server 2005 SP4 32-Bit
I have a DBCC CHECKDB job running nightly. Last night, soon after the job started, I got the errors below. The database is NOT in suspect mode, and CHECKDB comes back clean when I run it now. The database is fully accessible. Should I be concerned? I'd hate to go back to a backup at this point.
I have a DBCC CHECKDB job running nightly. Last night, soon after the job started, I got the errors below. The database is NOT in suspect mode, and CHECKDB comes back clean when I run it now. The database is fully accessible. Should I be concerned? I'd hate to go back to a backup at this point.
2013-04-02 02:10:55.53 spid56 Error: 1203, Severity: 20, State: 1.
2013-04-02 02:10:55.53 spid56 Process ID 56 attempted to unlock a resource it
does not own: PAGE: 34:1:388664. Retry the
transaction, because this error may be caused
by a timing condition. If the problem persists,
contact the database administrator.
2013-04-02 02:10:55.58 spid56 Error: 3314, Severity: 17, State: 3.
2013-04-02 02:10:55.58 spid56 During undoing of a logged operation in
database 'MY_DATABASE_NAME', an error occurred
at log record ID (1342973:12519:37). Typically,
the specific failure is logged previously as
an error in the Windows Event Log service.
Restore the database or file from a backup,
or repair the database.Solution
If this is just one time issue and CHECKDB run without any errors and you have good backups, do not bother to investigate it (unless you want to spend time and resources to what is not reproducible).
If you are able to reproduce the issue, then I would recommend you to
Profiler.
or powershell job to scan the error log (note that you can put a logic inside Powershell job to only scan from the last time it ended) to look for specific errors like Error: 1203 or Error: 3314 and then fire SQLDIAG to capture what was actually going on when the issue happened.
Let me know if you need any such script and I will be happy to share it.
If you are able to reproduce the issue, then I would recommend you to
- Replicate on a test environment and capture whats going using a
Profiler.
- As a proactive measure, you can probably have an agent job
or powershell job to scan the error log (note that you can put a logic inside Powershell job to only scan from the last time it ended) to look for specific errors like Error: 1203 or Error: 3314 and then fire SQLDIAG to capture what was actually going on when the issue happened.
Let me know if you need any such script and I will be happy to share it.
Context
StackExchange Database Administrators Q#39066, answer score: 2
Revisions (0)
No revisions yet.