维护SQL Server的交易日志经验总结

交易日志（Transaction logs）是数据库结构中很重要但又经常被忽略的部分。由于他并不像数据库中的schema那样活跃，因此很少有人关注交易日志。

交易日志是针对数据库改变所做的记录，他能够记录针对数据库的任何操作，并将记录结果保存在单独的文档中。对于任何每一个交易过程，交易日志都有很全面的记录，根据这些记录能够将数据文档恢复成交易前的状态。从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录范围，直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志连同一个数据文档。

出于性能上的考虑，SQL Server将用户的改变存入缓存中，这些改变会立即写入交易日志，但不会立即写入数据文档。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文档。当SQL Server重启后，他会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，因为这些交易记录并没有真正的将缓存中的数据写入数据文档。这能够防止那些中断的交易修改数据文档。

维护交易日志

因为很多人经常遗忘交易日志，因此他也会给系统带来一些问题。随着系统的不断运行，日志记录的内容会越来越多，日志文档的体积也会越来越大，最终导致可用磁盘空间不足。除非日常工作中经常对日志进行清理，否则日志文档最终会侵占分区内的全部可用空间。日志的默认配置为不限容量，假如以这种配置工作，他就会不断膨胀，最终也会占据全部可用空间。这两种情况都会导致数据库停止工作。

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

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

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

恢复数据库

交易记录备份能够用来将数据库恢复到某一指定状态，但交易记录备份本身不足以完成恢复数据库的任务，还需要备份的数据文档参和恢复工作。恢复数据库时，首先进行的是数据文档的恢复工作。在整个数据文档恢复完成前，不要将其设为完成状态，否则交易日志就不会被恢复。当数据文档恢复完成，系统会通过交易日志的备份将数据库恢复成用户希望的状态。假如在数据库最后一次备份后，存在多个日志文档的备份，备份程式会按照他们建立的时间依次将其恢复。

另一种被称为log shipping的过程能够提供更强的数据库备份能力。当log shipping配置好后，他能够将数据库整个复制到另一台服务器上。在这种情况下，交易日志也会定期发送到备份服务器上供恢复数据使用。这使得服务器一直处于热备份状态，当数据发生改变时他也随之更新。另一个服务器被称作监控（monitor）服务器，能够用来监控按规定时间间隔发送的shipping信号。假如在规定时间内没有收到信号，监控服务器会将这一事件记录到事件日志。这种机制使得log shipping经常成为灾难恢复计划中使用的方案。