大部分企業的最重要的信息都儲存在數據庫中。企業在計劃使用新數據庫應用軟件時往往需要再三斟酌，加倍小心。 它們通常需要考慮存儲器、服務器、高效率、容量和羣集等因素。
在制定數據庫的災難恢復和業務連續性計劃時，也必須採用相同的規劃過程。任何涉及到企業尖端技術應用的行爲都必須是有組織和審慎的。 中斷是非常重要的事情，絕對不能掉以輕心。 正如2006年一篇關於財政規劃的文章所述：“這不僅僅是將數據重現在電腦顯示屏上，而是關乎業務是否能夠繼續進行下去。”如今，企業核心數據庫往往會影響到服務中斷時災難恢復的正常進行。 業務部分中斷或完全中斷均會影響全局。規劃業務持續性可以在必要時爲重要業務提供容量。 業務持續性領域的資深專業人士明白，災難過後業務仍可以繼續。在制定某些規劃時，必須弄明白如何讓業務順利進行下去。 災難同時也會造成資產的損失。保險雖然可以彌補財務上的損失，但是卻無法在一夜之間重建業務。 這就給員工帶來了巨大的麻煩。這給員工和客戶都造成了巨大壓力。 如果沒有合適的災難恢復計劃，就沒有可能重建業務。
必要條件
首先要滿足所支持的各數據庫的必要條件。恢復時間可能是其中最重要的一個條件。 中斷幾秒鐘與中斷幾分鐘之間的區別可能會很大。有些業務的允許中斷時間可能會達到幾個小時。
Charlene O'Hanlon在2007年的THE Journal文章中說：“你必須優先考慮你最需要的功能，你必須弄清楚什麼是最重要的。”
此外，還需考慮數據損耗的因素。如果無需考慮數據損耗的因素，那麼在選擇災難恢復解決方案時只需考慮預算的問題。 如果昨晚的備份能夠滿足要求，那麼這就可以節省大量的成本。
制定災難恢復解決方案時必須考慮容量的問題。應向客戶諮詢性能降低以及可接受的範圍等事宜。 這是個很難回答的問題，必須在客戶的幫助下才能找出答案。如果讓它們自己來回答，它們一定會說性能完全不降低才行。
在性能降低的同時，還需搞清楚在中斷時訪問系統的用戶數量。這兩個因素有助於確定更準確的容量需求。 必須說明的是，在中斷期間，企業員工均不能使用企業應用軟件。也許只有高級用戶才需要運行功能強大的系統。
人力資源應用軟件就是個很好的例子。業務正常進行時，員工們需要使用人力資源應用軟件來查工資、升級W-2等。 業務中斷時，應禁止一般用戶使用那些應用軟件，但是高級用戶仍可以使用工資系統、僱傭和解僱員工等等。只要數據庫彼此之間無需互通，很可能你所需的容量沒有你想象得那麼多。 虛擬服務器也可以使用。 據Andreas Antonopoulos編寫的一份Nemertes研究報告稱：“你可能要頻繁地例示虛擬機。因此，那些允許性能微降的企業就可以以更低廉的成本建立一個輔助數據中心來處理臨時中斷事故。”
訪問數據庫和應用軟件是另一個重要問題。如果主要的辦公地點不能用，員工們就需要另一個地方來辦公。 工作站需要配備必要軟件來連接數據庫。切記不可忽視這個要點。
測試也非常重要。確定你測試災難恢復計劃的頻率。 只有通過測試才能發現和解決問題。測試還可以改善災難恢復計劃。
由於業務時常在變，你將在災難恢復計劃中發現同樣的性能。要想保持災難恢復計劃的相關性和時效性，就必須經常進行測試。 測試的頻率可以是一年一次，一年兩次或者一季度一次。
通常，災難恢復的計劃中不包括突發事件。突發事件只有在計劃實施時纔會發生。在制定數據庫的災難恢復計劃時必須考慮到時間的因素。然而不幸的是，在其他計劃面前，災難恢復計劃總是靠邊站。將災難恢復計劃融入所有計劃之中，那樣才能及時完成災難恢復計劃。
災難恢復通常必須在短時間內完成。 除非萬不得已，沒人願意總是呆在災難恢復中心。 計劃好中斷時間、遷移、測試、決策和撤退過程。應將所有事務都計劃好，用戶必須徹底弄清損耗和轉換計劃。
企業中必須有一個決策者來判定災難的發生。確定這個決策者是誰以及應在災難發生時傳達出何種信息。 信息應通過多種形式發佈。在災難發生時，很少會出現各種通信方式都可以使用的情況。
如同我們在本系列的上篇部分所指出的那樣，數據庫管理員對於任何災難恢復方案的成功實施都是關鍵的一環。
數據庫管理員的成功需要許多其他關鍵人員的協助。數據庫管理員需要服務器管理員來安裝和設置好服務器；需要系統管理員來安裝和設置好操作系統；需要存儲管理員來複制好相應的磁盤；需要應用程序開發人員來幫助尋找出錯誤或故障的原因。數據庫管理員甚至還依賴於其中的一些人員。
許多步驟（如果不是全部的話）可以災難發生前就完成或進行測試。在進行故障復原的時候，也可能某些領域會出現一些問題，並且必須重新設置這些領域。在正常時候，數據庫管理員知道應該找誰以及同哪些人一起協同工作，但是如果災難發生而且一些主要的支持人員不在，那麼數據庫管理員該如何應對呢？這些人可能在照顧受傷的家庭成員或自己也受了傷。那麼如果你的數據庫管理員也不在了呢？這些情境的發生概率必須予以適當的考慮。
當員工遇到問題的時候，他們必須知道正確的尋找對象。
避免找不到相關人員的最好辦法之一就是對員工進行交叉培訓。如果一個員工知道兩個以上的工作職能和內容，那麼他就可以在發生災難的時候扮演關鍵角色，因爲他知道如何做好兩個以上的任務。
在《安全計劃和災難恢復》（McGraw-Hill）一書中，Eric Maiwald 和William Sieglein指出，一些人員可能無法出現在恢復現場，使得一些領域無人負責，因此交叉培訓能夠幫助避免這種情況。除非員工自己要求，否則交叉培訓不應該使員工完全脫離他們自己的正常職業。通常來說，更好的做法是讓員工學習新的技能，同時這個技能也符合他們目前所從事的工作。
例如，Oracle數據庫管理員可以交叉培訓成一名SQL Server數據庫管理員。他們已經熟悉了這兩種數據庫共同的概念、SQL（結構式查詢語言）、結構和數據庫管理的其他功能。他們所要做的只是學習新數據庫軟件的不同工具集。這樣對於組織和員工來說都是一個雙贏的選擇。員工學習寶貴的新技能可以幫助他們提升自己的職業發展道路。組織則得到了一個擁有多技能的員工，以便能夠在異常情況和危機情勢下依賴這些員工。
備份
數據庫的要求會影響相關的備份類型。如果一個數據庫可能會有數小時的宕機時間，而且在這種時候管理人員可以通過在前一個晚上的預先備份來滿足要求，那麼完全備份是好的做法。如果一點點的宕機時間和少量的數據損失是可以接受的，那麼完全備份則沒有很大的必要。
像遠程鏡像這樣的技術也有必要研究和考慮。在遠程鏡像中，生產系統中的所有變化都被複制到災難恢復站點。由於大部分災難恢復站點離主站有一定的距離，因此遠程鏡像一般異步進行。當需要故障復原的時候，數據庫可以從被鏡像的數據中予以恢復，以便保持業務的連續。
另一個可以保持災難恢復數據庫更新的技術是數據複製。這種軟件的基本功能是複製系統所發生的變化。這種功能可以進行調整爲定期進行，比如每隔四小時進行一次。這樣當用戶發生錯誤操作的時候，就可以用於數據恢復。數據庫管理員可以利用災難恢復數據庫來修正錯誤的生產數據。
安裝
對於數據庫管理員來說，數據庫軟件的安裝是一個相當常規的任務，對於在不同的服務器中安裝相同版本的數據庫來說也是如此。數據庫的安裝和設置必須做好記錄。當需要故障復原的時候，可能會發生無法找到數據庫管理員的情況。清楚且詳細、一步一步的安裝及設置指導能夠幫助其他領域的技術人員安裝和設置數據庫軟件。
話雖如此，但是每個生產服務器都是不同的。要準備好數據庫可能需要做一些特定的事情。有些時候需要運行特定的腳本或者載入特定的任務或卸載一些數據。個別數據庫的這些步驟以及這些數據的執行順序必須詳細清楚地予以記錄。
充分利用災難恢復（DR）站點
災難恢復的最好辦法就是建設專門的站點，在這些站點中安裝同樣的服務器和運行同樣的應用程序軟件，這樣可以在需要的時候馬上進行故障復原。但是這種方法的成本很高而且不普及。現實中還有一些其他實用的辦法可以在實施災難恢復站點的同時節省成本。
雙重利用災難恢復設施的一個很好方法就是更新測試。所有的操作系統、應用程序和數據庫都需要定期的維護補丁、修復和更新。由於災難恢復設施的環境基本上和生產系統相同，因此這裏是測試維護性發布主要地點。
補丁和修復可以定期進入災難恢復系統進行測試。在這個環境中，一個經過批准的測試系統可以檢查維護性發布本身是否有問題。如果這些補丁本身沒有發現任何問題，那麼這些補丁可以根據計劃定期遷移到測試環境。如果補丁在測試環境中也沒有產生任何問題，那麼這些補丁可以根據定期計劃接着遷移到生產系統中去。
如果這些維護性發布在災難恢復站點或測試系統中發現了問題，那麼這些補丁可以回滾到原來的狀態。這樣用戶就可以不用再建立一個單獨的實驗性環境了。建立實驗性環境的成本也可能比較高。用戶不需要實驗室所需的新的硬件、軟件、許可證、維護、管理和空間就可以測試維護性發布。
如果你目前還沒有實驗室來測試軟件的補丁和修復，那麼利用災難恢復站點來測試維護性發布可以帶來三種好處。首先，原來用於建立實驗室的資金可以用於災難恢復站點，而災難恢復站點本身就是一個必須的設施。第二，你可以用一個基本上相同於生產系統的複製環境來測試軟件的補丁，也就無需再建立實驗室。第三，一旦這些補丁安裝到生產系統中，管理人員就可以減少系統的維護。保持軟件的補丁和修復可以減少系統的宕機時間以及管理人員用於系統修復的時間。
對於數據庫管理員來說，這種方式特別有好處。雖然在許多情況下，你可以用一個服務器來測試數據庫的安裝、補丁安裝和更新，但是你很少能夠用整個環境來測試所有這些任務。應用程序開發人員和用戶希望能夠在補丁已經被安裝的情況下測試數據庫的應用程序。數據庫管理員可以進行有限的測試，但是用戶在使用系統的時候纔是真實的測試。
在災難恢復站點中部署試驗服務器還可以讓災難恢復站點更快地啓動和運行，並最大化這些服務器本身的使用價值。大部分情況下，數據中心購買這些測試服務器來測試新的項目，然後再讓這些項目進入生產系統。測試服務器必須擁有和生產系統相同的規格或者更好的規格。大部分測試服務器需要更高的容量和功能，因爲比起生產硬件，測試服務器通常需要運行更多的數據庫、應用程序服務器、Web服務器。通過災難恢復設施中的測試服務器，軟件的許多安裝工作實際已經完成。災難恢復實例可以在測試服務器上建好，然後就可以讓它們處於閒置狀態，應用程序服務器、Web服務器和數據庫只要等待需要故障復原的那一天就可以了。
使用虛擬化服務器也可以幫助災難恢復站點降低成本，特別是在當前虛擬化技術的成本正變得越來越低且虛擬化技術的複雜性越來越低的時候。現在，虛擬服務器的實施要比過去容易得多。如今，市場上有許多應用程序、操作系統和數據庫支持服務器虛擬化軟件。這種情況的發生是因爲虛擬化廠商正試圖在他們之間建立更密切的協作，而且他們也同其他的軟件廠商進行了良好和充分的合作。
來自客戶的壓力也促使軟件公司同虛擬化公司合作以便認證和支持它們的虛擬化產品。通過虛擬化，一個物理服務器可以被鏡像並在虛擬環境中產生一個虛擬服務器。一個包含Web服務器、應用程序服務器和數據服務器的生產系統可以被全部鏡像並在一個物理服務器上進行虛擬化。這種方式能有效地將三個物理服務器合併成一個服務器，同時還保留了所有的功能。雖然虛擬化後的容量可能不一樣，但是對於災難恢復來說也足夠用了。這種方式並不意味着所有的應用程序都必須在虛擬服務器上工作，它們必須能夠共同存在。
導師
交叉培訓之外的一個關鍵步驟是導師計劃。通過導師計劃，一個對不同領域感興趣並希望成爲該領域專家的員工可以同項目專家直接溝通。對於僱主來說，這種制度還可以提升員工士氣，從而爲企業帶來回報。對於員工來說，當他們希望通過交叉培訓得到另一個技術團隊的空缺職位時，導師計劃也可以在這方面幫助這些員工。
通過爲員工打開不同團隊之間的職業空間和機會，個人員工將備受鼓舞，他們將感覺到自己不會侷限於自己目前所從事的工作。例如，一個數據庫管理員的職位可能很難從外部招聘。而一個擁有相應的才能、能力並且希望成爲數據庫管理員的開發人員可能因爲缺少相關的經驗卻錯失這個機會。通過導師計劃這種方式，個人員工可以在工作變動上得到幫助，同時符合條件的候選人員也可以得到新的職業路徑。
導師計劃可以在團隊內部以及不同團隊之間傳播知識和技能，當項目專家無法抵達現場或失去工作能力的時候，導師計劃可以爲災難恢復提供支持性人員。通過在導師計劃中記錄下過程和流程，組織和系統應對故障或災難並採取響應行動的能力將大大提升。
作者Kevin Medlin自1997年以來曾經在多個行業（包括能源、零售、保險和服務）中擔任過管理、支持和開發職位。他目前是一位DBA（數據庫管理員），熟悉Oracle和SQL Server數據庫，而且通過了Oracle版本8到10的技能認證。他在Regis大學獲得存儲局域網畢業證書，並將在2008年獲得東卡來羅那州立大學的技術系統碩士學位。