SQL 2005 日志文件增长过快，如何处理
服务器现在的情况是这样的，数据是从SQL2000转过来的，原来的日志增长没这么打的
我把恢复模式设置为简单了，还做了一个发布订阅快照。
现在数据只有10G 但是日志增量每天9G这样，周末3天 今天早上一看日志已经27G了 ，周四的时候清零过一次
想问一下 是什么原因引起的，快照发布这个以前也有 但是没有这么快的增长啊。郁闷死了
------解决方案--------------------
1.3.2 日志文件增长的原因
前面已经谈到，SQL Server 会为所有的修改记录日志，以便将来重新提交或者回滚时使用。那不
停地记录，日志文件岂不会空间耗尽？为此，SQL Server 设计了相对应的机制，能够定期清理日志文
件中不再需要的日志记录。
那哪些日志记录是“不再需要”的呢？我们反过来看，什么是SQL Server“需要”的。SQL Server
需要下面这几类日志记录：
1. 所有没有经过“检查点”的日志记录。
SQL Server 定期做检查点（Checkpoint），保证所有的“脏页”都被写入硬盘。未做检查点的修改，
可能仅是内存中的修改。数据文件里还没有同步。SQL Server 要硬盘上的日志文件里有一份记录，以
便在异常重启后重新修改。
2. 所有没有提交的事务所产生的日志记录，以及在它们之后的所有日志记录。
如果一个事务还没有提交，那它可以在任何时候回滚。SQL Server 必须做好这种准备，以便能够
从日志记录中找回修改前的数据内容，完成回滚。在SQL Server 里面，所有的日志记录都有严格顺序，
中间不可以有任何跳跃。所以如果某个数据库有没有提交的事务，SQL Server 会标记所有从这个事务
开始的日志记录（不管和这个事务有没有关系）为活动事务日志。这些日志记录都有可能“需要”被
用来做回滚。
3. 所有要做备份的日志记录。
如果数据库设的恢复模式不是简单模式，那 SQL Server 就假设用户是要去备份日志记录的。所有
未被备份的记录，SQL Server 都会为用户保留，哪怕这些记录对数据库本身已经没有其他用途了。
4. 有其他需要读取日志的数据库功能模块。
除了数据库引擎，还有一些功能，比如说，事务型复制（Transactional Replication）和数据库镜像
（Database Mirroring）也需要读取日志文件中的内容，完成它们的同步工作。在这些功能组件没有读取
Microsoft SQL Server 企业级平台管理实践
34 第1章 数据库空间管理
日志记录之前，SQL Server 也会保留。
对所有“不需要”的日志记录，SQL Server 会在每个检查点做一次截断的动作，把这些记录占
用的空间标志成可重用。这样这些空间就被释放出来。因为日志文件是循环使用的，只要日志文件
里有这样的空间，SQL Server 都会去重用，所以不会报告空间已满，或者试图去做自动增长。SQL Server
做检查点的频率取决于服务器属性“Recovery Interval”。默认大概一分钟左右做一次检查点。
如果日志文件里“需要”的记录越来越多，那就会出现日志文件不停增长的现象。通常的原因有
下面几个。
1. 数据库恢复模式不是简单模式，但是没有安排日志备份。
需要强调的是，对于非简单模式的数据库，只有做完日志备份后记录才会被截断。做完整备份和
差异备份都不会起这个作用。
2. 数据库上面有一个很长时间都没有提交的事务。
由于应用程序设计的问题，有些连接可能会遗留一个事务在 SQL Server 里面，而不是及时提交了
它。SQL Server 是不会干预用户的这种行为的。只要这个连接不退出，这个事务就会永远存在，直到
客户端主动提交或者回滚它。而从这个事务开启的那个时间点开始的所有日志记录，SQL Server 都会
保留。（做过日志备份也没有用。）
3. 数据库上有一个很大的事务正在运行。
例如，某个用户正在建立/重建索引，或者用 DELETE/INSERT 语句删除或插入大量数据等。或者
用户端开了一个服务器端游标，但是没有把数据及时取走等。
4. 数据库复制或者镜像出了异常。
要避免日志文件不停增长，其实就是要避免上面这些情况的发生。对于一个最近不会去做日志备份
的数据库，设成简单恢复模式即可。如果数据库设成了完整恢复模式，那就一定要安排定期做日志备份。
如复制或镜像任务出问题，要及时解决。如果没办法解决，就必须暂时拆除复制或镜像，以防止日志记
录越积越多，最终造成数据库不可使用。在设计程序的时候，也要避免事务时间过长，一个事务做太多
的操作。数据库晚上或周末会做一些维护工作，例如历史数据清洗整理，数据导入导出，索引重建等。
这些操作都可能写许多日志，所以要为它们预留出足够的空间，并且在做完之后及时备份。