SQL Server中事務日誌管理的階梯，第5級：在完全恢復模式下管理日誌

作者：Tony Davis，2012/01/27

文章轉載自：http://www.sqlservercentral.com/articles/Stairway+Series/73785/

該系列

本文是Stairway系列的一部分:SQL Server中事務日誌管理的進階

當事情進展順利時，沒有必要特別注意事務日誌的功能或工作方式。 您只需要確信每個資料庫都有正確的備份機制。 當出現問題時，瞭解事務日誌對於採取糾正措施非常重要，尤其是在需要對資料庫進行時間點恢復時！Tony Davis給出了每個DBA應該知道的正確程度的細節。

在此級別，我們將檢視在完全恢復模式下工作時如何以及如何進行日誌備份，以及如何使用這些日誌備份檔案以及完整資料庫備份執行資料庫還原。 完全恢復模式支援將資料庫恢復到可用日誌備份中的任何時間點，並假設可以在故障發生之前進行尾部日誌備份，直到上次提交事務的時間。

什麼得到記錄？
在完全恢復模式下，所有操作都已完全記錄。對於INSERT，UPDATE和DELETE操作，這意味著對於每個被修改的行，都會有一個日誌記錄，描述執行該語句的事務的ID，當該事務開始和結束時，哪些頁面被更改，資料更改制作的，等等。

可以最小化記錄的操作SELECT INTO，BULK INSERT和CREATE INDEX在完全恢復模式下工作時仍然完全記錄，但操作略有不同。受這些操作影響的行不會單獨記錄;相反，只有資料庫頁面被記錄，因為它們被填滿。這樣可以減少此類操作的日誌記錄，同時確保仍然存在執行回滾，重做和時間點恢復所需的所有相同資訊。 Kalen Delaney釋出了一些關於SELECT INTO（http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/15/what-gets-logged-for-select-into.aspx）和索引重建的日誌記錄的調查（ http://sqlblog.com/blogs/kalen_delaney/archive/2011/03/08/what-gets-logged-for-index-rebuilds.aspx）操作，包括FULL和BULK_LOGGED恢復模式。在BULK_LOGGED模式下工作時，記錄最小日誌操作的差異將在第6級 - 管理BULK LOGGED恢復模式中的日誌中詳細討論。

為什麼備份事務日誌？
在完全恢復模式下，只有日誌備份可能導致截斷日誌。因此，事務日誌將儲存自上次備份事務日誌以來執行的事務的完整和完整記錄。由於所有操作都已完全記錄，因此在繁忙的系統中，日誌檔案可以非常快速地增長。

因此，在完全恢復模式下工作時，除了完全備份和（可選）差異備份之外，還必須執行常規事務日誌備份。許多新手或兼職DBA在其資料庫上執行完全備份，但它們不執行事務日誌備份。因此，事務日誌不會被截斷，並且它會增長並增長，直到它所在的驅動器用完磁碟空間，從而導致SQL Server停止工作。

一旦進行日誌備份，就會發生日誌截斷，假設自上次備份以來發生了檢查點，並且沒有其他因素延遲截斷，例如資料備份或恢復操作。有關可能延遲截斷可恢復VLF的因素的完整列表，以及保留大量日誌活動的因素，否則將不需要，例如流氓，長時間執行的未提交事務或資料庫映象或複製程序，請參閱：http：//msdn.microsoft.com/en-gb/library/ms345414.aspx。

COPY_ONLY備份事務日誌
COPY_ONLY事務日誌備份不會截斷事務日誌。 COPY_ONLY日誌備份“獨立”存在於正常日誌備份方案中; 它不會破壞日誌備份鏈。

簡而言之，事務日誌備份執行雙重目的，即允許還原和恢復到以前的某個時間點，以及控制事務日誌的大小。 可能導致事務日誌相關問題的最常見原因是在完全恢復模式下工作，並且根本不進行日誌備份，或者不經常使用日誌備份來控制事務日誌檔案的大小。

如果您不確定是否在給定資料庫上進行事務日誌備份，那麼您可以使用類似於清單5.1中所示的查詢來查詢MSDB資料庫中的backupset表。

USE msdb ;
SELECT   backup_set_id ,
         backup_start_date ,
         backup_finish_date ,
         backup_size ,
         recovery_model ,
         [type]
FROM     dbo.backupset
WHERE    database_name = 'TestDB'

程式碼清單5.1：是否正在進行日誌備份？

在型別列中，D表示資料庫備份，L表示日誌備份，I表示差異備份。

