0

We have inherited a corrupted database 'DBName', with no good backup available to us. The corruption apparently happened some months ago.

We have tried a few thing:

DBCC CHECKDB(DBName); --Shows no errors

BACKUP DATABASE DBName TO DISK = 'D:\Backup\DBName.BAK' WITH CHECKSUM

This backup fails with detected error:

Msg 3043, Level 16, State 1, Line 3 BACKUP 'DBName' detected an error
on page (1:188137) in file 'D:\Data\DBName.mdf'. Msg 3013,
Level 16, State 1, Line 3 BACKUP DATABASE is terminating abnormally.

This puts a row into msdb.dbo.suspect_pages with event_type = 'Bad Checksum'

dbcc traceon (3604)
DBCC PAGE('DBName',1,188137,0) WITH TABLERESULTS
dbcc traceoff (3604)



ParentObject    Object  Field   VALUE
BUFFER: BUF @0x0000000E931A54C0 bpage   0x00000007D1BC6000
BUFFER: BUF @0x0000000E931A54C0 bhash   0x0000000000000000
BUFFER: BUF @0x0000000E931A54C0 bpageno (1:188137)
BUFFER: BUF @0x0000000E931A54C0 bdbid   64
BUFFER: BUF @0x0000000E931A54C0 breferences 0
BUFFER: BUF @0x0000000E931A54C0 bcputicks   0
BUFFER: BUF @0x0000000E931A54C0 bsampleCount    0
BUFFER: BUF @0x0000000E931A54C0 bUse1   42902
BUFFER: BUF @0x0000000E931A54C0 bstat   0x809
BUFFER: BUF @0x0000000E931A54C0 blog    0x215a215a
BUFFER: BUF @0x0000000E931A54C0 bnext   0x0000000000000000
PAGE HEADER:    Page @0x00000007D1BC6000    m_pageId    (43690:-1431655766)
PAGE HEADER:    Page @0x00000007D1BC6000    m_headerVersion 170
PAGE HEADER:    Page @0x00000007D1BC6000    m_type  170
PAGE HEADER:    Page @0x00000007D1BC6000    m_typeFlagBits  0xaa
PAGE HEADER:    Page @0x00000007D1BC6000    m_level 170
PAGE HEADER:    Page @0x00000007D1BC6000    m_flagBits  0xaaaa
PAGE HEADER:    Page @0x00000007D1BC6000    m_objId (AllocUnitId.idObj) -1431655766
PAGE HEADER:    Page @0x00000007D1BC6000    m_indexId (AllocUnitId.idInd)   43690
PAGE HEADER:    Page @0x00000007D1BC6000    Metadata: AllocUnitId   -6148914691236560896
PAGE HEADER:    Page @0x00000007D1BC6000    Metadata: PartitionId   0
PAGE HEADER:    Page @0x00000007D1BC6000    Metadata: IndexId   -1
PAGE HEADER:    Page @0x00000007D1BC6000    Metadata: ObjectId  0
PAGE HEADER:    Page @0x00000007D1BC6000    m_prevPage  (43690:-1431655766)
PAGE HEADER:    Page @0x00000007D1BC6000    m_nextPage  (43690:-1431655766)
PAGE HEADER:    Page @0x00000007D1BC6000    pminlen 43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_slotCnt   43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_freeCnt   43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_freeData  43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_reservedCnt   43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_lsn   (-1431655766:-1431655766:43690)
PAGE HEADER:    Page @0x00000007D1BC6000    m_xactReserved  43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_xdesId    (43690:-1431655766)
PAGE HEADER:    Page @0x00000007D1BC6000    m_ghostRecCnt   43690
PAGE HEADER:    Page @0x00000007D1BC6000    m_tornBits  -1431655766
PAGE HEADER:    Page @0x00000007D1BC6000    DB Frag ID  1
PAGE HEADER:    Allocation Status   GAM (1:2)   ALLOCATED
PAGE HEADER:    Allocation Status   SGAM (1:3)  NOT ALLOCATED
PAGE HEADER:    Allocation Status   PFS (1:186024)  0x40 ALLOCATED   0_PCT_FULL
PAGE HEADER:    Allocation Status   DIFF (1:6)  NOT CHANGED
PAGE HEADER:    Allocation Status   ML (1:7)    NOT MIN_LOGGED

It appears that the page has been deallocated, because object ID = 0

The following command does not resolve the error:

DBCC CHECKDB ('DBName', repair_allow_data_loss)

We would appreciate some help in resolving this problem since (as noted above) the backups are all failing.

  • It's just the one page that's bad? – Erik Darling Apr 17 '17 at 15:36
  • Sounds like a good time to open a Support Ticket. – John Eisbrener Apr 17 '17 at 16:29
  • I wouldn't trust any of the data on the page header. The BUF struct says one thing, the page header another, and the allocation bitmaps/bytemaps say it is allocated. If the complaint is the page is corrupt, well then I'd agree that something is off. If you can do dumpstyle 3 then you might be able to get more data... or look at the allocated pages to figure out what it goes to and work from there. – Sean Gallardy Apr 17 '17 at 16:31
  • What's your goal? Is this mission-critical data and you need to try to repair it? Or do you just need to be able to carve the corruption out of the database and move on with your life? – AMtwo Apr 17 '17 at 17:07
  • We dug deeper and determined that there are currently 35 pages with some sort of corruption, including Torn Page, 823 caused by an operating system CRC error, or 824 errors. Most pages have torn page and 823 , 824 errors. We are planning to open a Support Ticket. – RLF Apr 20 '17 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.