最近一个数据库日志很大，想要进行截断日志的操作，查了相关资料，总结如下：

推荐的截断、收缩日志的方法：

1、BACKUP LOG with no_log 或TRUNCATE_ONLY，这两个参数的区别下面会再介绍。

2、DBCC SHRINKFILE (日志文件名)，收缩日志文件。

3、使用 BACKUP DATABASE 做数据库全备。

不推荐的方法：

1、分离数据库。

2、将日志文件改名或删除。

3、附加数据库，会提示找不到对应的日志文件，系统会重新生成一个初始化的日志文件。

－－－－－－－－－－

在SQL 2000下，只能手工进行截断日志操作，即备份日志时加no_log和truncate_only参数。截断日志会截断不活动日志，不减小物理日志文件的 大小，但逻辑日志会减小，收缩数据库后会把不活动虚拟日志删除来释放空间，不会损坏数据。 如果不收缩日志文件，那么新的日志文件可以使用不活动的虚拟日志删除后的空间，而不会导致日志文件无限增长。

手工截断事务日志，将断开日志备份链。在创建完整数据库备份前，将无法为数据库提供媒体故障保护。只有在非常特殊的环境中才使用手工日志截断，而且尽可能快地创建完整数据库备份。

数据库故障还原模型为“简单”的，在每次处理检查点时就会截断日志，所以可以大大减慢日志增长的速度。 如果把还原模型调到简单，这样就不支持时间点还原了，但是日志文件会很小，如果数据比较重要推荐还是把数据库的还原模型调为完全 。

所以在SQL2000下，平时维护控制日志文件作业步骤如下：

1、进行数据库全备（可省，主要是为了防止截断日志出错后的还原）

2、BACKUP LOG （可省，主要是为了备份全备的截断日志间隔时间的增量备份）

3、BACKUP LOG with no_log 或TRUNCATE_ONLY

4、DBCC SHRINKFILE (日志文件名)，收缩日志文件。

5、进行数据库全备

－－－－－－－－－－

在SQL2005下，使用 BACKUP LOG 时，系统会自动截断日志，不需要再手工进行了。所以在平时的维护中，只要定期执行BACKUP LOG语句，就可以保证日志文件不会无限制增长了。

－－－－－－－－－－

TRUNCATE_ONLY选项是用来节省事务日志文件中的空间 （通常是由于包含事务日志的文件或磁盘满了）。由于它把那些对于完全恢复来说很重要的日志中的信息删除了，所以在它的后面必须紧跟着一个完全数据库备份。 截断日志操作本身就是一个被记录的操作，并且在TRUNCATE_ONLY选项中，这些操作都会被记录在日志中。

NO_LOG选项和TRUNCATE_ONLY选项唯一的区别 是，NO_LOG选项截断日志的操作是不会记录到日志中的。由于SQL Server 2000　是个提前写入的关系数据库管理系统（RDBMS,Relational Database Management System），因此每个事务都要先写入事务日志。而BACKUP LOG本身也是个事务，因此也要先写入事务日志。在日志满了的情况下BACKUP LOG命令就会失败，因为它不能写入满了的日志，此时就应该选择NO_LOG选项，让SQL Server路过写入日志的操作，放弃日志的非活动部分以清理出一些空间。

－－－－－－－－－

还有一个截断日志的命令：

DUMP TRANSACTION 数据库名 WITH NO_LOG ，实际效果等同于BACKUP LOG WITH NO LOG，在微软SQL2005的帮助文档中说明如下：

为保持向后兼容性，可在 BACKUP 语句中使用 DUMP 关键字替代 BACKUP 关键字。另外，可以使用 TRANSACTION 关键字替代 LOG 关键字。SQL Server 数据库引擎 对 DUMP DATABASE 或 DUMP TRANSACTION 的解释分别与 BACKUP DATABASE 或 BACKUP LOG 相同。