R9账套数据库日志文件达13G，如何处理？
【问题描述】
两个业务量基本相同的账套，一个的事务日志为1024MB，另一个却高达13，888MB，这是为什么？能否限制事务日志的大小，如果能，应限制在什么范围？通过分离数据库删除事务日志是否有负面影响？为什么分离后生成的事务日志文件名总是多了＿LOG三个字母？如业务几乎相等的两个账套zw0005和zw0011，日志文件前者是后者10倍。
【排查过程】
检查两个账套的业务量，发现关于数据量几乎是相同的，那为何一个大，一个小呢？日志文件，可以通过企业管理器来限制，限制的比例一般为数据文件比日志文件为5:1。如图：

而当我们去限制其大小时，如图：

我们通常也可以通过分离来做，没有问题。
多了_LOG文件，那是逻辑文件名称，而我们的使用的是物理文件名称，两者是有区别的。如图：

我们这里看到的R93DB_Log，以及R93DB_Data都是我们的逻辑文件名，而在资源管理器中看到的，如下图所示，都是物理文件名。

【解决方法】
日志文件满而造成SQL数据库无法写入文件时，可用两种方法：
一种方法：清空日志。
1．打开查询分析器，输入命令
DUMP TRANSACTION 数据库名 WITH NO_LOG
2.再打开企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM，这里会给出一个允许收缩到的最小M数，直接输入这个数，确定就可以了。
另一种方法有一定的风险性，因为SQL SERVER的日志文件不是即时写入数据库主文件的，如处理不当，会造成数据的损失。
1：删除LOG
分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG文件
附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新的LOG，大小只有500多K。
注意：建议使用第一种方法。
如果以后,不想要它变大。
SQL2000下使用：
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用SQL语句：
alter database 数据库名 set recovery simple
【经验总结】

对交易日志的日常备份工作可以有效的防止日志文件过分消耗磁盘空间。备份过程会将日志中不再需要的部分截除。截除的方法是首先把旧记录标记为非活动状态，然后将新日志覆盖到旧日志的位置上，这样就可以防止交易日志的体积不断膨胀。如果无法对日志进行经常性的备份工作，最好将数据库设置为"简单恢复模式"。在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志覆盖旧日志。


截除过程发生在备份或将旧标记点标为非活动状态时，它使得旧的交易记录可以被覆盖，但这并不会减少交易日志实际占用的磁盘空间。就算不再使用日志，它依然会占据一定的空间。因此在维护时，还需要对交易日志进行压缩。压缩交易日志的方法是删除非活动记录，从而减少日志文件所占用的物理硬盘空间。


通过使用DBCC SHRINKDATABASE语句可以压缩当前数据库的交易日志文件，DBCC SHRINKFILE语句用来压缩指定的交易日志文件，另外也可以在数据库中激活自动压缩操作。当压缩日志时，首先会将旧记录标记为非活动状态，然后将带有非活动标记的记录彻底删除。根据所使用的压缩方式的不同，你可能不会立即看到结果。在理想情况下，压缩工作应该选在系统不是非常繁忙的时段进行，否则有可能影响数据库性能。

　　好资料，感谢楼主分享。。

　　好资料当然得支持了，谢谢。。

感谢

非常感谢，

为什么都要钱才可以下载呀？真是想不

成功就在眼前，继续努力学习！

先谢谢！再好好看看了

我怎么没有早点看到呀.我以前也是出现这个问题没有办法解决.

一般通过控制面板就可以处理了

不用那么麻烦吧
不是有数据库紧缩么
或者日志收缩工具的