sql伺服器第5級事務日誌管理的階梯：完全恢復模式下的日誌管理
sql伺服器第5級事務日誌管理的階梯：完全恢復模式下的日誌管理
原文連結http://www.sqlservercentral.com/articles/Stairway+Series/73785/
作者 Tony Davis, 2012/01/27
系列
本文是階梯系列的一部分：sql伺服器中事務日誌管理的樓梯
當事情進展順利時，沒有必要特別注意事務日誌的工作或工作方式。你只需要確信每個資料庫都有正確的備份系統。當出現問題時，對事務日誌的理解對於採取糾正行動非常重要，特別是當需要立即對資料庫進行點對點恢復時！作者Tony Davis給出了每個資料庫管理員
在此級別中，我們將討論在完全恢復模式下工作時為什麼要日誌備份、如何進行日誌備份，以及如何使用這些日誌備份檔案與完整資料庫備份一起執行資料庫還原。完全恢復模式支援資料庫恢復到可用日誌備份中的任何時間點，並且假設可以進行跟蹤日誌備份，在故障發生之前的上次提交的事務。
什麼會被記錄？
在完全恢復模式下，所有操作都已完全登入。對於插入、更新和刪除操作，這意味著對於每個被修改的行，將有一個日誌記錄，描述執行該語句的事務的id，該事務開始和結束時，哪些頁被更改，所做的資料更改，等等。
在完全恢復模式下，可以進行最小程度的登入選擇、批量插入和建立索引的操作仍然會被完全記錄，但操作略有不同。受這些操作影響的行不會單獨記錄，而只會在資料庫頁面被填充時進行記錄。這減少了這種操作的偶然聽到的日誌記錄，同時確保仍然存在執行回滾、重做和時間恢復點所需的所有相同的資訊。
(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) 。在完整和大容量日誌恢復模式中。在第6級----在批量日誌恢復模式下管理日誌----中更詳細地討論了最小日誌操作的日誌記錄的不同。
為什麼要備份事務日誌？
在完全恢復模式下，只有日誌備份才能導致日誌的截斷。因此，事務日誌將儲存自上次備份事務日誌以來所進行的交易的完整記錄。由於所有操作都已完全登入，日誌檔案在繁忙的系統中可以非常多、非常快地增長。
因此，在完全恢復模式下工作時，執行常規事務日誌備份是非常重要的，此外還有完整的備份和可選的差異備份。許多新手或兼職的資料庫管理員，在他們的資料庫中執行完整的備份，但是他們不執行事務日誌備份。因此，事務日誌不會被截斷，並且它會不斷地增長，直到它執行的驅動器的磁碟空間用完，從而導致sql伺服器停止工作。
一旦進行日誌備份，日誌就會被截斷，假設檢查點已發生自上次備份後，並且沒有其他因素延遲截斷，例如資料備份或還原操作。用於獲取可能延遲截斷可恢復的虛擬日誌檔案的全部因素列表，以及使日誌中的大部分割槽域保持活動狀態而不需要保持活動狀態的因素，例如流氓的、長期執行的未提交的事務或資料庫映象或複製過程。http://msdn.microsoft.com/en-gb/library/ms345414.aspx.
僅複製事務日誌的備份
僅複製事務日誌的備份不會截斷事務日誌。僅使用版權的日誌備份與正常日誌備份方案“獨立”存在；它不會破壞日誌備份鏈。簡而言之，事務日誌備份執行雙重目的，即允許還原和恢復到以前的時間點，以及控制事務日誌的大小。事務日誌相關問題的最常見原因可能是在完全恢復模式下工作，而不進行日誌備份，或者日誌備份不夠頻繁，不能控制事務日誌檔案的大小。
如果您不確定是否在給定的資料庫上進行事務日誌備份，那麼可以簡單地使用類似於清單5.1所示的查詢來詢問主存資料庫資料庫中的備份設定表。
USE msdb ;SELECT backup_set_id ,
backup_start_date ,
backup_finish_date ,
backup_size ,
recovery_model ,
[type]FROM dbo.backupsetWHERE database_name = 'TestDB'
表5.1：是否正在進行日誌備份？
在型別列中，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/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分鐘進行一次日誌備份，或者更頻繁地這樣做。在這種情況下，為了避免需要還原大量的事務日誌檔案，您可以選擇採用一個備份方案，其中包括穿插有差異備份的完整備份，以及穿插有事務日誌備份的備份。
在現實中，備份方案往往是理想和實際之間的折衷，是評估資料丟失的真實風險、公司將付出的代價和減輕這種風險所涉及的費用之間的折衷。許多非常重要的業務應用程式使用的備份方案比較簡單，但卻很嚴格，可能包括定期的夜間完整備份和每小時的事務日誌備份。
日誌備份的頻率也可能取決於資料庫所涉及的事務的數量。對於非常繁忙的資料庫，可能需要經常備份以控制日誌的大小。
沒有簡單的方法來計算使用日誌備份的頻率。大多數資料庫管理員將對日誌備份的頻率進行最佳估計，然後觀察檔案的增長特性，然後根據需要調整備份方案，來防止檔案變得過大。
日誌鏈和如何打破日誌鏈
如前所述，不先執行至少一個完整備份的情況下，不可能執行事務日誌備份。為了將資料庫恢復到某個時間點，或者恢復到特定日誌備份的末尾，或者恢復到特定日誌備份中的某個時間點，必須存在一個完整的完整的日誌記錄鏈，從完整備份（或差異備份）後的第一個日誌備份，一直到故障。這就是所謂的日誌鏈。
有許多方法可以打破日誌鏈，如果這樣做，則意味著您只能恢復資料庫到事件發生前的日誌備份時間。簡而言之，如果你關心恢復資料的能力，打破這個鏈不是一個好主意。打破僵局最常見的兩種方式包括：
（1）事務日誌備份檔案丟失或損壞——您只能恢復到前一個良好日誌備份。日誌鏈將在下一次良好的完全備份或特定時間再次啟動。
（2）切換到簡單的恢復模式——如果您曾經從完全恢復模式切換到簡單恢復模式，就會打破日誌鏈，因為一個檢查點將被啟動，事務日誌將被立即截斷。當您返回到完全模式時，您將需要採取另一個完全備份來重新啟動日誌鏈。事實上，除非您使用完整備份，否則資料庫將保持自動截斷模式，您將無法備份日誌檔案。
在sql伺服器2008之前，有幾個命令，即帶有 BACKUP LOGWITH NO_LOG 或 BACKUP LOG WITH TRUNCATE_ONLY（它們在功能上是等價的），當釋出時，將強制截斷日誌檔案，從而打破日誌鏈。您不應該在sql伺服器的任何版本中釋出這些命令，我在這裡提到它們，是因為它們仍然被誤用，當試圖處理一個“失控的日誌檔案”，不瞭解它對他們恢復資料庫的能力的影響。想知道更多細節看看第八層--救命，我的日誌已經滿了。
尾部日誌備份
只要您有最近的完整備份和完整的日誌鏈，就可以在任何失敗之前將資料庫恢復到最終日誌備份結束時的狀態。但是，假設您每小時、每小時都使用事務日誌備份，在下午1:45發生故障。您可能會損失45分鐘的資料；實際上，如果故障是災難性的，導致實時事務日誌無法恢復，那麼您將損失的資料量就是這45分鐘的資料。
但是，即使資料檔案不是動態的，有時仍然可以使用動態事務日誌，特別是如果事務日誌包含在單獨的專用驅動器上。如果是這種情況，則應備份正在執行的事務日誌，即執行自上次日誌備份以來生成的日誌記錄的最後備份。這將捕獲實時日誌檔案中的剩餘日誌記錄，直到故障點。這稱為跟蹤日誌備份，是在開始還原和恢復操作之前應該執行的最後一個操作。
跟蹤日誌備份和最小日誌操作
如果資料庫失敗導致資料檔案不可用，且日誌尾部包含的日誌操作最少，則不可能進行尾部日誌備份，因為這將需要訪問資料檔案中已更改的資料區域。這將在第6級中更詳細地描述，以批量日誌模式管理事務日誌。
如果要還原的資料庫線上，則日誌的尾部將被備份如下：
BACKUP LOG DatabaseNameTO DISK
='FileLocation\DatabaseName_Log.bak'WITH NORECOVERY
不恢復（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;
如果在還原時省略了帶不恢復選項，則預設情況下還原命令將繼續進行恢復。換句話說，sql伺服器將嘗試協調資料和日誌檔案，向前滾動已完成的事務，然後在必要時回滾未完成的事務。通過使用不恢復選項指定，我們指示sql伺服器，我們正在輸入一個還原序列，在執行任何回滾之前，必須向前滾動更多的操作。在還原還原序列中的最後一個備份之後，資料庫可以按以下方式恢復：
RESTORE DATABASE DatabaseName WITH RECOVERY
常見的要求是將資料庫還原到不同的位置，在這種情況下，您可以簡單地移動檔案作為還原過程的一部分，如下所述：
http://msdn.microsoft.com/en-us/library/ms190255.aspx.
資料庫失敗後恢復
下面的示例描述瞭如何針對失敗恢復資料庫，資料庫資料檔案不再可訪問。
完全恢復到故障點
假設在資料庫失敗之後，可能是硬體失敗導致了“實時”事務日誌，那麼理論上應該可以通過使用以下步驟將資料庫還原和恢復到故障點：
（1）備份日誌的尾部
（2）還原最近一次的完全備份（如果適用，附加差異）
（3）依次還原在完整備份（或差異備份）之後進行並在故障時間之前完成的每個事務日誌備份
（4）還原尾部日誌備份
（5）恢復資料庫
許多線上書籍上的例子展示了從一個“備份集”恢復和恢復，換句話說，一個儲存所有備份的“裝置”。實際上，這意味著備份到磁碟時，備份裝置是單個的.bak檔案位於該磁碟的某處。
例如，表5.2所示的簡單示例使用一個由一個完整備份和一個事務日誌備份組成的備份集，並演示如何執行完整還原。為了執行此程式碼，您首先需要重新建立testdb資料庫，然後插入幾行樣例資料（為了方便起見，將在此級別的程式碼下載中包含建立和流行的指令碼）。您還需要在本地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 setBACKUP DATABASE TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH FORMAT;
GO
-- Perform a transaction log backup of the Test database-- This is the second file in the setBACKUP Log TestDBTO DISK = 'C:\Backups\TestDB.bak'
GO
-- ....<FAILURE OCCURS HERE>....
-- The RESTORE HEADERONLY command is optional.-- It simply confirms the files that comprise -- the current setRESTORE HEADERONLYFROM 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 setBACKUP Log TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
GO
-- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=1, NORECOVERY;
-- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=2, NORECOVERY;
-- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH FILE=3, NORECOVERY;
-- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.2：備份和恢復備份集（不推薦）
然而，使用備份集是資料庫備份到磁帶時遺留下來的。當備份到磁碟時，不能用這個方案，當然是因為備份檔案很快變得非常大。
在實踐中，每個完整的備份和事務日誌備份檔案都將被單獨命名，並可能以備份的時間和日期為標記，這是非常常見的。例如，大多數第三方備份工具、流行的社群生成的指令碼，加上資料庫整合開發環境中的維護計劃嚮導/設計器，都將建立單獨的日期標記檔案，例如AdventureWorks_FULL_20080904_000001.bak.
因此，更常見的備份和還原方案將使用單獨命名的備份，如表5.3所示。
BACKUP DATABASE TestDBTO DISK ='C:\Backups\TestDB.bak'WITH INIT;
GO
-- Perform a transaction log backup of the Test databaseBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log.bak'WITH INIT;
GO
-- ....<FAILURE OCCURS HERE>....
-- Back up the tail of the log to prepare for restoreBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_taillog.bak'WITH NORECOVERY, INIT;
GO
-- Restore the full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
-- Apply the transaction log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_log.bak'WITH NORECOVERY;
-- Apply the tail log backupRESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_taillog.bak'WITH NORECOVERY;
-- Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.3：備份和恢復獨立命名的備份檔案
及時還原到最後一個良好的日誌備份
不幸的是，有時可能無法執行完全還原；例如，如果由於失敗而無法使用正在執行的事務日誌。在這種情況下，我們只需要還原到最近的日誌備份結束。需要為這種可能的情況做好準備，即包含事務日誌的驅動器發生故障，這就決定了是否經常進行日誌備份。如果你每15分鐘做一次備份，那麼你就會面臨15分鐘資料丟失的風險。
想象一下，我們已經執行了表5.4中顯示的備份序列。為了這個演示，我們覆蓋了以前的備份檔案，而且備份序列顯然比實際情況縮短了很多。
-- FULL BACKUP at 2AMUSE master ;BACKUP DATABASE TestDBTO DISK = 'C:\Backups\TestDB.bak'WITH INIT ;
GO
-- LOG BACKUP 1 at 2.15 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:\Backups\TestDB_log.bak'WITH INIT ;
GO
-- LOG BACKUP 2 at 2.30 AMUSE master ;BACKUP LOG TestDBTO DISK = 'C:\Backups\TestDB_log2.bak'WITH INIT ;
GO
表5.4：一系列簡短的日誌備份
如果在凌晨2:30後不久發生了災難性的故障，我們可能需要將資料庫恢復到日誌備份2結束時的狀態，即凌晨2:30。
這樣的例子中的還原序列和我們在第5.3項中看到的非常相似，但是由於尾部備份是不可能的，我們只能恢復到某個點，我們需要使用停止選項，如清單5.5所示。
--RESTORE Full backupRESTORE DATABASE TestDBFROM DISK = 'C:\Backups\TestDB.bak'WITH NORECOVERY;
--RESTORE Log file 1RESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_log.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--RESTORE Log file 2RESTORE LOG TestDBFROM DISK = 'C:\Backups\TestDB_Log2.bak'WITH NORECOVERY, STOPAT = 'Jan 01, 2020 12:00 AM';
--Recover the databaseRESTORE DATABASE TestDBWITH RECOVERY;
GO
表5.5：恢復到一個時間點，使用停止在（STOPAT）
由於我們已經在未來指定了一個停止時間，這個程式碼將把所有已完成的事務滾動到第二個事務日誌的末尾。
或者，可以指定在特定日誌檔案中記錄的事務的時間範圍內的停止時間。在這種情況下，資料庫將在指定的時間恢復到最後一次提交的事務。您知道要恢復到什麼時間的話很有幫助，但不知道該時間日誌備份包含了什麼。
你也可以還原到特定標記的事務。例如，當您需要將一個應用程式訪問的多個數據庫還原到邏輯一致的點時，這是很有用的。在這裡不對這個題目作進一步討論，但你可以在網上找到更多(http://msdn.microsoft.com/en-us/library/ms187014.aspx)
Mladen Prajdic提供了一個很好的例子：
“不良交易”後恢復
在資料庫失敗的情況下，可能有必要恢復資料庫備份和事務日誌，以便在錯誤的資料修改之前將資料庫返回到特定的時間點，這樣的丟失或截斷表。
你對這種情況的反應將取決於問題的性質。如果可能的話，您可以將所有使用者從資料庫中斷開（在通知他們之後），並評估剛剛發生的事情的含義。在某些情況下，您可能需要估計問題發生的時間，然後使用時間還原點對資料庫和日誌進行完全恢復。一旦還原完成，您必須通知使用者一些事務可能已經丟失，並請求原諒。
當然，通常情況下，您將無法以這種方式中斷正常的業務操作，來修復意外的資料丟失。由於現場資料庫仍處於執行狀態並被訪問，可以嘗試在備用模式下恢復資料庫的備份。這樣可以恢復更多的日誌備份，但與使用不恢復時不同的是，資料庫仍然是可讀的。還原方案可能是這樣的：
（1）恢復資料庫的備份，在備用模式下，與動態資料庫一起
（2）將日誌向前滾動到錯誤事務發生之前的點，資料丟失。
（3）將丟失的資料複製到實時資料庫，並刪除已還原的副本
當然，這個過程不但不簡單，而且相當耗時。除非你購買了一個專門的日誌讀取工具，並且可以直接查詢日誌備份，否則向前滾動日誌可能意味著一系列艱苦的步驟，包括恢復日誌、檢查資料、進一步恢復等等，直到你弄清楚錯誤的事務發生在哪裡。步驟3也可能是困難的，因為您將把資料引入到動態系統中，而這些資料不一定與資料庫的當前狀態一致，因此可能存在引用完整性問題。
讓我們來看一個實現上述步驟1和2的例子。首先，讓我們從頭開始，執行建立和流行的sql指令碼來重新建立testdb資料庫，並將10行測試資料插入到新的日誌測試表中。在表5.6中，我們只需要做一個完整的資料庫備份（覆蓋任何先前的備份檔案）。如果尚未建立“備份”目錄，則需要建立“備份”目錄，或酌情調整路徑。
-- full backup of the databaseBACKUP DATABASE TestDBTO DISK ='C:\Backups\TestDB.bak'WITH INIT;
GO
清單5.7：在TestDB插入第11行
現在我們有一個有11行的實時測試資料庫和一個有10行的備份版本。現在讓我們在日誌備份中捕獲額外的修改，如表5.8所示。
USE master
GOBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log.bak'WITH INIT;
GO
表5.8：日誌備份TestDB
現在，我們要模擬一個錯誤的“糟糕的事務”，只要刪除日誌測試表，然後做最後的日誌備份。
USE TestDB
GODROP TABLE dbo.LogTest ;
USE master
GOBACKUP Log TestDBTO DISK ='C:\Backups\TestDB_log2.bak'WITH INIT;
GO
表5.9：災難！
為了在不中斷正常業務的前提下試圖恢復丟失的資料，我們將在備用模式下恢復一個testdb資料庫的副本。備用資料庫的資料和日誌檔案被移到“備用”目錄（您需要事先建立這個目錄）。
-- restore a copy of the TestDB database, called-- ANewTestDB, in STANDBY modeUSE master ;
GORESTORE 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資料庫中的日誌測試表的查詢將顯示10行。然而，我們希望將表恢復到它被錯誤丟失之前的狀態。因此，下一步是對備用資料庫執行還原日誌備份。
USE master
GORESTORE LOG ANewTestDBFROM DISK = 'C:\Backups\TestDB_log.bak'
WITH STANDBY='C:\Backups\ANewTestDB_log.bak'
表5.11：在待機模式下恢復newtestdb資料庫的日誌備份
此時，對ANewTestDB的查詢顯示了11行，我們現在可以將這些資料複製回實時資料庫了。如果我們更進一步，恢復第二個日誌備份，我們就會意識到我們做得太過分了，備用資料庫中也會缺少這個表。
做備用還原的替代方法是考慮使用第三方工具，比如紅門的sql虛擬還原，它提供了一種不需要物理還原就可以作為實時、功能齊全的資料庫安裝備份的方法。
不管資料庫管理員喜歡與否，開發人員通常都可以訪問生產資料庫來執行特定的資料載入和更改。資料庫管理員和開發者的共同責任是確保這些過程順利進行，從而避免引發需要採取上述行動的問題。稍後我們將在第6級討論大型操作時回到這個話題。
當然，所要求的賠償行動的確切性質取決於不良事務的性質。如果一個表格“不小心掉了”，那麼你很可能是在沿著備用路線往前走。在其他時候，你可以簡單地建立一個指令碼來“逆轉”流氓的修改。
如果損壞隻影響到單列或有限的行數，那麼作為一種替代方法，可能使用sql資料比較等工具，可以直接與備份檔案進行比較，並可以進行行級還原。
或者，如果您執行sql伺服器2005（或以後的）企業版，並提供了最近的資料庫快照，則您可以對快照執行查詢，以便在資料庫快照拍攝時檢視資料，然後編寫一個更新或插入命令，將資料從資料庫快照中放到正在執行的源資料庫中。
作為最後的手段，一個專門的日誌讀取工具可以幫助您消除事務的影響，儘管我完全不知道在sql伺服器2005和以後版本工作可靠性。
總結
在這個級別中，我們已經涵蓋了備份和還原資料庫日誌檔案的基本知識，這些日誌檔案在完全恢復模式下執行，這將成為許多生產資料庫的常規。
對於大多數資料庫管理員來說，執行點內還原的需要是一個罕見的事件，但如果有必要的話，它是其中的一項任務，它的完成和完成是絕對關鍵的；資料庫管理員的聲譽取決於它。
在腐敗、驅動失敗等情況下，可能涉及到點的及時恢復，如果你幸運的話，備份事務日誌的尾部並恢復到故障點。如果沒有可用的事務日誌，或是為了在“壞事務”發生之前回到某個時間點，那麼情況就會變得更復雜，但希望這個步驟中包含的一些技術會有所幫助。
資源：
事務階梯-5級程式碼
本文是sql伺服器樓梯中事務日誌管理的一部分