解剖SQLSERVER 第十七篇 使用 OrcaMDF Corruptor 故意损坏数据库(译)

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
简介: 原文:解剖SQLSERVER 第十七篇 使用 OrcaMDF Corruptor 故意损坏数据库(译)解剖SQLSERVER 第十七篇 使用 OrcaMDF Corruptor 故意损坏数据库(译) http://improve.dk/corrupting-databases-purpose-using-orcamdf-corruptor/ 有时候你必须先作恶,后行善。
原文: 解剖SQLSERVER 第十七篇 使用 OrcaMDF Corruptor 故意损坏数据库(译)

解剖SQLSERVER 第十七篇 使用 OrcaMDF Corruptor 故意损坏数据库(译)

http://improve.dk/corrupting-databases-purpose-using-orcamdf-corruptor/

有时候你必须先作恶,后行善。情况就是 当你想磨练你的数据库修复技能

我现在添加了一个Corruptor 类到OrcaMDF里面 去测试新的RawDatabase 的功能。Corruptor 就跟他的名字一样--他会故意损坏数据库文件


Corruptor 本身是比较简单的。Corruptor 会随机选择一些页面并且简单的使用0来完全复写页面。
根据页面的类型,这可能会造成致命伤害

我不想多说什么了,不过万一。。。请不要在你的生产库上运行。这会损坏你的数据。

 

例子
有两个 Corruptor.CorruptFile重载方法,他们都返回integers 的枚举值 -- 一系列的pageid 列表并且被复写0的

下面的代码会损坏5%的页面在AdventureWorks2008R2LT.mdf 文件里面,然后他会输出每个被损坏了的页面ID 。
你可以定义损坏页面的百分比 只需要改变第二个参数

var corruptedPageIDs = Corruptor.CorruptFile(@"C:\AdventureWorks2008R2LT.mdf", 0.05);
Console.WriteLine(string.Join(", ", corruptedPageIDs));
606, 516, 603, 521, 613, 621, 118, 47, 173, 579,
323, 217, 358, 515, 615, 271, 176, 596, 417, 379,
269, 409, 558, 103, 8, 636, 200, 361, 60, 486,
366, 99, 87

为了使损坏更厉害,你也可以使用第二个重载方法,他允许你定义一个确切的损坏页面的数目,在一个确定的pageid范围内。
下面的代码会确切的损坏pageid在0到49这个范围内的10个页面,因此会损坏大部分的元数据,大家知道系统表的数据基本都存储在数据库最靠前的页面上

var corruptedPageIDs = Corruptor.CorruptFile(@"C:\AdventureWorks2008R2LT.mdf", 10, 0, 49);
Console.WriteLine(string.Join(", ", corruptedPageIDs));
16, 4, 0, 32, 15, 14, 30, 2, 49, 9

 

在上面的情况我非常不幸的看到 下面这些页面都被填充了0 包括:

file header page,page 2 is the first GAM page,page 9 is the boot page ,page 16 allocation unit metadata。

这样的损坏程度,即使使用DBCC CHECKDB也没办法修复,留下给你的选择只有从备份中还原

 

或者,你可以尝试一下使用OrcaMDF RawDatabase去恢复尽可能多的数据,先到这里了,我以后还会继续介绍。

 

DBCC TRACEON(3604,-1)
GO

DBCC PAGE([sss],1,16,3)
GO

DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。

PAGE: (1:16)


BUFFER:


BUF @0x0000000080FDEB80

bpage = 0x0000000080A74000 bhash = 0x0000000000000000 bpageno = (1:16)
bdbid = 8 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 19980 bstat = 0xc00009
blog = 0x32159 bnext = 0x0000000000000000

PAGE HEADER:


Page @0x0000000080A74000

