redo log大量生成的诊断处理流程

标签: redo log 诊断 | 发表时间:2014-11-19 01:18 | 作者:msdnchina
出处:http://blog.csdn.net
redo log大量生成的诊断处理流程

本文是原创文章,转载请注明出处:

http://write.blog.csdn.net/postedit/41249705

1.获得归档日志暴增时段的一个归档日志:可以查询v$archived_log视图,结合completion_time列进行定位
2.对该归档日志进行转储dump

  ALTER SYSTEM DUMP LOGFILE '/u01/oracle/V7323/dbs/arch1_76.dbf'; 
   --请将路径修改成当时的redo归档的路径

  以上命令会在user_dump_dest中生成一个trace文件,请将该trace文件传到linux中(root用户or oracle用户均可)

3.
[root@hosta ~]# grep -A2 "^REDO RECORD" his_ora_29032886_dump_arch.trc > redo.log 
4.
[root@hosta ~]# grep OBJ: redo.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r
2038012 4294967295  <----出现了2038012次。
    107 60635
     60 60464
     30 59848
     29 62992
     29 60669
      9 59810
      8 60706
      8 59842
OBJ:4294967295,这个是undo的redo记录,出现了2038012次,也就是说:产生redo最多的为undo操作
[root@hosta ~]# grep OBJ: redo.log |awk -F "OBJ:" '{print $2}' | more
4294967295 SCN:0x0001.96090e1b SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e1e SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e1f SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e20 SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e21 SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e22 SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e23 SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e24 SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e25 SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e26 SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e27 SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e28 SEQ:  1 OP:5.4
4294967295 SCN:0x0001.96090e29 SEQ:  1 OP:5.2
4294967295 SCN:0x0001.96090e29 SEQ:  2 OP:5.4

注意上面的最后一列:op,这是操作的标志码

OP:5.2 Undo Header
OP:5.4 Commit

5.
[root@hosta ~]# grep -A2 "^CHANGE #" his_ora_29032886_dump_arch.trc > redo_c.log 
6.
[root@hosta ~]# grep OBJ: redo_c.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r
   ---这是对object_id按照出现的次数进行倒序排列,举例:
[root@hosta ~]# grep OBJ: redo_c.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r
3057384 4294967295
1018128 15
    279 60669
    174 60635
这是说明:OBJ:4294967295 出现了3057384次;
          OBJ:15 出现了1018128次。
OBJ:4294967295,这个是undo的redo记录.
OBJ:15,可以用如下的语句查询出来:select object_name from dba_objects where object_id='15';
以上就可以定位到是哪个object_name 导致的redo log暴增。

下面来确认一下,是何种操作导致的redo log暴增:
[root@hosta ~]# grep OBJ: redo_c.log | more
CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1b SEQ:  1 OP:5.2
CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e1a SEQ:  1 OP:5.1
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e1b SEQ:  1 OP:11.5
CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1e SEQ:  1 OP:5.4
CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e1f SEQ:  1 OP:5.2
CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e1e SEQ:  1 OP:5.1
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e1f SEQ:  1 OP:11.5
CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e20 SEQ:  1 OP:5.4
CHANGE #1 TYP:0 CLS:15 AFN:1 DBA:0x00400009 OBJ:4294967295 SCN:0x0001.96090e21 SEQ:  1 OP:5.2
CHANGE #2 TYP:0 CLS:16 AFN:1 DBA:0x0040000a OBJ:4294967295 SCN:0x0001.96090e20 SEQ:  1 OP:5.1
CHANGE #3 TYP:2 CLS: 1 AFN:1 DBA:0x0040006a OBJ:15 SCN:0x0001.96090e21 SEQ:  1 OP:11.5

注意上面的最后一列:op,这是操作的标志码

OP:5.1 Undo Recorder
OP:5.2 Undo Header
OP:5.4 Commit
OP:11.5 Update Row Piece,也就是update操作,根据obj:15,就能确认是哪个对象上的update


参考文章:
http://www.traveldba.com/archives/479
http://blog.csdn.net/duanbeibei/article/details/6091507
作者:msdnchina 发表于2014-11-18 17:18:03 原文链接
阅读:3 评论:0 查看评论

相关 [redo log 诊断] 推荐:

redo log大量生成的诊断处理流程

