SQL Server數據庫事務日誌存儲序列

若是你的數據庫運行在完整或是批量日誌恢復模式下，那麼你就須要使用做業(job)來按期備份事務日誌，保持你的事務文件大小處在一個可管理的範圍。當你須要還原事務日誌時，你就須要按照建立事務日誌的順序來恢復它們。你能夠參考存在msdb..backupset表中的信息來肯定還原文件的順序，使用FirstLSN和LastLSN列的值做參考。當你備份時，這些備份信息就會存在backupset表中

 

 

 

只要序列處於維護狀態下，你就能夠使用對應的日誌把數據恢復到任意恢復點上。不幸的是，有些實例的序列已經被損壞了。下面兩種狀況普通是引發損壞的緣由：

• 數據庫的恢復模型被切換到了簡單(SIMPLE)後，再次被切換回完整或是批量日誌。
• Backup log命令運行時，附帶了TRUNCATE_ONLY/NO_LOG選項。

當上面兩種狀況發生時，你須要便可作一個數據庫的完整備份，做爲事務日誌恢復的新的恢復點。那麼你如何判斷序列已經被破壞了呢？

在SQL Server 2000中，這確實有點麻煩。假如數據庫恢復模型已經被更改了，或是備份時日誌已經被截斷了，那麼當更改後，你第一次備份事務日誌時，SQL Server 2000會顯示以下輸出：

There is no current database backup. This log backup cannot be used to roll forward a preceding database backup.
Processed 1 pages for database 'logtest', file 'logtest_log' on file 1.
BACKUP LOG successfully processed 1 pages in 0.078 seconds (0.019 MB/sec).

注意這僅僅是個消息。雖然備份依然會成功完成，但卻不可用。由於這是個計劃做業，因此你什麼都看不到，不過當事務日誌被截斷時，在Windows事件日誌中是相關警告日誌的。。

 

 

注意：若是你正在使用SQL Server 2000，那麼日誌事務對於數據庫是很是重要的，因此要在Windows事件日誌中不間斷的監控日誌事務事件。

假如你既沒有關注警告消息，也沒有監控Windows事件日誌，那麼基本上你就是有一批不可恢復的事務日誌備份。SQL Server不該該警告咱們嗎？不該該中止無效的備份嗎？假如你正在使用SQL Server 2005，那麼答案確定是應該的，並且它也是這麼作的。下面就是當日志備份序列被毀壞時顯示的消息:

Server: Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.
Server: Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.

是否是好多了。總之，若是你正在使用SQL Server 2000，你須要關注上面提到兩個警告事件，這兩個事件會毀壞你的日誌備份序列，使你的備份失效。

下面是一些通用操做來保證日誌序列不被破壞：

• 數據庫恢復模型能夠從完整到批量日誌，反過來也同樣
• 執行數據庫完整備份，差別備份但是文件/文件組備份

假如你有以下一個備份序列(F表明完整數據備份，T表明事務日誌)

F1,T1,T2,T3,T4,T5,T6

如今假設你要恢復到T6時間點，以下的恢復序列會幫你達到目的：

F1,T1,T2,T3,T4,T5,T6

F2,T3,T4,T5,T6

F3,T5,T6