SQL Server簡略形式下誤刪除堆表記載恢復辦法(繞過頁眉校驗)。本站提示廣大學習愛好者：（SQL Server簡略形式下誤刪除堆表記載恢復辦法(繞過頁眉校驗)）文章只能為提供參考，不一定能成為您想要的結果。以下是SQL Server簡略形式下誤刪除堆表記載恢復辦法(繞過頁眉校驗)正文
起首，我須要強調下，這篇宗旨是提醒堆表的刪除記載找回的道理，我所斟酌的方面其實不實用於每一個人的每種情形，望年夜家見諒~
許多同伙以為數據庫在簡略形式下，堆表誤刪除一筆記錄，是沒法找回的，由於沒有日記記載。其實否則，某種意義上是可以找回的，由於堆表在刪除記載時，只更改了行偏移，現實數據沒有被物理刪除，所以應用這點，測試了下恢單數據，果真勝利了，然則還有點成績沒有研討出成果：假如不封閉頁面校驗，除更改偏移量，刪除數據時還須要更改頁眉，這點還沒時光去揣摩，所以恢單數據時還要能揣摸出頁眉的16進制對應關系，有興致的同伙可以分享下經歷給我。這裡為了消除頁眉的校驗毛病，封閉後測試
空話不多說，測試的demo以下：
測試情況：
SQL Server 2008 R2
數據庫：repl_test 簡略形式
測試表：test_del
測試步調
1.創立測試表test_del，並拔出測試數據。
create table test_del( a int identity,b char(10))
go
insert into test_del select 'row 1';
insert into test_del select 'row 2';
insert into test_del select 'row 3';
insert into test_del select 'row 4';
insert into test_del select 'row 5';
go
2.檢查測試數據，顯示正常。
3.DBCC IND敕令來找到數據頁id，找到數據頁id：219，這個數據頁寄存了test_del的數據
應用dbcc page檢查數據頁的內容和行偏移量
dbcc page(repl_test,1,219,1)
go輸入成果為：
DATA:
Slot 0, Offset 0x60, Length 21, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 21
Memory Dump @0x00000000120CC060
0000000000000000: 10001200 01000000 726f7720 31202020 †........row 1
0000000000000010: 20200200 00†††††††††††††††††††††††††† ...
Slot 1, Offset 0x75, Length 21, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 21
Memory Dump @0x00000000120CC075
0000000000000000: 10001200 02000000 726f7720 32202020 †........row 2
0000000000000010: 20200200 00†††††††††††††††††††††††††† ...
Slot 2, Offset 0x8a, Length 21, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 21
Memory Dump @0x00000000120CC08A
0000000000000000: 10001200 03000000 726f7720 33202020 †........row 3
0000000000000010: 20200200 00†††††††††††††††††††††††††† ...
Slot 3, Offset 0x9f, Length 21, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 21
Memory Dump @0x00000000120CC09F
0000000000000000: 10001200 04000000 726f7720 34202020 †........row 4
0000000000000010: 20200200 00†††††††††††††††††††††††††† ...
Slot 4, Offset 0xb4, Length 21, DumpStyle BYTE
Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 21
Memory Dump @0x00000000120CC0B4
0000000000000000: 10001200 05000000 726f7720 35202020 †........row 5
0000000000000010: 20200200 00†††††††††††††††††††††††††† ...
OFFSET TABLE:
Row - Offset
4 (0x4) - 180 (0xb4)
3 (0x3) - 159 (0x9f)
2 (0x2) - 138 (0x8a)
1 (0x1) - 117 (0x75)
0 (0x0) - 96 (0x60)
個中行偏移量第一行動96 (0x60)，現實記載為row 1，row 2： (0x75)，row 3： (0x8a)，row 4：(0x9f)，row 5： (0xb4)
4. 刪除第三行數據 a = 3，b = row 3的記載
delete test_del where a = 3
go
解釋a=3 b=row3的記載曾經被刪除。
5.再次檢查數據頁的行偏移
dbcc page(repl_test,1,219,1)
goRow - Offset
4 (0x4) - 180 (0xb4)
3 (0x3) - 159 (0x9f)
2 (0x2) - 0 (0x0)
1 (0x1) - 117 (0x75)
0 (0x0) - 96 (0x60)
發明第3行的行偏移量被更改成了0，持續履行
dbcc page(repl_test,1,219,2)
goDATA:
..
00000000120CC060: 10001200 01000000 726f7720 31202020 †........row 1
00000000120CC070: 20200200 00100012 00020000 00726f77 † ...........row
00000000120CC080: 20322020 20202002 00001000 12000300 † 2 .........
00000000120CC090: 0000726f 77203320 20202020 02000010 †..row 3 ....
00000000120CC0A0: 00120004 00000072 6f772034 20202020 †.......row 4
00000000120CC0B0: 20020000 10001200 05000000 726f7720 † ...........row
00000000120CC0C0: 35202020 20200200 00000021 21212121
發明row3的記載還存在數據頁中！
那末料想，能否將第三行的行偏移量0x0修正回本來的0x8a便可以恢復記載了？
應用winHex對象，翻開mdf文件，由於是219頁面，8*220 = 1802240字節，所以219的行偏移量應當在1802239處，剩下的任務就很簡略了
6.封閉數據庫的數據頁I/O掩護機制，即設置page_verify數據庫選項為none，並將repl_test 數據庫設置為脫機，應用winhex找到repl_test.mdf文件的1802240開頭處16進制碼
alter database repl_test set page_verify none
go
use master
alter database repl_test set offline
go
把repl_test數據庫設置為脫機，用winhex對象找到219頁面的開頭處（220頁面的其實地位）：
果真第3行的行偏移量為00 00，那末我將其改回8A 00後保留，並將數據庫設置為online
記載被勝利恢復。
假如不停止
alter database repl_test set page_verify none
go
則會讀取表時產生頁面校驗毛病。
那末若何找回記載又可以DBCC checkdb平安經由過程呢？
1.笨辦法找回記載後將原表刪除，破壞頁面會被喪失，從新表，導入數據便可。
2.修正頁眉校驗，惋惜小弟不才，還沒研討頁眉構造對應的物理16進制關系。只靠修正前的頁眉截圖，修正後依照截圖復原頁眉，這裡沒法向年夜家解釋白修正的處所。願望有經歷或許有興致的同伙可以和我分享下，感謝~
若何釋放堆中的余暇頁面？
若要刪除堆中的行並釋放頁，我們可使用以下辦法之一。
•在 DELETE 語句中指定 TABLOCK 提醒。應用 TABLOCK 提醒會招致刪除操作獲得表的同享鎖，而不是行鎖或頁鎖。這將許可釋放頁。
•假如要從表中刪除一切行，請應用 TRUNCATE TABLE。
•刪除行之前，請對堆創立集合索引。刪除行以後，可以刪除集合索引。與先前的辦法比擬，此辦法異常耗時，而且應用更多的暫時資本。
假如釋放余暇頁面空間，很有能夠記載就沒法再恢復了，同時解釋數據庫完全形式+日記備份是何等的主要，可以省去許多發雜的步調
文筆欠好，假如哪裡看的隱約請留言。
