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.

[[email protected] ~]# grep -A2 "^REDO RECORD" his_ora_29032886_dump_arch.trc > redo.log 

4.

[[email protected] ~]# 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操作

[[email protected] ~]# 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.

[[email protected] ~]# grep -A2 "^CHANGE #" his_ora_29032886_dump_arch.trc > redo_c.log 

6.

[[email protected] ~]# grep OBJ: redo_c.log |awk -F "OBJ:" '{print $2}'|awk '{print $1}'|sort -n|uniq -c |sort -n -r

---这是对object_id按照出现的次数进行倒序排列,举例:

[[email protected] ~]# 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暴增:

[[email protected] ~]# 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

时间: 2024-10-13 16:56:06

redo log大量生成的诊断处理流程的相关文章

oracle redo log的维护

Oracle online redo log是Oracle数据库中核心文件之一.在数据库操作中,只要有任何的数据块变化,都会生成相应的redo entry.redo entry首先保存在log buffer中,最后由lgwr进程写入到Redo log里面. Online Redo Log的维护和性能是影响Oracle工作的一个重要方面.本文从日常维护角度出发,介绍几个常见的场景处理方法. 1.Redo Log Group和Redo Log Group Member Redo Log在数据库中的作

MySQL系列:innodb源码分析之redo log恢复

在上一篇<innodb源码分析之重做日志结构>中我们知道redo log的基本结构和日志写入步骤,那么redo log是怎么进行数据恢复的呢?在什么时候进行redo log的日志推演呢?redo log的推演只有在数据库异常或者关闭后,数据库重新启动时会进行日志推演,将数据库状态恢复到关闭前的状态.那么这个过程是怎么进行的呢?以下我们逐步来解析. 1.recv_sys_t结构 innodb在MySQL启动的时候,会对重做日志文件进行日志重做,重做日志是通过一个recv_sys_t的结构来进行数

zz MySQL redo log及recover过程浅析

原作地址:http://www.cnblogs.com/liuhao/p/3714012.html 写在前面:作者水平有限,欢迎不吝赐教,一切以最新源码为准. InnoDB redo log 首先介绍下Innodb redo log是什么,为什么需要记录redo log,以及redo log的作用都有哪些.这些作为常识,只是为了本文完整. InnoDB有buffer pool(简称bp).bp是数据库页面的缓存,对InnoDB的任何修改操作都会首先在bp的page上进行,然后这样的页面将被标记为

MySQL redo log及recover过程浅析

写在前面:作者水平有限,欢迎不吝赐教,一切以最新源码为准. InnoDB redo log 首先介绍下Innodb redo log是什么,为什么需要记录redo log,以及redo log的作用都有哪些.这些作为常识,只是为了本文完整. InnoDB有buffer pool(简称bp).bp是数据库页面的缓存,对InnoDB的任何修改操作都会首先在bp的page上进行,然后这样的页面将被标记为dirty并被放到专门的flush list上,后续将由master thread或专门的刷脏线程阶

Redo Log File(inactive、active)损坏,处理恢复对策

redolog的生命周期中共有四种状态:current  -> 正在使用的active   -> 非正在使用的,对应的Dirty Block还没有完全写入到数据文件中inactive -> 非正在使用的,可以覆盖的,Dirty Block已经完全写入.unused   -> 没有使用过的-- 查看redolog状态SQL> select group#,status from v$log; 模拟三种状态下redolog丢失,处理方案: 一.inactive 情况   (Inac

MySQL &#183; 引擎特性 &#183; InnoDB redo log漫游(转)

前言 InnoDB 有两块非常重要的日志,一个是undo log,另外一个是redo log,前者用来保证事务的原子性以及InnoDB的MVCC,后者用来保证事务的持久性. 和大多数关系型数据库一样,InnoDB记录了对数据文件的物理更改,并保证总是日志先行,也就是所谓的WAL,即在持久化数据文件前,保证之前的redo日志已经写到磁盘. LSN(log sequence number) 用于记录日志序号,它是一个不断递增的 unsigned long long 类型整数.在 InnoDB 的日志

mysql日志redo log 和binlog

在上一篇中我们说到了mysql的基础架构,通常一个查询操作只会涉及到基础架构中的那几部分: 首先连接数据库,分析器进行语义.语法分析,优化器生成执行计划和索引选择.执行器执行对应的语句.存储引擎查看内存中是否有对应的数据,有的话直接返回,没有的话从磁盘查找(不考虑查询缓存):但是对于更新操作的话还需要用到日志来辅助 日志的作用:1.数据恢复需要用到binlog 2.数据库重启后需要redo log来保证数据的可靠,会出现数据还没写入磁盘服务器异常重启的情况 一.redo log(重做log) 由

mysql物理日志redo log和逻辑日志 binlog

1.redo log(InnoDB引擎特有的日志)1.1.有了 redo log,InnoDB 就可以保证即使数据库发生异常重启,之前提交的记录都不会丢失,这个能力称为 crash-safe.具体来说,当有一条记录需要更新的时候,InnoDB 引擎就会先把记录写到 redo log里面,并更新内存,这个时候更新就算完成了.同时,InnoDB 引擎会在适当的时候,将这个操作记录更新到磁盘里面,而这个更新往往是在系统比较空闲的时候做1.2.innodb_flush_log_at_trx_commit

关于MySQL redo log,挖些坑,慢慢填

1. 为什么可以设置为多个redo log ? (innodb_log_files_in_group,默认值和推荐值都是2,我们线上设的统一为4): 2. 什么条件下会触发刷脏?除了master_thread\强制checkpoint以外,这个频率是否可以调整: 3. recovery阶段,bp是否启用.如启用,是根据my.cnf设置,占用一个特别大的内存吗? 4. redo log recovery阶段是否并行,是否可以并行? 5. 记录格式看清一种,记录及恢复阶段: 6. 环状的redo l