SQL Server中事務日誌管理的步驟，第5級：完全恢復模式管理日誌

作者：Tony Davis，2012/01/27

系列

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

當事情進展順利時，無需特別註意事務日誌的作用或工作方式。您只需要確信每個數據庫都有正確的備份機制。當出現問題時，了解事務日誌對於采取糾正措施很重要，特別是在需要緊急恢復數據庫的時間點時！Tony Davis給出了每個DBA都應該知道的正確的細節級別。

在此級別中，我們將回顧在完全恢復模式下工作時進行日誌備份的原因和方法，以及如何使用這些日誌備份文件以及完整的數據庫備份執行數據庫還原。完全恢復模式支持將數據庫還原到可用日誌備份中的任何時間點，並且假設可以進行尾日誌備份，直到發生故障之前最後一次提交事務的時間為止。

什麽會被記錄？

在完全恢復模式下，將完全記錄所有操作。對於插入、更新和刪除操作，這意味著對於修改的每一行，都會有一個日誌記錄，描述執行語句的事務的ID、事務開始和結束時、哪些頁已更改、所做的數據更改等。

在完全恢復模式下工作時，可以最低限度地記錄的操作（選擇進入、大容量插入和創建索引）仍然完全記錄，但執行方式略有不同。受這些操作影響的行不是單獨記錄的；而是在數據庫頁被填充時只記錄它們。這減少了對此類操作的日誌記錄，同時確保仍然存在執行回滾、重做和時間點還原所需的所有相同信息。Kalen Delaney已經發布了一些關於select into（）和index rebuild（）操作的日誌調查，包括完整和批量日誌恢復模式。在大容量日誌記錄模式下工作時，最小日誌記錄操作的日誌記錄差異將在第6級-在大容量日誌記錄恢復模式下管理日誌中進行更詳細的討論。http://sqlbog.com/blogs/kalen_delaney/archive/2011/03/15/what-gets-logged-for-select-into.aspxhtp://sqlbog.com/blogs/kalen_delaney/archive/2011/03/08/what-gets-logged-for-index-rebuilds.aspx

為什麽備份事務日誌？

在完全恢復模式下，只有日誌備份才能導致日誌截斷。因此，事務日誌將保存自上次備份事務日誌以來執行的事務的完整記錄。由於所有操作都已完全記錄，因此在繁忙的系統中，日誌文件可能會增長得非常大、非常快。

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

在執行日誌備份後，會立即截斷日誌，前提是自上次備份以來已發生檢查點，並且沒有其他因素會延遲截斷，例如數據備份或還原操作。有關可能延遲截斷可恢復VLF的因素的完整列表，以及保持大量日誌活動的因素（否則不需要），如惡意、長時間運行的未提交事務或數據庫鏡像或復制進程，請參閱：http://msdn.microsoft.com/en-gb/library/ms345414.aspx。

僅復制事務日誌的備份

只復制事務日誌的備份不會截斷事務日誌。僅復制日誌備份與正常日誌備份方案“獨立”存在；它不會中斷日誌備份鏈。

簡而言之，事務日誌備份的雙重目的是允許恢復和恢復到以前的時間點，並控制事務日誌的大小。與事務日誌相關的問題最常見的原因可能是在完全恢復模式下工作，而不是簡單地進行日誌備份，或者不經常進行日誌備份以控制事務日誌文件的大小。

如果您不確定是否在給定的數據庫上執行事務日誌備份，那麽您可以使用類似於列表5.1所示的查詢，簡單地查詢msdb數據庫中的backupst表。

USEmsdb ;

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表示差異備份。

請註意，由於可以在不影響備份和還原行為的情況下操作此backupset表中的數據，因此您可能希望通過查詢sys.database_recovery_status來驗證此查詢的結果，以查看最後一個log_backup_lsn的值（請參見列表3.5），或查看sys.databases表以查看log_reuse_wait_desc的值（將返回如果需要備份，則返回urn 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將對日誌備份的頻率進行最佳估計，然後觀察文件的增長特性，然後根據需要調整備份方案，以防止文件過大。

如何打破日誌鏈

如前所述，如果不首先進行至少一次完整備份，就不可能執行事務日誌備份。為了將數據庫恢復到某個時間點，或者恢復到特定日誌備份的末尾，或者恢復到特定日誌備份中的某個時間點，必須存在一個完整的完整的日誌記錄鏈，從完整（或差異備份）之後的第一個日誌備份到故障點。這就是所謂的日誌鏈。

有很多方法可以破壞日誌鏈，如果這樣做，則意味著您只能將數據庫恢復到破壞日誌鏈的事件發生之前的日誌備份時間。簡而言之，如果您關心恢復數據的能力，那麽斷開鏈並不是一個好主意。斷鏈最常見的兩種方法包括：

?事務日誌備份文件丟失或損壞

