恢復數據庫的方法介紹

下面我們給大家介紹一下恢復數據庫的方法吧!交易記錄備份可以用來將數據庫恢復到某一指定狀態，但交易記錄備份本身不足以完成恢復數據庫的任務，還需要備份的數據文件參與恢復工作。恢復數據庫時，首先進行的是數據文件的恢復工作。在整個數據文件恢復完成前，不要將其設為完成狀態，否則交易日志就不會被恢復。當數據文件恢復完成，系統會通過交易日志的備份將數據庫恢復成用戶希望的狀態。如果在數據庫最後一次備份後，存在多個日志文件的備份，備份程序會按照它們建立的時間依次將其恢復。

另一種被稱為log shipping的過程可以提供更強的數據庫備份能力。當log shipping配置好後，它可以將數據庫整個復制到另一台服務器上。在這種情況下，交易日志也會定期發送到備份服務器上供恢復數據使用。這使得服務器一直處於熱備份狀態，當數據發生改變時它也隨之更新。另一個服務器被稱作監視(monitor)服務器，可以用來監視按規定時間間隔發送的shipping信號。如果在規定時間內沒有收到信號，監視服務器會將這一事件記錄到事件日志。這種機制使得log shipping經常成為災難恢復計劃中使用的方案。

性能優化

交易日志對數據庫有重要作用，同時它對系統的整體性能也有一定影響。通過幾個選項，我們可以對交易日志的性能進行優化。由於交易日志是一個連續的磁盤寫入過程，在這當中不會發生讀取動作。因此將日志文件放在一個獨立的磁盤，對優化性能有一定作用。

另一項優化措施與日志文件的體積有關。我們可以設置日志文件的體積不超過硬盤空間的百分之幾，或者確定它的大小。如果將其設置的過大會浪費磁盤空間，而如果設置的過小則會強制記錄文件不斷嘗試擴展，導致數據庫性能下降。

事務日志文件Transaction Log File是用來記錄數據庫更新情況的文件，擴展名為ldf。

在 SQL Server 7.0 和 SQL Server 2000 中，如果設置了自動增長功能，事務日志文件將會自動擴展。

一般情況下，在能夠容納兩次事務日志截斷之間發生的最大數量的事務時，事務日志的大小是穩定的，事務日志截斷由檢查點或者事務日志備份觸發。

然而，在某些情況下，事務日志可能會變得非常大，以致用盡空間或變滿。通常，在事務日志文件占盡可用磁盤空間且不能再擴展時，您將收到如下錯誤消息：

Error:9002, Severity:17, State:2

The log file for database ’%.*ls’ is full.

除了出現此錯誤消息之外，SQL Server 還可能因為缺少事務日志擴展空間而將數據庫標記為 SUSPECT。有關如何從此情形中恢復的其他信息，請參見 SQL Server 聯機幫助中的“磁盤空間不足”主題。

另外，事務日志擴展可能導致下列情形：

· 非常大的事務日志文件。

· 事務可能會失敗並可能開始回滾。

· 事務可能會用很長時間才能完成。

· 可能發生性能問題。

· 可能發生阻塞現象。

原因

事務日志擴展可能由於以下原因或情形而發生：

· 未提交的事務

· 非常大的事務

· 操作：DBCC DBREINDEX 和 CREATE INDEX

· 在從事務日志備份還原時

· 客戶端應用程序不處理所有結果

· 查詢在事務日志完成擴展之前超時，您收到假的“Log Full”錯誤消息

· 未復制的事務

以上是由編輯老師為大家整理的恢復數據庫的方法，如果您覺得有用，請繼續關注精品。