自学内容网 自学内容网
自学内容网 > 正文

Oracle11.2.0.4.0的版本，RAC ADG备库mrp进程出现应用日志卡主的问题

🕗 发布于 2024-12-13 05:19 oracle  

Oracle11.2.0.4.0的版本，RAC ADG备库mrp进程出现应用日志卡主的问题

问题原因分析:

1、查看当前mrp进程的状态，当前在应用日志14450

SYS@hddbsz2> select process,pid from V$managed_standby where process like '%MRP%';

PROCESS          PID
--------- ----------
MRP0           14450

 

2、对mrp进程进行10046跟踪

查看mrp进程一直在等待parallel recovery slave next change，等待并行子进程的信息回复
 
oradebug setospid 41045
oradebug unlimit
oradebug Event 10046 trace name context forever, level 12
oradebug Event 10046 trace name context off
oradebug tracefile_name

3、查看日志

/u01/app/oracle/diag/rdbms/hddbsz/hddbsz2/trace/hddbsz2_mrp0_14450.trc

4、这个问题由于BUG17695685产生的，ADG打上补丁，重新开启应用日志进程，发现正常应用了

MOS参考：
Bug 17695685 - Hang in Active Dataguard Database with RAC (Doc ID 17695685.8)    

Bug 17695685  Hang in Active Dataguard Database with RAC
 This note gives a brief overview of bug 17695685.
 The content was last updated on: 08-MAR-2022

Affects:

Product (Component)    Oracle Server (Rdbms)
Range of versions believed to be affected    Versions >= 11.2
Versions confirmed as being affected    
11.2.0.4
11.2.0.3
Platforms affected    Generic (all / most platforms affected)

Fixed:

The fix for 17695685 is first included in    
12.1.0.1 (Base Release)
11.2.0.4.190716 (Jul 2019) Database Patch Set Update (DB PSU)
11.2.0.4.190716 Exadata Database Bundle Patch (Jul 2019)
11.2.0.4.190716 (Jul 2019) Bundle Patch for Windows Platforms


Description

This bug is only relevant when using Real Application Clusters (RAC)
Rediscovery:
- There is hang in Active Dataguard Database (ADG)
- MRP or its slave waits for a buffer with state: MEDIA_RCV
 
For example a hanganalyze trace might show something like:
 
 Oracle session identified by:
    {
                instance: 1 
                   os id: 31520
              process id: 82, <.....> (PR0J)
              session id: 982
        session serial #: 1157
    }
    which is waiting for 'gc buffer busy release' with wait info:
    {
                      p1: 'file#'=0x3
                      p2: 'block#'=0x1399a
                      p3: 'class#'=0x1c
            time in wait: 0.567673 sec
      heur. time in wait: 40 min 7 sec
           timeout after: 0.432327 sec
                 wait id: 35008931
                blocking: 2737 sessions
             current sql: <none>
             short stack:
  ksedsts()+465<- ... 
  <-semtimedop()+10<-skgpwwait()+160<-ksliwat()+2022<-kslwaitctx()+163<-kslwait()+141
   <-kclwlr()+535<-kcbzfc()+656<-kcbr_media_apply()+1782<-krp_slave_apply()+284<-krp_slave_main()
 
GLOBAL CACHE ELEMENT DUMP (address: 0xf7e7c360):
  id1: 0x1399a id2: 0x3 pkey: INVALID block: (3/80282)
  lock: X rls: 0x7 acq: 0x0 latch: 3
  flags: 0x20 fair: 255 recovery: 0 fpin: 'kclwh2'
 bscn: 0x2.3927d9d3 bctx: (nil) write: 0 scan: 0x0
 lcp: (nil) lnk: [NULL] lch: [0x31f91f2b0,0x31f91f2b0]
  seq: 89 hist: 54 113 238 180 113 238 180 113 238 180 113 238 180 113 238 180
 113 238 180 113
  LIST OF BUFFERS LINKED TO THIS GLOBAL CACHE ELEMENT:
flg: 0x00280400 lflg: 0x8 state: MEDIA_RCV tsn: 2 tsh: 4  waiters: 4
 
- There are waiters for "Media Recovery" buffer.
 
- This issue may also sometime present as "buffer deadlock" / "gc buffer busy acquire" waits in RAC
Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

References

Bug:17695685 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article


原文地址：https://blog.csdn.net/gsforget321/article/details/144430243

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

相关文章

自学内容网
Copyright © 2015-2024