以完全恢復模式管理日誌
SQL Server中事務日誌管理的階梯,級別5:以完全恢復模式管理日誌
作者:Tony Davis, 2012/01/27
該系列
本文是Stairway系列的一部分:SQL Server中事務日誌管理的階梯
當事情進展順利時,沒有必要特別註意事務日誌的功能或工作方式。您只需要確信每個數據庫都有正確的備份機制。當出現問題時,了解事務日誌對於采取糾正措施非常重要,尤其是在需要對數據庫進行時間點恢復時!托尼戴維斯給出了每個DBA應該知道的正確程度的細節。
在此級別中,我們將查看在FULL恢復模式下工作時為何以及如何進行日誌備份,以及如何使用這些日誌備份文件以及完整數據庫備份執行數據庫還原。FULL恢復模式支持將數據庫還原到可用日誌備份中的任何時間點,並假設可以在發生故障之前進行尾部日誌備份,直到上次提交的事務的時間。
什麽得到記錄?
在FULL恢復模式下,所有操作都已完全記錄。對於INSERT,UPDATE和DELETE運營,這意味著對於每個被修改的行,將有描述該執行的語句,當交易開始和結束的,哪些頁面被改變交易的ID的日誌記錄,進行過的數據進行修改的, 等等。
可以最低限度記錄的操作SELECT INTO,BULK INSERT並且CREATE INDEX,在工作時,仍完全記錄FULL恢復模式,但略有不同完成。受這些操作影響的行不會單獨記錄; 相反,只有數據庫頁面被記錄,因為它們被填滿。這樣可以減少此類操作的日誌記錄,同時確保仍然存在執行回滾,重做和時間點恢復所需的所有相同信息。Kalen Delaney
為什麽備份事務日誌?
在FULL恢復模式下,只有日誌備份可能導致截斷日誌。因此,事務日誌將保存自上次備份事務日誌以來執行的事務的完整和完整記錄。由於所有操作都已完全記錄,因此在繁忙的系統中,日誌文件可以非常快速地增長。
因此,在工作時FULL恢復模式,這是 至關重要的,你執行定期事務日誌備份,除了完整備份和可選的差異備份。許多新手或兼職DBA在其數據庫上執行完全備份,但它們不執行事務日誌備份。因此,事務日誌不會被截斷,並且它會增長並增長,直到它所在的驅動器用完磁盤空間,從而導致SQL Server停止工作。
一旦進行日誌備份,就會發生日誌截斷,假設自上次備份以來發生了檢查點,並且沒有其他因素延遲截斷,例如數據備份或恢復操作。有關可能延遲截斷可恢復VLF的因素的完整列表,以及保留大量日誌活動的因素,否則將不需要,例如流氓,長時間運行的未提交事務或數據庫鏡像或復制進程,請參閱:http://msdn.microsoft.com/en-gb/library/ms345414.aspx。
COPY_ONLY 備份事務日誌
COPY_ONLY事務日誌的備份不會截斷事務日誌。一個COPY_ONLY日誌備份是否存在“獨立”正常的日誌備份方案; 它不會破壞日誌備份鏈。
簡而言之,事務日誌備份執行雙重目的,即允許還原和恢復到以前的某個時間點,以及控制事務日誌的大小。可能導致事務日誌相關問題的最常見原因是在FULL恢復模式下工作,並且根本不進行日誌備份,或者不經常使用日誌備份來控制事務日誌文件的大小。
如果您不確定是否在給定數據庫上執行事務日誌備份,則可以使用類似於清單5.1中所示的查詢來查詢數據庫中的backupset表MSDB。
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:是否正在進行日誌備份?
在type列中,a D表示數據庫備份,L日誌備份和I差異備份。
請註意,由於可以在不影響備份和還原行為的情況下操作此備份集表中的數據,因此您可能希望通過查詢sys.database_recovery_status以查看值last_log_backup_lsn(參見清單3.5)或sys.databases表中的值來驗證此查詢的結果。of log_reuse_wait_desc(LOG_BACKUP如果需要備份,將返回)。
如何備份事務日誌
如前所述,如果沒有首先進行至少一次完整備份,則無法執行事務日誌備份。實際上,如果您的數據庫處於FULL恢復模式但從未進行過備份,那麽它實際上不會在FULL恢復模式下工作。數據庫將處於自動截斷模式,直到執行第一次完全備份。
使用該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選項將數據庫置於還原狀態,並假定您要執行的下一個操作是a 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:在數據庫服務器的本地驅動器上創建“備份”目錄,或者根據需要修改文件路徑。
-- 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:備份到備份集並從中恢復; 不建議
但是,使用備份集似乎是數據庫備份到磁帶時的遺留問題。備份到磁盤時,使用此方案是一個壞主意,因為當然,備份文件會很快變大。
實際上,每個完整備份和事務日誌備份文件將被單獨命名,並且可能標記了備份所用的時間和日期,這種情況更為常見。例如,大多數第三方備份工具,流行的社區生成腳本以及SSMS中的維護計劃向導/設計器都將創建單獨的帶日期戳的文件,例如AdventureWorks_FULL_20080904_000001.bak。
因此,更常見的備份和還原方案將使用唯一命名的備份,如清單5.3所示。
USE master;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中看到的非常類似,但由於尾部備份是不可能的,我們只能恢復到某一點,我們需要使用該STOPAT選項,如清單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
由於我們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中,我們只是進行完整的數據庫備份(覆蓋任何以前的備份文件)。如果您尚未創建“備份”目錄,則需要創建“備份”目錄,或者根據需要調整路徑。
-- full backup of the databaseBACKUP DATABASE TestDBTO DISK =‘C:\Backups\TestDB.bak‘WITH INIT;
GO
代碼清單5.6:完全備份 TestDB
然後,我們將一行新數據插入LogTest表中。
USE TestDB
GOINSERT 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
GOBACKUP Log TestDBTO DISK =‘C:\Backups\TestDB_log.bak‘WITH INIT;
GO
代碼清單5.8:日誌備份 TestDB
現在,我們將模擬一個錯誤的“壞事務”,只需刪除LogTest表,然後我們進行最終的日誌備份。
USE TestDB
GODROP TABLE dbo.LogTest ;
USE master
GOBACKUP Log TestDBTO DISK =‘C:\Backups\TestDB_log2.bak‘WITH INIT;
GO
清單5.9:災難!
為了在不中斷正常業務操作的情況下嘗試檢索丟失的數據,我們將TestDB在STANDBY模式下恢復數據庫的副本。備用數據庫的數據和日誌文件(稱為ANewTestDB)將移至“備用”目錄(您需要事先創建此目錄)。
-- 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:恢復TestDBin STANDBY模式的副本
我們現在有一個名為的新數據庫,它處於“Standby / Read-Only”模式,如圖5.1所示。ANewTestDB
圖5.1:備用數據庫
對ANewTestDB數據庫中的LogTest表的查詢將顯示10行。但是,我們希望讓桌子恢復到錯誤丟棄之前的狀態。因此,下一步是執行將日誌備份還原到備用數據庫。
USE master
GORESTORE LOG ANewTestDBFROM DISK = ‘C:\Backups\TestDB_log.bak‘
WITH STANDBY=‘C:\Backups\ANewTestDB_log.bak‘
代碼清單5.11:在模式下將日誌備份恢復到ANewTestDB數據庫STANDBY
此時,針對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及更高版本中的任何可靠工作。
摘要
在本級別中,我們已經介紹了備份和恢復在FULL恢復模式下運行的數據庫的日誌文件的基礎知識,這將成為許多生產數據庫的標準。
對於大多數DBA來說,執行時間點恢復的需求是一種罕見的事件,但它是其中一項任務,如果有必要,完成並完成它是絕對關鍵的; DBA的聲譽取決於它。
在損壞,驅動器故障等情況下,如果幸運的話,時間點恢復可能涉及備份事務日誌的尾部並恢復到故障點的權限。如果事務日誌不可用,或者您正在恢復以便在發生“錯誤事務”之前恢復到某個時間點,則情況變得更加棘手,但希望此步驟中涉及的一些技術將有所幫助。
資源:
TransactionLogStairway_Level5_Code.zip
本文是 SQL Server Stairway中事務日誌管理的階梯的一部分
以完全恢復模式管理日誌