請注意，由於可以在不影響備份和還原行為的情況下操作此備份集表中的資料，因此您可能需要通過查詢sys.database_recovery_status以檢視last_log_backup_lsn（參見清單3.5）或sys的值來驗證此查詢的結果。 .databases表檢視log_reuse_wait_desc的值（如果需要備份，將返回LOG_BACKUP）。

如何備份事務日誌
如前所述，如果沒有首先進行至少一次完整備份，則無法執行事務日誌備份。實際上，如果您的資料庫處於完全恢復模式但從未進行過備份，那麼它實際上不會在完全恢復模式下工作。資料庫將處於自動截斷模式，直到執行第一次完全備份。

使用BACKUP命令執行所有資料庫備份，完整，日誌或其他。該命令接受了許多選項，這些選項在此處記錄：http：//msdn.microsoft.com/en-us/library/ms186865.aspx。但是，最基本的，通常是如何使用它，執行磁碟完全備份的命令如下：

BACKUP DATABASE DatabaseNameTO DISK ='FileLocation \ DatabaseName.bak';

如果這是要執行的第一個備份，則將在指定的目錄中建立DatabaseName.bak檔案。如果此類檔案已存在，則預設行為是將後續備份附加到該檔案。要覆蓋此行為，並規定應覆蓋任何現有檔案，我們可以使用INIT選項，如下所示：

BACKUP DATABASE DatabaseNameTO DISK ='FileLocation \ DatabaseName.bak'WITH INIT;

但是，最常見的是，每個後續備份都有一個唯一的名稱;更多關於這一點在即將到來的部分，恢復到失敗點。

在每次定期（例如每天）完整備份之後，將會有頻繁（例如每小時）的日誌備份，其基本命令非常相似：

BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak';

儲存日誌備份
顯然，備份的資料和日誌檔案不應儲存在託管實時檔案的同一驅動器上。如果該驅動器遭受硬體故障，那麼所有副本將與實時檔案一起丟失，備份將是徒勞的。這些檔案應備份到單獨的裝置，或備份到本地映象驅動器。

日誌備份的頻率
如前面的級別所述，您可能每15分鐘或甚至更頻繁地進行日誌備份。在這種情況下，為了避免恢復大量事務日誌檔案的需要，您可以選擇採用備份方案，其中包含散佈有差異備份的完整備份，其中散佈著事務日誌備份。

實際上，備份方案通常在理想和實際之間，在評估資料丟失的真實風險，公司成本以及降低風險所涉及的成本之間做出妥協。許多非常重要的業務應用程式使用稍微簡單但仍然嚴格的備份方案，可能涉及定期夜間完整備份以及每小時事務日誌備份。

日誌備份的頻率也可以由資料庫所處的事務數量決定。對於非常繁忙的資料庫，可能需要經常備份以控制日誌的大小。

沒有簡單的方法來計算日誌備份的頻率。大多數DBA會對日誌備份的頻率進行最佳估計，然後觀察檔案的增長特性，然後根據需要調整備份方案，以防止它們變得過大。

日誌鏈以及如何打破它
如上所述，如果沒有首先進行至少一次完整備份，則無法執行事務日誌備份。為了將資料庫恢復到某個時間點，或者在特定日誌備份結束時或者在特定日誌備份中的某個時間點，必須存在完整的不間斷的日誌記錄鏈，從第一次日誌備份開始在完整（或差異備份）之後，直到故障點。這稱為日誌鏈。

有許多方法可以打破日誌鏈，如果這樣做，則意味著您只能將資料庫恢復到在事件發生之前進行日誌備份時才會破壞鏈。簡而言之，如果您關心恢復資料的能力，打破鏈條並不是一個好主意。打破鏈條的兩種最常見的方法包括：

事務日誌備份檔案丟失或損壞 - 您只能恢復到上一個​​良好的日誌備份。日誌鏈將在下一個良好的完整或差異備份時再次啟動。
切換到SIMPLE恢復模式 - 如果您從FULL切換到SIMPLE恢復模式，這將打破日誌鏈，因為將啟動檢查點並且可以立即截斷事務日誌。當您返回FULL模式時，您需要進行另一次完整備份以重新啟動日誌鏈。實際上，在進行完全備份之前，資料庫將保持自動截斷模式，您將無法備份日誌檔案。
在SQL Server 2008之前，有一些命令，即BACKUP LOG WITH NO_LOG或BACKUP LOG WITH TRUNCATE_ONLY（它們在功能上等效），當發出時，會強制執行日誌檔案截斷，從而破壞日誌鏈。您不應該在任何版本的SQL Server中發出這些命令，但是我在這裡提到它們，因為當他們試圖處理“失控的日誌檔案”時，他們仍然會使用它們，而不瞭解它對它們的能力的影響。恢復他們的資料庫有關更多詳細資訊，請參閱第8級 - 幫助，我的日誌已滿。

