经验技巧：分享两条Delphi开发经验[2]

清空数据库的日志文件

问题的引出我们的切割过程就是将单据数据中某个日期以前的数据先复制到新的数据库中(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相对于庞大的数据文件而言微之戡微

[] []