物理日誌文件：
這個比較好理解，實實在在的東西，數據庫目錄下面的.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,他表示備份但不截斷日誌（默認是截斷的），在數據庫因故障損壞時用這個備份日誌特別有效
好了，就說這麼多了，由於這部分的概念實在是太抽象，本人能力也非常有限，所以表述可能不大清楚，錯誤的地方請多多指教！！！