Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1402115
  • 博文数量: 556
  • 博客积分: 12626
  • 博客等级: 上将
  • 技术积分: 5799
  • 用 户 组: 普通用户
  • 注册时间: 2006-01-11 15:56
个人简介

从事IT基础架构多年,发现自己原来更合适去当老师……喜欢关注新鲜事物,不仅限于IT领域。

文章分类

全部博文(556)

文章存档

2019年(6)

2018年(15)

2017年(17)

2016年(11)

2015年(2)

2014年(2)

2013年(36)

2012年(54)

2011年(100)

2010年(41)

2009年(72)

2008年(14)

2007年(82)

2006年(104)

分类: Oracle

2009-09-10 17:44:28

    前几篇blog中提到最近在帮别人解决一个latch free的问题,目前问题解决,简单记录一下情况吧。
    首先出问题的数据库主机做了一次配置升级,CPU和内存加大了一倍,同时把SGA也做了相当的扩大(包括shared pool,可升级完成之后马上发现,当业务压力上来之后cpu负载很快提高到接近极限,检查发现等待事件中latch free占到了80%,继续分析发现这些latch问题基本都属于row cache objects。
    这个问题初看还是挺奇怪的,原则上讲row cache objects是出现了row cache的争用,通常的做法是想办法加大shared pool的使用空间,可主机刚刚扩了容就马上出现这个问题,而且扩容以前都没有显现的这么恶劣,难道又是个bug?(latch free对应的bug还是很多的,特别还是在RAC环境,呵呵)
    检查过程中发各个session的事务并不是完全僵死,只是运行非常缓慢,通过oradebug也找不出什么头绪,blocker的session也一直在变。检查sqlarea,发现绑定变量很差,占用的sqlarea区很多,shared pool的空闲空间已经很小了。暂时先没考虑是不是bug(不能什么都是bug啊,太没技术含量了),可怎么看statspack报告都只像是row cache的争用,row cache objects的命中率非常差,不过有一点比较奇怪,
v$rowcache中只是dc_sequences和dc_tablespace_quotas的miss很高,其他都很正常,而这两项的get请求又不多,因此也只是建议先调整应用,把绑定变量做好并且适当调整比较频繁使用的sequence的cache。
   最后经过问题方会诊多方会诊后终于定位这个问题,没错,又是个bug,而且是9208版本的bug。问题描述如下:
 
Bug 5887309 - Slower row cache lookup in 9.2.0.8
  : 5887309.8 类型: PATCH
  上次修订日期: 24-SEP-2008 状态: PUBLISHED

Bug 5887309  Slower row cache lookup in 9.2.0.8

 This note gives a brief overview of bug 5887309.
 The content was last updated on: 07-MAY-2008
 Click for details of each of the sections below.

Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions >= 9.2.0.8 but < 10.1.0.2
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

 It is believed to be a in default behaviour thus:
   Regression introduced in 9.2.0.8

Fixed:

This issue is fixed in
  • (None Specified)

Symptoms:

Related To:

  • (None Specified)
  • _MORE_ROWCACHE_LATCHES

Description

This problem is introduced in 9.2.0.8 by the fix for 

Note: This fix introduces a problem which can lead to ORA-600[504] 
      - this fix has been superceded by the fix for 

It is possible for row cache lookups to use more CPU / hold
latches for longer than in earlier releases in 9.2.0.8.
The extra CPU used is in generally in function kqrpre1().

Workaround:
  Set "_more_rowcache_latches" = false
   to disable the extra row cache latches in 9.2.0.8
  Note that the instance must be restarted to pick
   up any change to this parameter.

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. Always consult with Oracle Support for advice.

References

(This link will only work for PUBLISHED bugs)
Information on the sections in this article 
   
    很显然,问题都对上了,cpu的扩展触发了这个问题,导致了额外的争用发生,调整参数_more_rowcache_latches为false后问题解决。另外bug 5040691的表象跟这个也很类似,不过这个bug只对应9207以前的版本(怎么感觉是没改利索啊!)。
    又一次感觉到,对于oracle来说,但凡出现这类奇怪的问题都可以先想想是不是bug可能更节约时间,呵呵。
阅读(7683) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~