Presentation is loading. Please wait.

Presentation is loading. Please wait.

Data Recovery and Fixing Database Corruptions

Similar presentations


Presentation on theme: "Data Recovery and Fixing Database Corruptions"— Presentation transcript:

1 Data Recovery and Fixing Database Corruptions
When changing a byte or a bit really makes a difference. Few steps on knowing what to change. Dan Andrei STEFAN Senior Database Administrator SCC Services Romania @dba-lounge Iasi

2 Database corruptions?!

3 Or possible data loss?

4 If a DBA did not yet encounter a database corruption issue, he/she is not lucky. Sooner or later, corruptions will strike!

5 A corruption is not necessary due to infrastructure issues.

6 Practice your knowledge on the “storage engine”, corruptions or data loss. Be prepared!

7 a bit of theory, internals, details
you in the next 15 minutes ?!

8 Physical Architecture

9 Page 0: Header Page 1: First PFS (Page Free Space)
File Anatomy Page 0: Header Page 1: First PFS (Page Free Space) Page 2: First GAM (Global Allocation Map) Page 3: First SGAM (Shared Global Allocation Map) Page 4: Unused Page 5: Unused Page 6: First DCM (Differential Change Map) (DIFF) Page 7: First BCM (Bulk Changed Map) (ML) Page 8: Data Page Page 9: Boot Page PFS: covers 8088 pages / approx. 64 MB GAM, SGAM, DCM, BCM: covers extents / approx. 4 GB

10 Anatomy of a SQL Server Page
page size is always 8192 bytes header is always 96 bytes 8096 bytes available for in-row-data 8060 bytes max row size

11 “Viewing” a page dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ]) filenum – file number for specified database pagenum – page number for specified database printopt - 0 - print just the page header 1 - page header plus per-row hex dumps and a dump of the page slot array (unless its a page that doesn't have one, like allocation bitmaps) 2 - page header plus whole page hex dump 3 - page header plus detailed per-row interpretation How to use DBCC PAGE: DBCC TRACEON(3604, -1) to enable messages to current connection (default to errorlog)

12 DBCC PAGE & page header PAGE HEADER: Page @0x00000001C56AA000
m_pageId = (3:33) m_headerVersion = m_type = 1 m_typeFlagBits = 0x m_level = m_flagBits = 0x204 m_objId (AllocUnitId.idObj) = m_indexId (AllocUnitId.idInd) = 256 Metadata: AllocUnitId = Metadata: PartitionId = Metadata: IndexId = 1 Metadata: ObjectId = m_prevPage = (3:32) m_nextPage = (3:34) pminlen = m_slotCnt = m_freeCnt = 21 m_freeData = m_reservedCnt = m_lsn = (30:79:89) m_xactReserved = m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = DB Frag ID = 1 Allocation Status GAM (3:2) = ALLOCATED SGAM (3:3) = NOT ALLOCATED PFS (3:1) = 0x40 ALLOCATED 0_PCT_FULL DIFF (3:6) = NOT CHANGED ML (3:7) = NOT MIN_LOGGED

13 The 96 bytes header (1) Byte 0 m_headerVersion (tinyint)
This is the page header version. Since version 7.0 this value has always been 1. Byte 1 m_type (tinyint) 1 – data page 2 – index page 3 – text mix page 4 – text tree page 7 – sort page 8 – GAM page 9 – SGAM page 10 – IAM page 11 – PFS page 13 – boot page 15 – file header page 16 – diff map page 17 – ML map page 18 – a page that’s be deallocated by DBCC CHECKDB during a repair operation. 19 – the temporary page that ALTER INDEX … REORGANIZE (or DBCC INDEXDEFRAG) uses when working on an index. 20 – a page pre-allocated as part of a bulk load operation, which will eventually be formatted as a ‘real’ page. Byte 2 m_typeFlagBits (tinyint) This is mostly unused. For data and index pages it will always be 4. For all other pages it will always be 0 – except PFS pages. If a PFS page has m_typeFlagBits of 1, that means that at least one of the pages in the PFS interval mapped by the PFS page has at least one ghost record. Byte 3 m_level (tinyint) This is the level that the page is part of in the b-tree. Levels are numbered from 0 at the leaf-level and increase to the single-page root level (i.e. the top of the b-tree). For all page types apart from index pages, the level is always 0. Bytes 4-5 m_flagBits (smallint) This stores a number of different flags that describe the page. For example,0x200 means that the page has a page checksum on it (as our example page does) and 0x100 means the page has torn-page protection on it. Some bits are no longer used in SQL Server 2005. Bytes 6-7 m_indexId (smallint) In SQL Server 2000, these identified the actual relational object and index IDs to which the page is allocated. In SQL Server 2005 this is no longer the case. The allocation metadata totally changed so these instead identify what’s called the allocation unit that the page belongs to. This post explains how an allocation unit ID is calculated. BIGINT = ; BIGINT; = CONVERT (BIGINT, CONVERT * (1 / POWER (2.0, 48)) ); /* right shift, reciprocal of left shift */ SELECT CONVERT (BIGINT, CONVERT - * CONVERT (BIGINT, POWER (2.0, 48)))) * (1 / POWER (2.0, 16)) /* right shift, reciprocal of left shift */) AS [m_objId] AS [m_indexId];

