重做日志全部ACTIVE故障诊断处理

作者介绍:裴征峰,现就职于北京海天起点,专家组成员,南京办事处负责人,持有OCP 10g、OCP 11g、OCM 11g证书,主要从事客户的现场维护,重大问题的解决,数据库性能分析,服务质量保证等工作。拥有超过八年的Oracle服务经验,具备丰富的行业服务背景,对Oracle数据库有深刻的理解,在Oracle数据库RAC以及高可用解决方案方面具有深厚的实践经验,擅长数据库故障诊断,数据库性能调优。

分析过程和方法

系统环境

服务器型号
操作系统版本 AIX 6.1
Oracle 版本 Oracle Enterprise Edition 11.2.0.4 SI
数据文件存储 Veritas文件系统
归档存储方式 非归档
DB Name htdb
IP xxx.xxx.xxx.xxx

问题现象

运维人员发现htdb数据库的所有重做日志状态为ACTIVE,要求加大重做日志文件大小。当前重做日志大小每组为2g,共8组。

当前数据库因为业务特性,redo切换特别频繁,大约2分钟切换一个日志,日志切换信息如下:

当前重做日志状态如下:

分析过程

v$log.status说明

ACTIVE表明该重做日志组在数据库崩溃恢复时需要用到。该重做日志组可能已归档或未归档。数据库崩溃恢复时,首先需要根据DBWR检查点确定重做日志位置,读取后面的重做日志文件实现前滚,再根据UNDO实现回滚。

当前重做日志组全部为ACTIVE,那表明DBWR检查点已经落后太多了。

脏块

DBWR检查点落后太多,表明数据库中脏块数应该很多了,通过以下SQL检查脏块数:

当前数据库中的脏块数已达到104万。当前数据库版本是11.2.0.4,fast_start_mttr_target参数是0,表明是自动调整的。修改该参数为100:

到下午14:00,查看v$log发现8个redo组,只有1个是ACTIVE,1个CURRENT其它都是INACTIVE了。检查脏块数,下降到11万左右。

其它信息

在v$instance_recovery视图显示了检查点的相关信息

  • RECOVERY_ESTIMATED_IOS    db cache中的脏块数
  • TARGET_MTTR            数据库崩溃恢复的目标时间(单位秒)
  • ESTIMATED_MTTR        根据当前数据库负载计算的实际时间,只是个计算值。
  • WRITES_MTTR         由FAST_START_MTTR_TARGET参数驱动的写出次数
  • WRITES_OTHER_SETTINGS    由其它参数驱动的写出次数
  • CKPT_BLOCK_WRITES        由于检查点写出的Block的数量
  • WRITES_AUTOTUNE        指由于自动调整检查点执行的写出次数

建议

修改fast_start_mttr_target参数

 


未经允许不得转载:Oracle一体机用户组 » 重做日志全部ACTIVE故障诊断处理

相关推荐