規劃損毀復原
當您要管理 SQL Server 資料庫時，必須隨時作好從可能的損毀狀況進行復原的準備。若要在損毀狀況之後復原資料庫，就必須要有設計完善且通過測試的備份以及 SQL Server 備份的還原計畫。如需詳細資訊，請參閱＜SQL Server 中的備份和還原策略簡介＞。此外，為了確保發生天然災害時，所有系統與資料可以迅速還原到正常作業，您必須建立嚴重損壞復原計畫。建立這個計畫時，要考慮到可能影響辦公室營運的不同損毀類型。這包括如火災的天然災害以及技術性損毀，如 RAID-5 陣列中有兩個磁碟失敗。建立嚴重損壞復原計畫時，要識別並備妥可回應各種損毀狀況的所有必要步驟。一定要測試每種狀況的復原步驟。Microsoft 建議您透過模擬天然災害來驗證您的嚴重損壞復原計畫。
設計備份與還原計畫時，您應該著眼於特定的環境與業務需要來考慮嚴重損壞復原的規劃。例如，假設發生火災，而使您的全天候資料中心徹底摧毀。確定能夠完全復原嗎？需要多久的時間才能復原並使系統恢復運作？使用者可接受資料遺失的程度為何？
理論上，重大災害復原計畫要說明復原所花的時間長短，以及使用者可期待的最終資料庫狀態。例如，您可能決定要在取得指定的硬體後，於 48 小時內完成復原，同時資料只能保證復原到上星期結束時。
嚴重損壞復原計畫可以利用許多不同的方法建構，而且可以包含許多種資訊。以下是嚴重損壞復原計畫類型：
取得硬體的計畫。
通訊計畫。
災害發生時要連絡的人員名單。
與因應重大災害關係人連絡的指示。
有關計畫管理權誰屬的資訊。
每種復原狀況的必要工作檢查清單。可讓您檢視損毀復原進度，在每項工作完成時簽上該工作的縮寫，並在檢查清單上指出完成時間。
SQL Server 復原模式
SQL Server 提供三種替代復原模式：簡單、完整與大量記錄。復原模式是控制資料庫之備份和還原作業基本行為的資料庫屬性。為每個資料庫選取最適合的復原模式，是規劃備份和還原策略時的必要步驟。在為特定資料庫選擇復原模式時，或多或少都應該考慮可用性與復原需求。復原模式選擇會影響資料庫損毀復原的可能性。
如需復原模式的簡介，請參閱＜復原模式概觀＞。
管理備份媒體
Microsoft 建議您備份計畫中要包含管理備份媒體的規定，例如：
儲存與循環利用備份組的追蹤與管理計畫。
覆寫備份媒體的排程。
在多伺服器環境中，決定使用集中式或分散式備份。
追蹤媒體可用壽命的方法。
將損失備份組或備份媒體 (例如損失磁帶) 的影響減到最低的步驟。
將備份組儲存在當地或異地的決定，以及這對復原時間的影響分析。
如需有關 SQL Server 如何使用備份裝置與媒體的詳細資訊，請參閱＜在 SQL Server 中使用備份媒體＞。
執行基本功能指令碼
通常，嚴重損壞復原計畫中會包含一份基本功能指令碼，以確保一切都能如預期般運作。基本功能指令碼為系統管理員或資料庫管理員提供可靠的工具，讓他們不必依靠使用者的確認，就能確定資料庫是否已回復到可行的狀態。
基本功能指令碼會因不同的應用程式而有差異，也可能採用許多不同形式。例如，在決策支援/報告系統中，指令碼可能只是複製幾個關鍵的報告查詢。對於線上交易處理 (OLTP) 應用程式，指令碼可能是執行整批的預存程序，以執行 INSERT、UPDATE 與 DELETE 陳述式。例如，基本功能指令碼可能會像 .sql 檔案一樣簡單，可將批次的 SQL 陳述式從 sqlcmd 公用程式傳送到伺服器。另一則範例是使用同時包含 bcp 和 sqlcmd 命令的 .bat 檔。
確定已對損毀狀況作好準備
Microsoft 建議您定期執行以下活動，確定可對損毀狀況作好準備：
在實際發生故障前，徹底測試備份與復原程序。進行測試可幫助確定您已備有從不同失敗狀況復原的必要備份、已清楚地定義和記錄步驟，而且可以由任何合格的操作員順暢且迅速地執行。
定期執行資料庫與交易記錄備份，將損失的資料量減到最少。我們建議您將系統與使用者資料庫都備份起來。
以安全的方式維護系統記錄。保留 Microsoft Windows 與 SQL Server 上安裝之所有 Service Pack 的記錄。保留使用之網路程式庫和安全性模式的記錄。此外，如果 SQL Server 是在混合模式驗證 (SQL Server 和 Windows 驗證模式) 下執行，請在安全的位置記錄 sa 密碼。如需詳細資訊，請參閱＜安全性與保護 (Database Engine)＞。
.gif "重要事項")
重要事項Windows 驗證比 SQL Server 驗證更安全。如果可能，您應該使用 Windows 驗證。
在另一個伺服器上，評估要復原損毀狀況所需採取的步驟。如有必要，請修改步驟以符合本機伺服器環境，並測試修改過的步驟。
維護基本功能指令碼，以迅速恢復使用最起碼的功能。
稽核和減少可能造成損毀的使用者錯誤
其中一個更具挑戰性的復原狀況是從嚴重的使用者錯誤中復原，例如意外卸除資料庫物件。此章節列出可協助您稽核 (以及在某些情況下規範) 資料庫變更的工具。
資料定義語言 (DDL) 觸發程序
這些觸發程序可建立來稽核及規範資料庫結構描述的特定變更。DDL 觸發程序會引發預存程序以回應各種 DDL 陳述式。這些主要是以 CREATE、ALTER 和 DROP 開頭的陳述式。DDL 觸發程序的範圍是特定資料庫或整個伺服器執行個體。如需詳細資訊，請參閱＜瞭解 DDL 觸發程序＞。
事件通知
事件通知是為了回應各種 Transact-SQL DDL 陳述式和 SQL 追蹤事件而執行，並將有關這些事件的資訊傳送給 Service Broker 服務。
可以針對 SQL 追蹤所擷取的許多相同事件，來將事件通知程式化。但是，與建立追蹤不同的是，事件通知可用來在 SQL Server 的執行個體內部執行動作，以便回應事件。由於事件通知是以非同步方式執行，因此這些動作並不會耗用即時交易所定義的任何資源。如需詳細資訊，請參閱＜事件通知 (Database Engine)＞。
[!附註]
並非所有的 DDL 事件都可以在 DDL 觸發程序中使用。有些事件只能用於非同步、非交易的陳述式。例如，CREATE DATABASE 事件無法用於 DDL 觸發程序。您應該針對這些事件使用事件通知。
SQL Server Agent
這是一種 Windows 服務，它會執行排程的管理工作 (稱為作業)。SQL Server Agent 使用 SQL Server 來儲存作業資訊。最重要的是，SQL Server Agent 可執行作業來回應特定事件，例如具有特定嚴重性層級或訊息編號的錯誤。
如需 SQL Server Agent 的簡介，請參閱＜自動化管理工作 (SQL Server Agent)＞。如需有關如何針對事件使用 SQL Server Agent 的詳細資訊，請參閱＜監視和回應事件＞。
SQL 追蹤
SQL 追蹤會提供 Transact-SQL 系統預存程序，以便在 SQL Server Database Engine 的執行個體中針對使用者選取的事件類別建立追蹤。您可以從自己的應用程式中使用這些系統預存程序，以手動方式建立追蹤。如需詳細資訊，請參閱＜SQL 追蹤簡介＞。
[!附註]
SQL Server Profiler 是 SQL 追蹤的圖形化使用者介面，可用來監視 Database Engine 或 Analysis Services 的執行個體。如需詳細資訊，請參閱＜使用 SQL Server Profiler＞。