SQL Server事務日誌過大的處理

 

假設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   語句按間隔發生，以使事務日誌不致增長到超過預期的大小。  
  *當不維護日誌備份序列時，指定簡單恢復模式。    
   
  詳情請參考   MS   SQL   Server   2000   聯機叢書：  
  目錄--&gt   SQL   Server構架--&gt資料庫構架--&gt物理資料庫構架--&gt事務日誌構架--&gt收縮事務日誌  
  目錄--&gt   SQL   Server構架--&gt資料庫構架--&gt物理資料庫構架--&gt事務日誌構架--&gt截斷事務日誌