重創歷史性數據 SQL Server災難恢復
這是我希望你永遠不要面對的一個任務：永遠都不需要重新創建不同時間點上的數據，以此來澄清一個可疑的動作或則和揭示損失或者被偷的數據。大多數的數據庫都在核心數據層上存儲數據，上面只為終端用戶和數據庫管理員顯示數據的最近狀態。這就意味著你只能看到***版本的數據，你無法識別在數據生命周期中不同時間點上特定數據的下落。
作為一個數據庫管理員和顧問，我見到許多的數據庫只存儲當前的數據快照，而不是數據在其生命周期中發生變化的每個歷史時期的數據行。在大多數情況下，這對于數據庫來說都是不錯的，因為每個事務的一次迭代都會讓你的數據庫的規模比現在的尺寸大上100到1000倍。這是因為它需要保證數據庫處在可管理的層面上，歷史性的數據行通常不會存儲，因此不容易重新創建。
金融行業則采用了相反的方式。不僅僅是存儲數據的最近狀態，它還存儲了發生的每個事務，并且將條目還原到變化之前。這個方式意味著數據被寫入，但是它永遠不會發生變化。任何的歷史時間點都可以輕松地顯示出來，需要重新創建數據等其他操作。從純粹的感覺出發，檢索金融數據的變更并不像你存儲在數據庫中的其他數據那么頻繁。就是說，你應該調查一下你需要檢索哪些歷史數據，以及那些類型的數據只需要你存儲***版本即可。
市場上也有此類工具，例如Lumigent Technologies公司的AuditDB和 Idera公司的 SQL compliance manager，它們都可以讓你捕捉數據庫中發生的每個變化的每個階段。它用了非常大的空間來存儲數據，只有用上面提到的工具，你才可以檢索數據隨著時間變化的不同狀態——除非是你修改了你的應用程序來存儲每個歷史數據行。當然，還有其他的選擇，例如使用觸發器來捕捉每個數據變更，但是，還是這個問題，你的存儲空間需要很大，因為使用觸發器的時候對你的服務器的要求很大。
不使用工具或者修改你的應用程序來捕捉每個歷史性數據行的話，你就剩下無盡的痛苦和無限的麻煩來嘗試重新創建你的數據了。幾年之前，我曾經接受了這樣的任務，重新創建幾年前的保健記錄，以此來發現一些可疑的行為。那時候，上面提到的工具還不存在，我就嘗試使用觸發器，還有額外的存儲需求，都無法選擇。
重新創建每個歷史性特定數據集合的視圖的過程，是從歸檔備份磁帶的檢索開始的。讓我們感到驚恐的是，我們被通知，每個月只有一盤磁帶用于長期的存儲，因此我們只能創建每個月一次的快照。當我們開始重新存儲磁帶的時候，我們再次郁悶地發現，有些磁帶已經沒法讀了。那時候的數據庫的規模只有10GB，但是需要一遍又一遍地重新儲存，還有要捕捉到的數據的話，需要我們在適當的位置重新存儲，因為這些是9GB磁盤驅動的時代，沒有足夠的存儲空間。今天，10GB是個極小的數字。現在的數據庫規模在100GB到500GB的范圍。所以，即使是存在較大的驅動，整體的問題仍然存在。
我知道重新創建歷史性數據的任務不是經常發生的情況，但是我也知道，我曾經面對過這樣的挑戰好幾次。作為一名數據庫管理員，保護數據并幫助你的公司盡可能地再次制造是你的責任。為了理解真正的需求和數據的重要性，你必須詢問一些問題來幫助你判斷需求。基于你學到的內容，在合適的地方采取措施將會保證你可以重新創建你需要的東西。
再一次提到，這里有3個選項考慮讓你了解什么是可能的，什么是不可能的：
第三方工具，例如Lumigent的AuditDB 或者Idera的 SQL compliance manager
使用觸發器或者修改其它應用程序
備份和重新存儲的方法
根據你的選擇，你需要理解什么是可能的，什么是不可能的。通過使用第三方工具，你可以重新創建每個發生的變化。這些工具構建在業務處理中，可以最小化對服務器和數據庫的性能影響，它們可以讓你有選擇的捕捉重要的數據。使用觸發器或者其它經過修改的應用程序是另一個很好的選擇，但是如果你的系統非常繁忙，如果你用這樣的方式的話，你的性能會受到很大的影響。
***一種方式，使用備份和重新存儲，需要進行調查以便你能夠理解長期的備份存儲。查明存儲多長時間的備份，存儲哪些類型的備份，以及你重新存儲所有步驟的可能性。即使是一天只進行一次完全備份，你仍然有潛在的風險會丟失某一天的變更，于是你需要在那一天進行變更的恢復。在我所涉及的案例中，每個月都可能會發生很多很多的動作無法重新創建。
根據紙質的記錄來重新創建計算機記錄的日子一去不復返了。越來越多的信息只在線抓取。如果沒有采取適當的措施的話，數據就會永遠丟失，人們永遠也不知道發生了什么。作為一個數據庫管理員，你需要理解你的角色，保持系統在線，是你的數據的，實際上也是全公司的保護神。
【編輯推薦】