尾部日誌備份
只要您擁有最近的完整備份和完整的日誌鏈，就可以在發生任何故障之前將資料庫恢復到最終日誌備份結束時存在的狀態。但是，假設您按小時，每小時進行事務日誌備份，並在下午1:45發生故障。您可能會丟失45分鐘的資料;事實上，如果失敗是如此災難性以至於實時交易日誌無法恢復，那麼這就是您將失去的資料量。

但是，有時即使資料檔案不可用，實時事務日誌仍然可用，特別是如果事務日誌包含在單獨的專用驅動器上。如果是這種情況，則應備份實時事務日誌，即執行自上次日誌備份以來生成的日誌記錄的最終備份。這將捕獲實時日誌檔案中的剩餘日誌記錄，直至故障點。這稱為尾部日誌備份，是在開始還原和恢復操作之前應執行的最後一個操作。

尾部日誌備份和最少日誌記錄的操作
如果由於資料庫故障導致資料檔案不可用，並且日誌尾部包含最少日誌記錄的操作，那麼將無法執行尾部日誌備份，因為這將需要訪問更改的資料擴充套件區。資料檔案。這將在第6級“以批量記錄模式管理事務日誌”中進行更詳細的介紹。

如果要還原的資料庫處於聯機狀態，則會按如下方式備份日誌尾部：

BACKUP LOG DatabaseNameTO DISK ='FileLocation \ DatabaseName_Log.bak'WITH NORECOVERY

NORECOVERY選項將資料庫置於還原狀態，並假定您要執行的下一個操作是RESTORE。如果資料庫處於離線狀態且無法啟動，您仍應嘗試按照上述描述備份日誌尾部（儘管可省略NORECOVERY選項，因為不會進行任何事務處理）。

如果您確定日誌檔案已損壞，則文件建議您作為最後的手段，嘗試使用以下命令執行尾部日誌備份：

BACKUP LOG DatabaseNameTO DISK ='FileLocation\DatabaseName_Log.bak'WITH CONTINUE_AFTER_ERROR

如果主資料庫和資料檔案已損壞，但日誌可用，Microsoft建議重建master資料庫，然後備份上一個活動日誌。但是，這些主題超出了本Stairway的範圍，我將向您介紹文件以獲取更多詳細資訊。請參閱http://msdn.microsoft.com/en-us/library/ms190952.aspx。

執行還原和恢復
執行尾部日誌備份後，如果可能，下一步是還原上次完全備份（如果適用，則執行差異備份），然後還原完整的日誌備份檔案序列，包括尾部日誌備份。此序列還原操作的基本語法如下：

RESTORE {DATABASE | LOG} DatabaseNameFROM DISK ='FileLocation \ FileName.bak'WITH NORECOVERY;

如果在恢復時省略了WITH NORECOVERY選項，則預設情況下RESTORE命令將繼續執行WITH RECOVERY。換句話說，SQL Server將嘗試協調資料和日誌檔案，前滾已完成的事務，然後根據需要回滾未完成的事務。通過指定WITH NORECOVERY，我們指示SQL Server我們正在進行恢復序列，並且在執行任何回滾之前必須前滾更多操作。在還原序列中還原最後一個備份後，可以按如下方式恢復資料庫：

RESTORE DATABASE DatabaseName WITH RECOVERY

常見的要求是將資料庫還原到其他位置，在這種情況下，您只需將檔案作為還原過程的一部分進行移動，如下所述：http：//msdn.microsoft.com/en-us/library/ms190255的.aspx。

資料庫失敗後恢復
以下示例描述瞭如何恢復資料庫以響應故障，從而無法再訪問資料庫資料檔案。

完全恢復到失敗點
假設可能由於硬體故障導致資料庫故障後可以訪問“實時”事務日誌，那麼理論上應該可以通過使用以下步驟恢復和恢復資料庫直到故障點：

