SQL Server災難恢複：重創曆史性資料

這是我希望你永遠不要面對的一個任務：永遠都不需要重新建立不同時間點上的資料，以此來澄清一 個可疑的動作或則和揭示損失或者被偷的資料。大多數的資料庫都在核心資料層上儲存資料，上面只為終 端使用者和資料庫管理員顯示資料的最近狀態。這就意味著你只能看到最新版本的資料，你無法識別在資料 生命週期中不同時間點上特定資料的下落。

作為一個資料庫管理員和顧問，我見到許多的資料庫只儲存當前的資料快照，而不是資料在其生命周 期中發生變化的每個曆史時期的資料行。在大多數情況下，這對於資料庫來說都是不錯的，因為每個事務 的一次迭代都會讓你的資料庫的規模比現在的尺寸大上100到1000倍。這是因為它需要保證資料庫處在可 管理的層面上，曆史性的資料行通常不會儲存，因此不容易重新建立。

金融行業則採用了相反的方式。不僅僅是儲存資料的最近狀態，它還儲存了發生的每個事務，並且將 條目還原到變化之前。這個方式意味著資料被寫入，但是它永遠不會發生變化。任何的記錄點都可以 輕鬆地顯示出來，需要重新建立資料等其他動作。從純粹的感覺出發，檢索金融資料的變更並不像你儲存 在資料庫中的其他資料那麼頻繁。就是說，你應該調查一下你需要檢索哪些曆史資料，以及那些類型的數 據只需要你儲存最新版本即可。

市場上也有此類工具，例如Lumigent Technologies公司的AuditDB和 Idera公司的 SQL compliance manager，它們都可以讓你捕捉資料庫中發生的每個變化的每個階段。它用了非常大的空間來儲存資料， 只有用上面提到的工具，你才可以檢索資料隨著時間變化的不同狀態——除非是你修改了你的 應用程式來儲存每個曆史資料行。當然，還有其他的選擇，例如使用觸發器來捕捉每個資料變更，但是， 還是這個問題，你的儲存空間需要很大，因為使用觸發器的時候對你的伺服器的要求很大。

不使用工具或者修改你的應用程式來捕捉每個曆史性資料行的話，你就剩下無盡的痛苦和無限的麻煩 來嘗試重新建立你的資料了。幾年之前，我曾經接受了這樣的任務，重新建立幾年前的保健記錄，以此來 發現一些可疑的行為。那時候，上面提到的工具還不存在，我就嘗試使用觸發器，還有額外的儲存需求， 都無法選擇。

重新建立每個曆史性特定資料集合的視圖的過程，是從歸檔備份磁帶的檢索開始的。讓我們感到驚恐 的是，我們被通知，每個月只有一盤磁帶用於長期的儲存，因此我們只能建立每個月一次的快照。當我們 開始重新儲存磁帶的時候，我們再次鬱悶地發現，有些磁帶已經沒法讀了。那時候的資料庫的規模只有 10GB，但是需要一遍又一遍地重新儲存，還有要捕捉到的資料的話，需要我們在適當的位置重新儲存，因 為這些是9GB磁碟驅動的時代，沒有足夠的儲存空間。今天，10GB是個極小的數字。現在的資料庫規模在 100GB到500GB的範圍。所以，即使是存在較大的驅動，整體的問題仍然存在。

我知道重新建立曆史性資料的任務不是經常發生的情況，但是我也知道，我曾經面對過這樣的挑戰好 幾次。作為一名資料庫管理員，保護資料並協助你的公司儘可能地再次製造是你的責任。為了理解真正的 需求和資料的重要性，你必須詢問一些問題來協助你判斷需求。基於你學到的內容，在合適的地方採取措 施將會保證你可以重新建立你需要的東西。

再一次提到，這裡有3個選項考慮讓你瞭解什麼是可能的，什麼是不可能的：

第三方工具，例如Lumigent的AuditDB 或者Idera的 SQL compliance manager

使用觸發器或者修改其它應用程式

備份和重新儲存的方法

根據你的選擇，你需要理解什麼是可能的，什麼是不可能的。通過使用第三方工具，你可以重新建立 每個發生的變化。這些工具構建在業務處理中，可以最小化對伺服器和資料庫的效能影響，它們可以讓你 有選擇的捕捉重要的資料。使用觸發器或者其它經過修改的應用程式是另一個很好的選擇，但是如果你的 系統非常繁忙，如果你用這樣的方式的話，你的效能會受到很大的影響。

最後一種方式，使用備份和重新儲存，需要進行調查以便你能夠理解長期的備份儲存。查明儲存多長 時間的備份，儲存哪些類型的備份，以及你重新儲存所有步驟的可能性。即使是一天只進行一次完全備份 ，你仍然有潛在的風險會丟失某一天的變更，於是你需要在那一天進行變更的恢複。在我所涉及的案例中 ，每個月都可能會發生很多很多的動作無法重新建立。

根據紙質的記錄來重新建立電腦記錄的日子一去不複返了。越來越多的資訊只線上抓取。如果沒有 採取適當的措施的話，資料就會永遠丟失，人們永遠也不知道發生了什麼。作為一個資料庫管理員，你需 要理解你的角色，保持系統線上，是你的資料的，實際上也是全公司的保護神。