« 《Oracle DBA手记 2》即将出版 | Blog首页 | 想要离开不容易 - 滞留世博上海 »
案例分析:row cache objects与pin s wait on X
作者:eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接:https://www.eygle.com/archives/2010/10/latch_row_cache_objects.html
到今天,已经来上海整整一个星期了,终于完美的解析了整个故障的过程和原因,并且也找到了解决方案,虽然还需要一点时间,但总算是一块石头落了地。链接:https://www.eygle.com/archives/2010/10/latch_row_cache_objects.html
中午从陆家嘴步行到东方明珠、正大广场,给儿子买了一个大巴车 -- 他最喜欢的,买了两个变形金刚,现在他是最喜欢车、恐龙的阶段,以前的车都是趴在地上跑的,现在变形金刚或许可以给他一个惊喜,开拓一下想象的翅膀,记得我小时候,整天为变形金刚着迷,想来这是一个时代的宠爱,到今天变形金刚的电影也是风靡不绝。
昨天傍晚,在回宾馆的路上,给太太打电话,碰巧看到报刊摊上有韩寒的《1988:我想和这个世界谈谈》,第一次读韩寒的小说,一口气读完,周老师让我发表点看法,我想到的第一感觉是:我仿佛看到了赛林格,以及那个带着鸭舌帽的少年,现在韩寒就是在这样一条路上,走着并引导我们。我喜欢他的叙事方式。
以前年少时,喜欢读安妮宝贝的书,现在怎么也不能读完了。太太买了很多安妮的书,多数跟旅行游走有关,于是我们多了个话题,那就是去西藏、去墨脱,现在去了西藏,还有墨脱。
从《独唱团》那遍布的隐喻看,1988中也有无数的谜语和隐喻,但是不可说。这是这个时代的悲哀,在这个时代成长起来的孩子,在以他们的视角讲述这个世界。
有时候也想写点小说一样的文字,想想,还是写Oracle吧。
这次处理的案例,最为典型的等待表征就是:latch row cache objects 和 cursor:pin s wait on X:
Top 5 Timed Events
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
---|---|---|---|---|---|
latch: row cache objects | 475,336 | 127,021 | 267 | 48.2 | Concurrency |
db file sequential read | 8,350,230 | 45,113 | 5 | 17.1 | User I/O |
CPU time | 31,695 | 12.0 | |||
read by other session | 6,195,757 | 17,313 | 3 | 6.6 | User I/O |
cursor: pin S wait on X | 1,204,552 | 12,212 | 10 | 4.6 | Concurrency |
那么我首先想到的就是,这两个事件是如何出现的?
如何互相影响?
我们又能够怎样去模拟这个故障?如何通过实验得到同样的输出?
另外,修改_KKS_USE_MUTEX_PIN会否有改善?这一切是否是Mutex惹的祸?
大家和我一起思考下,看一看能够在自己的数据库环境中,模拟到类似的情况。
历史上的今天...
>> 2019-10-18文章:
>> 2012-10-18文章:
>> 2008-10-18文章:
>> 2007-10-18文章:
>> 2006-10-18文章:
>> 2005-10-18文章:
>> 2004-10-18文章:
By eygle on 2010-10-18 00:21 | Comments (23) | Case | 2638 |
不是ddl,不是分区,
那就是 cursor invalidate了,而且应该是长时间的holding 处理中
实时抓不到objects吗?给点信息吧再?
你能描述怎么抓Objects么?什么Objects?
可以像老白那样,写oracle的案例
怎么抓Objects. 参考 Expert Oracle Practices: Oracle Database Administration from the Oak Table, 第十二章, Troubleshooting Latch Contention , Riyaj Shamsudeen.
鄙人改编的, 没有实战使用过, 扫描一遍$bh, 会比较费劲, 也不精确, 可能会产生更多的contention.
PROMPT
PROMPT Querying to find objects involved in the latch contention
PROMPT ...Need to be logged on as sys as this query accesses x$bh
with bh_lc as
(select
lc.addr, lc.child#, lc.gets, lc.misses, lc.immediate_gets, lc.immediate_misses,
lc.spin_gets, lc.sleeps,
bh.hladdr, bh.tch tch, bh.file#, bh.dbablk, bh.class, bh.state, bh.obj
from
v$session_wait sw,
v$latchname ld,
v$latch_children lc,
x$bh bh
where lc.addr =sw.p1raw
and sw.p2= ld.latch#
and ld.name='row cache objects'
and lower(sw.event) like '%latch%'
and bh.hladdr=lc.addr
)
select bh_lc.hladdr, bh_lc.tch, o.owner, o.object_name, o.object_type,
bh_lc.child#,
bh_lc.gets, bh_lc.misses, bh_lc.immediate_gets,
bh_lc.immediate_misses, spin_gets, sleeps
from
bh_lc, dba_objects o
where bh_lc.obj = o.data_object_id(+)
order by 1,2 desc
;
什么Objects?猜测会是那些stats有关的dictionary object. 或者是一些影响了SQL的执行环境的因素,不停的产生新的child cursor, V$SYS_OPTIMIZER_ENV, V$SES_OPTIMIZER_ENV, V$SQL_OPTIMIZER_ENV.
也有可能是Mutex的bug, 阻塞了后面的请求队列.
不是什么objects,是此时正在执行什么sql语句,这个难吗
实时抓语句,看看正在执行着什么操作
to 木匠:
stats影响可能性不大,除非是bug.
发力的还是sql和物理结构啊
改一下应用,避免soft parse最好。 就不用研究那么多了⋯⋯
哥,soft parse哪能造成这问题
从系统收集的信息来看,几乎任何SQL都可能产生row cache objects的竞争,在故障时刻有成千的SQL被捕获。
减少硬解析,确实是根本,但是不现实,在客户系统中,几乎不可能。
可以参考warehouse的:
http://warehouse.itpub.net/post/777/493962
可以参考warehouse的:
http://warehouse.itpub.net/post/777/493962
请 模拟一下,latch row cache objects / cursor: pin S wait on X 同时出现的情况。
呃,模拟?
SQL组合万万种,表像更多,这个题目大。。。
来个正解?
9.2.0.8上有8个子latch来保护dc_object_ids,不知道为什么在10g中,包括10.2.0.4就只有1个子latch来保护dc_objects_ids,当然还有其他一些dc对象的latch也是如此。难道oracle认为10g在这方面的处理效率比9i提高了很多.....我个人一直没明白。
老熊,你去Check一下Oracle 11g,dc_object_ids已经不存在了,这个类型的操作我就觉得是不合理的,应该强拆予以取缔:)
我们已经帮助Oracle想好了解决方案,希望Oracle能够按照我们的建议写一个Patch,或者将11g的改进Backport进Oracle10g好了。
在操作系统中设置关于信号量的参数
愿闻其详!
你这个案例分析文章结尾了?
抱歉,等我做完手头的几个Case,会继续写这个案例!
我也遇到类似的情况,不知eygle怎样解决的
row cache主要就是dc层的问题,一般看row cache的数据就能知道问题的方向。
参考这里的信息:
http://www.eygle.com/archives/2010/10/baseinfo_database.html
客户的这个问题,是由于索引以及柱状图引致的,dc_object_ids会因为索引的数量增加而加剧使用,在高并发的系统就可能导致较为严重的竞争。
row cache objects 倒是无意中“模拟”到过了。9i的系统。dc_histogram_defs为主。
http://cronwa.blog.163.com/blog/static/136666714201121091036139/