備份日誌的尾部
恢復最近的完整備份（加上差異，如果適用）
反過來，還原在完全（或差異）備份之後並在故障發生之前完成的每個事務日誌備份
恢復尾部日誌備份
恢復資料庫
聯機叢書中的許多示例演示了從“備份集”恢復和恢復，換句話說，是儲存所有備份的單個“裝置”。實際上，這意味著，備份到磁碟時，備份裝置是位於該磁碟上某個位置的單個.bak檔案。

因此，例如，清單5.2中所示的簡單示例使用由一個完整備份和一個事務日誌備份組成的備份集，並顯示如何執行完全還原。為了執行此程式碼，您首先需要重新建立TestDB資料庫，然後插入一些示例資料行（為方便起見，執行此操作的指令碼，CreateAndPopulateTestDB.sql，包含在此級別的程式碼下載中） 。您還需要在資料庫伺服器的本地C：驅動器上建立“備份”目錄，或者根據需要修改檔案路徑。

- 執行Test資料庫的完整備份
- WITH FORMAT選項啟動新的備份集
- 小心，因為它會覆蓋任何現有的集合
- 完整備份成為集合中的第一個檔案

BACKUP DATABASE TestDB
TO DISK = 'C:\Backups\TestDB.bak'
WITH FORMAT;
GO

- 執行Test資料庫的事務日誌備份
- 這是集合中的第二個檔案

BACKUP Log TestDB
TO DISK = 'C:\Backups\TestDB.bak'
GO

-- ....<FAILURE OCCURS HERE>....

- RESTORE HEADERONLY命令是可選的。
- 它只是確認包含的檔案
- 當前的設定

RESTORE HEADERONLY
FROM DISK = 'C:\Backups\TestDB.bak'
GO

- 備份日誌的尾部以準備還原
- 這將成為bakup集的第三個檔案

BACKUP Log TestDB
TO DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;
GO

 - 恢復完整備份
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=1, NORECOVERY;

 - 應用事務日誌備份
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=2, NORECOVERY;

 - 應用尾部日誌備份
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH FILE=3, NORECOVERY;

 - 恢復資料庫
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

程式碼清單5.2：備份到備份集並從中恢復; 不建議

但是，使用備份集似乎是資料庫備份到磁帶時的遺留問題。 備份到磁碟時，使用此方案是一個壞主意，因為當然，備份檔案會很快變大。

實際上，每個完整備份和事務日誌備份檔案將被單獨命名，並且可能標記了備份所用的時間和日期，這種情況更為常見。 例如，大多數第三方備份工具，流行的社群生成指令碼以及SSMS中的維護計劃嚮導/設計器都將建立單獨的帶日期戳的檔案，例如AdventureWorks_FULL_20080904_000001.bak。

因此，更常見的備份和還原方案將使用唯一命名的備份，如清單5.3所示。

USE master;
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO

- 執行Test資料庫的事務日誌備份
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log.bak'
WITH INIT;
GO

-- ....<FAILURE OCCURS HERE>....

 - 備份日誌的尾部以準備還原
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_taillog.bak'
WITH NORECOVERY, INIT;
GO

 - 恢復完整備份
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;

 - 應用事務日誌備份
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY;

 - 應用尾部日誌備份
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_taillog.bak'
WITH NORECOVERY;

 - 恢復資料庫
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

程式碼清單5.3：備份和恢復唯一命名的備份檔案

時間點恢復到上次良好日誌備份
有時，遺憾的是，可能無法執行完全恢復; 例如，如果由於失敗而導致實時事務日誌不可用。 在這種情況下，我們需要恢復到最近的日誌備份結束。 需要為這種可能性做好準備，即包含事務日誌的驅動器出現故障，該事務日誌規定了日誌備份的頻率。 如果每15分鐘進行一次備份，則會面臨15分鐘資料丟失的風險。

想象一下，我們已經執行了清單5.4中所示的備份序列。 為了這個演示，我們覆蓋了以前的備份檔案，並且備份序列顯然比實際中縮短了很多。

 - 凌晨2點全面備份
USE master ;
BACKUP DATABASE TestDB
TO DISK = 'C:\Backups\TestDB.bak'
WITH INIT ;
GO

- 日誌備份1在凌晨2點15分
USE master ;
BACKUP LOG TestDB
TO DISK = 'C:\Backups\TestDB_log.bak'
WITH INIT ;
GO

- 日誌備份2在凌晨2點30分
USE master ;
BACKUP LOG TestDB
TO DISK = 'C:\Backups\TestDB_log2.bak'
WITH INIT ;
GO

程式碼清單5.4：一系列簡短的日誌備份

