訪問 poi 管理員 token continue 業務 all tro red

此為本小組翻譯外國作家文章，原文鏈接為http://www.sqlservercentral.com/articles/Stairway+Series/73785/

樓梯到事務日誌管理SQL Server，5級：在完整恢復模式的日誌管理

由湯尼戴維斯，2012 / 01 / 27

該系列

這篇文章是樓梯系列的一部分：在SQL Server事務日誌管理的樓梯

當事情進展順利，沒有需要特別在意日誌或它是如何工作的交易。你只需要相信，每一個數據庫已經有正確的備份制度。當事情出錯時，了解事務日誌是重要的采取糾正措施，特別是在一個時間點恢復數據庫是必需的，迫切的！Tony Davis只給出正確的細節層次，每個DBA都應該知道。

在這個層面我們會檢討為何以及如何執行日誌備份，當工作在全部恢復模式，以及如何執行數據庫恢復使用這些日誌備份文件，在完整數據庫備份相結合。全部恢復模式支持數據庫恢復到任何時間點內可用的日誌備份，如果尾日誌備份可以用，到最後提交的事務的時間，在發生故障。

會得到什麽樣的記錄？

進入全部恢復模式下，所有的操作都是完全記錄。為插入，更新和刪除操作，這意味著每行被修改，會有一個日誌記錄描述交易進行聲明的ID，當交易開始和結束，哪些頁面被改變，數據變化了，等等。

操作可以最小日誌記錄選擇 成，散裝 插入和創造 指數，仍然完全記錄在工作全部恢復模式，但它是略有不同。行受這些操作不記錄個別；只數據庫頁被記錄，因為他們得到了。這降低了測井聽到這樣的操作，同時確保存在的信息存在，需要進行回滾，重做和時間點恢復。Kalen Delaney已經發表了一些調查記錄選擇進入

（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恢復模式。在最小日誌記錄操作日誌記錄的差異，當工作在bulk_logged模式，更詳細的討論，在6級–管理登錄 大容量日誌 恢復模式。

為什麽備份事務日誌？

進入全部恢復模式，只有一個日誌備份可以導致日誌截斷。因此，事務日誌將保持完整的交易自上次事務日誌備份進行記錄。因為所有的操作都是完全記錄，日誌文件會變得很大，很快，在繁忙的系統。

因此，當工作在全部恢復模式，它是 至關重要的你做的常規事務日誌備份，除了完整備份和差異備份，可選。很多新手或兼職DBA執行完全備份對數據庫，但他們不執行事務日誌備份。因此，事務日誌不會被截斷，它成長直到它的驅動器上的磁盤空間耗盡，導致SQL服務器停止工作。

該日誌截斷將盡快日誌備份是發生，假設從以前的備份，沒有其他因素推遲截斷發生了一個檢查站，如數據備份或還原操作。對於一個完整的，可能會延遲恢復體截斷因子列表，以及因素，保持大量的日誌活動，否則就不需要，如一個流氓，長期未提交的事務或數據庫鏡像或復制的過程中，看到：http://msdn.microsoft.com/en-gb/library/ms345414.aspx。

copy_only備份事務日誌

copy_only備份事務日誌不截斷事務日誌。一copy_only日誌備份存在“獨立”的正常日誌備份方案；它不破的日誌備份鏈。

總之，事務日誌備份執行允許還原和恢復到之前的某個時間點的雙重目的，以及控制事務日誌的大小。可能交易的最常見的原因是工作日誌的相關問題全部恢復模式和不帶日誌備份，日誌備份或沒有足夠頻繁的大小來控制事務日誌文件。

如果你不確定是否事務日誌備份正在采取在一個給定的數據庫，那麽你可以簡單地詢問備份集表中msdb數據庫，使用查詢類似於清單5.1所示。

使用msdb；
 
選擇backup_set_id，
 
 backup_start_date，
 
 backup_finish_date，
 
 backup_size，
 
 recovery_model，
 
 [型]

清單5.1：是日誌備份了嗎？

