以新日志覆盖旧日志,交易过程中对数据库的任何操作都在记录范围

交易日志会通过一个标记点来确定某个交易是否已将缓存中的数据写入数据文件,交易过程中对数据库的任何操作都在记录范围,交易过程中对数据库的任何操作都在记录范,每个数据库都拥有至少一个交易日志以及一个数据文件,以新日志覆盖旧日志,然后将新日志覆盖到旧日志的位置上

核心提示:是数据库结构中非常重要但又经常被忽略的部分

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

事务日志扩展可能由于以下原因或情形而发生:  · 未提交的事务   · 非常大的事务   · 操作:DBCC DBREINDEX 和 CREATE INDEX   · 在从事务日志备份还原时   · 客户端应用程序不处理所有结果   · 查询在事务日志完成扩展之前超时,您收到假的“Log Full”错误消息   · 未复制的事务

是数据库结构中非常重要但又经常被忽略的部分。由于它并不像数据库中的schema那样活跃,因此很少有人关注交易日志。
交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中。对于任何每一个交易过程,交易日志都有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范围,直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。

  交易日志是针对数据库改变所做的记录,它可以记录针对数据库的任何操作,并将记录结果保存在独立的文件中。对于任何每一个交易过程,交易日志都
有非常全面的记录,根据这些记录可以将数据文件恢复成交易前的状态。从交易动作开始,交易日志就处于记录状态,交易过程中对数据库的任何操作都在记录范
围,直到用户点击提交或后退后才结束记录。每个数据库都拥有至少一个交易日志以及一个数据文件。
  出于性能上的考虑,SQL
Server将用户的改动存入缓存中,这些改变会立即写入交易日志,但不会立即写入数据文件。交易日志会通过一个标记点来确定某个交易是否已将缓存中的数
据写入数据文件。当SQL
Server重启后,它会查看日志中最新的标记点,并将这个标记点后面的交易记录抹去,因为这些交易记录并没有真正的将缓存中的数据写入数据文件。这可以
防止那些中断的交易修改数据文件。
  

事务日志扩展可能导致下列情形:   · 非常大的事务日志文件。   · 事务可能会失败并可能开始回滚。   · 事务可能会用很长时间才能完成。   · 可能发生性能问题。   · 可能发生阻塞现象。

从上面可以看出,日志会出现比较大的增长问题主要还是在于程序的事务处理上。

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

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

  维护交易日志

日志文件满而造成SQL数据库无法写入文件时,处理的方法:

l  清空日志。

n  打开查询分析器,输入命令

DUMP TRANSACTION 数据库名 WITH NO_LOG


再打开企业管理器–右键你要压缩的数据库–所有任务–收缩数据库–收缩文件–选择日志文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。

l  该方法有一定的风险性,因为SQL
SERVER的日志文件不是即时写入数据库主文件的,如处理不当,会造成数据的损失。

n  删除LOG

分离数据库企业管理器->服务器->数据库->右键->分离数据库

n  删除LOG文件

附加数据库企业管理器->服务器->数据库->右键->附加数据库

此法生成新的LOG,大小只有500多K。

建议使用第一种方法

维护交易日志

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

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

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

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

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

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

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

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

  恢复数据库

恢复数据库

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

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

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

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

  性能优化

性能优化

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