黃昏的甘蔗

 

 前一篇才寫了「交易記錄檔 LDF 太大」，怎麼這一篇還是寫交易記錄檔太大，會不會太過騙人了，想衝篇數也不是這樣......不是的～是因為直接刪LDF這種手法太暴力，太不可預測風險，所以決定要用SQL本身提供的工具（DBCC ShrinkFile）來正確的處理他。又不想將2種混在同一篇說，所以又多了這一篇囉～

執行步驟

1. 將資料庫復原模式設成「簡單」
2. 執行 （DBCC ShrinkFile）
3. 將資料庫復原模式設成「完整」

↓ 目前MDF與LDF的檔案大小

↓ DBCC  參數說明與指令

 

/* DBCC SHRINKFILE  ( { file_name | file_id }      { [ , EMPTYFILE ]      | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]   } ) [ WITH NO_INFOMSGS ]  1st 參數：使用檔案名稱或檔案ID  select * from sys.database_files  2nd 參數：設定清空檔案或指定大小(MB) http://msdn.microsoft.com/zh-tw/library/ms189493.aspx*/ select * from sys.database_files DBCC SHRINKFILE (web_statistics_Log , 2)

 

↓ 執行的成效

↓ 真實的檔案縮小

↓ 將資料庫復原模式設成「完整」

 

↓ 那為何是2048KB 呢？ 這跟你資料庫預設的檔案初始大小有關

搞定收工～

但～不知道你會不會像我一樣很「背骨」的想說，那幹嘛不乾脆，直接執行「DBCC SHRINKFILE (web_statistics_Log , 2)」就好了呢？幹嘛把 recovery mode 改來改去呢？

↓ 答案是當然不行囉～不然幹嘛多那兩個步驟

因為在 Recovery Mode 為完整時，所有 Transactions 都會持續記錄在LDF裡，這樣才能任意的還原到哪一時間點，所以所有LOG都是有意義的，有意義的當然不讓你清掉囉！

設定成簡單之後，那些過往交易的值，都被寫入（或更新）到資料檔MDF裡，例如：

收100、收500、花200、花100、收50～而你設定成簡單，表示只想知道最後剩下 350 不想記錄過程，那麼那些歷史資料就能被 DBCC ShrinkFile 給清掉囉～

～ End