ORACLE Active dataguard 一个latch: row cache objects BUG

在Active dataguard遇到latch: row cache objects 查询如下语句
select a.SAMPLE_TIME,a.SQL_ID,a.EVENT,a.P1TEXT,a.P1,a.P2TEXT,a.P2,a.P3TEXT,a.P3,
 b.f2
  from v$active_session_history a,  
  (select max(b.SQL_TEXT) f2,sql_id from  v$sql b group by sql_id ) b
 where a.sql_id = b.sql_id
   and a.SAMPLE_TIME < sysdate - 1
   and a.SAMPLE_TIME >
       to_date('2017-07-04 11:04:30', 'yyyy-mm-dd hh24:mi:ss')
   and a.sql_id is not null
   and a.event is not null
 order by a.sample_time

如下很多latch: row cache objects:

通过metalink找到:

查询:
地址换算为0X16进制就是下面的
SQL>  SELECT name, 'Child '||child#, gets, misses, sleeps
  2      FROM v$latch_children
  3     WHERE addr='000000073692E9B0'
  4    ;
NAME                                                             'CHILD'||CHILD#                                      GETS     MISSES     SLEEPS
---------------------------------------------------------------- ---------------------------------------------- ---------- ---------- ----------
row cache objects                                                Child 1                                        2944545138  584527074   70118020
SQL>     SELECT "WHERE", SLEEP_COUNT, WTR_SLP_COUNT, LONGHOLD_COUNT
  2      FROM v$latch_misses
  3     WHERE parent_name='row cache objects'
  4     and SLEEP_COUNT <>0
  5     ORDER BY SLEEP_COUNT;
WHERE                                                                            SLEEP_COUNT WTR_SLP_COUNT LONGHOLD_COUNT
-------------------------------------------------------------------------------- ----------- ------------- --------------
kqreqd                                                                              18475287      12578418              0
kqreqd: reget                                                                       23620027      15993065              0
kqrpre: find obj                                                                    27962864      41519129              0
SQL>    SELECT
  2          kqrsttxt PARAMETER,
  3   -- kqrstcid CACHE#,
  4          kqrstcln "Lchild#",
  5          kqrstgrq "DCGets",
  6          l.gets   "LGets",
  7          l.misses "Misses"
  8    FROM X$KQRST, V$LATCH_CHILDREN l
  9   WHERE l.addr='000000073692E9B0'
 10     and l.child#=KQRSTCLN
 11   ORDER BY 1,2
SQL>  SELECT
  2          kqrsttxt PARAMETER,
  3          kqrstcln "Lchild#",
  4          kqrstgrq "DCGets"
  5     FROM X$KQRST
  6    WHERE KQRSTCLN = 1
  7    ;
PARAMETER                           Lchild#     DCGets
-------------------------------- ---------- ----------
dc_rollback_segments                      1 2413168646

而这是一个bug

Bug 17608518  "row cache objects" latch contention on dc_rollback_segments

 This note gives a brief overview of bug 17608518. 
 The content was last updated on: 29-NOV-2016
 Click here for details of each of the sections below.

Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

Description

High Row Cache contention on dc_rollback_segments in Data Guard Active Standby (ADG)
manifested with wait events "latch: row cache objects" or "Child row cache objects".

This fix provides a latchless enhancement for alleviating "row cache objects" latch contention
on dc_rollback_segments. It is primarily intended for read-only environments such as Active
Data Guard since row cache lookups for other purposes such as writes will cause the
latchless lookups to fail and fall back to the latching mechanism, increasing overhead. 

Therefore, this enhancement needs to be used with care in a read-write environments.

After applying patch the fix must be enabled by setting event 17608518 at level 3.

If using a pfile add following line:

  event='17608518 trace name context forever, level 3'

If using spfile, add event like:

 SQL> alter system set event = '17608518 trace name context forever, level 3' scope=spfile sid='*';

Restart the standby for event to be in effect.
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.

参考文档:
WAITEVENT: "latch: row cache objects" Reference Note (文档 ID 1550722.1)

记录于此。

时间: 2024-11-14 12:18:02

ORACLE Active dataguard 一个latch: row cache objects BUG的相关文章