- - CSDN博客推荐文章
redo log大量生成的诊断处理流程. 本文是原创文章,转载请注明出处:. 1.获得归档日志暴增时段的一个归档日志:可以查询v$archived_log视图,结合completion_time列进行定位. 2.对该归档日志进行转储dump.    --请将路径修改成当时的redo归档的路径.   以上命令会在user_dump_dest中生成一个trace文件,请将该trace文件传到linux中(root用户or oracle用户均可).

Oracle online redo log 扫盲

- - CSDN博客数据库推荐文章
Oracle 的日志分为:ONLINE REDO LOG 和 archived log. 一个数据库至少要有2组 redo log,每组 redo log 至少要有一个 member(出于安全考虑,建议每组 redo log 至少有 2 个多元化的 redo log member). redo log 循环使用,当一组日志写满后,就会切换到下一组日志.

必须了解的MySQL三大日志:binlog、redo log和undo log

- - DockOne.io
日志是 MySQL数据库的重要组成部分,记录着数据库运行期间各种状态信息. MySQL日志主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类. 作为开发,我们重点需要关注的是二进制日志( binlog)和事务日志(包括 redo log和 undo log),本文接下来会详细介绍这三种日志.

REDO管理

- - CSDN博客数据库推荐文章
一、什么是REDO LOG.  REDOLOG文件是十分重要的文件,它记录了Oracle的所有变化,是数据库实例恢复机制中最为关键的组成部分.     GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME     NEXT_CHANGE# NEXT_TIME.

Log调试

- - ITeye博客
在开发中我们一定不能避免使用Log类,但是这个类存在一个问题就是,当你在程序中使用了大量的Log,那么在程序开发完毕的时候,这将是一个问题,因为,你需要将所有的Log记录注释掉(当然,你不注释也是可以的). 我们可以写一个类,将Log类包装起来,使用一个boolean来控制所有的Log记录的显示. public static final boolean isDebug = true;//这里控制所有Log的显示情况.

log file sync总结

- - 数据库 - ITeye博客
log file sync等待时间发生在redo log从log buffer写入到log file期间. 下面对log file sync做个详细的解释. 1.commit或者rollback. 3.log buffer 1/3满或者已经有1M的redo数据.       更精确的解释:_LOG_IO_SIZE 大小默认是LOG_BUFFER的1/3,当log buffer中redo数据达到_LOG_IO_SIZE 大小时,发生日志写入.

Redo write触发的四种情况

- - CSDN博客推荐文章
1、当LGWR空闲的时候,会每隔3秒检查一次是否有从redo buffer写入redelog中的数据,如果有,一个后台进程就会自动的执行将其写入. 2、当有进程要从redo buffer中分配空间时,会先计算redo buffer中已经占用的空间,如果该空间大于_log_io_size这个参数值,并且此时的LGWR处于空闲状态,便会被激活执行后台写.

静态cache之log共现词分析

- - 搜索技术博客-淘宝
搜索引擎的log数据可以用于query理解、user理解、doc理解和ranking. 我们运行共现词分析,挖掘出引擎的query log里面共现的词,离线建静态cache,用于提升引擎的性能. 分析query log里query的平均的term数,值为5. 我们对query log依次进行一至四元共现词分析,高于四元的我们推荐用fullcache解决,而且高元的离线计算成本也太高.

[转]用mysqldumpslow分析mysql的slow query log

- - 小彰
mysql有一个功能就是可以log下来运行的比较慢的sql语句,默认是没有这个log的,为了开启这个功能,要修改my.cnf或者在mysql启动的时候加入一些参数. 如果在my.cnf里面修改,需增加如下几行. long_query_time 是指执行超过多久的sql会被log下来,这里是1秒. log-slow-queries 设置把日志写在那里,可以为空,系统会给一个缺省的文件 host_name-slow.log,我生成的log就在mysql的data目录.

log file sync等待超高一例

- - CSDN博客数据库推荐文章
这是3月份某客户的情况,原因是服务器硬件故障后进行更换之后,业务翻译偶尔出现提交缓慢的情况. 我们可以看到,该系统的load profile信息其实并不高,每秒才21个transaction. 先来看看top5events:. 从top 5event,我们可以发现,log file sync的avg wait非常之高,高达124ms.