14 The 96 bytes header (2) Bytes 8-11 m_prevPage (int) (page number)
Pointer to the previous page at this level of the b-tree. The pages on the left-hand side of a b-tree level will have the m_prevPage pointer be NULL. In a heap, or if an index only has a single page, these pointers will both be NULL for all pages. This value stands for the page number (file number : page number). Reserved byte order. Bytes m_prevPage (smallint) (file number) This value stands for the file number of the previous page (file number : page number) . Reserved byte order. Bytes pminlen (smallint) This is the size of the fixed-length portion of the records on the page. Bytes m_nextPage (int) (page number) Pointer to the next page at this level of the b-tree. The pages on the right-hand side will have the m_nextPage be NULL. In a heap, or if an index only has a single page, these pointers will both be NULL for all pages Bytes m_nextPage (smallint) (file number) This value stands for the file number of the next page (file number : page number) Bytes m_slotCnt (smallint) This is the count of records on the page. Bytes m_objId (int) Bytes m_freeCnt (smallint) This is the number of bytes of free space in the page. Bytes m_freeData (smallint) This is the offset from the start of the page to the first byte after the end of the last record on the page. It doesn’t matter if there is free space nearer to the start of the page. Bytes m_pageId (int) (page number) Bytes m_pageId (smallint) (file number) Bytes m_reservedCnt (smallint) This is the number of bytes of free space that has been reserved by active transactions that freed up space on the page. It prevents the free space from being used up and allows the transactions to roll-back correctly. There’s a very complicated algorithm for changing this value. Bytes m_lsn (1) (int) The VLF sequence number. Bytes m_lsn (2) (int) The offset to the log block Bytes m_lsn (3) (smallint) The slot number inside the log block Bytes m_xactReserved (smallint) This is the amount that was last added to the m_reservedCnt field Bytes m_xdesId (2) (int) Bytes m_xdesId (1) (smallint) This is the internal ID of the most recent transaction that added to the m_reservedCnt field. Bytes m_ghostRecCnt (smallint) The is the count of ghost records on the page. Bytes m_tornBits (int) Contains torn bits value for checksum value. Reserved byte order. Bytes ?!

15 Online Resources Anatomy of a page (Paul Randal)
GAM, SGAM, PFS and other allocation maps (Paul Randal) anatomy-of-a-page/ gam-sgam-pfs-and-other-allocation-maps/ Anatomy of an extent (Paul Randal) Reverse Engineering SQL Server Page Headers (Mark S. Rasmussen) anatomy-of-an-extent/ What is an LSN: Log Sequence Number (Remus Rusanu) Anatomy of a record (Paul Randal) number/ anatomy-of-a-record/ IAM pages, IAM chains, and allocation units (Paul Randal) pages-iam-chains-and-allocation-units/

16 Moment of truth

17 The Demo a 10 weeks challenge 100% data recovery scenarios During the demo: How? fix page header use HxD hex editor  fix page linkage fix page checksum DBCC WRITEPAGE fix record header “undo” a truncate table

18 Thanks! dbaTDPMon - Troubleshoot Database Performance and Monitoring
out on , under GNU GPL v3 work with SQL Server versions from 2000 onwards custom database maintenance plan (consistency checks; backups; indexes, heaps & statistics maintenance, etc.) daily health checks fully customizable


Download ppt "Data Recovery and Fixing Database Corruptions"

Similar presentations


Ads by Google