最近遇到某個mssqlserver2008 資料庫的日誌檔案過於龐大，資料檔案4g，日誌檔案達到80g。
日誌檔案這麼大的原因還得從資料庫的恢復模式說起：
三種恢復模式：簡單恢復模式、完整恢復模式和大容量日誌恢復模式。通常，資料庫使用完整恢復模式或簡單恢復模式。而大容量模作為完整模式的補充，比如需要一次性匯入大量資料，這會產生大量日誌，可以暫時切換到大容量日誌模式可以提高效能，減少日誌大小。大容量日誌模式為附加模組不常用，所以主要介紹簡單和完整模式：
簡單恢復模式是無日誌備份的。在這種模式下會自動**日誌空間以減少空間需求，實際上不再需要管理事務日誌空間。最新備份之後的更改不受保護。在發生災難時，這些更改必須重做。只能恢復到上次的備份。 完整模式是需要日誌備份。資料檔案丟失或損壞不會導致丟失工作。可以恢復到任意時點（例如應用程式或使用者錯誤之前）。但是如果日誌尾部損壞，則必須重做自最新日誌備份之後所做的更改。
檢視現場恢復模式為完整恢復模式，所有操作都記錄log，所以日誌才會這麼大。（btw：現場資料檔案和日誌檔案在同一目錄下，不建議這樣做，最好放到不同的分割槽，這樣如果乙個分割槽壞了，還可以恢復，否則....）。
查詢資料網上說收縮檔案，使用了效果不理想。繼續查詢資料得出結果:要先截斷日誌再收縮。例如我拿了另外相對較小的乙個資料庫做測試.
開始時候資料庫檔案大小為：資料檔案94m，而日誌檔案為425m。
圖一：資料庫初始大小：
執行收縮操作：在資料庫右鍵-任務-收縮-檔案。在檔案型別選擇日誌，點選確定，待執行完畢後。重新整理【注意這裡一定要重新整理】檢視檔案資料庫屬性發現效果很不理想，只減少了19m。下圖為收縮之後的效果：
圖二：第一次收縮
於是就進行日誌截斷。日誌截斷可以使用命令列【backup log with truncate_only】來做。但是這樣，就可能導致之前的操作資訊丟失。不能恢復到以前的某個時間點。另外可以通過備份來自動截斷日誌，mssqlserver中全備份是不會截斷日誌的，備份日誌檔案可以自動截斷日誌。接下來做日誌備份：資料庫右鍵-任務-備份-檔案。備份型別選擇事物日誌，點選確定執行。
這樣截斷日誌之後，再執行收縮操作後檢視日誌檔案大小只有6m：
圖三：截斷之後收縮效果
附：日誌收縮和日誌截斷的區別：
◆日誌收縮
截斷日誌雖然確實從日誌檔案中清除了事務，但它並不會真正的減小物理日誌檔案的大小。sql server希望事務日誌最終會擴充套件到其截斷前的大小，所以截斷不會釋放已經分配給日誌的硬碟空間。如果你的日誌在某一時刻人為地擴充套件到某個大小，卻再也無法恢復到這個大小的話可就麻煩大了。
◆日誌截斷 截斷事務日誌操作就是清除事務日誌檔案中的非活動記錄。在一般的情況下，sql server能夠自動執行截斷操作，不需要人工干預管理。截斷的頻率取決於資料庫的使用程度。你每進行一次完整恢復模式或大容量日誌恢復模式的資料庫備份，sql server就會截斷一次事務日誌。如果是在簡單恢復模式下(不能還原事務日誌)，sql server會在每個檢查點之後截斷事務日誌。【注：全備份不能截斷日誌，必須備份日誌檔案之後才能截斷日誌，我在mssqlserver2008中遇到的是這樣的】
簡單來說 日誌收縮：物理的收縮資料日誌檔案的大小 日誌截斷：邏輯的釋放日誌空間以供事務日誌重新使用
SQL Server日誌過大，清理日誌
直接執行下面的 use master go alter database 資料庫 set recovery with no wait goalter database 資料庫 set recovery 簡單模式 gouse 資料庫 godbcc shrinkfile n 邏輯名 2000,trunc...
CruiseControl 日誌檔案過大
zoundrydocument 前一陣，為了提公升公司 質量，改善開發流程，在我們專案組內，引入了持續整合伺服器，由於我們使用vs作為開發工具，所以選擇使用cruisecontrol.net，下面簡稱cc。server和dashboard的部署，基本看附帶的文件就能搞定，我建立了乙個簡單的流程，每隔...
sql server日誌占用空間過大的問題
方法2 1 清空日誌 dump transaction 庫名 with no log 2 截斷事務日誌 backup log庫名 with no log 3 收縮資料庫檔案 如果不壓縮,資料庫的檔案不會減小 企業管理器 右鍵你要壓縮的資料庫 所有任務 收縮資料庫 收縮檔案 選擇日誌檔案 在收縮方式裡...