如果在凌晨2:30之後不久發生災難性故障，我們可能需要將資料庫恢復到日誌備份2結束時凌晨2:30的狀態。

這個示例中的恢復序列與我們之前在清單5.3中看到的非常相似，但由於尾部備份是不可能的，我們只能恢復到某一點，我們需要使用STOPAT選項 ，如清單5.5所示。

- 恢復完整備份
RESTORE DATABASE TestDB
FROM DISK = 'C:\Backups\TestDB.bak'
WITH NORECOVERY;

- 恢復日誌檔案1
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';

- 恢復日誌檔案2
RESTORE LOG TestDB
FROM DISK = 'C:\Backups\TestDB_Log2.bak'
WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';

 - 恢復資料庫
RESTORE DATABASE TestDB
WITH RECOVERY;
GO

代碼清單5.5：使用STOPAT恢復到某個時間點

由於我們將來指定了STOPAT時間，因此該程式碼將向前滾動所有已完成的事務，直到第二個事務日誌結束。

或者，可以指定STOPAT時間，該時間落在特定日誌檔案中記錄的事務的時間範圍內。在這種情況下，資料庫將在指定的時間恢復到上次提交的事務。當您知道要還原到什麼時間但不確切知道該時間包含哪些日誌備份時，這非常有用。

還可以恢復到特定標記的事務。例如，當您需要將某個應用程式訪問的多個數據庫還原到邏輯上一致的點時，這非常有用。這裡不再討論這個主題，但你可以在聯機叢書（http://msdn.microsoft.com/en-us/library/ms187014.aspx）上找到更多資訊，Mladen Prajdic在這裡提供了一個很好的例子：http ：//weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx。

在“不良交易”之後恢復
在任何資料庫故障的上下文之外，可能需要還原資料庫備份和事務日誌，以便在錯誤的資料修改之前將資料庫返回到特定時間點，例如刪除或截斷表。

您對這種情況的迴應將取決於問題的性質。如果可能，您可以斷開所有使用者與資料庫的連線（在通知他們之後），並評估剛剛發生的事情的影響。在某些情況下，您可能需要估計問題發生的時間，然後使用時間點恢復完全恢復資料庫和日誌。恢復完成後，您必須通知使用者某些交易可能已丟失，並請求原諒。

當然，通常您無法以這種方式中斷正常的業務操作，以修復意外的資料丟失。由於實時資料庫仍在執行並正在被訪問，因此您可以嘗試在STANDBY模式下恢復資料庫的備份。這允許恢復進一步的日誌備份，但與使用NORECOVERY時不同，資料庫仍然可讀。恢復方案可能如下所示：

在STANDBY模式下，與實時資料庫一起恢復資料庫的備份
將日誌向前滾動到錯誤事務發生之前的點，資料丟失。
將丟失的資料複製到實時資料庫並刪除已還原的副本
當然，這個過程不一定是直截了當的，而且可能非常耗時。除非您購買了專門的日誌讀取工具，並且可以直接查詢日誌備份，否則滾動日誌可能意味著一系列艱苦的步驟，包括恢復日誌，檢查資料，進一步恢復等等，直到您已經確定了壞交易發生的確切位置。第3步也很困難，因為您將資料引入實時系統，這不一定與資料庫的當前狀態一致，因此可能存在引用完整性問題。

讓我們看一下實現上面步驟1和2的示例。首先，讓我們從頭開始，執行CreateAndPopulateTestDB.sql指令碼來重新建立TestDB資料庫，並將10行測試資料插入到新的LogTest表中。在程式碼清單5.6中，我們只是進行完整的資料庫備份（覆蓋任何以前的備份檔案）。如果您尚未建立“備份”目錄，則需要建立“備份”目錄，或者根據需要調整路徑。

 - 資料庫的完整備份
BACKUP DATABASE TestDB
TO DISK ='C:\Backups\TestDB.bak'
WITH INIT;
GO

程式碼清單5.6：TestDB的完全備份

然後，我們將一行新資料插入LogTest表。

USE TestDB
GO
INSERT INTO [TestDB].[dbo].[LogTest]
           ([SomeInt]
           ,[SomeLetters2])
     VALUES
           (66666,
           'ST')
           
SELECT * FROM dbo.LogTest

程式碼清單5.7：在TestDB中插入第11行

所以現在我們在LogTest表中有一個包含11行的實時TestDB資料庫，以及一個包含10行的備份版本。 現在讓我們在日誌備份中捕獲其他修改，如清單5.8所示。

