--假設test2為數據庫名稱
日志已經很大的時候用
方法一
此方法適用於7.0和2000。
1、在查詢分析器中執行：
exec sp_detach_db 'DB_Name'
2、在我的電腦中將日志的物理文件xxx_Log.LDF改名。
3、在查詢分析器中執行：
exec sp_attach_single_file_db 'DB_Name','C:\Program Files\Microsoft SQL Server\MSSQL\Data\DB_Name.MDF'
4、如果上一步成功，將步驟2中改名後的文件刪除。如果上一步不成功，改回原來的文件名，
用sp_attach_db將數據庫附加到服務器，然後用方法二。
方法二
6.X中
DUMP TRANSACTION test2 with NO_LOG
DUMP TRANSACTION test2 with TRUNCATE_ONLY
將上面的語句多次執行，直到日志縮小。
7.0和2000中
backup log test2 with NO_LOG
backup log test2 with TRUNCATE_ONLY
DBCC SHRINKDATABASE(test2)
將上面的語句多次執行，直到日志文件縮小。
上面的方法治標不治本，標本兼治要用下面的方法。
方法三：
--6.X和7.0中改為日志處於截斷模式，2000中恢復模型改為簡單恢復
exec sp_dboption 'test2','trunc. log on chkpt.','on'
--7.0和2000中設為自動收縮,6.x中不用執行。
exec sp_dboption 'test2','autoshrink','on'
通常用於測試環境。
方法四:
--7.0中改為日志不處於截斷模式，2000中恢復模型改為完全恢復
exec sp_dboption 'test2','trunc. log on chkpt.','off'
--7.0和2000中設為自動收縮,6.x中不用執行。
exec sp_dboption 'test2','autoshrink','on'
建立作業,每半個小時一次日志備份,每天一次完全數據庫備份。
7.0和2000中：在Log收縮到正常大小後，將autoshrink選項設置為off。
通常用於真實環境。
在產品化系統中將autoshrink選項設置為開啟狀態並非明智之舉（除非您真的需要這樣做），這是因為，當您的系統正在忙於完成其它任務時，autoshrink選項可能會同時啟動，從而降低系統運行速度。然而，對於那些數據庫管理員無暇估計並且數據庫尺寸有可能在您毫無察覺的情況下超出控制范圍的桌面或遠程系統來說，開啟這一選項卻是一種非常有效的措施。
收縮事務日志
在下列情況下，日志文件的物理大小將減少：
*執行 DBCC SHRINKDATABASE 語句時。
*執行引用日志文件的 DBCC SHRINKFILE 語句時。
*自動收縮操作發生時。
日志收縮操作依賴於最初的日志截斷操作。日志截斷操作不減小物理日志文件的大小，但減小邏輯日志的大小，並將沒有容納邏輯日志任何部分的虛擬日志標記為不活動。日志收縮操作會刪除足夠多的不活動虛擬日志，將日志文件減小到要求的大小。
按下面任一方式控制事務日志的大小：
*在維護日志備份序列時，調度 BACKUP LOG 語句按間隔發生，以使事務日志不致增長到超過預期的大小。
*當不維護日志備份序列時，指定簡單恢復模式。
