由于日志是順序?qū)懭耄薷臄?shù)據(jù)分散在數(shù)據(jù)庫(kù)各個(gè)頁(yè)面，屬于隨機(jī)寫入，而磁盤順序?qū)懭胨俣冗h(yuǎn)高于隨機(jī)寫入，因此主流數(shù)據(jù)庫(kù)都采用預(yù)寫日志的方式來確保數(shù)據(jù)完整性

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

虛擬日志文件的狀態(tài)：1.活動(dòng)(ACTIVE),在VLF上有任一條LSN是活動(dòng)的2.可恢復(fù)(RECOVERABLE),VLF上的LSN不活動(dòng)的，但尚未被截?cái)?truncated)，該片區(qū)域的日志將可能被用于備份/鏡像/復(fù)制等3.可重用(REUSED),VLF上無活動(dòng)的LSN,且已經(jīng)被截?cái)啵摽臻g可以被再次使用4.未使用(UNUSED),VLF是不活動(dòng)的，且空間從未被使用過

（PS: DBCC LOGINFO 中Status=0表示可重用或未使用，Status=2表示活動(dòng)或可恢復(fù)）

數(shù)據(jù)增長(zhǎng)大小與VLF增長(zhǎng)數(shù)量1-64M：4個(gè)VLF64M-1G:8個(gè)VLF1G以上：16個(gè)VLF

截?cái)?Truncated)是將VLF從Recoberable 狀態(tài)轉(zhuǎn)變成 reused 狀態(tài)

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

在簡(jiǎn)單恢復(fù)模式下，日志僅用于事務(wù)回滾和數(shù)據(jù)庫(kù)崩潰時(shí)的恢復(fù)。

在完整恢復(fù)模式下，只有經(jīng)過日志備份過的日志才可以被截?cái)?/p>

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

引發(fā)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)

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

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

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

SQL SERVER限制log flush的并發(fā)數(shù)最大為32，因此，在同一時(shí)間點(diǎn)，只能有32個(gè)事務(wù)被提交

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

提高事務(wù)日志的寫入速度1>如果日志所在磁盤較慢，可以將日志移動(dòng)到較快的磁盤上2>如果日志所在磁盤已經(jīng)足夠快的情況下，有大量并發(fā)的小事務(wù)操作，可拆分為多個(gè)數(shù)據(jù)庫(kù)來解決