SqlServer資料庫數據恢復報告

1、故障概述

SQL server資料庫的數據無法被讀取。

2、故障分析

SQL server資料庫文件無法被讀取,是由於底層File Record被截斷為0,無法找到文件開頭,數據表結構也被損壞。鏡像文件的前面80M左後的空間,還有中間一部分被覆蓋掉,導致系統表被損壞,所以無法讀取,考慮用自動備份文件來提取表結構。

日誌中的操作記錄:

由於系統表被損壞,有大量數據表的結構無法被確定,只能靠工程師根據經驗進行恢復工作。

3、解決方案

備份用戶數據,對丟失數據的硬碟。做全盤備份,以確保數據的安全性。

分析備份文件中舊數據的資料庫。

從舊資料庫中尋找數據表的結構。

從日誌中提取一部分數據表的結構。

從日誌中和殘留數據中提取完好的數據。

根據日誌恢復對應的數據,並檢查數據是否正確。

核對數據沒問題後恢復所有數據。

4、數據恢復實施過程

4.1備份用戶數據

由於數據全部都放在客戶的原盤中,先交給硬體部門檢測硬碟是否存在物理故障。經檢測沒問題後對每塊硬碟做全盤鏡像,使用專用工具將硬碟中所有扇區鏡像到一塊備份硬碟中。

如下圖:使用專業工具備份所有硬碟數據

4.2掃描鏡像文件

用winhex打開殘留文件,仔細分析硬碟底層數據,發現硬碟底層中還殘留著許多以前SQL server的日誌和備份文件。經過細心察看和分析,發現日誌中有資料庫很多包括插入語句的操作記錄,這些記錄可以考慮提取出來。還有備份文件,打開備份文件可以發現有建表語句,還有一部分舊數據。

但由於整個硬碟太大,人工去搜索SQL server相關數據部分會很慢,因此編寫一個提取資料庫相關數據的小程序,對整個硬碟中所有存在的資料庫殘留做掃描,提取所有數據。

4.3分析掃描數據

對掃描到的所有日誌文件進行分析,發現日誌文件中也分數據頁,有著固定的開頭和結尾,其中每條數據都在固定的位置有自己的object ID號,在接下來的掃描文件中,繼續搜尋有同樣的object Id的數據記錄,發現結構相同,可以確定這是完好的數據,可以提取。

再對掃描到的備份文件進行分析,發現可以從中提取出很多建表語句,可以得到一部分表結構。剩餘的表結構,由於截斷為0的部分剛好在系統表,沒有辦法提取表結構,只能從日誌中提取的數據來猜測表結構和數據類型。

4.4提取數據

根據之前分析的結論,先編寫程序從備份文件中提取建表語句,根據建表語句分析出表結構與各種數據類型,同時在殘留的系統表中尋找22H、07H、05H表,根據這些建立表與OBJECT_ID的對應關係。然後編寫新的程序對日誌中的記錄進行提取(我是在這一步無法把numeric類型的位元組碼解析成數據,所以卡住了),根據object ID(frombyte)來對數據和表進行對應,並插入到新表中。

4.5驗證所有數據

經驗證,數據恢復出來的新表與人工用winhex觀察到的數據基本一致。

數據恢復成功。


推薦閱讀:

一條LEFT JOIN+ORDER BY的sql語句優化問題?
索引列只要參與了計算, 查詢就會不走索引, 為什麼 MySQL 不對這種情況進行優化?
Python3 pandas如何加快SQL Server讀寫速度?
沒有任何基礎的人怎麼學SQL?
SQL面試,讓你的面試官無fu,ck可說,第17題難倒一片人

TAG:MySQL | SQL | 資料庫 |