m_pageId = (1:16) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x4 m_level = 0 m_flagBits = 0x200
m_objId (AllocUnitId.idObj) = 7 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 458752
Metadata: PartitionId = 458752 Metadata: IndexId = 1 Metadata: ObjectId = 7
m_prevPage = (0:0) m_nextPage = (1:130) pminlen = 73
m_slotCnt = 49 m_freeCnt = 4225 m_freeData = 4331
m_reservedCnt = 0 m_lsn = (1037:459:3) m_xactReserved = 0
m_xdesId = (0:455) m_ghostRecCnt = 0 m_tornBits = -563242027

Allocation Status

GAM (1:2) = ALLOCATED SGAM (1:3) = NOT ALLOCATED 
PFS (1:1) = 0x60 MIXED_EXT ALLOCATED 0_PCT_FULL DIFF (1:6) = CHANGED
ML (1:7) = NOT MIN_LOGGED

Slot 0 Offset 0x60 Length 77

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 77

Memory Dump @0x000000000DC7A060

0000000000000000: 10004900 00000300 00000000 01000003 †..I............. 
0000000000000010: 00000000 00000000 0001001f 00000001 †................ 
0000000000000020: 00570000 00010056 00000001 000b0000 †.W.....V........ 
0000000000000030: 00000000 00090000 00000000 00110000 †.....    .......... 
0000000000000040: 00000000 00010000 000c0000 00††††††††.............

Slot 0 Column 1 Offset 0x4 Length 8 Length (physical) 8

auid = 196608

Slot 0 Column 2 Offset 0xc Length 1 Length (physical) 1

type = 1

Slot 0 Column 3 Offset 0xd Length 8 Length (physical) 8

ownerid = 196608

Slot 0 Column 4 Offset 0x15 Length 4 Length (physical) 4

status = 0

Slot 0 Column 5 Offset 0x19 Length 2 Length (physical) 2

fgid = 1

pgfirst = [Binary data] Slot 0 Column 6 Offset 0x1b Length 6 Length (physical) 6

pgfirst = 0x1f0000000100

pgroot = [Binary data] Slot 0 Column 7 Offset 0x21 Length 6 Length (physical) 6

pgroot = 0x570000000100

pgfirstiam = [Binary data] Slot 0 Column 8 Offset 0x27 Length 6 Length (physical) 6

pgfirstiam = 0x560000000100

Slot 0 Column 9 Offset 0x2d Length 8 Length (physical) 8

pcused = 11

Slot 0 Column 10 Offset 0x35 Length 8 Length (physical) 8

pcdata = 9

Slot 0 Column 11 Offset 0x3d Length 8 Length (physical) 8

pcreserved = 17

Slot 0 Column 12 Offset 0x45 Length 4 Length (physical) 4

dbfragid = 1

Slot 0 Offset 0x0 Length 0 Length (physical) 0

KeyHashValue = (016862d84319)

 

SELECT COUNT(*) FROM sys.[allocation_units]
--131
SELECT * FROM sys.[allocation_units]
SELECT * FROM sys.[system_internals_allocation_units]

 

存储在数据库1:16页面上(是[sys.system_internals_allocation_units]系统表)《深入解析sql2008》

 

第十七篇完

