關於SQL Server 截斷日誌[zt]

http://www.itpub.net/513162,1.html 

            SQL Server 在完成事務日誌備份時將自動截斷事務日誌中的不活動部分。這些不活動的部分包含已完成的事務，因此在恢復過程中不再使用。相反，事務日誌的活動部分包含仍在執行但尚未完成的事務。SQL Server 將重新使用事務日誌中這些截斷的非活動空間，而不是任由事務日誌繼續增大並佔用更多的空間。

雖然可以手工截斷事務日誌，但強烈建議最好不要這樣做，因為這將斷開日誌備份鏈。在建立完整資料庫備份前，將無法為資料庫提供媒體故障保護。只有在非常特殊的環境中才使用手工日誌截斷，而且儘可能快地建立完整資料庫備份。


事務日誌非活動部分的終點（因此就是截斷點）是下列事件的最早點：

最近的檢查點。


最早的活動事務的起點，即尚未提交或回滾的事務。
這代表在恢復過程中，SQL Server 必須回滾事務的最早點。

最早事務的起點，這些事務包括已釋出但尚未複製更改的複製物件。
這代表 SQL Server 仍必須複製的最早點。



這個好象類似 oracle 的rman 備份中,備份完archivelog 後,archivelog 是不再需要的,rman 可以自動刪除備份的log ,而sqlserver 系統會截斷部分日誌.
oracle 的日誌是迴圈使用online redolog 並生成archivelog 檔案,而
sqlserver 的日誌構架如下描述
事務日誌物理構架
資料庫內的事務日誌對映在一個或多個物理檔案上。日誌檔案在概念上是一串連續的日誌記錄。在物理上，日誌記錄序列必須有效地儲存在實現事務日誌的物理檔案集內。

Microsoft® SQL Server™ 2000 在內部將每個物理日誌檔案分成許多虛擬日誌檔案。虛擬日誌檔案沒有固定大小，且物理日誌檔案所包含的虛擬日誌檔案數不固定。在建立或擴充套件日誌檔案時，SQL Server 動態地選擇虛擬日誌檔案的大小。SQL Server 嘗試維護少量的虛擬檔案。在日誌副檔名後，根據現有日誌的大小和新檔案增量的大小確定虛擬檔案的大小。虛擬日誌檔案的大小或數量不能由管理員配置或設定，而是由 SQL Server 程式碼動態確定。

只有當虛擬日誌檔案的 size 和 growth_increment 值較小時，它們才會影響系統的效能。如果這些日誌檔案經過多次按小增量值增長後變得很大，它們將有大量的虛擬日誌檔案，從而降低恢復的速度。建議使用接近最終所需大小的 size 值來定義日誌檔案，並將日誌檔案的 growth_increment 值設得相對大一些。

事務日誌是迴繞的日誌檔案。例如，假設有一個資料庫，它包含一個分成四個虛擬日誌檔案的物理日誌檔案。當建立資料庫時，邏輯日誌檔案從物理日誌檔案的始端開始。在邏輯日誌的末端新增新的日誌記錄，邏輯日誌就向物理日誌末端增長。截斷操作發生時，刪除最小恢復日誌序號（MinLSN）之前的虛擬日誌內的記錄。本示例資料庫內的日誌外觀與下圖所示相似。




這個迴圈不斷重複，只要邏輯日誌的末端不到達邏輯日誌的始端。如果經常截斷舊的日誌記錄，使得總能為下一個檢查點建立的所有新日誌記錄保留足夠的空間，那麼日誌永遠不會填滿。然而，如果邏輯日誌的末端真的到達了邏輯日誌的始端，將發生下列兩件事之一：

如果對日誌啟用了自動增長且磁碟上有可用空間，檔案就按 growth_increment 指定的數量擴充套件，新的日誌記錄則新增到擴充套件中。


如果沒有啟用自動增長，或者儲存日誌檔案的磁碟上的可用空間比 growth_increment 指定的數量少，則生成 1105 錯誤。
如果邏輯日誌包含多個物理日誌檔案，則邏輯日誌將沿著所有的物理日誌檔案移動，然後迴繞到第一個物理日誌檔案的始端。

 

截斷事務日誌
如果從來沒有從事務日誌中刪除日誌記錄，邏輯日誌就會一直增長，直到填滿容納物理日誌檔案的磁碟上的所有可用空間。在某個即時點，必須刪除恢復或還原資料庫時不再需要的舊日誌記錄，以便為新日誌記錄騰出空間。刪除這些日誌記錄以減小邏輯日誌的大小的過程稱為截斷日誌。

永遠不能截斷事務日誌的活動部分。日誌的活動部分是在任何時間恢復資料庫所需的日誌部分，因此必須有回滾所有未完成的事務所需的日誌映像。這部分必須始終在資料庫中，因為一旦伺服器發生故障，在伺服器重新啟動時必須用它恢復資料庫。日誌活動部分起點處的記錄由最小恢復日誌序號 (MinLSN) 標識。

為資料庫選擇的恢復模式決定了在資料庫內，必須在活動部分之前保留的事務日誌量。雖然 MinLSN 之前的日誌記錄對恢復活動事務沒有作用，但在使用日誌備份將資料庫還原到故障點時，必須用這些記錄前滾修改。如果由於某種原因丟失了資料庫，則可以透過還原上次的資料庫備份，然後還原自該資料庫備份後的每個日誌備份來恢復資料。這意味著這些日誌備份必須包含自資料庫備份後所寫入的每個日誌記錄。當維護事務日誌備份序列時，日誌記錄直到寫入日誌備份時才能被截斷。

MinLSN 之前的日誌記錄只用於維護事務日誌備份序列。

在簡單恢復模式中，不維護事務日誌序列。MinLSN 之前的所有日誌記錄可以隨時被截斷，但在處理 BACKUP 語句時除外。NO_LOG 和 TRUNCATE_ONLY 是隻對使用簡單恢復模式的資料庫有效的 BACKUP LOG 選項。


說明  tempdb 資料庫始終使用簡單恢復模式，不能切換到其它恢復模式。日誌截斷始終發生在 tempdb 中的檢查點上。

在完全恢復模式和有日誌記錄的大容量恢復模式中，維護事務日誌備份序列。MinLSN 之前的邏輯日誌部分直到複製到某個日誌備份時才能被截斷。
日誌截斷在下列情況下發生：

執行完 BACKUP LOG 語句時。


在每次處理檢查點時（如果資料庫使用的是簡單恢復模式）。這包括 CHECKPOINT 語句所產生的顯式檢查點和系統生成的隱式檢查點。例外情況是如果檢查點發生在 BACKUP 語句仍活動時，則不截斷日誌。有關自動檢查點間隔的更多資訊，請參見檢查點和日誌的活動部分。
事務日誌在內部分成若干稱為虛擬日誌檔案的部分。虛擬日誌檔案是截斷的單元。當截斷事務日誌時，刪除包含 MinLSN 的虛擬日誌檔案頭之前的所有日誌記錄。有關虛擬日誌檔案的更多資訊，請參見事務日誌物理構架。

因此，按下面任一方式控制事務日誌的大小：

在維護日誌備份序列時，排程 BACKUP LOG 語句按間隔發生，以使事務日誌不致增長到超過預期的大小。


當不維護日誌備份序列時，指定簡單恢復模式。