近期在做“数据库切割工具”时，碰到了一些棘手的问题，经过多方打探、查找，最终得以解决，现总结下来，给大家共享，免的大家以后在碰到类似问题时再耗费大量时间去查找、去打探!

　　1、判断输入的路径在服务器上是否存在：

　　例如，要在客户端执行一个创建数据库的程序，数据库要在服务器上创建，但路径可以手工输入，这时就面临一个判断自已现在输入的路径在服务器上是否存在的问题，免得在执行Create Database SQL时才报错：找不到路径。

　　具体方法如下：

　　exec master..xp_cmdshell 'dir E:\DATA' ，在查询分析器中执行此段SQL，如果存在此路径，会输出此路径下的所有文件与文件夹信息，还有此盘的可用字节数与已此文件夹的字节数(图1所示);如果此路径不存在，则输出信息如图2所示，提示“找不到文件”。

　　但是，当路径中含有空格时，如C:\Program Files，直接用exec master..xp_cmdshell 'dir C:\Program Files'，系统返回结果会如跟图2显示一样，我们需要做额外处理，才能得到正确的返回结果：

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

　　这种写法，在查询分析器中直接执行是没有问题的，也能返回正确结果，但如果放到程序中执行：

　　SQL.Add('exec master..xp_cmdshell ''dir "C:\Program Files\Microsoft SQL Server\MSSQL"'')，Open时就会报错，不能执行。

　　为什么呢???

　　(2)我们接下来查看SQL联机帮助，对XP_CMDSHELL的描述如下：

　　xp_cmdshell {'command_string'} [, no_output]

　　参数

　　'command_string'

　　是在操作系统命令行解释器上执行的命令字符串。command_string 的数据类型为 varchar(255) 或 nvarchar(4000)，没有默认值。command_string 不能包含一对以 上的双引号。如果由 command_string 引用的文件路径或程序名称中有空格，则需要使用一对引号。如果使用嵌入空格不方便，可考虑使用 FAT 8.3 文件名作为解决办 法。

　　no_output

　　是可选参数，表示执行给定的 command_string，但不向客户端返回任何输出。

　　帮助文件提示我们要用一对引号将文件路径或者程序名称包起来，将整个路径包不起来不会报错，那我就将带有空格的单步路径包起来试试，看看行不行，执行 如下SQL：SQL.Add('exec master..xp_cmdshell ''dir C:\"Program Files"\"Microsoft SQL Server"\MSSQL'')，这样Open时果然不报错了，看来查询分析器的语法检查与我们的Query自己的语法检查还是有一定区别的，不能等同的。因此，碰到路径中带空格的情况，正确的写法还是：

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

　　这同时说明SQL帮助文件中的绿色字体部分 command_string 不能包含一对以上的双引号 的描述是不正确的，看来SQL Server帮助文件与产品也出现了“规格与程序不相符”的问题了，呵呵......

　　2、清空数据库的日志文件

　　问题的引出：我们的切割过程就是将单据数据中某个日期以前的数据先复制到新的数据库中(select ... into ...)，然后再将原来数据库中的这些数据删除,这样操作在数量量很大的数据库上时，其日志文件的增长也是惊人的：我复制一个48万条记录的表时，最后发现仅这一个表的操作就使新数据库的日志文件增加了170MB，如果不加清理，那就会被日志文件占用大量宝贵的磁盘空间。况且，我们转移到的新建数据库的作用也只是用来查询，以后不会有任何Insert、Update、Delete操作的，要这些日志文件没有什么用处，因此必须在向它转移数据的过程中做一些缩小日志文件的处理，怎么办??问题由此而生...

　　(1)处理过程中不记录日志

　　设置方法如下：企业管理器中打开对应数据库的“属性”，页框“选项”中将“模型”改为“简单”。这样设置的结果是对此数据库的任何操作都将不记录事务日志。对应的SQL为：EXEC sp_dboption @pdbName, 'trunc. log on chkpt.', 'TRUE'

　　但是，我们经过测试发现：启用此功能后，我们在对这个数据库操作时，就不能用事务操作了，程序执行到BeginTranSaction时就报错，不能执行下去，由于我们不能在对此库的操作中保证100%的正确性，因此我们还需要事务，因此这种方法适用空间有限，也不能满足我们程序的需求。

　　我们还得继续查找.....

　　(2)处理过程中允许记录日志，但要对日志文件进行处理，时时缩小它。

　　SQL Server的联机帮助告诉我们：

　　在下列情况下，日志文件的物理大小将减少：

　　执行 DBCC SHRINKDATABASE 语句时。

　　执行引用日志文件的 DBCC SHRINKFILE 语句时。

　　自动收缩操作发生时。

　　下面我们逐个分析这三个方案：

　　① DBCC SHRINKDATABASE：收缩特定数据库的所有数据和日志文件，包含我们的需求，但也大于我们的需求，此方案可用，但不要着急，给人的感觉是买了一件能穿的衣服，但尺寸大了些，穿在身上有点不舒服，我们接着分析以下两个方案...

　　② DBCC SHRINKFILE: 收缩相关数据库的指定数据文件或日志文件大小。与方案1的区别仅一字之差：“和”与“或”，相当于把方案1拆成两步来执行，我们需要的就是收缩日志文件，因此，它对我们来说显得比较合适，有点量体裁衣的感觉。但还有没有更好的呢，我们来看第三个方案...

　　③自动收缩：数据库也可设置为按给定的时间间隔自动收缩，服务器定期检查每个数据库中的空间使用情况。如果发现数据库中有大量闲置空间，而且它的 autoshrink 选项设置为 true，SQL Server 就缩小该数据库中的文件大小。它是周期性的执行DBCC SHRINKDATABASE，既然方案1已经是一件尺寸大了一些的衣服，则此方案就相当于又穿上了N件大尺寸衣服，一件就已经够了，我还要那么多干嘛呢??

　　综合对比发现，方案2正是我们需要的。

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

　　经过这个语句处理以后，日志文件将回到它的最小状态504KB，任何的日志记录都将清空。

　　再结合我们的工具，复制完一个表之后，我们就执行方案2，处理过程中日志文件暂时占用的最大空间也就是处理最大数据表时产生的日志空间，但最后都将清空，显示为500多KB，相对于庞大的数据文件而言，微之戡微.