資料庫中事務日誌管理的階梯，級別5：以完全恢復模式管理日誌

原文連結：http://www.sqlservercentral.com/articles/Stairway+Series/73785/

作者：Tony Davis, 2012/01/27

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

當事情進展順利時，沒有必要特別注意事務日誌的作用或它是如何工作的。您只需要確認每個資料庫都有正確的備份機制。當事情出錯時，對事務日誌的理解對於採取糾正措施是很重要的，特別是當需要對資料庫進行實時恢復時。託尼·戴維斯給出了每個DBA都應該知道的正確的細節水平。

在這個級別上，我們將回顧為什麼以及如何完整備份，如何使用這些日誌備份檔案與完整資料庫備份一起執行資料庫還原。完整備份支援資料庫還原到可用日誌備份中的任何時間點，並且可以進行尾日誌備份，直到上次提交的事務發生之前。

什麼會被記錄？

在完整備份中，所有操作都會被完全記錄下來。包括INSERT, UPDATE和DELETE操作，這意味著對於被修改的每一行，都會有一個日誌記錄，描述執行語句的事務的ID、事務開始和結束時間、哪些頁面、資料更改等等。

可以最少記錄的操作有SELECT INTO, BULK INSERT和CREATE INDEX，在完全備份中，但略有不同。受這些操作影響的行不會單獨記錄；相反，只有資料庫頁在填充時才會被記錄。這減少了此類操作的日誌記錄，同時確保仍然存在執行回滾、重做和點時間恢復所需的所有相同資訊。Kalen Delaney發表了一些關於伐木的調查SELECT INTO(

http：/sqlblog.com/blog/Kalen_Delaney/Archive/2011/03/15/什麼-獲取日誌-為-選擇-into.aspx)和索引重建(http：/sqlblog.com/blog/Kalen_Delaney/Archive/2011/03/08/什麼-獲取日誌-for-index-rebuilds.aspx)業務，均為完整備份和完整日誌備份。工作時，差異日誌記錄操作時日誌記錄的不同之處。日誌備份，將在第6級 – 管理登入 大容量日誌 恢復

為什麼備份事務日誌？

在完整備份中，只有日誌備份才能導致日誌的截斷。因此，事務日誌將儲存自上次備份事務日誌以來執行的事務的完整記錄。由於所有操作都是完全記錄的，日誌檔案在繁忙的系統中可以非常大、非常快地增長。

因此，完整備份時，它會進行定期的事務日誌備份，除了完全備份之外，還可以選擇差異備份。許多新手或兼職DBA在其資料庫上執行完全備份，但不執行事務日誌備份。因此，事務日誌不會被截斷，它會不斷增長，直到它所在的驅動器耗盡磁碟空間，從而導致資料庫停止工作。

日誌的截斷將在日誌備份後立即發生，前提是自上一次備份以來就發生了檢查點，並且沒有其他因素延遲截斷，例如資料備份或還原操作。有關可能延遲截斷可恢復VLFS的因素的完整列表，以及保持日誌中大量活動(否則不需要)的因素，如流氓、長時間執行的未提交事務或資料庫映象或複製程序，請參見：http：/msdn.microsoft.com/en-GB/Library/ms345414.aspx.

僅複製事務日誌的備份

僅複製事務日誌的備份不會截斷事務日誌。一個僅複製日誌備份與常規日誌備份方案“獨立”存在；它不會破壞日誌備份鏈。簡而言之，事務日誌備份具有雙重功能，即允許恢復和恢復到以前的時間點，以及控制事務日誌的大小。可能與事務日誌相關的問題最常見的原因是完整備份，只是不進行日誌備份，或者沒有頻繁地進行日誌備份以控制事務日誌檔案的大小。

如果不確定給定資料庫是否正在進行事務日誌備份，則只需查詢回溯表中的MSDB資料庫，使用類似於清單5.1所示的查詢。

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：是否進行日誌備份？

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

注意，由於本文中的資料回溯表可以在不影響備份和還原行為的情況下進行操作，您可能希望通過查詢驗證此查詢的結果。sys.database_recovery_status的價值last_log_backup_lsn(參見清單3.5)，或sys.databases表以檢視log_reuse_wait_desc(將返回日誌備份如果需要備份)。

如何備份事務日誌

如前所述，如果不首先進行至少一次完全備份，就不可能執行事務日誌備份。實際上，如果您的資料庫位於完整備份，但是從來沒有備份過，那麼它實際上不會在完整備份執行第一次完全備份之前，資料庫將處於自動截斷模式。所有資料庫備份，包括完整備份、日誌備份或其他備份，都將使用備份命令。該命令接受許多選項，這些選項記錄在這裡：http：/msdn.microsoft.com/en-us/Library/ms 186865.aspx。但是，在其最基本的(通常是如何使用它)中，執行磁碟完整備份的命令如下所示：

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

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

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

但是，最常見的情況是，隨後的每個備份都有一個惟一的名稱；在接下來的部分中將對此進行更詳細的介紹，恢復到故障點.

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

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

儲存日誌備份

顯然，備份的資料和日誌檔案不應該儲存在承載活動檔案的同一驅動器上。如果該驅動器遇到硬體故障，那麼您的所有副本都將與實時檔案一起丟失，而備份也將徒勞無功。檔案應備份到單獨的裝置，或備份到本地映象驅動器。

日誌備份頻率

如前所述，您可能每15分鐘進行一次日誌備份，或者甚至更頻繁地進行日誌備份。在這種情況下，為了避免需要還原大量事務日誌檔案，您可以選擇採用一種備份方案，該備份方案由包含差異備份的完整備份組成，這些備份與事務日誌備份交織在一起。

在現實中，備份方案通常更多地是在理想和實際之間，在評估資料丟失的真實風險和公司將付出的代價之間，以及在減輕風險所涉及的成本之間達成妥協。許多非常重要的業務應用程式使用了一些簡單但嚴格的備份方案，可能涉及定期的夜間完整備份和小時事務日誌備份。

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

沒有一種簡單的方法可以計算日誌備份的頻率。大多數DBA將對應該進行日誌備份的頻率進行最佳估計，然後觀察檔案的增長特徵，然後根據需要調整備份方案，以防止檔案過大。

日誌鏈及其破解

如前所述，如果不首先進行至少一次完全備份，就不可能執行事務日誌備份。為了將資料庫恢復到某個時間點，無論是某個特定日誌備份的結束，還是某個特定日誌備份中的某個時間點，必須存在一個完整的日誌記錄鏈，從完整(或差異備份)之後的第一次日誌備份到故障點。這被稱為日誌鏈.打破日誌鏈的方法有很多種，如果這樣做，就意味著只能將資料庫恢復到在中斷鏈的事件發生之前進行日誌備份的時間。總之，如果您不關心恢復資料的能力，打破鏈是個好主意。打破鏈條的兩種最常見的方式包括：

• 事務日誌備份檔案的丟失或損壞-您只能恢復到上次良好的日誌備份。日誌鏈將在下一個良好的完整備份或差異備份時再次啟動。
• 切換到簡單恢復模式-如果你從完整到簡單恢復模式，這將打破日誌鏈，因為檢查點將被啟用，事務日誌可以立即被截斷。什麼時候，如果你回到完整模式下，需要進行另一次完全備份才能重新啟動日誌鏈。實際上，在進行完全備份之前，資料庫將保持自動截斷模式，並且無法備份日誌檔案。

在資料庫2008之前，有兩個命令，即當BACKUP LOG WITH NO_LOG或BACKUP LOG WITH TRUNCATE_ONLY(它們在功能上是等價的)發出時，將強制日誌檔案截斷，從而破壞日誌鏈。您不應該在任何版本的資料庫中發出這些命令，但我在這裡提到它們，因為在試圖處理“失控日誌檔案”時，它們仍然會被粗心大意者使用，而不瞭解它們對恢復資料庫能力的影響。看見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

如果主資料庫和資料檔案損壞，但日誌可用，則建議重新生成主資料庫，然後備份最後一個活動日誌。但是，這些主題超出了本階梯的範圍，有關詳細資訊，請參閱文件。看見http：/msdn.microsoft.com/en-us/Library/ms190952.aspx.

執行恢復和恢復

在執行了尾日誌備份之後，如果可能的話，下一步是恢復最後一個完整備份(如果適當的話，接著是差異備份)，然後恢復日誌備份檔案的完整序列，包括尾日誌備份。此還原操作序列的基本語法如下：

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

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

RESTORE DATABASE DatabaseName WITH RECOVERY

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

資料庫故障後恢復

下面的示例描述如何在發生故障時恢復資料庫，從而無法再訪問資料庫資料檔案。

完全恢復到故障點

假設“活動”事務日誌可以在資料庫故障(可能是由硬體故障引起的)之後到達，那麼理論上應該可以通過使用以下步驟恢復和恢復資料庫直到故障點：

1. 備份尾日誌
2. 恢復最近的完整備份(如果適用，再加上差異備份)
3. 依次還原在完整(或差異)備份之後並在故障發生前完成的每個事務日誌備份。
4. 恢復尾日誌備份
5. 恢復資料庫

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

因此，例如，清單5.2中所示的簡單示例使用了由一個完整備份和一個事務日誌備份組成的備份集，並演示瞭如何執行完全恢復。為了執行這段程式碼，首先需要重新建立TestDB資料庫，然後插入幾行資料示例(為方便起見，指令碼要這樣做，CreateAndPopulateTestDB.sql，包含在此級別的程式碼下載中)。您還需要在本地建立一個“備份”目錄C:驅動資料庫伺服器，或酌情修改檔案路徑。

-- Perform a full backup of the Test database

-- The WITH FORMAT option starts a new backup set

-- Be careful, as it will overwrite any existing sets

-- The full backup becomes the first file in the set

BACKUP DATABASE TestDB

TO DISK = 'C:\Backups\TestDB.bak'

WITH FORMAT;

GO

 

-- Perform a transaction log backup of the Test database

-- This is the second file in the set

BACKUP Log TestDB

TO DISK = 'C:\Backups\TestDB.bak'

GO

 

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

 

-- The RESTORE HEADERONLY command is optional.

-- It simply confirms the files that comprise

-- the current set

RESTORE HEADERONLY

FROM DISK = 'C:\Backups\TestDB.bak'

GO

 

-- Back up the tail of the log to prepare for restore

-- This will become the third file of the bakup set

BACKUP Log TestDB

TO DISK = 'C:\Backups\TestDB.bak'

WITH NORECOVERY;

GO

 

-- Restore the full backup

RESTORE DATABASE TestDB

FROM DISK = 'C:\Backups\TestDB.bak'

WITH FILE=1, NORECOVERY;

 

-- Apply the transaction log backup

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB.bak'

WITH FILE=2, NORECOVERY;

 

-- Apply the tail log backup

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB.bak'

WITH FILE=3, NORECOVERY;

 

-- Recover the database

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

 

-- Perform a transaction log backup of the Test database

BACKUP Log TestDB

TO DISK ='C:\Backups\TestDB_log.bak'

WITH INIT;

GO

 

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

 

-- Back up the tail of the log to prepare for restore

BACKUP Log TestDB

TO DISK ='C:\Backups\TestDB_taillog.bak'

WITH NORECOVERY, INIT;

GO

 

-- Restore the full backup

RESTORE DATABASE TestDB

FROM DISK = 'C:\Backups\TestDB.bak'

WITH NORECOVERY;

 

-- Apply the transaction log backup

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB_log.bak'

WITH NORECOVERY;

 

-- Apply the tail log backup

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB_taillog.bak'

WITH NORECOVERY;

 

-- Recover the database

RESTORE DATABASE TestDB

WITH RECOVERY;

GO

清單5.3：備份和恢復唯一名稱的備份檔案

時間點恢復到上次良好日誌備份

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

假設我們執行了清單5.4所示的備份序列。為了這個演示，我們正在覆蓋以前的備份檔案，而且備份序列顯然比現實中的短得多。

-- FULL BACKUP at 2AM

USE master ;

BACKUP DATABASE TestDB

TO DISK = 'C:\Backups\TestDB.bak'

WITH INIT ;

GO

 

-- LOG BACKUP 1 at 2.15 AM

USE master ;

BACKUP LOG TestDB

TO DISK = 'C:\Backups\TestDB_log.bak'

WITH INIT ;

GO

 

-- LOG BACKUP 2 at 2.30 AM

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 Full backup

RESTORE DATABASE TestDB

FROM DISK = 'C:\Backups\TestDB.bak'

WITH NORECOVERY;

 

--RESTORE Log file 1

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB_log.bak'

WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';

 

--RESTORE Log file 2

RESTORE LOG TestDB

FROM DISK = 'C:\Backups\TestDB_Log2.bak'

WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';

 

--Recover the database

RESTORE DATABASE TestDB

WITH RECOVERY;

GO

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

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

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

還可以恢復到特定的標記事務。例如，當您需要將由某個應用程式訪問的多個數據庫還原到邏輯一致的點時，這是非常有用的。本主題不在此進一步討論，但您可以在聯機叢書上找到更多資訊(http：/msdn.microsoft.com/en-us/Library/ms 187014.aspx)，並在這裡提供了一個很好的示例：http：/weblogs.sqlWG.com/mladenp/Archive/2010/10/20/sql-server-Transaction-mark-MultiDatabaseto-a-Common.aspx。

在“壞事務”之後恢復

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

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

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

1. 在STANDBY模式下，與實時資料庫一起恢復資料庫的備份。
2. 將日誌前滾到錯誤事務發生之前的點，資料丟失。
3. 將丟失的資料複製到實時資料庫並刪除已還原的副本。

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

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

-- full backup of the database

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：將第11行插入到TestDB

所以現在我們在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）將移至“備用”目錄（您需要事先建立此目錄）。

-- restore a copy of the TestDB database, called

-- ANewTestDB, in STANDBY mode

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，它處於“備用/只讀”模式，如圖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(或更高版本)EnterpriseEdition，並且可以使用最近的資料庫快照，您就可以對快照執行一個查詢，以便在獲取資料庫快照時檢索資料，然後編寫一個UPDATE或INSERT命令將資料從資料庫快照中提取到實時的源資料庫中。

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

摘要

在這個級別上，我們已經介紹了備份和還原資料庫日誌檔案的基礎知識。這將是許多生產資料庫的標準。

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

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