USE master
GO
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log.bak'
WITH INIT;
GO

程式碼清單5.8：TestDB的日誌備份

現在，我們將模擬一個錯誤的“壞事務”，只需刪除LogTest表，然後我們進行最終的日誌備份。

USE TestDB
GO
DROP TABLE dbo.LogTest ;

USE master
GO
BACKUP Log TestDB
TO DISK ='C:\Backups\TestDB_log2.bak'
WITH INIT;
GO

清單5.9：災難！

為了在不中斷正常業務操作的情況下嘗試檢索丟失的資料，我們將以STANDBY模式恢復TestDB資料庫的副本。 備用資料庫的資料和日誌檔案（稱為ANewTestDB）將移至“備用”目錄（您需要事先建立此目錄）。

- 恢復名為TestDB資料庫的副本
- 在STANDBY模式下的ANewTestDB

USE master ;
GO
RESTORE DATABASE ANewTestDB
   FROM DISK ='C:\Backups\TestDB.bak'
   WITH STANDBY='C:\Backups\ANEWTestDB.bak',
   MOVE 'TestDB_dat' TO 'C:\Standby\ANewTestDB.mdf', 
   MOVE 'TestDB_log' TO 'C:\Standby\ANewTestDB.ldf'
GO

程式碼清單5.10：在STANDBY模式下恢復TestDB的副本

我們現在有一個名為ANewTestDB的新資料庫，它處於“Standby / Read-Only”模式，如圖5.1所示。

圖5.1：備用資料庫

對ANewTestDB資料庫中的LogTest表的查詢將顯示10行。 但是，我們希望讓桌子恢復到錯誤丟棄之前的狀態。 因此，下一步是執行將日誌備份還原到備用資料庫。

USE master
GO
RESTORE LOG ANewTestDB
FROM DISK = 'C:\Backups\TestDB_log.bak'
   WITH STANDBY='C:\Backups\ANewTestDB_log.bak'

程式碼清單5.11：在STANDBY模式下將日誌備份恢復到ANewTestDB資料庫

此時，針對ANewTestDB的查詢顯示11行，現在我們可以準備將​​該資料複製回實時資料庫。如果我們更進一步並恢復了第二個日誌備份，我們就會發現我們已經走得太遠了，備用資料庫中的表也會丟失。

執行備用還原的另一種方法是考慮使用第三方工具，例如Red Gate的SQL Virtual Restore，它提供了一種將備份掛載為實時，功能齊全的資料庫而無需物理還原的方法。

無論DBA是否喜歡，開發人員通常都可以訪問生產資料庫來執行臨時資料載入和更改。 DBA和開發人員共同負責確保這些過程順利進行，因此不會導致需要採取剛才所述行為的問題。我們稍後將在第6級 - 處理批量操作中回到此主題。

當然，所需修復行動的確切性質取決於不良交易的性質。如果一張桌子被“意外掉落”，那麼你很可能會沿著RESTORE WITH STANDBY路線前進。在其他時候，您可以簡單地建立一個指令碼來“反轉”流氓修改。

如果損壞隻影響單個列或有限數量的行，那麼可以使用SQL Data Compare之類的工具，它可以直接與備份檔案進行比較，並且可以進行行級恢復。 。

或者，如果您執行SQL Server 2005（或更高版本）Enterprise Edition，並且可以使用最近的資料庫快照，則可以對快照執行查詢，以便在檢視資料庫快照時檢視資料，然後編寫UPDATE或INSERT命令將資料從資料庫快照提取到實時源資料庫。

最後，作為最後的手段，專門的日誌閱讀器工具可以幫助您消除事務的影響，儘管我不知道SQL Server 2005及更高版本中的任何可靠工作。

總結
在本級別中，我們已經介紹了備份和恢復以完全恢復模式執行的資料庫的日誌檔案的基礎知識，這將是許多生產資料庫的標準。

對於大多數DBA來說，執行時間點恢復的需求是一種罕見的事件，但它是其中一項任務，如果有必要，完成並完成它是絕對關鍵的; DBA的聲譽取決於它。

在損壞，驅動器故障等情況下，如果幸運的話，時間點恢復可能涉及備份事務日誌的尾部並恢復到故障點的許可權。 如果事務日誌不可用，或者您正在恢復以便在發生“錯誤事務”之前恢復到某個時間點，則情況變得更加棘手，但希望此步驟中涉及的一些技術將有所幫助。