Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

SH Latch Expand / Collapse
Author
Message
Posted Friday, August 16, 2013 8:55 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 29, 2014 9:40 AM
Points: 201, Visits: 811
Hi,

After a disk failure we had a corruption on a live database, we did have backups and was able to perform a restore to bring everything back online so restores not a problem, however a question over the type of corruption and is purely educational.

First CHECKDB results: Msg 0, Level 11, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.

At this point I know this is probably going to be an unrecoverable corruption but will try, next is to run DBCC CHECKTABLE (only 5 tables in this DB) which runs ok except on one which returns:

Msg 8966, Level 16, State 2, Line 1
Unable to read and latch page (1:79912) with latch type SH. Latch failed.
Msg 8966, Level 16, State 2, Line 1
Unable to read and latch page (1:79913) with latch type SH. Latch failed.
Msg 8966, Level 16, State 2, Line 1
Unable to read and latch page (1:79914) with latch type SH. Latch failed.
Msg 8966, Level 16, State 2, Line 1
Unable to read and latch page (1:79915) with latch type SH. Latch failed.

So looks like corruption across just 4 pages, after running DBCC PAGE I was able to find the range of data (about 121 rows) which it couldn’t read. Now I have tried deleting those rows but get a timeout error as it can’t create a latch on the pages, can’t update or do any modifications.

I do have those pages in the restored database but because the database is in simple mode, page restore isn’t an option and DBCC repair_allow_data_loss doesn’t remove the corruption either.

Any other idea on how you could get the delete not to use a SH lock or bypass it? Like I said this is only educational, the database was restored from backup awhile ago.
Post #1485247
Posted Thursday, September 26, 2013 6:52 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 1:30 AM
Points: 3,084, Visits: 3,195

I do have those pages in the restored database but because the database is in simple mode, page restore isn’t an option and DBCC repair_allow_data_loss doesn’t remove the corruption either.


The database should be in full or bulk_logged recovery model in order to perform a page restore.
See Requirements for page restoring on this link http://technet.microsoft.com/en-us/library/ms175168(v=sql.105).aspx and this link too: http://technet.microsoft.com/en-us/library/ms175168.aspx

Regards,
IgorMi




Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Post #1498802
Posted Thursday, September 26, 2013 7:12 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 2:35 PM
Points: 40,438, Visits: 36,895
You can't bypass latches, they are essential for physical protection of the page. Besides, the latch error is a symptom of the corruption, not a cause. If you could bypass the latch (which you can't), you'd get other errors.

Copy the good data out and truncate the table. Truncating doesn't need to read the pages, therefore doesn't encounter the corrupt pages.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1498819
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse