十七周翻譯
SQL Server中的事務日誌管理的階梯:第5級:在完全恢復模式下管理日誌
該系列
本文是樓梯系列的一部分:SQL Server中的事務日誌管理的階梯
當事情進展順利時，沒有必要特別註意事務日誌的作用或它是如何工作的。您只需要確信每個數據庫都有正確的備份機制。當事情出錯時，對事務日誌的理解對於采取糾正措施非常重要，特別是當需要一個時間點的數據庫恢復時！Tony Davis給出了每個DBA都應該知道的正確的細節。
在這個級別上，我們將回顧在完全恢復模式下工作的原因和如何使用日誌備份，以及如何使用這些日誌備份文件執行數據庫恢復，並結合完整的數據庫備份。完全恢復模式支持在可用的日誌備份中對任何時間點進行數據庫恢復，並假定可以在發生故障之前進行尾日誌備份，直到最後一次提交事務的時間。
什麽記錄?
在完全恢復模式下，所有操作都被完全記錄下來。對於插入、更新和刪除操作，這意味著對於每一個被修改的行，都將有一個日誌記錄來描述執行語句的事務的ID，當事務開始和結束時，哪些頁面被更改，所做的數據更改，等等。
可以進行最低記錄的操作，批量插入並創建引索，當在完全恢復模式下工作時，仍然完全被記錄下來，但是它的工作方式略有不同。受這些操作影響的行沒有單獨記錄;相反，只有數據庫頁面會被記錄，因為它們會被填滿。這減少了對此類操作的記錄，同時確保仍然存在執行回滾、重做和點時間恢復所需的所有相同信息。Kalen德萊尼發表了一些調查記錄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)操作,完整和BULK_LOGGED恢復模式。在批量登錄模式下工作的日誌記錄的差異在第
為什麽要備份事務日誌?
在完全恢復模式下，只有一個日誌備份可以導致日誌的截斷。因此，事務日誌將保存自上次事務日誌備份以來執行的事務的完整且完整的記錄。由於所有操作都是完全日誌記錄的，所以日誌文件在繁忙的系統中可以非常快速地增長。
因此，當在完全恢復模式下工作時，除了完全備份和可選的差異備份之外，執行常規事務日誌備份是非常重要的。許多新手或兼職dba在他們的數據庫上執行完整的備份，但是他們不執行事務日誌備份。因此，事務日誌不會被截斷，它會不斷增長，直到磁盤空間耗盡，導致SQL服務器停止工作。
一旦日誌備份被執行，日誌的截斷就會發生，假設在之前的備份之後發生了一個檢查點，並且沒有其他的因素在延遲截斷，比如數據備份或恢復操作。完整列表的因素
對事務日誌的復制備份
只對事務日誌進行復制的備份不會截斷事務日誌。一個只復制日誌備份的日誌備份是“獨立”的;它不會破壞日誌備份鏈。
簡而言之，事務日誌備份執行雙重目的，允許恢復和恢復到以前的時間點，以及控制事務日誌的大小。可能是事務日誌相關問題最常見的原因是在完全恢復模式下工作，而不使用日誌備份，或者不頻繁地使用日誌備份來控制事務日誌文件的大小。
如果您不確定是否在給定的數據庫上執行了事務日誌備份，那麽您可以使用類似於清單5.1中所示的查詢來簡單地查詢MSDB數據庫中的back心煩表。
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微分備份。
註意，由於這個back心煩表中的數據可以在不影響備份和恢復行為的情況下進行操作，所以您可能需要通過查詢sys來驗證您的發現。數據庫恢復狀態，以查看lastlogbackuplsn的值(請參見清單3.5)或系統。數據庫表，以查看logreusewaitdesc的值(如果需要備份，將返回logbackup)。
如何備份事務日誌
正如前面所討論的，在不進行至少一次完整備份的情況下執行事務日誌備份是不可能的。實際上，如果您有一個完全恢復模式的數據庫，但是從來沒有備份過，那麽它實際上不會在完全恢復模式下工作。數據庫將處於自動截斷模式，直到執行第一個完整的備份。
所有數據庫備份，全部，日誌或其他，都是使用備份命令執行的。命令接受大量的選項,文檔:http://msdn.microsoft.com/en-us/library/ms186865.aspx。但是，在最基本的情況下，通常是如何使用它的，執行完整備份到磁盤的命令如下:
備份數據庫到磁盤=‘FileLocation\DatabaseName.bak‘;
如果這是要執行的第一個備份，則是DatabaseName。將在指定的目錄中創建bak文件。如果已經存在這樣的文件，那麽默認的行為是將後續的備份附加到該文件。為了覆蓋這個行為，並規定任何現有的文件都應該被覆蓋，我們可以使用INIT選項，如下:
備份數據庫到磁盤=‘FileLocation\DatabaseName.bak‘WITH INIT;
然而，最常見的情況是，每個後續的備份都有一個惟一的名稱;關於這一點，在接下來的部分中，將會恢復到失敗的程度。
在每一個常規的(例如日常)的備份之後，將會有頻繁的(例如每小時)日誌備份，基本的命令非常相似:
備份數據庫到磁盤=‘FileLocation\DatabaseName_Log.bak‘;
存儲日誌備份
顯然，備份的數據和日誌文件不應該存儲在承載活動文件的同一驅動器上。如果該驅動器受到硬件故障的影響，那麽您的所有副本將與實時文件一起丟失，而備份將是無效的。文件應該備份到一個單獨的設備上，或者備份到本地鏡像驅動器上。
日誌備份的頻率
正如前面提到的，您可能每15分鐘就會使用日誌備份，甚至可能更頻繁。在這種情況下，為了避免需要恢復大量的事務日誌文件，您可以選擇采用一種備份方案，其中包含了包含有差異備份的完整備份，並穿插了事務日誌備份。
在現實中，備份計劃通常更像是理想與現實之間的折衷，是對數據丟失真實風險的評估，以及它將對公司造成的損失，以及降低風險的成本。許多非常重要的業務應用程序使用了一些簡單的、但嚴格的備份計劃，可能包括定期的每夜完全備份，以及每小時的事務日誌備份。
日誌備份的頻率也可能由數據庫所受的事務數量決定。對於非常繁忙的數據庫，為了控制日誌的大小，可能需要頻繁地進行備份。
要計算日誌備份的頻率是不容易的。大多數dba將對日誌備份的頻率進行最佳估計，然後觀察文件的增長特性，然後根據需要調整備份計劃，以防止它們變得過大。
日誌鏈，以及如何打破它
正如所指出的，如果不首先進行一次完整的備份，就不可能執行事務日誌備份。為了恢復一個數據庫的時間點,要麽結束的一個特定的日誌備份或時間點在一個特定的日誌備份,一定存在一個完整的日誌記錄,從第一個日誌備份後,一個完整
的(或微分備份),直到故障點。這就是所謂的對數鏈。
有很多方法可以打破這個日誌鏈，如果您這樣做，就意味著只有在事件發生之前，才能夠恢復數據庫，以便在事件發生之前進行日誌備份。簡而言之，如果您關心恢復數據的能力，那麽打破這個鏈條並不是一個好主意。打破這一鏈條的最常見的兩種方法包括:
事務日誌備份文件的丟失或損壞——您將只能恢復到最後一個良好的日誌備份。日誌鏈將在下一個良好的全或差備份中重新啟動。
切換到簡單的恢復模式——如果您從完全恢復模式切換到簡單的恢復模式，這將破壞日誌鏈，因為一個檢查點將被啟動，事務日誌可以立即被截斷。當您返回到FULL模式時，您將需要另一個完整的備份來重新啟動日誌鏈。實際上，在您進行完全備份之前，數據庫將保持自動截斷模式，您將無法備份日誌文件。
在sql Server 2008之前，有一些命令，即帶有nolog的備份日誌或僅帶樹幹的備份日誌(它們在功能上是等價的)，在發出時，會強制執行日誌文件截斷，從而破壞日誌鏈。您不應該在任何版本的SQL Server中發出這些命令，但是我在這裏提到它們，因為它們在處理“失控的日誌文件”時仍然會使用這些命令，而不理解它們對恢復數據庫的能力有何影響。看第8級-幫助，我的日誌已經滿了，更多的細節。
尾日誌備份
只要您有一個完整的備份和一個完整的日誌鏈，您就可以將數據庫恢復到在任何故障之前，它存在於最終日誌備份的末尾的狀態。但是，假設您每小時以小時為單位執行事務日誌備份，並且在下午1點45分發生故障。你可能會損失45分鐘的數據;實際上，如果失敗是如此的災難性，實時事務日誌無法恢復，那麽這就是您將丟失的數據量。
然而，即使數據文件不存在，有時仍然可以使用實時事務日誌，特別是如果事務日誌包含在一個單獨的專用驅動器上。如果是這種情況，您應該備份live事務日誌，即執行自上次日誌備份以來生成的日誌記錄的最終備份。這將捕獲實時日誌文件中剩余的日誌記錄，直至故障點。這被稱為尾日誌備份，是在開始恢復和恢復操作之前應該執行的最後一個操作。
尾日誌備份和最小日誌操作
如果由於數據庫故障導致數據文件不可用，日誌的尾部包含最少的日誌記錄操作，那麽就不可能進行尾日誌備份，因為這需要訪問數據文件中更改的數據區段。這將在第6級更詳細地介紹，在批量日誌模式下管理事務日誌。
如果您希望恢復的數據庫是聯機的，那麽日誌的尾部就會備份如下:
備份數據庫到磁盤=‘FileLocation\DatabaseName_Log.bak‘WITH NORECOVERY
norecooption選項將數據庫置於恢復狀態，並假設您希望執行的下一個操作是恢復。如果數據庫是離線的，並且不會啟動，那麽您仍然應該嘗試按照剛才描述的方式備份日誌的尾部(盡管可以忽略noreco選項，因為沒有任何事務正在進行中)。
如果您確定日誌文件損壞了，那麽文檔說明，作為最後的手段，您可以嘗試做一個尾日誌備份:
備份數據庫到磁盤=‘FileLocation\DatabaseName_Log.bak‘WITH CONTINUE_AFTER_ERROR
如果主數據庫和數據文件被損壞，但是日誌是可用的，微軟建議重新構建主數據庫，然後備份最後一個活動日誌。然而，這些主題超出了這一階梯的範圍，我將向您介紹進一步的詳細信息。見http://msdn.microsoft.com/en-us/library/ms190952.aspx。
執行恢復和恢復
如果可能的話，執行了尾部日誌備份，下一步是恢復最後一個完整的備份(如果適當的話，後面是差異備份)，然後恢復日誌備份文件的完整序列，包括尾部日誌備份。這個恢復操作序列的基本語法如下:
從磁盤=‘FileLocation文件名恢復數據庫日誌數據庫。貝克‘WITH NORECOVERY;
如果在恢復時，刪除了noreco選項，那麽在默認情況下，恢復命令將繼續進行恢復。換句話說，SQL Server將嘗試協調數據和日誌文件，將已完成的事務向前滾動，然後在必要時回滾未完成的事務。通過使用norecowe指定，我們正在指示SQL Server，我們正在進入一個恢復序列，並且在執行任何回滾之前，必須將更多的操作向前推進。在恢復恢復序列中的最後一個備份之後，可以恢復數據庫，如下所列:
恢復數據庫數據庫的恢復
一個常見需求是將數據庫恢復到一個不同的位置,在這種情況下,您可以簡單地將文件恢復過程的一部分,這裏所描述的那樣:http://msdn.microsoft.com/en-us/library/ms190255.aspx。
數據庫故障後恢復
下面的示例描述了如何在響應失敗時恢復數據庫，從而使數據庫數據文件不再可訪問。
完全恢復故障點
假設“live”事務日誌可以在數據庫失敗之後達到，這可能是由於硬件故障導致的，那麽理論上應該可以通過以下步驟來恢復和恢復您的數據庫。
1、備份日誌的尾部
2、恢復最近的全備份(如果可以的話，還可以使用微分)
2、反過來，恢復在完全(或差異)備份之後進行的每個事務日誌備份，並在故障發生之前完成備份。
3、恢復尾日誌備份
5、恢復數據庫
在線書籍中發現的許多例子都表明了“備份集”的恢復和恢復，換句話說，就是一個“設備”，所有備份都存儲在其中。在實際操作中，這意味著當備份到磁盤時，備份設備是單一的。這個文件位於磁盤的某個地方。
例如，清單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中的維護計劃向導/設計器，都將創建單獨的日期戳的文件，例如adventureworksfull20080904000001.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所示。
--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:使用STOPAT恢復到某個時間點
由於我們在將來指定了一個停止時間，這段代碼將把所有已完成的事務轉發到第二個事務日誌的末尾。
或者，也可以指定在特定日誌文件中記錄的事務的時間範圍內的停止時間。在這種情況下，數據庫將被恢復到指定時間的最後一個提交事務。當您知道需要恢復什麽時間時，這是很有用的，但是不知道日誌備份包含了什麽時間。
還可以恢復到一個特定的標記事務。例如，當您需要恢復某個應用程序訪問的多個數據庫，以達到邏輯上一致時，這是很有用的。這裏沒有進一步討論這個話題,但是你可以找到更多圖書在線(http://msdn.microsoft.com/en-us/library/ms187014.aspx),和姆Prajdic提供了一個很好的例子:http://weblogs.sqlteam.com/mladenp/archive/2010/10/20/sql-server-transaction-marks-restoring-multiple-databases-to-a-common.aspx。
在“糟糕的交易”之後恢復
在任何數據庫失敗的情況下，可能需要恢復數據庫備份，再加上事務日誌，以便在錯誤的數據修改之前及時將數據庫返回到某個特定的點上，這樣就會刪除或截斷表。
你對這種情況的反應將取決於問題的性質。如果可能，您可能會將所有用戶從數據庫斷開(在通知他們之後)，並評估所發生的事情的影響。在某些情況下，您可能需要估計問題發生的時間，然後使用時間恢復的點對數據庫和日誌進行全面恢復。一旦恢復完成，您就必須通知用戶一些事務可能已經丟失，並請求原諒。
當然，通常您不能以這種方式中斷正常的業務操作，從而修復意外的數據丟失。由於live數據庫仍然處於運行狀態，並且正在被訪問，所以您可以嘗試在備用模式中恢復數據庫的備份。這允許重新恢復日誌備份，但是與使用noreco非常不同，數據庫仍然是可讀的。恢復計劃可能是這樣的:
1、恢復數據庫的備份，在備用模式下，與實時數據庫一起
2、在出現錯誤的事務之前，將日誌滾到該點，數據丟失了
2、將丟失的數據復制到實時數據庫並刪除已恢復的副本
當然，這個過程並不一定是直接的，而且可能非常耗時。除非您已經購買了專門的日誌閱讀工具，並且可以直接查詢日誌備份，否則，將日誌向前滾動可能意味著一系列艱苦的步驟，包括恢復日誌、檢查數據、恢復進一步的數據等等，直到您確定了錯誤的事務發生的確切位置。步驟3也很困難，因為您將把數據引入到與數據庫當前狀態不一致的實時系統中，因此可以引用
讓我們來看一個實現上述步驟1和步驟2的示例。首先，讓我們從頭開始，運行CreateAndPopulateTestDB。用於重新創建TestDB數據庫的sql腳本，並將10行測試數據插入到一個新的日誌測試表中。在清單5.6中，我們只做一個完整的數據庫備份(覆蓋以前的備份文件)。如果您還沒有這樣做，那麽您需要創建“備份”目錄，或者適當地調整路徑。
-- full backup of the database
BACKUP DATABASE TestDB
TO DISK =‘C:\Backups\TestDB.bak‘
WITH INIT;
GO
清單5.6:TestDB的完整備份，然後將一個新的數據行插入到LogTest表中。
然後，我們將一個新的數據行插入到LogTest表中。
USE TestDB
GO
INSERT INTO [TestDB].[dbo].[LogTest]
([SomeInt]
,[SomeLetters2])
VALUES
(66666,
‘ST‘)
SELECT * FROM dbo.LogTest
清單5.7:將第11行插入到TestDB中
現在，我們有一個實時的TestDB數據庫，在LogTest表中有11行，一個有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:災難!
為了嘗試檢索丟失的數據，不中斷正常的業務操作，我們將在備用模式中恢復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:在備用模式中恢復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:在備用模式下恢復到ANewTestDB數據庫的日誌備份
此時，針對ANewTestDB的查詢將顯示11行，現在我們可以將這些數據復制到實時數據庫中。如果我們更進一步，恢復了第二個日誌備份，那麽我們就會意識到我們已經走得太遠了，在備用數據庫中也會丟失這個表。
備用恢復的另一種選擇是考慮使用第三方工具，如Red Gate的SQL虛擬恢復，它提供了一種將備份作為實時的、功能完備的數據庫，而不需要物理恢復的方法。
不管dba是否喜歡，開發人員通常都可以訪問生產數據庫來執行特定的數據加載和更改。DBA和開發人員的共同職責是確保這些進展順利進行，因此不會導致需要描述的操作的問題。我們將在稍後的第6級回到這個主題——處理批量操作。當然，所需要的修復行動的確切性質取決於糟糕交易的性質。如果一個表被“意外地刪除”，那麽很有可能您將使用備用路徑沿著恢復的方向前進。在其他時候，您可以簡單地創建一個腳本，以“反轉”這個流氓的修改。
如果損害只影響單個列或有限的行數，那麽作為另一種選擇，可以使用SQL數據比較之類的工具，它可以直接與備份文件進行比較，並且可以進行行級別的恢復。或者,如果您運行SQL Server 2005企業版(或更高版本),並提供最近的數據庫快照,您可以運行一個查詢檢索數據的快照,因為它看起來當時數據庫快照,然後寫一個更新或插入命令將數據從數據庫快照進入生活,源數據庫。
如果損害只影響單個列或有限的行數，那麽作為另一種選擇，可以使用SQL數據比較之類的工具，它可以直接與備份文件進行比較，並且可以進行行級別的恢復。或者,如果您運行SQL Server 2005企業版(或更高版本),並提供最近的數據庫快照,您可以運行一個查詢檢索數據的快照,因為它看起來當時數據庫快照,然後寫一個更新或插入命令將數據從數據庫快照進入生活,源數據庫。
摘要
在這個級別上，我們已經介紹了備份和恢復以完全恢復模式運行的數據庫日誌文件的基礎知識，這將是許多生產數據庫的規範。
對於大多數dba來說，執行一個時間點恢復的需求是一個罕見的事件，但是這是其中一個任務，如果有必要，它是非常重要的，它可以做得很好;DBA的聲譽取決於它。
在腐敗、驅動失敗等方面，時間點的恢復可能涉及到，如果您幸運的話，可以備份事務日誌的尾部並恢復到故障點。如果事務日誌不可用，或者如果您正在恢復，以便在出現“壞事務”之前恢復到某個時間點，那麽情況將變得更加復雜，但是希望本文所涉及的一些技術將會有所幫助。
資源:
TransactionLogStairway_Level5_Code.zip
本文是SQL Server階梯上的事務日誌管理的一部分
註冊到我們的RSS訂閱源，當我們在樓梯上發布一個新級別的時候，就會得到通知！
十七周翻譯