您只能恢復到上一次良好日誌備份。日誌鏈將在下一次良好的完整備份或差異備份時重新啟動。

?切換到簡單恢復模式

如果您從完全恢復模式切換到簡單恢復模式，這將破壞日誌鏈，因為將啟動檢查點，並且可以立即截斷事務日誌。當且如果您返回到完整模式，則需要進行另一個完整備份以重新啟動日誌鏈。實際上，在進行完整備份之前，數據庫將保持自動截斷模式，並且您將無法備份日誌文件。

在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選項將數據庫置於還原狀態，並假定要執行的下一個操作是還原。如果數據庫處於脫機狀態且無法啟動，則仍應嘗試按照剛才描述的方式備份日誌的尾部（盡管可以省略norecovery選項，因為不會進行任何事務）。

如果您確定日誌文件已損壞，文檔建議作為最後一種方法，您嘗試使用以下方法進行尾日誌備份：

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

如果主數據庫和數據文件已損壞，但日誌可用，Microsoft建議重建主數據庫，然後備份上一個活動日誌。但是，這些主題不在這個進階的範圍內，我將參考文檔了解更多的細節。請參閱http://msdn.microsoft.com/en-us/library/ms190952.aspx。

執行還原和恢復

在執行了尾日誌備份之後，如果可能的話，下一步是還原最後一次完整備份（如果合適，在後面是差異備份），然後還原日誌備份文件的完整序列，包括尾日誌備份。此還原操作序列的基本語法如下：

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

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

RESTORE DATABASE DatabaseName WITH RECOVERY

一個常見的要求是將數據庫還原到不同的位置，在這種情況下，您可以簡單地將文件作為還原過程的一部分移動，如下所述：http://msdn.microsoft.com/en-us/library/ms190255.aspx。

數據庫故障後恢復

下面的示例描述了如何恢復數據庫以響應故障，從而使數據庫數據文件不再可訪問。

完全恢復到故障點

假設“實時”事務日誌可以在數據庫故障（可能由硬件故障引起）後訪問，那麽理論上，應該可以使用以下步驟恢復和恢復數據庫，直至故障點：

1 備份日誌的尾部

2 恢復最新的完整備份（如果適用，還包括差異備份）

3 依次還原在完全（或差異）備份之後執行並在失敗之前完成的每個事務日誌備份。

4 恢復尾日誌備份

5 恢復數據庫

聯機叢書中的許多示例演示了從“備份集”恢復和恢復，換句話說，是存儲所有備份的單個“設備”。實際上，這意味著當備份到磁盤時，備份設備是位於該磁盤上某個位置的單個.bak文件。

因此，例如，列表5.2中所示的簡單示例使用由一個完整備份和一個事務日誌備份組成的備份集，並演示如何執行完整恢復。為了運行此代碼，首先需要重新創建數據庫，然後插入一些示例數據行（為了方便起見，此級別的代碼下載中包含執行此操作的腳本CreateAndPopulateTestDB.sql）。您還需要在數據庫服務器的本地C盤上創建一個“Backups”目錄，或者根據需要修改文件路徑。測試數據庫

--執行測試數據庫的完整備份

--WITH FORMAT選項啟動新的備份集

--小心，因為它將覆蓋任何現有集

--完整備份成為集中的第一個文件

BACKUPDATABASETestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHFORMAT;

GO

--對測試數據庫執行事務日誌備份

--這是集合中的第二個文件

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB.bak‘

GO

——…<此處出現故障>…

 

--restore headeronly命令是可選的。

--它只是確認組成

——當前設置

RESTOREHEADERONLY

FROMDISK=‘C:\Backups\TestDB.bak‘

GO 

--備份日誌尾部以準備還原

--這將成為備份集的第三個文件

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHNORECOVERY;

GO 

--還原完整備份

RESTOREDATABASETestDB

FROMDISK=‘C:\Backups\TestDB.bak‘

WITHFILE=1,NORECOVERY;

--應用事務日誌備份

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB.bak‘

WITHFILE=2,NORECOVERY;

--應用尾日誌備份

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB.bak‘

WITHFILE=3,NORECOVERY;

--恢復數據庫

RESTOREDATABASETestDB

WITHRECOVERY;

GO

列表5.2：備份到備份集並從中恢復；不推薦

然而，使用備份集似乎是數據庫備份到磁帶時的遺留問題。當備份到磁盤時，使用這個方案是一個壞主意，因為，當然，備份文件將迅速增長非常大。

在實踐中，更常見的情況是，每個完整備份和事務日誌備份文件都將分別命名，並可能標記備份的時間和日期。例如，大多數第三方備份工具、流行的社區生成腳本以及SSMS中的維護計劃向導/設計器都將創建單獨的帶日期戳的文件，例如AdventureWorks_20080904_000001.bak。

