清空數據庫的日志文件
問題的引出我們的切割過程就是將單據數據中某個日期以前的數據先復制到新的數據庫中(select into )然後再將原來數據庫中的這些數據刪除這樣操作在數量量很大的數據庫上時其日志文件的增長也是驚人的我復制一個萬條記錄的表時最後發現僅這一個表的操作就使新數據庫的日志文件增加了MB如果不加清理那就會被日志文件占用大量寶貴的磁盤空間況且我們轉移到的新建數據庫的作用也只是用來查詢以後不會有任何InsertUpdateDelete操作的要這些日志文件沒有什麼用處因此必須在向它轉移數據的過程中做一些縮小日志文件的處理怎麼辦??問題由此而生
()處理過程中不記錄日志
設置方法如下企業管理器中打開對應數據庫的屬性頁框選項中將模型改為簡單這樣設置的結果是對此數據庫的任何操作都將不記錄事務日志對應的SQL為EXEC sp_dboption @pdbName trunc log on chkpt TRUE
但是我們經過測試發現啟用此功能後我們在對這個數據庫操作時就不能用事務操作了程序執行到BeginTranSaction時就報錯不能執行下去由於我們不能在對此庫的操作中保證%的正確性因此我們還需要事務因此這種方法適用空間有限也不能滿足我們程序的需求
我們還得繼續查找
()處理過程中允許記錄日志但要對日志文件進行處理時時縮小它
SQL Server的聯機幫助告訴我們
在下列情況下日志文件的物理大小將減少
執行 DBCC SHRINKDATABASE 語句時
執行引用日志文件的 DBCC SHRINKFILE 語句時
自動收縮操作發生時
下面我們逐個分析這三個方案
① DBCC SHRINKDATABASE收縮特定數據庫的所有數據和日志文件包含我們的需求但也大於我們的需求此方案可用但不要著急給人的感覺是買了一件能穿的衣服但尺寸大了些穿在身上有點不舒服我們接著分析以下兩個方案
② DBCC SHRINKFILE: 收縮相關數據庫的指定數據文件或日志文件大小與方案的區別僅一字之差和與或相當於把方案拆成兩步來執行我們需要的就是收縮日志文件因此它對我們來說顯得比較合適有點量體裁衣的感覺但還有沒有更好的呢我們來看第三個方案
③自動收縮數據庫也可設置為按給定的時間間隔自動收縮服務器定期檢查每個數據庫中的空間使用情況如果發現數據庫中有大量閒置空間而且它的 autoshrink 選項設置為 trueSQL Server 就縮小該數據庫中的文件大小它是周期性的執行DBCC SHRINKDATABASE既然方案已經是一件尺寸大了一些的衣服則此方案就相當於又穿上了N件大尺寸衣服一件就已經夠了我還要那麼多干嘛呢??
綜合對比發現方案正是我們需要的
DBCC SHRINKFILE (+Trim(edDBMCText)+_Log TRUNCATEONLY)
經過這個語句處理以後日志文件將回到它的最小狀態KB任何的日志記錄都將清空
再結合我們的工具復制完一個表之後我們就執行方案處理過程中日志文件暫時占用的最大空間也就是處理最大數據表時產生的日志空間但最後都將清空顯示為多KB相對於龐大的數據文件而言微之戡微
[] []
From:http://tw.wingwit.com/Article/program/Delphi/201311/24748.html
