解剖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》

第十七篇完