在類型柱，一個D代表一個數據庫備份，l一個日誌備份I差異備份。

註意，因為在這種數據備份集表可以被操縱而不影響備份和恢復性能，你可能想驗證你的結果從這個查詢，通過查詢sys.database_recovery_status看的價值last_log_backup_lsn（參見清單3.5），或sys.databases表看的價值log_reuse_wait_desc（將返回log_backup如果備份是必需的）。

如何備份事務日誌

正如前面所討論的，這是不可能執行事務日誌備份不先以至少一個完整的備份。事實上，如果你有一個數據庫，在全部恢復模式，但從來沒有備份，那麽它將不會工作全部恢復模式。該數據庫將自動截斷模式直到進行第一次完整備份。

所有的數據庫備份，日誌全，或以其他方式，進行備份命令。命令接受無數次的選擇，這是記錄在這裏：http://msdn.microsoft.com/en-us/library/ms186865.aspx。然而，在其最基本的，這往往是如何使用，命令執行完全備份到磁盤如下：

數據庫備份<em>數據庫</em>磁盤=“<em>filelocation \ databasename.bak</em>”；

如果這是首次進行的備份，databasename.bak文件會在指定的目錄中創建。如果此文件已經存在，則默認行為是，追加後續的備份文件。重寫此行為，並規定任何現有文件將被覆蓋，我們可以使用初始化選項，如下：

數據庫備份<em>數據庫</em>磁盤=“<em>filelocation \ databasename.bak</em>與初始化；

最常見的，然而，每個後續的備份是一個獨特的名字；更在這即將到來的部分，<em>恢復到故障點</em>。

在每次定期（如每日）全備份，會有頻繁的日誌備份（例如每小時），其基本的命令非常相似：

備份日誌<em>數據庫</em>磁盤=“<em>filelocation \ databasename_log.bak</em>”；

存儲日誌備份

顯然，備份的數據和日誌文件不能存放在同一個驅動器，主機的活檔案。如果硬盤有硬件故障然後你所有的副本都將隨著生活的文件丟失，和備份就白費了。文件要備份到一個獨立的設備，或備份到本地，鏡像驅動器。

日誌備份的頻率

在以前的水平，註意，你可以將日誌備份每15分鐘，甚至更多。在這種情況下，為了避免需要恢復大量的事務日誌文件，你可以選擇備份方案包括全備份和差異備份的穿插，穿插的事務日誌備份。

在現實中，備份方案更多的是理想與現實之間的妥協，對損失數據的真實風險評估之間，它將使公司的成本和費用，減少風險。許多重要的商業應用程序使用較為簡單，但嚴格的備份方案，也許涉及定期夜間全備份加上每小時的事務日誌備份。

日誌備份的頻率也可由交易數量的數據庫對象。非常繁忙的數據庫，它可能需要備份經常為了控制日誌大小。

有沒有簡單的方法來計算經常把日誌備份。大多數數據庫管理員會在多久日誌備份應采取他們的最佳估計，然後觀察文件的生長特性，然後調整備份方案以防止過大的。

日誌鏈如何打破它

值得註意的是，這是不可能執行事務日誌備份不先以至少一個完整的備份。為了恢復數據庫到一個時間點，或者一個特定的日誌備份或到某個時間點結束在一個特定的日誌備份，必須存在一個完整的不間斷的鏈條，日誌記錄，從後全采取的第一個日誌備份（備份或差異備份），直到失敗這一點。這是被稱為<strong>日誌鏈</strong>。

有許多方法來打破鏈，如果你這樣做就意味著你只能將數據庫恢復到日誌備份事件發生前采取斷鏈的時間。總之，斷鏈是<strong>不是</strong>一個好主意，如果你關心的能力來恢復您的數據。兩打破鏈的最常見的方式包括：

• <strong>丟失或損壞的事務日誌備份文件</strong>–只能恢復到上次好的日誌備份。日誌鏈又將開始在下一個好的完整備份或差異備份。
• 開關 簡約 恢復模式如果你從–全部到簡約恢復模式，這將打破鏈作為一個檢查點會煽動和事務日誌可以立即截斷。當你回到全部模式，你將需要一個完整備份恢復日誌鏈。事實上，直到你完全備份，數據庫將自動截斷模式和無法備份日誌文件。