相关实践学习
使用SQL语句管理索引
本次实验主要介绍如何在RDS-SQLServer数据库中,使用SQL语句管理索引。
SQL Server on Linux入门教程
SQL Server数据库一直只提供Windows下的版本。2016年微软宣布推出可运行在Linux系统下的SQL Server数据库,该版本目前还是早期预览版本。本课程主要介绍SQLServer On Linux的基本知识。 相关的阿里云产品:云数据库RDS SQL Server版 RDS SQL Server不仅拥有高可用架构和任意时间点的数据恢复功能,强力支撑各种企业应用,同时也包含了微软的License费用,减少额外支出。 了解产品详情: https://www.aliyun.com/product/rds/sqlserver
目录
相关文章
|
22天前
|
SQL 数据库
数据库数据恢复—SQL Server报错“错误 823”的数据恢复案例
SQL Server数据库附加数据库过程中比较常见的报错是“错误 823”,附加数据库失败。 如果数据库有备份则只需还原备份即可。但是如果没有备份,备份时间太久,或者其他原因导致备份不可用,那么就需要通过专业手段对数据库进行数据恢复。
|
2月前
|
数据库 Windows
SqlServer数据恢复—SqlServer数据库所在分区损坏的数据恢复案例
一块硬盘上存放的SqlServer数据库,windows server操作系统+NTFS文件系统。由于误操作导致分区损坏,需要恢复硬盘里的SqlServer数据库数据。
|
3月前
|
关系型数据库 MySQL 数据库
数据库数据恢复—MYSQL数据库文件损坏的数据恢复案例
mysql数据库文件ibdata1、MYI、MYD损坏。 故障表现:1、数据库无法进行查询等操作;2、使用mysqlcheck和myisamchk无法修复数据库。
|
4月前
|
SQL 存储 Linux
从配置源到数据库初始化一步步教你在CentOS 7.9上安装SQL Server 2019
【11月更文挑战第16天】本文介绍了在 CentOS 7.9 上安装 SQL Server 2019 的详细步骤,包括配置系统源、安装 SQL Server 2019 软件包以及数据库初始化,确保 SQL Server 正常运行。
217 4
|
4月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
4月前
|
SQL 存储 Linux
从配置源到数据库初始化一步步教你在CentOS 7.9上安装SQL Server 2019
【11月更文挑战第8天】本文介绍了在 CentOS 7.9 上安装 SQL Server 2019 的详细步骤,包括系统准备、配置安装源、安装 SQL Server 软件包、运行安装程序、初始化数据库以及配置远程连接。通过这些步骤,您可以顺利地在 CentOS 系统上部署和使用 SQL Server 2019。
208 1
|
6月前
|
SQL 数据库
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
SQL Server附加数据库出现错误823,附加数据库失败。数据库没有备份,无法通过备份恢复数据库。 SQL Server数据库出现823错误的可能原因有:数据库物理页面损坏、数据库物理页面校验值损坏导致无法识别该页面、断电或者文件系统问题导致页面丢失。
153 12
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
|
4月前
|
SQL 存储 Linux
从配置源到数据库初始化一步步教你在CentOS 7.9上安装SQL Server 2019
【11月更文挑战第7天】本文介绍了在 CentOS 7.9 上安装 SQL Server 2019 的详细步骤,包括系统要求检查与准备、配置安装源、安装 SQL Server 2019、配置 SQL Server 以及数据库初始化(可选)。通过这些步骤,你可以成功安装并初步配置 SQL Server 2019,进行简单的数据库操作。
136 1
|
5月前
|
存储 数据挖掘 数据库
数据库数据恢复—SQLserver数据库ndf文件大小变为0KB的数据恢复案例
一个运行在存储上的SQLServer数据库,有1000多个文件,大小几十TB。数据库每10天生成一个NDF文件,每个NDF几百GB大小。数据库包含两个LDF文件。 存储损坏,数据库不可用。管理员试图恢复数据库,发现有数个ndf文件大小变为0KB。 虽然NDF文件大小变为0KB,但是NDF文件在磁盘上还可能存在。可以尝试通过扫描&拼接数据库碎片来恢复NDF文件,然后修复数据库。
|
6月前
|
SQL 关系型数据库 MySQL
创建包含MySQL和SQLServer数据库所有字段类型的表的方法
创建一个既包含MySQL又包含SQL Server所有字段类型的表是一个复杂的任务,需要仔细地比较和转换数据类型。通过上述方法,可以在两个数据库系统之间建立起相互兼容的数据结构,为数据迁移和同步提供便利。这一过程不仅要考虑数据类型的直接对应,还要注意特定数据类型在不同系统中的表现差异,确保数据的一致性和完整性。
78 4