因此，更常見的備份和恢復方案將使用唯一命名的備份，如列表5.3所示。

USEmaster;

BACKUPDATABASETestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHINIT;

GO

 

--對測試數據庫執行事務日誌備份

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB_log.bak‘

WITHINIT;

GO

——…<此處出現故障>…

 

--備份日誌尾部以準備還原

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB_taillog.bak‘

WITHNORECOVERY,INIT;

GO

 

--還原完整備份

RESTOREDATABASETestDB

FROMDISK=‘C:\Backups\TestDB.bak‘

WITHNORECOVERY;

 

--應用事務日誌備份

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB_log.bak‘

WITHNORECOVERY;

 

--應用尾日誌備份

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB_taillog.bak‘

WITHNORECOVERY;

 

--恢復數據庫

RESTOREDATABASETestDB

WITHRECOVERY;

GO

列表5.3：備份和恢復唯一命名的備份文件

時間點恢復到最後一次良好的日誌備份

不幸的是，有時可能無法執行完全還原；例如，如果由於失敗而導致實時事務日誌不可用。在這種情況下，我們只需要恢復到最新日誌備份的末尾。需要為這種情況做準備，即包含事務日誌的驅動器發生故障，這決定了日誌備份的頻率。如果您每15分鐘進行一次備份，那麽您將面臨15分鐘數據丟失的風險。

假設我們已經執行了列表5.4所示的備份序列。為了這個演示，我們正在覆蓋以前的備份文件，備份順序明顯比實際情況縮短了很多。

--淩晨2點完全備份

USEmaster ;

BACKUPDATABASETestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHINIT ;

GO

 

--淩晨2:15記錄備份1

USEmaster ;

BACKUPLOGTestDB

TODISK=‘C:\Backups\TestDB_log.bak‘

WITHINIT ;

GO

 

--2.30 AM時的日誌備份2

USEmaster ;

BACKUPLOGTestDB

TODISK=‘C:\Backups\TestDB_log2.bak‘

WITHINIT ;

GO

列表5.4：一系列簡短的日誌備份

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

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

--還原完整備份

RESTOREDATABASETestDB

FROMDISK=‘C:\Backups\TestDB.bak‘

WITHNORECOVERY;

 

--還原日誌文件1

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB_log.bak‘

WITHNORECOVERY,STOPAT =‘Jan 01, 2020 12:00 AM‘;

--還原日誌文件2

RESTORELOGTestDB

FROMDISK=‘C:\Backups\TestDB_Log2.bak‘

WITHNORECOVERY,STOPAT =‘Jan 01, 2020 12:00 AM‘;

--恢復數據庫

RESTOREDATABASETestDB

WITHRECOVERY;

GO

列表5.5：使用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。

“事務破壞”後恢復

在任何數據庫故障的上下文之外，可能需要還原數據庫備份和事務日誌，以便在錯誤的數據修改（例如刪除或截斷表）之前將數據庫返回到特定的時間點。

你對這種情況的反應將取決於問題的性質。如果可能，您可以斷開所有用戶與數據庫的連接（在通知他們之後），並評估剛剛發生的事情的影響。在某些情況下，您可能需要估計問題發生的時間，然後使用時間點還原對數據庫和日誌進行完全恢復。一旦恢復完成，您就必須通知用戶一些事務可能已經丟失，並請求原諒。

當然，您通常無法以這種方式中斷正常的業務操作，以修復意外的數據丟失。由於實時數據庫仍在運行和訪問中，您可以嘗試在待機模式下還原數據庫的備份。這允許進一步還原日誌備份，但與使用norecover時不同的是，數據庫仍然是可讀的。還原方案可能如下所示：

1 在備用模式下，在實時數據庫旁邊還原數據庫的備份

2 將日誌前滾到壞事務發生之前的點，數據丟失。

3 將丟失的數據復制到實時數據庫，並刪除還原的副本

當然，這個過程不一定簡單，而且可能非常耗時。除非您購買了專門的日誌讀取工具，並且可以直接查詢日誌備份，否則向前滾動日誌可能意味著一系列艱苦的步驟，包括恢復日誌、檢查數據、進一步恢復等等，直到您確定錯誤事務發生的確切位置。步驟3也可能很困難，因為您將向實時系統引入不一定與數據庫當前狀態一致的數據，因此可能存在引用完整性問題。

讓我們來看一個實現上述步驟1和2的示例。首先，讓我們從頭開始，運行CreateAndPopulateTestDB.sql腳本重新創建數據庫，並將10行測試數據插入到新的LogTest表中。在列表5.6中，我們只需執行完整的數據庫備份（覆蓋任何以前的備份文件）。如果尚未創建“備份”目錄，則需要創建該目錄，或者根據需要調整路徑。測試數據庫

--數據庫的完整備份

BACKUPDATABASETestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHINIT;

GO

列表5.6:TestDB的完整備份

然後我們在LogTest表中插入一行新數據。

USETestDB

GO

INSERTINTO[TestDB].[dbo].[LogTest]

           ([SomeInt]

           ,[SomeLetters2])

     VALUES

           (66666,

          ‘ST‘)

           

SELECT*FROMdbo.LogTest

列表5.7：在TestDB中插入第11行

現在我們有了一個在LogTest表中包含11行的數據庫TestDB，以及一個包含10行的備份版本。現在讓我們在日誌備份中捕獲額外的修改，如列表5.8所示。測試數據庫

USEmaster

GO

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB_log.bak‘

WITHINIT;

GO

列表5.8:TestDB的日誌備份

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

USETestDB

GO

DROPTABLEdbo.LogTest ;

 

USEmaster

GO

BACKUPLogTestDB

TODISK=‘C:\Backups\TestDB_log2.bak‘

WITHINIT;

GO

列表5.9：災難！

為了在不中斷正常業務操作的情況下嘗試檢索丟失的數據，我們將在待機模式下還原數據庫的副本。備用數據庫的數據和日誌文件（稱ANewTestDB）被移動到一個“備用”目錄（您需要預先創建這個目錄）。測試數據庫

--還原TestDB數據庫的副本，調用

--ANewTestDB，待機狀態

USEmaster ;

GO

RESTOREDATABASEANewTestDB

   FROMDISK=‘C:\Backups\TestDB.bak‘

   WITHSTANDBY=‘C:\Backups\ANEWTestDB.bak‘,

   MOVE ‘TestDB_dat‘ TO‘C:\Standby\ANewTestDB.mdf‘,

   MOVE ‘TestDB_log‘ TO‘C:\Standby\ANewTestDB.ldf‘

GO

列表5.10：在待機模式下還原TestDB的副本

我們現在有了一個名為ANewTestDB的新數據庫，它處於“待機/只讀”模式，如圖5.1所示。

圖5.1：備用數據庫

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

--數據庫的完整備份

BACKUPDATABASETestDB

TODISK=‘C:\Backups\TestDB.bak‘

WITHINIT;

GO

列表5.11：在待機模式下將日誌備份還原到ANewTestDB數據庫

此時，對ANewTestDB的查詢將顯示11行，現在我們可以準備將數據復制回實時數據庫。如果我們更進一步並恢復第二個日誌備份，我們就會意識到我們做得太過分了，而且備用數據庫中的表也會丟失。

與執行備用恢復相比，另一種方法是考慮使用第三方工具，如Red Gate的SQL虛擬恢復，它提供了一種將備份作為活動的、完全功能的數據庫進行裝載的方法，而無需進行物理恢復。

無論DBA喜歡與否，開發人員通常都可以訪問生產數據庫來執行特殊的數據加載和更改。DBA和開發人員的共同責任是確保這些過程順利進行，因此不會導致需要剛才描述的那種操作的問題。我們稍後將在第6級中討論這個主題——處理批量操作。

當然，所需修復操作的確切性質取決於壞事務的性質。如果一個表被“意外地丟棄”，那麽很可能您將使用備用路由進行恢復。在其他時候，您可能不需要簡單地創建一個腳本來“逆轉”惡意修改。

如果損壞只影響單個列或有限的行數，那麽作為替代方法，可以使用諸如SQL數據比較之類的工具，該工具可以直接與備份文件進行比較，並且可以執行行級還原。

或者，如果運行SQL Server 2005（或更高版本）Enterprise Edition，並且提供了最新的數據庫快照，則可以對快照運行查詢，以便在獲取數據庫快照時檢索數據，然後編寫更新或插入命令，將數據從數據庫快照拉入實時源數據庫。

最後，作為最後的手段，一個專門的日誌閱讀器工具可以幫助您逆轉事務的影響，盡管我不知道在SQL Server 2005和更高版本中有任何可靠的工作。

總結

在這個級別中，我們介紹了備份和恢復以完全恢復模式運行的數據庫的日誌文件的基本知識，這將是許多生產數據庫的標準。

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

在損壞、驅動器故障等情況下，如果幸運的話，時間點恢復可能涉及備份事務日誌的尾部並恢復到故障點的權限。如果事務日誌不可用，或者為了在發生“壞事務”之前恢復到某個時間點而進行恢復，那麽情況會變得更加棘手，但希望本步驟中介紹的某些技術會有所幫助。

資源：

交易記錄進階級別代碼.zip

本文是SQL Server階梯中事務日誌管理階梯的一部分。

原文鏈接：Stairway to Transaction Log Management in SQL Server, Level 5: Managing the Log in Full Recovery Modev

SQL Server中事務日誌管理的步驟，第5級：完全恢復模式管理日誌