latch: row cache objects 和cursor: pin S wait on X共同出现

 Snap Id Snap Time Sessions Cursors/Session Begin Snap: 5980 11-Nov-13 16:00:37 1403  39.6 End Snap: 5981 11-Nov-13 16:31:29 1422  42.8 Elapsed:    30.86 (mins)    DB Time:    3,660.60 (mins)    Per Second Per Transaction Redo size:  1,185,514.75  6,

row cache字典缓冲区简介

字典缓冲区: dictionary cache,也叫row cache; 用于保存数据字典信息:如表空间相关信息.用户权限.objects信息.histogram信息等. 字典缓冲区在大小无法直接调整,只能通过调整共享池大小来调整字典缓冲区大小. SYS@ bys3>select pool,name ,bytes/1024/1024 MB from v$sgastat where name like 'row cache%'; POOL         NAME                

shared pool latch/ library cache latch /lock pin介绍

latch:library cache --desc v$librarycache; latch:library cache用于保护hash bucket. library cache lock保护HANDLE. library cache pin保护library cache object--LCO. 从10G开始,library cache lock和library cache pin被MUTEX部分取代.暂时不讨论MUTEX. latch:library cache的数量: SYS@ by

Oracle 11g DataGuard 物理备库配置及Active DataGuard测试

说明: 本文安装配置了Oracle 11g Dataguard 物理备库,并测试了11g Dataguard 物理备库新特性Active Data Guard, 是Oracle Database Enterprise Edition的一个功能,需要额外授权,本文只用于测试. 一.环境介绍 1. 主数据库环境 操作系统版本: OEL5.8 x64 数据库版本  : Oracle 11.2.0.3 x64 数据库sid名 : orcl 2. 备库环境 操作系统版本: OEL5.8 x64 数据库版本

Oracle 11g Dataguard物理备库配置(二) Active Dataguard测试

在Oracle 11g之前,物理备库(physical Standby)在应用redo的时候,数据库需要处于mount状态.从11g开始,应用redo的时候,物理备库可以处于read-only模式,这就称为Active Data Guard,这种状态可以实现实时查询功能. 1. 备库上操作 1) 查看备库当前状态 mount SQL> select open_mode,database_role,db_unique_name from v$database; OPEN_MODE        

Oracle结果集缓存(Result Cache)--服务器、客户端、函数缓存

Oracle结果集缓存(Result Cache)--服务器.客户端.函数缓存 在11g中,Oracle提供了结果集缓存特性.该缓存是在共享内存中存储全部的结果集,如果一个查询SQL被执行,且它对应的结果集在缓存中,那么,该SQL的几乎全部开销都可以避免.这些开销包括,解析时间.逻辑读.物理读和任意的通常可能会遭遇的争用.但是,在实际的情况中,结果集缓存仅在少数的情况下是有效的,原因有如下几点: (1)有数据重叠的多个SQL会在缓存中保存冗余的数据. (2)对依赖对象的任何改变(包括对查询中引用

Oracle 10g dataguard常用的维护命令总结

DataGuard可以提供Oracle数据库的冗灾.数据保护.故障恢复等,实现数据库快速切换与灾难性恢复.在生产数据库的保证"事务一致性"时,使用生产库的物理全备份创建备库,备库会通过生产库传输过来的归档日志或重做条目自动维护备用数据库. DataGuard数据同步技术有以下优势:  1) Oracle数据库自身内置的功能,与每个Oracle新版本的新特性都完全兼容,且不需要另外付费. 2) 配置管理较简单,不需要熟悉其他第三方的软件产品. 3) 物理Standby数据库支持任何类型的

11g Active DataGuard初探

原本dataguard中日志应用和数据库只读查询是一个互斥的关系,两者不能并存.如果需要应用日志,则数据库只能在Mount状态下 使用recover managed standby database disconnect from session来不断地从后台进行日志应用. 如果想查看备库中的数据情况,则只能使用recover managed standby database cancel来取消日志应用,然后把数据库启动到read only 状态下.这种情况从道理上也讲也是有理有据,但是终归还是

ASMM 导致的latch: library cache 和latch: shared pool

核心系统故障及调整报告核心系统数据库在2012年7月13日下午2点到4点和2012年7月16上午11点出现了高负载,影响了核心系统的正常使用,我随即进行了性能分析.得出报告如下:2012年7月13日 Snap Id Snap Time Sessions Cursors/SessionBegin Snap: 28264 13-Jul-12 14:00:26 173 14.3End Snap: 28265 13-Jul-12 15:00:17 189 15.0Elapsed:   59.84 (mi