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

<a href="http://improve.dk/corrupting-databases-purpose-using-orcamdf-corruptor/">http://improve.dk/corrupting-databases-purpose-using-orcamdf-corruptor/</a>

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

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

Corruptor 本身是比较简单的。Corruptor 会随机选择一些页面并且简单的使用0来完全复写页面。

根据页面的类型，这可能会造成致命伤害

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

例子

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

下面的代码会损坏5%的页面在AdventureWorks2008R2LT.mdf 文件里面，然后他会输出每个被损坏了的页面ID 。

你可以定义损坏页面的百分比 只需要改变第二个参数

为了使损坏更厉害，你也可以使用第二个重载方法，他允许你定义一个确切的损坏页面的数目，在一个确定的pageid范围内。

下面的代码会确切的损坏pageid在0到49这个范围内的10个页面，因此会损坏大部分的元数据，大家知道系统表的数据基本都存储在数据库最靠前的页面上

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

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

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

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》

第十七篇完