對於數據庫管理員來說不可預測的災難雖然讓他們很頭疼但是並不可怕可拍的是沒有為可能發生的災難做好相關的准備以至於當災難發生的時候素手無策由於硬件故障服務器被偷或者其他意外事故數據庫管理員很難避免數據庫管理員能夠做的就是采取哪些措施來為未來可能發生的災難最好准備筆者在這方面雖然不能夠說做的面面俱到但是也算是做得不錯了筆者就在這裡跟大家分享一下這方面的管理經驗幫助大家來應對這些不可預知的災難
措施一定時的對備份文件進行測試
為了在數據庫出現故障的時候迅速利用備份文件進行恢復數據庫管理員往往會設計比較合理地備份策略如在SQL Server數據庫匯中可以通過完全備份與差異備份相結合的策略來對數據庫進行備份這一步大部分數據庫管理員都做的很好但是他們只做到這一步而已而很少有數據庫管理員會對這些備份文件進行測試看看能否利用這些備份文件進行順利恢復
筆者有一個朋友以前就犯過這個錯誤他配制好數據庫備份策略以後以為就萬事大吉了但是一次當數據庫出現故障利用這個備份文件恢復之後就出現了一些問題在數據庫中有些視圖的列采用了中文名字但是可能在數據部署的時候配置不當或者其他的原因導致在恢復的過程中這些中文備注顯示的是亂碼;而字段名稱或者視圖名字中包含中文漢字的則就無法正確恢復過去還是這些內容不是很多平時工作中又作了詳細的工作筆記為此發現這個問題後馬上可以重建這些視圖雖然這次事故最終沒有造成很大的損失但是也給我們數據庫管理員提了一個醒數據庫備份之後並不是萬無一失了數據庫管理員最好能夠不定時的對備份文件進行測試以確保這些備份文件的准確性;以及確保可以從這些備份文件中恢復需要的數據
筆者現在給企業部署SQL Server數據庫的時候都會要求企業的數據庫管理員至少每隔一個月需要對備份文件進行恢復測試一方面用來測試這些備份文件的准確性防止因為不正確的備份而造成無法挽回的損失另一方面也是鍛煉企業數據庫管理員對於數據庫恢復的熟練程度讓他們能夠在遇到數據庫服務器故障的時候能夠在最短時間內恢復數據庫軟件如果平時不怎麼關注這個恢復過程的話則這些數據庫管理員一段時間沒做的話很可能都會還給筆者了為此進行數據庫備份文件的還原測試即可以用來判斷備份文件是否准確;也可以讓企業數據庫管理員熟悉還原流程一舉多得數據庫管理員要定時不定時的做好還原測試
措施二設計並運行一些基本的功能腳本
作為數據庫管理員來說最悲慘的事情就是自己是最後一個知道問題的人可能某些故障如備份失敗或者某個觸發器無法正常運行已經發生了很長的一段時間但是由於數據庫管理員可能在忙於其他的事情沒有注意到這方面的內容久而久之當故障發生後才發現因為這些故障而導致原來針對這些災難的安全措施都不起作用了所以說數據庫管理員必須實時的了解這些安全措施的運行情況但是數據庫管理員畢竟精力有限沒有這麼多的時間來跟蹤這方面的內容
為此筆者建議作為數據庫管理員最好能夠自己開發或者直接采用數據庫系統中的一些功能性腳本這些腳本主要用來自動檢測數據庫的運行狀況如果數據庫運行有問題如在差異備份過程中有錯誤則這些功能性腳本就會探測到這個問題並通過郵件或者其他方式來告知數據庫管理員讓他們能夠及時的采取措施來解決這個問題簡單的說這些基本功能腳本就是為數據庫管理員提供了一種自動檢測數據庫的機制可以用來炎症數據庫是否可以回到可工作狀態以確認所有的作業都是在按預想的方式進行
通常情況下筆者認為可能需要對如下的一些作業進行監控以確保他們時刻都是有效的一是數據庫的備份策略需要確保數據庫在規定的時間內完成特定的備份(如差異備份與完全備份等等)二是需要考慮某些觸發器是否有效有些觸發器主要用來完成一些約束或者級聯更新的功能數據庫管理員需要確保這些觸發器是時刻有效的不然的話很可能導致數據庫中數據一致性的破壞如果由於觸發器無效導致級聯更新的失敗這也是一種災難而且由於這個災難比較難以發現為此其危害度可能比服務器故障還要嚴重的多所以說需要通過基本功能腳本來自動檢測這些觸發器的有效性
在上一篇《如何了解觸發器的執行信息》文章中筆者也介紹了一些查詢觸發器執行情況的手段各位數據庫管理員可以參看這篇文章的一些建議來追蹤觸發器的執行情況但是手工監督的話工作量比較大而且時間相隔也會比較久為此比較理想的情況是數據庫管理員能夠設計並運行一些基本的功能腳本用來監督這些觸發器的執行與生效情況
為此筆者認為通常情況下數據庫管理員最好能夠在災難恢復計劃中部署一些基本功能腳本以確認所有事情都是在按管理員的預期方式運行通過這些腳本可以幫助數據庫管理員來監督與檢測數據庫的運行情況而不用等到用戶來反映問題
措施三審議用戶的操作以減少災難發生的幾率
在實際工作中服務器等出現故障的幾率是比較少的其實數據庫運行中的很多災難可能是人為造成的也就是說數據庫災難中其七分是人禍造成的;而只有三分可能是一些不能夠預測的自然災難所造成的為此數據庫管理員應該審議用戶的操作以減少災難發生大幾率
筆者在數據庫維護過程中就遇到過這方面的事情那時用戶為了數據導入的方便就直接在數據庫中而不是通過前台的應用程序導入數據為此雖然符合了數據庫中的強制規范性要求如字段非空或者其他的一些約束性條件但是卻違反了前台應用程序的一些處理規則如字段過長數據類型不匹配數據必須為非空等等由於數據庫與前台應用程序業務邏輯的不一致性這些災難性問題很難查找最後不得不重新初始化數據庫來清空數據並重新導入
這個災難還算比較小筆者還遇到一些更大的人禍有家企業為了導入數據的方便竟然把數據庫中的約束全部禁用了本來他的想法可能是先把約束禁用掉以方便數據導入等到數據導入完成後在啟用約束但是這往往是行不通的因為稍微復雜一點的數據庫其表與表之間的約束字段的約束就好像一張漁網一樣纏繞在一起很難分清楚最後這家企業只好求助於我讓我們幫他們處理遇到這個問題筆者也束手無策筆者最後只好快到斬亂碼恢復數據庫然後在約束不取消的情況下讓企業導入數據此時的話由於系統約束的限制會自動對導入的數據進行完整性檢查如果發現有問題的數據則會馬上反映出來如此的話就可以保證導入數據庫中的數據都是符合數據庫約束條件的這就可以有效防止人為的不正常操作給數據庫帶來災難性的後果
為此筆者認為數據庫管理員應該審議用戶的日常操作防止因為各種不正常的操作而給數據庫帶來災難性的後果如通過數據庫中的事件通知功能或者跟蹤事件功能以追蹤各種可疑的SQL語句並匯報給數據庫管理員如此的話即使最終的災難不可避免但是數據庫管理員憑借這些信息也可以知道這些災難可能是什麼原因所造成的憑借這些信息數據庫管理員可以在最短的時間內排除故障畢竟在數據庫故障排除中查找問題的原因是其中最花時間最花精力的一項工作而這些SQL跟蹤或者事件通知功能則可以幫助數據庫管理員在發生數據庫災難事件中找出問題發生的原因迅速解決故障打個形象的比喻這就好像是飛機中的黑匣子可以幫助管理員記錄用戶操作數據庫過程中的不正常情況以減少數據庫管理員應對由此帶來的災難性故障所需要的時間
From:http://tw.wingwit.com/Article/program/SQL/201311/16389.html
