[SQL Server] 資料遺失後的檢討

前言:
公司的SQL Server有不同的Job(工作)每天負責把AS400的資料匯入到SQL Server。身為DBA當然要確保這些Job是OK。由於這些Job是由業務系統的管理員提供需求再由我來寫,對於Job的內容其實全不知情,這就是問題所在(哀)。


上星期接到業務部門投訴在公司網站上找不到一個多月前的申請,同事叫了我去查資料庫,果然出了意外。這個資料表每天給AS400的舊資料覆寫,造成新紀錄只能在SQL Server內存在一天。又剛好我們的第三方備份只保存一個月,又剛好我們沒有使用SQL Server內建的備份功能,當然,我就是回不去了....


至於結果,人家部門才不會理你是你的錯還是其他人的錯,總之資料不見了就是DBA的問題。最後好不容易堐過了幾場補救方案的會議....

問題:

  • 只有一個月的備份足夠嗎?
  • SQL Server只有Transaction log可以把資料救回來嗎?
研究
第一點:個人建議三個月是比較穩妥的做法。之於我們公司不知為什麼硬碟空間少得非常可憐,可以考慮每星期Full backup, 然後每天Diff的做法。總之,只備份一個月的確有很多難以估計的風險。

第二點:不行,死心吧。Transaction Log是交易的Delta資料,如果最初的時候沒有做一次Full Backup, 因為沒有被參照的完整備份,光有Transaction log是沒用的。如果你的SQL Server選擇的是Full Recovery, 可以看下這張圖,這張圖清楚說明先有Full backup後面的log才有意義。清楚的說明可以參考Microsoft這篇文章。 同學,死心吧...


總結:
異質資料庫資料同步的確是個很難搞的問題,會有很多不可預期的因素,因此個人是認為資源許可的話還是把備份時間盡量拉長,如果空間不足可以選擇Diff BackUp把備份時間再保持多一點點...

參考資料:

Popular posts from this blog

[SQL SERVER] 找出LOCK方法懶人包

[SQL Server] 解決log檔(ldf file)過度膨脹的實戰經驗

[開箱] Dell P2415Q 4K螢幕開箱