如何维护SQLServer的“交易日志”

事务日志是数据库结构中非常重要但经常被忽略的部分。因为它不像数据库中的模式那样活跃，所以很少有人关注事务日志。

事务日志是数据库更改的记录。它可以记录对数据库的任何操作，并将记录结果保存在一个单独的文件中。对于每一个事务处理过程，事务日志都有非常全面的记录，根据记录可以将数据文件恢复到事务前的状态。从事务开始，事务日志就处于记录状态，事务过程中对数据库的任何操作都在记录范围内，直到用户点击提交或返回，记录才结束。每个数据库至少有一个事务日志和一个数据文件。

为了提高性能，SQL Server将用户的更改存储在缓存中，这些更改将立即写入事务日志，但不会立即写入数据文件。事务日志将确定事务是否通过标记点将缓存的数据写入数据文件。当SQL Server重新启动时，它将检查日志中的最新标记点，并擦除该标记点之后的事务记录，因为这些事务记录并没有真正将缓存的数据写入数据文件。这可以防止那些被中断的事务修改数据文件。

维护交易日志

因为很多人经常忘记交易日志，也会给系统带来一些问题。随着系统的不断运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终导致可用磁盘空的不足。除非在日常工作中经常清理日志，否则日志文件最终会占用分区中所有可用的空空间。日志的默认配置是无限容量。如果你在这种配置下工作，它会不断膨胀，最终占据所有可用的空空间。这两种情况都会导致数据库停止工作。

事务日志的日常备份可以有效防止日志文件过度消耗磁盘空。备份过程将截断日志中不必要的部分。截断的方法是首先将旧日志标记为不活动，然后将新日志覆盖到旧日志的位置，以防止事务日志的体积扩大。如果无法定期备份日志，请将数据库设置为“简单恢复模式”。在这种模式下，每次记录标记点时，系统将强制事务日志自动切断，并用新日志覆盖旧日志。

当旧的标记点被备份或被标记为非活动时，会发生截断，这会使旧的事务记录被覆盖，但不会减少事务日志实际占用的磁盘空。即使不再使用日志，它仍然会占用一定的空空间。因此，在维护期间，需要对事务日志进行压缩。压缩事务日志的方法是删除不活动的记录，从而减少日志文件占用的物理硬盘空。

可以使用DBCC SHRINKDATABASE语句压缩当前数据库的事务日志文件。DBCC SHRINKFILE语句用于压缩指定的事务日志文件，并且自动压缩操作也可以在数据库中激活。压缩日志时，首先会将旧记录标记为不活动，然后将带有不活动标记的记录完全删除。根据使用的压缩方法，您可能不会立即看到结果。理想情况下，压缩应该在系统不太忙的时候进行，否则可能会影响数据库性能。

还原数据库

事务记录备份可用于将数据库恢复到指定状态，但事务记录备份本身不足以完成恢复数据库的任务，需要备份的数据文件参与恢复工作。恢复数据库时，首先要做的是恢复数据文件。在还原之前，不要将整个数据文件设置为完成状态，否则事务日志将无法还原。数据文件恢复完成后，系统将通过备份事务日志将数据库恢复到用户所需的状态。如果在上次备份数据库后有多个日志文件备份，备份程序将根据它们建立的时间依次还原它们。

另一个称为日志传送的过程可以提供更强大的数据库备份功能。配置日志传送后，它可以将整个数据库复制到另一台服务器上。在这种情况下，事务日志还会定期发送到备份服务器进行数据恢复。这使得服务器始终处于热备份状态，当数据发生变化时，也会进行更新。另一台服务器称为监控服务器，可用于监控以指定时间间隔发送的运输信号。如果在指定时间内未收到信号，监控服务器将在事件日志中记录此事件。这种机制使得日志传送经常用于灾难恢复计划中。