SQL Server 2008前，有一對夫婦的命令，即備份 日誌 與no_log或備份 日誌 與 truncate_only（他們在功能上是等價的），發的時候，會迫使一個日誌文件截斷，所以打破鏈。你不應該在任何版本的SQL Server發出這些命令，但我在這裏提到它們，他們仍然會被粗心的使用，當試圖處理一個“失控的日誌文件”，而不理解它所具有的意義為他們恢復他們的數據庫能力。看到8級–的幫助下，我的日誌已滿，更多的細節。

尾日誌備份

只要你有一個最近的完整備份和一個完整的日誌鏈，你可以恢復你的數據庫的一種狀態，它存在於最終的日誌備份結束之前的任何失敗。然而，假如你把事務日誌備份時，的時間，以及故障發生在下午1:45。你可能會失去45分鐘的數據；事實上，如果失敗是災難性的，所以生活事務日誌是無法挽回的，那麽就是數據量會失去你。

然而，有時候生活事務日誌仍然可以即使數據文件不可用，特別是如果事務日誌包含在一個單獨的、專用的驅動。如果是這種情況，你應該備份事務日誌的生活即執行的日誌記錄最後備份自上次日誌備份後生成的。這將在日誌文件中捕獲住剩余的日誌記錄，到故障點。這被稱為<strong>尾日誌備份</strong>，是最後的行動開始前應進行還原和恢復操作。

尾日誌備份和最小日誌記錄操作

如果數據文件不可用，由於數據庫故障，和日誌的尾部含有最小日誌記錄操作，那麽就不可能做尾日誌備份，這就需要在數據文件中獲取數據的變化程度。這將包括更詳細的<em>6級，</em><em>管理</em><em>事務日誌在大容量日誌模式</em>。

如果你想恢復數據庫在線，然後備份日誌尾部是如下：

備份日誌<em>數據庫</em>磁盤=“<em>filelocation \ databasename_log.bak</em>“WITH NORECOVERY

這個使用NORECOVERY選項使數據庫在恢復狀態，假設下一個行動，你要執行的是一個恢復。如果數據庫處於離線狀態，啟動不了，你還是應該嘗試備份日誌尾部如剛才所描述的（雖然使用NORECOVERY選項可以省略，因為沒有交易將進步）。

如果你確信日誌文件損壞，文件顯示，作為最後的手段，你想做一尾日誌備份：

備份日誌<em>數據庫</em>磁盤=“<em>filelocation \ databasename_log.bak</em> ‘ continue_after_error

如果主數據庫和數據文件被損壞，但日誌是可用的，微軟建議重建master數據庫，然後備份活動日誌。然而，這些主題在這樓梯的範圍，我是指你的文件的詳情。看到http://msdn.microsoft.com/en-us/library/ms190952.aspx。

進行還原和恢復

進行尾日誌備份，如果可能的話，下一步就是要恢復上次完全備份（其次是差異備份，如果合適的話），然後恢復日誌備份文件的完整序列，包括尾日誌備份。這個序列的基本語法恢復操作如下：

