SQL Server事務日誌介紹

SQL Server中的數據庫都是由一或多個數據文件以及一或多個事務日誌文件組成的。

顧名思意，數據文件主要存儲數據庫的數據，包括數據庫內容結構，數據頁，索引頁等等。那麼事務日誌究竟是幹什麼的呢？它主要是用來保存數據庫修改記錄的，以下圖： 

 

SQL Server的工做原理爲何這樣呢？爲何不把數據馬上寫入數據文件呢？緣由很簡單：爲了獲得更高的效率和性能。數據文件爲了適應新的數據可能會擴展，可能會從新分配頁，分配新空間等等。而日誌都是連續被記錄的，因此記錄事務日誌要快得多。這也就是爲何咱們經過推薦把物理磁盤單獨劃分一區用來存儲事務日誌的緣由了，這樣可使磁盤在讀寫上最大程序的保持天然連續。數據文件的讀寫有很大的隨機性。

那麼事務日誌到底都存些什麼呢？看下面這個很是簡單的例子： 

 

在事務日誌中，數據變化被記錄在一個連續的日誌記錄中，且每個記錄都有一個編號，叫作日誌序列編號(Log Sequence Number, LSN)。 

在事務日誌中，每個日誌記錄都被存儲在一個虛擬日誌文件中。事務日誌能夠有任意多個虛擬日誌文件，數量的多少取決於數據庫引擎，並且每一個虛擬日誌文件的大小也不是固定的。 

 

如上圖所示，活動區間(active portion)的日誌就是包含咱們事務的區域。這區間就是完整恢復數據庫所須要的。當更多的事務被建立時，活動區間的日誌也會隨着增加。 

 

那麼當CheckPoint被執行時，會發生什麼變化呢？答案是：全部有變化的數據寫到數據文件中，而後建立一個檢查點記錄(CheckPoint record)。

 

 

如今。由事務1，2，3所致使的變化將會被寫到數據文件中。由於事務3沒有被提交，因此活動區間日誌的範圍變成了從LSN50到LSN52之間。若是使用簡單恢復模型的話，那麼LSN45到LSN49之間區域能夠被重用，由於那些記錄已經再也不須要了。 

 當SQL Server把虛擬日誌文件1和2做爲可重用區域時，事務日誌也相應被截斷(Truncate)。須要注意的是，物理日誌大小也會隨着變更。若是數據庫運行在完整或是批量日誌恢復模型下，那麼從LSN45到49之間的區域將被刪除(delete)，並且直到事務日誌被備份後，這段區域的空間纔會被重用。

那麼當更新的事務被建立時，又會發生什麼呢？在簡單模式下，日誌的起始空間將會被重用。

 

在完整或是批量日誌恢復模型下，事務日誌的空間則會被擴展。 

 

 

 

假如事務日誌是一個固定大小的日誌，那麼在SQL Server2000系統中，你會收到以下錯誤信息：

Server: Msg 9002, Level 17, State 6, Line 1
The log file for database 'AdventureWorks' is full. Back up the transaction log for the database to free up some log space.

在SQL Server 2005裏面，錯誤會顯示爲：

Msg 9002, Level 17, State 4, Line 1
The transaction log for database 'AdventureWorks' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

注意：並非說運行在簡單恢復模式下的數據庫永遠都不會遇到9002的錯誤。若是你有一個很長的、正在運行的、未提交的事務，那麼你的事務日誌依然會被填滿，由於SQL Server不能刪除任何一個已經開始運行以後被建立的日誌。也就是說，活動區間裏面的日誌從事務起始時被記錄，而且已經沒有活動區間能夠被刪除或是重用了。

因此，要保持你的事務日誌基本處理一個可管理的範圍：

• 當更改已經被確認或是因爲錯誤致使的回滾已經完成時，要立刻提交的你事務。
• 若是數據庫運行在完整或是批量日誌恢復模型下的話，要按期備份你的事務日誌

爲了找出數據庫中最起始的活動事務，特別是事務起始時間時，就可使用DBCC OPENTRAN命令，例如：

DBCC OPENTRAN

結果爲：

Transaction information for database 'AdventureWorks'.
Oldest active transaction:
SPID (server process ID) : 52
UID (user ID) : 1
Name : user_transaction
LSN : (754:531:1)
Start time : Jul 14 2008 5:43:55:390PM

爲了找出每個數據庫已經使用的日誌空間大小，可使用DBCC SQLPERF命令：

DBCC SQLPERF(LOGSPACE)

爲了找出事務日誌使用了多少虛擬日誌數量，可使用DBCC LOGINFO命令。它顯示的細節內容就是你當前所鏈接數據庫的內容，下面就是AdventureWorks數據庫的輸出： 

 

從上圖咱們能夠獲得以下信息：你的事務日誌中有四個虛擬日誌文件（一行一個），且全部虛擬日誌文件包括在一個單一的物理文件中(FileId=2)。第一，二，三的虛擬日誌文件大小是458752比特，最後一個虛擬日誌文件的大小是712704比特。1~3虛擬文件歷來沒有被使用或是重用過(Status=0), 第四個虛擬日誌文件正在被使用(Status=2)。虛擬日誌文件在物理上的佈局具備鏈接的編號(FSeqNo是遞增的), 實際狀況可能與此有所不一樣。