淺談幾個SQL的日志概念

今天抽出一點時間解釋幾個關于SQL日志的概念，他們也經常使初學者望而止步，反正計算機的術語都是很抽象的，所以第一感覺就是頭疼，然后然后幾次后就沒感覺了.以下有些是從書上摘抄的,有的是從網上找的算是借花獻佛吧!!

物理日志文件：
? ? 這個比較好理解，實實在在的東西，數據庫目錄下面的.ldf文件就是，有些人喜歡改后綴，感覺不大好，數據庫的事務日志記錄就在這里面

虛擬日志：
? ? 相信多數人有這個感覺，虛擬這個字眼總是神秘的代名詞，虛擬個飯島愛我喜歡，但虛擬日志，虛擬內存，虛擬。。。。，看了就討厭。解釋應該是這樣的，對于一個或多個連續的物理日志文件，SQL SERVER在這些文件的內部又劃分成了多個小的文件，稱為虛擬日志文件，他是日志文件收縮和日志截斷的最小單位，比如物理日志文件是400M，內部劃分了4個100M的虛擬文件，收縮時你得到的是300M，200M，不可能得到239M，對于一個物理文件，會劃分成多少個虛擬文件，這個由SQL自己維護，唯一可以人工干預的是指定較大的物理日志文件，并指定較大的增長比例，這樣可能虛擬文件的塊頭會大點，數量會少點，系統的維護開銷會低一點

邏輯日志：
? ? 不要頭暈，硬著頭皮看吧！！！感覺這個應該是數據庫事務日志的真實寫照，物理日志文件好比是一個容器，里面容納的是日志記錄，這些記錄就稱為邏輯日志，從物理日志文件的起點開始，邏輯日志順序的生成，記錄下數據庫里發生的每個事務，這些事務被打上一個標簽，LSN，順序的排列下來，這樣邏輯日志就在物理日志文件內慢慢的成長，直到充滿了他，這個時候物理日志文件就會自動添加新的空間，以繼續前面的步驟，這種情況是最直接的一種（從來不截斷日志，基本上就是這樣的），但事實上往往是復雜的多

檢測點(checkpoint)和恢復周期(recovery interval)：
? ? checkpoint不是用于檢查數據是否完整，頁面連接是否正確的，他是由系統維護的一個進程（你也可以手工的執行），用于將高速緩存里的臟頁刷新到磁盤，兩者的配合算是惟妙惟肖，當緩存中的臟頁積累到一定的數量，SQL估計演算這些臟頁要花的時間快要接近設定的recovery interval（分鐘）時，系統就會產生一個checkpoint，所以checkpoint的產生不是定時的，它由recovery interval和數據庫的更新頻繁度決定。如果你的數據庫永遠不用重啟，永遠不會出現什么故障，就這么一直運行下去，那么checkpoint和recovery interval就沒有想象中的重要了，SQL總是先寫日志，情況應該是這樣的：用戶提交一個更新操作，SQL在高速緩存里緩沖了需要的數據頁和日志頁，然后打上begin tran標簽，對日志進行修改，再修改數據頁，然后打上commit tran標簽，最后把修改過的日志頁刷新到磁盤上，在保證了這個步驟完成后，數據頁才被寫入磁盤，如果這個時候機器突然斷電導致高速緩存中數據頁的丟失，那么重啟機器時SQL的恢復進程將根據已經刷新的日志記錄來演算剛才的數據頁，保證數據的完整性，這就好比支票已經開到了，但貨卻在路上丟了，憑借支票，你還是可以得到你的東西,像這種提交了又還沒來得及刷新數據頁到磁盤的日志事務可以稱為活動日志，雖然概念不是這么定義的，但可以這么理解，因為一旦日志記錄和其對應的數據頁被刷新到磁盤的話，這條日志的作用也就完成了，并稱為非活動的日志，他的唯一用處就是備份下來留著以后做日志恢復，所以SQL的邏輯日志你就應該知道大概是怎么個樣子了，前面一大部分，是已經演算的日志記錄（非活動日志），后面一部分，是還沒有演算的（活動日志），活動部分的第一條事務稱為MinLSN，系統會擱段時間利用檢測點（checkpoint）演算活動日志，來縮短數據庫重啟時的恢復時間，在演算結束后，checkpoint會在日志里打上一個結束語，并將MinLSN標識給下一個緊跟著的活動事務日志，這也是下一個checkpoint的起點

截斷事務日志：
? ? 這個概念很是讓初學者費解，截斷是什么意思？？？截斷后日志還會增長嗎？？？截斷總有個斷點吧，他是從哪里開始截斷的阿？？？截斷后會釋放日志空間嗎？？？等等。。。。現在逐一擊破
? ? 首先截斷是對SQL邏輯日志的一個清除過程，清除非活動的邏輯事務日志。可以想象斷點應該是活動與非活動的邊界處--MinLSN，他會將MinLSN前面的這段日志清除掉,邏輯日志的起點也會指向斷點MinLSN處，清除出來的空間并不會返還給操作系統，而是被標識為非活動的虛擬日志文件，他表示當有新的日志記錄進來時，這些空間可以被再次利用，所以截斷日志并不會減小物理日志文件的大小，只是清理了里面的一些內容，以便新的日志記錄可以進來，SQL總是以循環鏈表的方式使用物理日志文件的，當邏輯日志增長到物理日志文件的盡頭時，他會循環到日志文件的首部搜索被截斷而釋放出來的空間，如果這個時候沒有空間的話，說明物理日志已經用完了，就得增加物理日志的大小，如果磁盤也用盡了，系統就會返回一個錯誤提示。至于截斷后日志是否還會增長，疑點可能存在于trunc log on chkpt上，當數據庫處于這種狀態時用戶會發現他們的日志文件總是那么小一點點，道理很簡單，檢查點截斷日志后，日志文件里面總會有空間容納新的日志記錄，自然是不會變大了，但也有特殊情況，當一個較長的事務運行時（比如一個長達2個小時的UPDATE語句），他會迅速的充滿日志，并補充新的空間進來，這個時候系統是來不及截斷的，這樣物理日志文件就馬上變大了，當事務完成后，截斷再進行時，對文件的大小他是無能為力了，只是清理下剛才的戰場而已，所以截斷日志后邏輯日志是繼續增長的，至于物理日志，要看你提交事務的大小了

最后的話題：
? ? 經常聽到這樣的說法，定期轉存事務日志，以釋放日志空間，backup log...with no_log,backup log...with truncate_only,這些只能使日志文件不變大，要想減小日志文件，還是要收縮日志文件，這樣才真正將空間返還給操作系統，在sybase里面truncate_only和no_log還是有區別的，都是截斷日志，但前者在截斷之前會啟動checkpoint,所以當你的日志完全被充滿，truncate_only是不能成功的，他已經沒有空間讓你checkpoint，這時只能采用no_log(SQL里面我還不知道)，還有一個關鍵字就是no_truncate,他表示備份但不截斷日志（默認是截斷的），在數據庫因故障損壞時用這個備份日志特別有效

好了，就說這么多了，由于這部分的概念實在是太抽象，本人能力也非常有限，所以表述可能不大清楚，錯誤的地方請多多指教！！！

淺談幾個SQL的日志概念