部分
由于它并不像数据库中schema那样活跃
因此很少有人关注交易日志交易日志是针对数据库改变所做
记录它可以记录针对数据库任何操作并将记录结果保存在独立文件中对于任何每
个交易过程交易日志都有非常全面记录根据这些记录可以将数据文件恢复成交易前状态从交易动作开始交易日志就处于记录状态交易过程中对数据库任何操作都在记录范围直到用户点击提交或后退后才结束记录每个数据库都拥有至少个交易日志以及个数据文件 出于性能上
考虑SQL Server将用户改动存入缓存Cache中这些改变会立即写入交易日志但不会立即写入数据文件交易日志会通过个标记点来确定某个交易是否已将缓存Cache中数据写入数据文件当SQL Server重启后它会查看日志中最新标记点并将这个标记点后面交易记录抹去
这些交易记录并没有真正将缓存Cache中数据写入数据文件这可以防止那些中断交易修改数据文件维护交易日志
很多人经常遗忘交易日志因此它也会给系统带来些问题随着系统不断运行日志记录内容会越来越多日志文件体积也会越来越大最终导致可用磁盘空间不足除非日常工作中经常对日志进行清理否则日志文件最终会侵占分区内全部可用空间日志默认配置为不限容量如果以这种配置工作它就会不断膨胀最终也会占据全部可用空间这两种情况都会导致数据库停止工作 对交易日志
日常备份工作可以有效防止日志文件过分消耗磁盘空间备份过程会将日志中不再需要部分截除截除思路方法是首先把旧记录标记为非活动状态然后将新日志覆盖到旧日志位置上这样就可以防止交易日志体积不断膨胀如果无法对日志进行经常性备份工作最好将数据库设置为"简单恢复模式"在这种模式下系统会强制交易日志在每次记录标记点时自动进行截除操作以新日志覆盖旧日志 截除过程发生在备份或将旧标记点标为非活动状态时
它使得旧交易记录可以被覆盖但这并不会减少交易日志实际占用磁盘空间就算不再使用日志它依然会占据定空间因此在维护时还需要对交易日志进行压缩压缩交易日志思路方法是删除非活动记录从而减少日志文件所占用物理硬盘空间 通过使用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”消息 · 未复制
事务解决思路方法
日志文件满而造成SQL数据库无法写入文件时
可用两种思路方法:种思路方法:清空日志1．打开查询分析器
输入命令DUMP TRANSACTION 数据库名 WITH NO_LOG
2.再打开企业管理器--右键你要压缩
数据库--所有任务--收缩数据库--收缩文件--选择日志文件--在收缩方式里选择收缩至XXM,这里会给出个允许收缩到最小M数,直接输入这个数,确定就可以了另
种思路方法有定风险性SQL SERVER日志文件不是即时写入数据库主文件如处理不当会造成数据损失1: 删除LOG
分离数据库 企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2:删除LOG文件
附加数据库 企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法生成新
LOG大小只有500多K注意:建议使用第
种思路方法如果以后,不想要它变大
SQL2000下使用:
在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型
或用SQL语句:
alter database 数据库名
recovery simple另外
如上图中数据库属性有两个选项和事务日志增长有关:Truncate log on checkpo
(此选项用于SQL7.0
SQL 2000中即故障恢复模型选择为简单模型)当执行CHECKPOINT 命令时如果事务日志文件超过其大小
70% 则将其内容清除在开发数据库时时常将此选项设置为TrueAuto shrink
定期对数据库进行检查当数据库文件或日志文件
未用空间超过其大小25%时系统将会自动缩减文件使其未用空间等于25% 当文件大小没有超过其建立时
大小时不会缩减文件缩减后文件也必须大于或等于其大小对事务日志文件缩减只有在对其作备份时或将Truncate log on checkpo 选项设为True 时才能进行注意:
般立成建立数据库默认属性已设好但碰到意外情况使数据库属性被更改请用户清空日志后检查数据库以上属性以防事务日志再次充满
最新评论