MSSQL Server的事务日志简介一览

　　(Transaction logs)是数据库 构造中十分主要但又 时常被 忽略的 部分 。由于它并不像数据库中的schema那样活跃， 因此很少有人关注交易日志 。
　　交易日志是针对数据库转变所做的记录，它 可以记录针对数据库的任何操作，并将记录 后果 保留在独立的文件中 。关于任何每一个交易过程，交易日志都有十分全面的记录，依据这些记录 可以将数据文件 复原成交易前的状态 。从交易动作开始，交易日志就处于记录状态，交易过程中对数据库的任何操作都在记录 规模，直到消费者点击提交或后退后才 完毕记录 。每个数据库都 占有至少一个交易日志以及一个数据文件 。

　　出于性能上的考量，SQL Server将消费者的 改变存入缓存中，这些转变会马上写入交易日志，但不会马上写入数据文件 。交易日志会通过一个标记点来确定某个交易是不是已将缓存中的数据写入数据文件 。当SQL Server重启后，它会查看日志中最新的标记点，并将这个标记点后面的交易记录抹去，由于这些交易记录并没有真正的将缓存中的数据写入数据文件 。这 可以 预防那些中断的交易 批改数据文件 。

　　 保护交易日志

　　由于众多人 时常 忘记交易日志， 因此它也会给系统带来一些问题 。随着系统的不停运行，日志记录的内容会越来越多，日志文件的体积也会越来越大，最终招致可用磁盘空间缺乏 。除非日常工作中 时常对日志进行清理，不然日志文件最终会 强占分区内的所有可用空间 。日志的默许配置为不限容量，假如以这种配置工作，它就会不停膨胀，最终也会占领所有可用空间 。这两种状况都会招致数据库 停留工作 。

　　对交易日志的日常备份工作 可以有效的 预防日志文件过分 消费磁盘空间 。备份过程会将日志中不再需求的 部分截除 。截除的 步骤是首先把旧记录标记为非 运动状态， 而后将新日志 遮蔽到旧日志的位置上，这样就 可以 预防交易日志的体积不停膨胀 。假如 无奈对日志进行 时常性的备份工作，最好将数据库设置为" 方便 复原模式" 。在这种模式下，系统会强制交易日志在每次记录标记点时，自动进行截除操作，以新日志 遮蔽旧日志 。

　　截除过程 产生在备份或将旧标记点标为非 运动状态时，它使得旧的交易记录 可以被 遮蔽，但这并不会削减交易日志实际占用的磁盘空间 。就算不再 使用日志，它依旧会占领 定然的空间 。 因此在 保护时，还需求对交易日志进行压缩 。压缩交易日志的 步骤是删除非 运动记录，从而削减日志文件所占用的物理硬盘空间 。

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

　　 复原数据库

　　交易记录备份 可以用来将数据库 复原到某一指定状态，但交易记录备份 本身缺乏以 实现 复原数据库的 使命，还需求备份的数据文件 参加 复原工作 。 复原数据库时，首先进行的是数据文件的 复原工作 。在整个数据文件 复原 实现前，不要将其设为 实现状态，不然交易日志就不会被 复原 。当数据文件 复原 实现，系统会通过交易日志的备份将数据库 复原成消费者 盼望的状态 。假如在数据库最终一次备份后，存在多个日志文件的备份，备份程序会依照它们 构建的 工夫 顺次将其 复原 。

　　另一种被称为log shipping的过程 可以提供更强的数据库备份 威力 。当log shipping配置好后，它 可以将数据库整个复制到另一台服务器上 。在这种状况下，交易日志也会定期发送到备份服务器上供 复原数据 使用 。这使得服务器向来处于热备份状态，当数据 产生转变时它也随之更新 。另一个服务器被称作 监督(monitor)服务器， 可以用来 监督按规定 工夫 间隔发送的shipping信号 。假如在规定 工夫内没有收到信号， 监督服务器会将这一事件记录到事件日志 。这种机制使得log shipping 时常成为 苦难 复原 方案中 使用的 方案 。

　　性能优化

　　交易日志对数据库有主要作用，同时它对系统的整体性能也有 定然影响 。通过几个选项，我们 可以对交易日志的性能进行优化 。由于交易日志是一个延续的磁盘写入过程，在这当中不会 产生读取动作 。 因此将日志文件放在一个独立的磁盘，对优化性能有 定然作用 。

　　另一项优化措施与日志文件的体积有关 。我们 可以设置日志文件的体积不超过硬盘空间的百分之几，或者确定它的大小 。假如将其设置的过大会 浪费磁盘空间，而假如设置的过小则会强制记录文件不停尝试 扩大，招致数据库性能 降落 。

　　事务日志文件Transaction Log File是用来记录数据库更新状况的文件， 扩大名为ldf 。

　　在 SQL Server 7.0 和 SQL Server 2000 中，假如设置了自动增进 性能，事务日志文件将会自动 扩大 。

　　普通状况下，在 可以 包容两次事务日志截断中间 产生的最大数量的事务时，事务日志的大小是 巩固的，事务日志截断由 审查点或者事务日志备份触发 。

　　但是，在某些状况下，事务日志可能会变得十分大， 以致用尽空偶尔变满 。通常，在事务日志文件占尽可用磁盘空间且不能再 扩大时，您将收到如下 舛误 信息：

　　Error:9002, Severity:17, State:2

　　The log file for database ’%.*ls’ is full.

　　除了浮现此 舛误 信息之外，SQL Server 还可能由于 缺乏事务日志 扩大空间而将数据库标记为 SUSPECT 。有关如何从此 情景中 复原的 其余信息，请参见 SQL Server 联机协助中的“磁盘空间缺乏”主题 。
另外，事务日志 扩大可能招致下列 情景：

　　· 十分大的事务日志文件 。

　　· 事务可能会失败并可能开始回滚 。

　　· 事务可能会用很长期 威力 实现 。

　　· 可能 产生性能问题 。

　　· 可能 产生堵塞 景象 。

　　缘由

　　事务日志 扩大可能由于以下缘由或 情景而 产生：

　　· 未提交的事务

　　· 十分大的事务

　　· 操作：DBCC DBREINDEX 和 CREATE INDEX

　　· 在从事务日志备份还原时

　　· 客户端 利用程序不 解决所有 后果

　　· 查问在事务日志 实现 扩大之前超时，您收到假的“Log Full” 舛误 信息

　　· 未复制的事务