SQL Server 2005的默認設置很齷齪!, 不小心就沒注意,等到出現Log文件過大,大到10G的時候,才想起來要Shrink一下。
防止遺忘:
以下為引用的內容: use DBNAME; #選擇要操作的數據庫 go backup log DBNAME with truncate_only; #先切掉LOG文件 dbcc shrinkfile (DBNAME_log, 1); #再壓縮LOG文件 |
ps:察看當前數據庫使用情況用:
exec sp_spaceused
順便給個MS的連接,說是關于
SQL Server 中的自動增長和自動收縮配置注意事項
http://support.microsoft.com/?scid=kb%3Bzh-cn%3B315512&x=5&y=12
其中主要看:
最佳做法
對于受管理的生產系統,您必須將自動增長僅視為偶然的意外增長。請勿使用自動增長管理每天的數據和日志增長。
您可以使用警報或監控程序來主動地監控文件大小和增長文件。這有助于您減少碎片,并允許您將這些維護活動移到非高峰時段進行。
自動收縮和自動增長必須由訓練有素的數據庫管理員 (DBA) 仔細評估,而不能不對其進行管理。
您的自動增長增量必須足夠大,以避免上一節中列出的性能影響。要在您的配置設置中使用的精確值以及增量是以百分比還是以特定的 MB 值表示取決于環境中的許多因素。一種可供嘗試的通用經驗規則是:將您的自動增長設置設定為文件大小的八分之一左右。
打開每個文件的 設置,以防某個文件增長到會用盡全部可用磁盤空間的大小。
保持事務大小盡可能小,以防出現計劃外的文件增長。
CPU可能造成的SQL Server的BUG:
SQL Server timing values may be incorrect when you use utilities or technologies that change CPU frequencies