接下来将新日志覆盖到旧日志的岗位上,在事情日志文件占尽可用磁盘空间且不能够再举一反三时

总结

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

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

注意:一般立成建立的数据库默认属性已设好,但碰到意外情况使数据库属性被更改,请用户清空日志后,检查数据库的以上属性,以防事务日志再次充满。 

第二步:更改数据库恢复模式,将模式从“完整”改为“简单”

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

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

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

  恢复数据库

–不过这种方式要小心,在恢复时只能恢复到最后一次完整备份

最近经历了一次服务器SQL SERVER
数据库服务器端事务日志爆满,导致服务器数据库写入不进数据的宕机事件,经过此次事件的发生,奉劝各位同仁一句,如果没有绝对的充足存储空间,数据库事务日志文件千万不要采取完整备份,备份出的数据量是你无法承受的,简单备份就可以了,以下是收缩数据库事务日志的操作,希望可以帮助到大家!

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

l  清空日志。

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

DUMP TRANSACTION 数据库名 WITH NO_LOG


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

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

n  删除LOG

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

n  删除LOG文件

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

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

建议使用第一种方法

  另一项优化措施与日志文件的体积有关。我们可以设置日志文件的体积不超过硬盘空间的百分之几,或者确定它的大小。如果将其设置的过大会浪费磁盘空间,而如果设置的过小则会强制记录文件不断尝试扩展,导致数据库性能下降。
  
  事务日志文件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”错误消息
  · 未复制的事务
  
  解决方法
  日志文件满而造成SQL数据库无法写入文件时,可用两种方法:
  一种方法:清空日志。
  1.打开查询分析器,输入命令
  DUMP TRANSACTION 数据库名 WITH NO_LOG
  2.再打开企业管理器–右键你要压缩的数据库–所有任务–收缩数据库–收缩文件–选择日志文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。
  
  另一种方法有一定的风险性,因为SQL
SERVER的日志文件不是即时写入数据库主文件的,如处理不当,会造成数据的损失。
  1: 删除LOG
  分离数据库 企业管理器->服务器->数据库->右键->分离数据库
  2:删除LOG文件
  附加数据库 企业管理器->服务器->数据库->右键->附加数据库
  此法生成新的LOG,大小只有500多K。
  
  注意:建议使用第一种方法。
  
  如果以后,不想要它变大。
  SQL2000下使用:
  在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
  或用SQL语句:
  alter database 数据库名 set recovery simple
  
  
  另外,如上图中数据库属性有两个选项,与事务日志的增长有关:
  Truncate log on checkpoint
  (此选项用于SQL7.0,SQL 2000中即故障恢复模型选择为简单模型)
  当执行CHECKPOINT 命令时如果事务日志文件超过其大小的70%
则将其内容清除在开发数据库时时常将此选项设置为True
  Auto shrink
 
 定期对数据库进行检查当数据库文件或日志文件的未用空间超过其大小的25%时,系统将会自动缩减文件使其未用空间等于25%
当文件大小没有超过其建立时的初始大小时不会缩减文件缩减后的文件也必须大于或等于其初始大小对事务日志文件的缩减只有在对其作备份时或将
Truncate log on checkpoint 选项设为True 时才能进行。
  
  
  注意:一般立成建立的数据库默认属性已设好,但碰到意外情况使数据库属性被更改,请用户清空日志后,检查数据库的以上属性,以防事务日志再次充满。

如果以后,不想要它变大。
SQL2000下使用:
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。
或用SQL语句:
alter database 数据库名 set recovery simple

第一步:右键数据库属性

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

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

相关文章

You can leave a response, or trackback from your own site.

Leave a Reply

网站地图xml地图