华南俳烁实业有限公司

　　近期在做“數(shù)據(jù)庫(kù)切割工具”時(shí)，碰到了一些棘手的問題，經(jīng)過多方打探、查找，最終得以解決，現(xiàn)總結(jié)下來，給大家共享，免的大家以后在碰到類似問題時(shí)再耗費(fèi)大量時(shí)間去查找、去打探!

　　1、判斷輸入的路徑在服務(wù)器上是否存在：

　　例如，要在客戶端執(zhí)行一個(gè)創(chuàng)建數(shù)據(jù)庫(kù)的程序，數(shù)據(jù)庫(kù)要在服務(wù)器上創(chuàng)建，但路徑可以手工輸入，這時(shí)就面臨一個(gè)判斷自已現(xiàn)在輸入的路徑在服務(wù)器上是否存在的問題，免得在執(zhí)行Create Database SQL時(shí)才報(bào)錯(cuò)：找不到路徑。

　　具體方法如下：

　　exec master..xp_cmdshell 'dir E:\DATA' ，在查詢分析器中執(zhí)行此段SQL，如果存在此路徑，會(huì)輸出此路徑下的所有文件與文件夾信息，還有此盤的可用字節(jié)數(shù)與已此文件夾的字節(jié)數(shù)(圖1所示);如果此路徑不存在，則輸出信息如圖2所示，提示“找不到文件”。

　　但是，當(dāng)路徑中含有空格時(shí)，如C:\Program Files，直接用exec master..xp_cmdshell 'dir C:\Program Files'，系統(tǒng)返回結(jié)果會(huì)如跟圖2顯示一樣，我們需要做額外處理，才能得到正確的返回結(jié)果：

　　(1)exec master..xp_cmdshell 'dir "C:\Program Files\Microsoft SQL Server\MSSQL"'

　　這種寫法，在查詢分析器中直接執(zhí)行是沒有問題的，也能返回正確結(jié)果，但如果放到程序中執(zhí)行：

　　SQL.Add('exec master..xp_cmdshell ''dir "C:\Program Files\Microsoft SQL Server\MSSQL"'')，Open時(shí)就會(huì)報(bào)錯(cuò)，不能執(zhí)行。

　　為什么呢???

　　(2)我們接下來查看SQL聯(lián)機(jī)幫助，對(duì)XP_CMDSHELL的描述如下：

　　xp_cmdshell {'command_string'} [, no_output]

　　參數(shù)

　　'command_string'

　　是在操作系統(tǒng)命令行解釋器上執(zhí)行的命令字符串。command_string 的數(shù)據(jù)類型為 varchar(255) 或 nvarchar(4000)，沒有默認(rèn)值。command_string 不能包含一對(duì)以 上的雙引號(hào)。如果由 command_string 引用的文件路徑或程序名稱中有空格，則需要使用一對(duì)引號(hào)。如果使用嵌入空格不方便，可考慮使用 FAT 8.3 文件名作為解決辦 法。

　　no_output

　　是可選參數(shù)，表示執(zhí)行給定的 command_string，但不向客戶端返回任何輸出。

　　幫助文件提示我們要用一對(duì)引號(hào)將文件路徑或者程序名稱包起來，將整個(gè)路徑包不起來不會(huì)報(bào)錯(cuò)，那我就將帶有空格的單步路徑包起來試試，看看行不行，執(zhí)行 如下SQL：SQL.Add('exec master..xp_cmdshell ''dir C:\"Program Files"\"Microsoft SQL Server"\MSSQL'')，這樣Open時(shí)果然不報(bào)錯(cuò)了，看來查詢分析器的語法檢查與我們的Query自己的語法檢查還是有一定區(qū)別的，不能等同的。因此，碰到路徑中帶空格的情況，正確的寫法還是：

　　exec master..xp_cmdshell 'dir C:\"Program Files"\"Microsoft SQL Server"\MSSQL'

　　這同時(shí)說明SQL幫助文件中的綠色字體部分 command_string 不能包含一對(duì)以上的雙引號(hào) 的描述是不正確的，看來SQL Server幫助文件與產(chǎn)品也出現(xiàn)了“規(guī)格與程序不相符”的問題了，呵呵......

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

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

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

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

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

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

　　(2)處理過程中允許記錄日志，但要對(duì)日志文件進(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ù)庫(kù)的所有數(shù)據(jù)和日志文件，包含我們的需求，但也大于我們的需求，此方案可用，但不要著急，給人的感覺是買了一件能穿的衣服，但尺寸大了些，穿在身上有點(diǎn)不舒服，我們接著分析以下兩個(gè)方案...