昨天下午突然看到，《爐石傳說》遊戲資料庫發生宕機並引發資料丟失事故的新聞。剛看到時，滿滿的不可思議。暴雪啊，網易啊。
都是很牛叉的公司。他們出的遊戲我都是很喜歡的。
當我看到，第一時間著手搶修，重啟伺服器，並嘗試資料恢復時，我的想法是他們的高可用方案呢？為什麼不馬上切換？
當我看到相關備份資料庫也出現故障時，就更無語了。其實這樣的事情在我們的客戶每年都會遇到很多。前不久就有乙個醫院， 資料庫和備份都同時損壞，而且沒有高可用的方案。
雖然最終幫他們修復了好資料庫，但還是丟失部分資料，而且中間1天時間，業務都是手動操作，嚴重影響業務。
對於爐石這樣的大公司，對應的方案應該是做得很全的，本次事故也可能是有其他的原因。
這個原因暫且不論，當遇到同樣的問題時，相關的運維和dba都是很絕望的。總結下上面的問題：
1.缺乏高可用方案
2.制定更好的備份的策略
有小夥伴提到高可用性，這裡沒有寫。主要高可用 方案太多，在一篇文章難以說清楚，所以本文先給出備份的解決方案。
下面給出我之前給某外企制定的備份策略，可以解決上面提到的備份的問題。小夥伴們可以參考下：
1.本地的備份，放置於和資料庫檔案不同的物理磁碟
2.異機備份。使用自動同步軟體實時把備份同步到專門的nas
3.異地備份（可選）
首先，恢復模式強烈建議使用完整模式。為了保證資料庫損壞時，能最快速度恢復業務。
1.每週全備
2.每天差異
3.每半小時日誌
備份的頻率根據具體的業務情況可自行調整。
到目前為止我們的備份策略看上去很完美了。可事實是這樣的嗎？答案是否定的。
我們做好了看似完美的備份。但是如果我們的資料庫本身已經存在頁損壞，那麼我們的做再多備份也是徒勞。因為備份的檔案也是損壞的。
那我們如何解決呢？最好的方法就是定期還原備份，然後立即執行dbcc checkdb。如果當時條件不允許持續還原和檢查，那麼使用restore verifyonly命令就是你另乙個最好的選擇了。但是restore verifyonly並不是單獨使用的。它必須配合with checksum.意思就是，在backup 的使用使用with checksum 引數，然後定期對備份的檔案執行restore verifyonly 來驗證備份檔案的有效性。如果資料庫中的某些頁面損壞，使用with checksum 去備份的作業會馬上失敗。這可以讓我們第一時間發現資料庫頁損壞的問題。
舉個栗子：
backup database adventureworks to disk = 'g:/backups/adventureworks_full.bak' with checksum
server: msg 3189, level 16, state 1, line 1
damage to the backup set was detected.
server: msg 3013, level 16, state 1, line 1
verify database is terminating abnormally.
裝置 'd:\tttttt.bak' 上的介質簇的結構不正確。sql server 無法處理此介質簇。
備份有可能因為各種原因而失敗，比如備份磁碟的空間滿了，等資料庫損壞的時候，突然發現備份任務失敗了，再完美備份策略 百搭。所以對備份任務，增加郵件報警機制，如果備份失敗了，可以第一時間知道並解決。
SQLSERVER 運維日記 資料庫狀態
新年伊始，小夥伴是不是還處於假期綜合症的狀態。我們在日常運維資料庫的時候，會時常檢視資料庫的狀態，檢查資料庫是否正常執行。對於這些狀態的熟悉對於我們處理資料庫無法訪問的 問題非常重要。當資料庫突然變成乙個你沒有見到過的狀態時，你就會非常慌亂，手足無措。這裡給小夥伴普及下資料庫的各個狀態。已經他們是怎...
SQL SERVER 運維日記 資料庫備份
昨天下午突然看到，爐石傳說 遊戲資料庫發生宕機並引發資料丟失事故的新聞。剛看到時，滿滿的不可思議。暴雪啊，網易啊。都是很牛叉的公司。他們出的遊戲我都是很喜歡的。當我看到，第一時間著手搶修，重啟伺服器，並嘗試資料恢復時，我的想法是他們的高可用方案呢？為什麼不馬上切換？當我看到相關備份資料庫也出現故障時...
SQL SERVER運維日記 收縮資料庫
先檢查下，有沒有可以刪除的不用的檔案，結果都是重要的或者拿不準的。先收縮下資料庫吧，點選執行。等收縮完成就可以繼續去根hr妹妹聊天了。突然 座機和手機齊鳴，小王心裡一種不祥的預感呢？好像這個場景在 見過。不會是資料庫阻塞了吧？手忙腳亂的先接起手機，因為來電顯示是某業務部門主管 小王啊，現在系統卡死了...