恢復數據庫日誌} { |<em>數據庫</em>從磁盤=“<em>filelocation \ filename.bak</em>“WITH NORECOVERY；

如果當你恢復你的省略與 使用NORECOVERY選項，則默認恢復命令將與 恢復。換句話說，SQL Server將數據和日誌文件的調和，向前滾動完成交易然後回滾未完成事務的必要。通過指定與 使用NORECOVERY，我們指示SQL Server，我們正在進入一個還原順序，更多的操作必須向前滾動，在任何可以進行回滾。在還原順序還原最後一個備份後，數據庫就可以恢復如下：

還原數據庫的語句

一個共同的要求是要將數據庫還原到不同的位置，在這種情況下，你可以簡單地將文件作為恢復過程的一部分，這裏所描述的那樣：http://msdn.microsoft.com/en-us/library/ms190255.aspx。

恢復後的Database Failure

下面的示例說明如何回應一個故障恢復數據庫，該數據庫的數據文件無法訪問。

完全恢復到故障點

假設“活”的事務日誌可以是一個數據庫失敗後得出的，也許是由硬件故障引起的，那麽在理論上應該可以恢復和恢復數據庫到故障點，采用以下步驟：

1. 備份日誌尾部
2. 恢復最近的完整備份（加微分，如果適用的話）
3. 恢復，反過來，每個事務日誌備份後，全部采取（或差）失敗的時間前完成備份
4. 還原尾日誌備份
5. 恢復數據庫

很多例子發現在線圖書展示恢復從“備份集”，就是一個“裝置”，所有的備份存儲。在實踐中，這意味著，當備份到磁盤備份設備是單.bak位於某處的磁盤文件。

所以，例如，清單5.2中的例子使用一個備份集組成的一個完整備份和事務日誌備份，並說明如何執行完全恢復。為了運行這段代碼，你需要先創建其中數據庫然後插入一些樣本數據行（為方便起見，腳本來做這個，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

清單5.2：備份，恢復，備份集；不推薦

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

在實踐中，每個完整備份和事務日誌備份文件將被單獨命名的情況更為常見，而且可能加蓋，備份時的日期和時間。例如，大多數第三方備份工具，受歡迎的社區生成的腳本，加上維護計劃向導/ SSMS的設計師，都會創建單獨的文件如<em>adventureworks_full_20080904_000001.bak</em>郵戳日期。

因此，一個更常見的備份和恢復方案將使用唯一命名的備份，如清單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中，但由於尾備份是不可能的，我們只能夠恢復到某一點，我們需要使用在選項，如清單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：恢復到某個時間點，用在

既然我們已經指定了一個在在未來的時間裏，這段代碼將回滾所有完成交易到第二事務日誌的結束。

另外，指定一個可能在時間，屬於記錄在一個特定的日誌文件的交易時間範圍。在這種情況下，數據庫將恢復到上次提交的事務在規定時間。這是有用的當你知道你要恢復到什麽時候，但不知道什麽是日誌備份包含時間。

它也可以恢復到一個特定的標記的事務。這是非常有用的，例如，你需要恢復多個數據庫，通過一定的程序訪問，在邏輯上一致的點。這個話題不在這裏進一步討論，但你可以找到更多關於圖書在線（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。

恢復“壞交易”之後

對任何數據庫故障的情況之外，可能需要恢復數據庫備份，加上事務日誌，以一個數據庫返回到時間就在一個錯誤的數據修改了某個特定的點，如刪除或截斷表。

你這種情況的反應將取決於問題的性質。如果可能的話，你可能會從數據庫斷開所有用戶（在通知他們），並評估剛剛發生了什麽事的影響。在某些情況下，您可能需要估計問題發生然後完全恢復的數據庫和日誌的時間點恢復時間。一旦恢復了，你要通知用戶一些交易可能已經丟失，並請求原諒。

當然，你經常不能夠以這種方式中斷正常的業務操作，解決一個意外的數據丟失。由於實時數據庫仍然正常運行和訪問，你可以嘗試恢復數據庫的備份備用物品模式。這允許進一步的日誌備份來恢復但不像使用時使用NORECOVERY，數據庫仍然是可讀的。還原方案可能看起來像這樣：

1. 恢復數據庫備份，在備用物品模式，與實時數據庫
2. Roll the logs forward to the point just before the bad transaction occurred, and data was lost.
3. Copy the lost data across to the live database and drop the restored copy

Of course, this process is not necessarily straightforward, and can be quite time-consuming. Unless you‘ve purchased a specialized log reading tool, and can interrogate the log backup directly, rolling the logs forward can mean a series of painstaking steps involving restoring a log, checking the data, restoring a bit further, and so on, until you‘ve worked out exactly where the bad transaction occurred. 3步是困難的，因為你將引入數據到現場系統與數據庫的當前狀態必然是不一致的，所以可以參照完整性問題。

讓我們在執行步驟1和2以上，看一個例子。首先，讓我們再從頭開始運行createandpopulatetestdb.sql腳本來創建其中數據庫，並插入10行測試數據到一個新的logtest表在清單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數據庫中的行logtest表，以及備份與10行版本。現在讓我們來捕獲日誌備份額外的修飾，如清單5.8所示。

USE master
GO
BACKUP Log TestDB
TO DISK =‘C:\Backups\TestDB_log.bak‘
WITH INIT;
GO

清單5.8：日誌備份其中

現在，我們要模擬一個錯誤的“糟糕的交易”，簡單地把<em>logtest</em>表，之後我們做的最後一個日誌備份。

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：災難！

為了試圖找回丟失的數據，在不中斷業務的正常運行，我們將恢復的副本其中數據庫備用物品模式。的備用數據庫的數據文件和日誌文件，稱為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：恢復副本其中進入備用物品模式

我們現在有一個新的數據庫，稱為新的<em>庫</em>，和它的“待機/只讀”模式，如圖5.1所示。

圖5.1：備用數據庫

一個查詢logtest表中anewtestdb數據庫將顯示10行。然而，我們想把表回狀態是在之前它被錯誤地下降。因此，下一步是執行還原日誌備份到備用數據庫。

USE master
GO
RESTORE LOG ANewTestDB
FROM DISK = ‘C:\Backups\TestDB_log.bak‘
   WITH STANDBY=‘C:\Backups\ANewTestDB_log.bak‘

清單5.11：還原日誌備份的anewtestdb數據庫，在備用物品模式

在這一點上，查詢<em>anewtestdb</em>顯示11行，我們現在可以將數據重新進入實時數據庫。如果我們更進了一步，恢復第二日誌備份，我們意識到我們已經走得太遠了，表會丟失在備用數據庫以及。

另一個做備用恢復是考慮使用第三方工具如紅色的門SQL虛擬還原，這一方式來安裝備份為生活提供全功能的數據庫，沒有身體的恢復。

無論他們喜歡與否，開發商經常訪問生產數據庫來完成特定數據負載和變化。這是DBA和開發人員的共同責任，確保順利進行，所以不會造成需要的這種行動只是描述問題。我們回到這個話題，後來在<strong>6級處理批量操作</strong>。

當然，所需的修復作用的確切性質取決於糟糕的交易性質。如果一個表是“不小心掉了”，那麽很有可能你會走的恢復 與 備用物品路線。在其他時候，你可能會去做一個簡單的腳本來“逆淘汰”的流氓的修改。

如果傷害只會影響單柱或有限數量的行，那麽它是可能的，作為一種替代方法，使用的工具，如SQL數據的比較，可以比較直接的備份文件，可以做行級恢復。

或者，如果你運行SQL Server 2005企業版（或以後），和提供最近的數據庫快照，您可以運行一個對快照查詢來檢索數據，它看了看時間數據庫快照拍攝，然後寫一個更新或插入命令將數據從數據庫快照到現場，源數據庫。

最後，作為最後的手段，一個專門的日誌讀取器工具可以幫助你扭轉了影響交易的雖然我不知道有任何可靠地工作在SQL Server 2005及以後。

概要

在這個層面上，我們已經備份和恢復日誌文件的數據庫操作的基本知識全部恢復模式，這將對許多生產數據庫規範。

對於大多數數據庫管理員，需要執行時間點恢復是一種罕見的事件，但它是一個任務，如果有必要的話，它絕對是至關重要的，它是做的，做的很好；DBA的聲譽取決於它。

在腐敗案件的驅動器故障，等等，時間點恢復可能涉及，如果你幸運的話，備份尾事務日誌和恢復到故障點的權利。如果事務日誌不可用，或者如果你恢復以恢復到某個時間點，一個“壞交易”發生之前，那麽情況就變得比較復雜，但希望一些覆蓋在這一步的技術將幫助。

第十七周翻譯