January 23, 2013 at 4:14 am
Hi Experts,
Got below messages when ran checkdb
Executing the query "DBCC CHECKDB WITH NO_INFOMSGS
" failed with the following error: "Process ID 75 attempted to unlock a resource it does not own: PAGE: Retry the transaction, because this error may be caused by a timing condition. If the problem persists, contact the database administrator.
During undoing of a logged operation in database '', an error occurred at log record ID . 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.
A database snapshot cannot be created because it failed to start.
The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
The database could not be exclusively locked to perform the operation.
January 23, 2013 at 4:45 am
Hi ,
Please check the link below ... hope this helps
Cheer Satish 🙂
January 23, 2013 at 5:05 am
Thanks Satish for the reply.
I have already gone through that and wont help in this situation.
We have SQL Server 2005 SP4
January 23, 2013 at 5:40 am
The database couldn't be X-locked to perform the snap, something was happening with the database which prevented the first step of CheckDB to complete.
It needs to create a snapshot of the db to check for consistancy errors, if it cant do this it fails.
January 23, 2013 at 5:52 am
Thanks Anthony,
Any solution?? Anyway to find what this causes??
January 23, 2013 at 5:55 am
Could check the default trace see what else was happening at the time, or if you have any custom auditing try and look through that to see what was going on.
January 23, 2013 at 6:09 am
If you can't take an exclusive lock on the db, try kicking off users out of this db (make sure by running sp_who2) nobody is using that db, place it in single user mode, and then run consistency checks on that. Thoroughly check the output of dbcc for any errors noticed. Once, the checks have been completed, revert it to it's original state. If possible inform the users before carrying out dbcc checks, becoz of this you won't likely need to take the db into single user mode, as there won't be any live connections to the db.
Regards,
Faisal
January 23, 2013 at 9:02 am
Hi Faizal,
This is production box
January 23, 2013 at 11:28 am
You can create a snapshot of the DB and run CHECKDB against that.
January 24, 2013 at 8:21 am
Hi Ratheesh,
If that's a prod box then you have 2 options left, either restore a copy of that db to a test environment, and run dbcc checks on that. In case if you don't have a test environment setup for this (which I think shouldn't be the case) then you need to ask some downtime from the business owners of that db coz this will be a resource intensive operation, and you don't want anything coming your way of testing.
There is an alternate option as well, wherein you can use sql virtual restore from red gate, pickup the backup of the database, restore it as a virtual db, and run consistency checks on them. It will not only save on the space, but less utilization of resources as well.Try testing it with a trial version, it would definitely do wonders for you.
The product actually is beneficial for VLDB's, as checks would be quite stressful, and if you're down with drive space...for e.g: if you have 8 TB of database (mostly in a datawarehouse scenario), and you can't physically restore the db, then you should opt for this product, it will do the stuff for you.
I hope this helps!!!
Regards,
Faisal
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply