设为首页 收藏本站
查看: 670|回复: 0

[经验分享] SQL Server 简单模式下,误删除堆表记录如何恢复(绕过页眉校验)

[复制链接]

尚未签到

发表于 2015-6-27 08:15:59 | 显示全部楼层 |阅读模式
    首先,我需要强调下,这篇主旨是揭示堆表的删除记录找回的原理,我所考虑的方面并不适用于每个人的每种情况,望大家见谅~
  很多朋友认为数据库在简单模式下,堆表误删除一条记录,是无法找回的,因为没有日志记录。其实不然,某种意义上是可以找回的,因为堆表在删除记录时,没有回收空页面的前提下,只更改了行偏移,实际数据没有被物理删除,所以利用这点,测试了下恢复数据,果然成功了,但是还有点问题没有研究出结果:如果不关闭页面校验,除了更改偏移量,删除数据时还需要更改页眉,这点还没时间去琢磨,所以恢复数据时还要能推断出页眉的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.查看测试数据,显示正常。
DSC0000.png
  3.DBCC IND命令来找到数据页id,找到数据页id:219,这个数据页存放了test_del的数据
DSC0001.png
  使用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
DSC0002.png
  说明a=3 b=row3的记录已经被删除。
  5.再次查看数据页的行偏移



dbcc page(repl_test,1,219,1)
go
  Row - 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)
go
  DATA:
  ..
  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页面的其实位置):
   DSC0003.png
  
  果然第3行的行偏移量为00 00,那么我将其改回8A 00后保存,并将数据库设置为online
   DSC0004.png
  
  记录被成功恢复。
  如果不进行
  alter database repl_test set page_verify none
go
  则会读取表时发生页面校验错误。
  那么如何找回记录又可以DBCC checkdb安全通过呢?
  1.笨方法找回记录后将原表删除,损坏页面会被丢失,重新表,导入数据即可。
  2.修改页眉校验,可惜小弟不才,还没研究页眉结构对应的物理16进制关系。只靠修改前的页眉截图,修改后按照截图还原页眉,这里无法向大家说明白修改的地方。希望有经验或者有兴趣的朋友可以和我分享下,谢谢~
  如何释放堆中的空闲页面?
  若要删除堆中的行并释放页,我们可以使用下列方法之一。



    • 在 DELETE 语句中指定 TABLOCK 提示。使用 TABLOCK 提示会导致删除操作获取表的共享锁,而不是行锁或页锁。这将允许释放页。
    • 如果要从表中删除所有行,请使用 TRUNCATE TABLE。
    • 删除行之前,请对堆创建聚集索引。删除行之后,可以删除聚集索引。与先前的方法相比,此方法非常耗时,并且使用更多的临时资源。

  如果释放空闲页面空间,很有可能记录就无法再恢复了,同时说明数据库完整模式+日志备份是多么的重要,可以省去很多发杂的步骤
  文笔不好,如果哪里看的模糊请留言。
  

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-80862-1-1.html 上篇帖子: SQL Server 默认跟踪(Default Trace) 下篇帖子: SQL Server 2012 Express LocalDB
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表