由于日志是順序寫入，而修改數據分散在數據庫各個頁面，屬于隨機寫入，而磁盤順序寫入速度遠高于隨機寫入，因此主流數據庫都采用預寫日志的方式來確保數據完整性

1.日志記錄的是數據的變化而不是引發數據的操作2.每條記錄都有唯一的編號：LSN，并且記錄了它屬于的事務號。3.日志記錄的行數和實際修改的數據量有關4.日志記錄了事務發生的時間，但不記錄發起者的程序名稱和客戶端信息5.日志記錄數據修改前和修改后的數據

虛擬日志文件的狀態：1.活動(ACTIVE),在VLF上有任一條LSN是活動的2.可恢復(RECOVERABLE),VLF上的LSN不活動的，但尚未被截斷(truncated)，該片區域的日志將可能被用于備份/鏡像/復制等3.可重用(REUSED),VLF上無活動的LSN,且已經被截斷，該空間可以被再次使用4.未使用(UNUSED),VLF是不活動的，且空間從未被使用過

（PS: DBCC LOGINFO 中Status=0表示可重用或未使用，Status=2表示活動或可恢復）

數據增長大小與VLF增長數量1-64M：4個VLF64M-1G:8個VLF1G以上：16個VLF

截斷(Truncated)是將VLF從Recoberable 狀態轉變成 reused 狀態

In sample recovery model,Every checkpiont will check is there any vlf could be truncated, truncated the recoverable lsn and move the min lsn

在簡單恢復模式下，日志僅用于事務回滾和數據庫崩潰時的恢復。

在完整恢復模式下，只有經過日志備份過的日志才可以被截斷

從完整恢復模式切換到大容量日志恢復模式并不會破壞日志鏈條，因此可以在可能產生大量日志的操作（SELECT INTO/INSERT INTO SELECT /REBUILD INDEX/CREATE INDEX）等之前將恢復模式轉換成大容量日志模式，操作結束后在換回完整模式，這樣不會破壞現在的備份策略同時有效避免此操作生成大量日志和日志文件急速增長

引發Log 讀的操作

1. Transcation rollback2. crash recovery3. create a database snapshot4. running dbcc checkdb5. transaction log backup6. database full backup or differential backup7. transcation replication8. change data capture9. database mirroring10. a checkpoint in the simple recovery mode11. PRocessing a DML trigger(on sql server 2000)12. manually looking in the log(dbcc log or fn_log)

由于單個事務會產生多天事務日志記錄，如果每條事務日志記錄都寫一次磁盤，會造成嚴重的瓶頸，并且嚴重延遲事務執行時間，因此SQL SERVER 將事務日志先存放在Log Buffer中，在滿足以下條件時將日志記錄寫入磁盤：1>事務提交或回滾2>有超過60KB的日志沒有刷新寫入磁盤

在log flush時，會將log buffer中所有日志記錄都寫入磁盤，無論該日志所屬的事務是否提交。

由于每個事務提交或回滾都會造成一次log flush，每次事務提交需等待日志被寫入磁盤才算成功，因此日志寫入磁盤延遲直接影響事務的執行時間。

SQL SERVER限制log flush的并發數最大為32，因此，在同一時間點，只能有32個事務被提交

解決日志寫等待的問題1>減少日志的寫入量2>提高事務日志的寫入速度

提高事務日志的寫入速度1>如果日志所在磁盤較慢，可以將日志移動到較快的磁盤上2>如果日志所在磁盤已經足夠快的情況下，有大量并發的小事務操作，可拆分為多個數據庫來解決