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，任何的日志记录都将

清空。