計(jì)算機(jī)等級考試二級Delphi開發(fā)兩條經(jīng)驗(yàn)分享

　　2、清空數(shù)據(jù)庫的日志文件

　　問題的引出：我們的切割過程就是將單據(jù)數(shù)據(jù)中某個(gè)日期以前的數(shù)據(jù)先復(fù)制到新的數(shù)據(jù)庫中(select ... into ...)，然后再將原來數(shù)據(jù)庫中的這些數(shù)據(jù)刪除,這樣操作在數(shù)量量很大的數(shù)據(jù)庫上時(shí)，其日志文件的增長也是驚人的：我復(fù)制一個(gè)48萬條記錄的表時(shí)，最后發(fā)現(xiàn)僅這一個(gè)表的操作就使新數(shù)據(jù)庫的日志文件增加了170MB，如果不加清理，那就會(huì)被日志文件占用大量寶貴的磁盤空間。況且，我們轉(zhuǎn)移到的新建數(shù)據(jù)庫的作用也只是用來查詢，以后不會(huì)有任何Insert、Update、Delete操作的，要這些日志文件沒有什么用處，因此必須在向它轉(zhuǎn)移數(shù)據(jù)的過程中做一些縮小日志文件的處理，怎么辦??問題由此而生...

　　(1)處理過程中不記錄日志

　　設(shè)置方法如下：企業(yè)管理器中打開對應(yīng)數(shù)據(jù)庫的“屬性”，頁框“選項(xiàng)”中將“模型”改為“簡單”。這樣設(shè)置的結(jié)果是對此數(shù)據(jù)庫的任何操作都將不記錄事務(wù)日志。對應(yīng)的SQL為：EXEC sp_dboption @pdbName, 'trunc. log on chkpt.', 'TRUE'

　　但是，我們經(jīng)過測試發(fā)現(xiàn)：啟用此功能后，我們在對這個(gè)數(shù)據(jù)庫操作時(shí)，就不能用事務(wù)操作了，程序執(zhí)行到BeginTranSaction時(shí)就報(bào)錯(cuò)，不能執(zhí)行下去，由于我們不能在對此庫的操作中保證100%的正確性，因此我們還需要事務(wù)，因此這種方法適用空間有限，也不能滿足我們程序的需求。

　　我們還得繼續(xù)查找.....

　　(2)處理過程中允許記錄日志，但要對日志文件進(jìn)行處理，時(shí)時(shí)縮小它。

　　SQL Server的聯(lián)機(jī)幫助告訴我們：

　　在下列情況下，日志文件的物理大小將減少：

　　執(zhí)行 DBCC SHRINKDATABASE 語句時(shí)。

　　執(zhí)行引用日志文件的 DBCC SHRINKFILE 語句時(shí)。

　　自動(dòng)收縮操作發(fā)生時(shí)。

　　下面我們逐個(gè)分析這三個(gè)方案：

　�、� DBCC SHRINKDATABASE：收縮特定數(shù)據(jù)庫的所有數(shù)據(jù)和日志文件，包含我們的需求，但也大于我們的需求，此方案可用，但不要著急，給人的感覺是買了一件能穿的衣服，但尺寸大了些，穿在身上有點(diǎn)不舒服，我們接著分析以下兩個(gè)方案...

　　② DBCC SHRINKFILE: 收縮相關(guān)數(shù)據(jù)庫的指定數(shù)據(jù)文件或日志文件大小。與方案1的區(qū)別僅一字之差：“和”與“或”，相當(dāng)于把方案1拆成兩步來執(zhí)行，我們需要的就是收縮日志文件，因此，它對我們來說顯得比較合適，有點(diǎn)量體裁衣的感覺。但還有沒有更好的呢，我們來看第三個(gè)方案...

　�、圩詣�(dòng)收縮：數(shù)據(jù)庫也可設(shè)置為按給定的時(shí)間間隔自動(dòng)收縮，服務(wù)器定期檢查每個(gè)數(shù)據(jù)庫中的空間使用情況。如果發(fā)現(xiàn)數(shù)據(jù)庫中有大量閑置空間，而且它的 autoshrink 選項(xiàng)設(shè)置為 true，SQL Server 就縮小該數(shù)據(jù)庫中的文件大小。它是周期性的執(zhí)行DBCC SHRINKDATABASE，既然方案1已經(jīng)是一件尺寸大了一些的衣服，則此方案就相當(dāng)于又穿上了N件大尺寸衣服，一件就已經(jīng)夠了，我還要那么多干嘛呢??

　　綜合對比發(fā)現(xiàn)，方案2正是我們需要的。

　　DBCC SHRINKFILE ('+Trim(edDBMC.Text)+'_Log, TRUNCATEONLY)

　　經(jīng)過這個(gè)語句處理以后，日志文件將回到它的最小狀態(tài)504KB，任何的日志記錄都將清空。

　　再結(jié)合我們的工具，復(fù)制完一個(gè)表之后，我們就執(zhí)行方案2，處理過程中日志文件暫時(shí)占用的最大空間也就是處理最大數(shù)據(jù)表時(shí)產(chǎn)生的日志空間，但最后都將清空，顯示為500多KB，相對于龐大的數(shù)據(jù)文件而言，微之戡微.