HiveBrain v1.2.0
Get Started
← Back to all entries
patternsqlMinor

Process attempted to unlock a resource it does not own

Submitted by: @import:stackexchange-dba··
0
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.

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

  • 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.