transaction log file是採用循環使用的，當最後一個 virtual log file用完之後便會從檔案開頭繼續重複使用，所以通常檔案是固定大小不會成長的，只有遇到如交易量太大或某交易遲遲未commit，才會讓transaction log file長大，SQL Server裡面也有 MinLSN 的概念，只有MinLSN之前的 virtual log files空間才能被重複使用，這時就會依照所設定的growth_increment來自動成長，只要目錄空間夠的話。

SQL Server recovery model的設定跟 transaction log有很大的關聯，有3種model
1. Simple recovery model
2. Full recovery model
3. bulk-logged recovery model

Simple recovery model 方式就像 DB2 circular logging，完全不需管理，採循環使用方式，當checkpoint時會自動 truncate logs，但是只支援將資料庫復原到備份當時。

Full recovery model和 bulk-logged recovery model就類似 DB2 linear logging，checkpoint時 virtual logs並不會自動truncate，必須備份 log 之後才會truncate，可以支援 point-in-time recovery。

Full recovery model和 bulk-logged recovery model的差別在於執行某些可以被minimally logged的動作時，在Full recovery model中所有的動作都會被記錄下來，而在bulk-logged recovery model中只記錄重點可回復該動作的部分，且不支援point-in-time的復原。所以會加速該動作的執行，但是最後log record會比較大，因為會紀錄該動作的結果。

有關bulk-logged recovery model這部分的理解，很像是 DB2 在執行 LOAD 動作，過程僅產生很少的log record，所以速度比 IMPORT快，而為了資料庫的復原要求，需要將LOAD進資料庫的資料進行備份，而SQL Server就將該minimally logged動作的結果放在 transaction logs裡面。

因此SQL Server建議一般採用 Full Recovery Model,當有需要執行會產生大量交易的動作時，先切換到 Bulk-logged recovery model，完成後再切換回來，以加快速度。而在Bulk-logged recovery model期間是不支援 point-in-time recovery，所以最好在之前與之後各做一次LOG備份。