诊断案例:Oracle的Mutex机制和Cursor Pin S竞争分析

SQL的软解析也会带来性能问题么?我们都知道使用绑定变量,让SQL实现软解析是Oracle的最佳实践。那么大量的软解析会否带来负面的性能影响呢?

在以下数据库的AWR报告中,可以看到超高的Cursor: Pin S等待,这是一个由于频繁执行SQL共享软解析时产生的竞争。

当一个会话尝试以共享模式(S - Share)来获得一个游标时,需要修改相应的Mutex结构的引用计数(reference count),或者增加该计数,或者减少。修改引用技术的原子操作很快(其实和Latch的获取释放类似),但是在频繁解析的情况下,仍然产生了竞争和等待,由此就产生了 cursor : pin S 的等待。

以下是这个用户的AWR报告,Top 5事件(11.2.0.1.0版本,60分钟采样):

这种表征和等待通常是由于某些SQL以超高频繁的频率执行导致的,当然也与系统的CPU能力不足有关。

Mutex机制在Oracle 10g引入,用于替代Library cache pin操作,其性能更高,其原理为在每个Child Cursor上分配一个地址空间记录Mutex,当该Cursor被共享执行时,通过将该位进行加一处理来实现。虽然是指游标共享,但是更新Mutex结构的操作需要排他,当某一个SQL被频繁共享执行时,可能就会出现Pin S的等待。

每个Library Cache对象都有一个reference count (引用计数),用来表明有多少其他对象目前正保留一个对它的引用(reference). 对象A 想要引用对象B, A 就把B 的 reference count 加 1。 当A 结束了对B 的引用, A 就把 B 的reference count 减 1. 当没有任何对象再引用 B 时, B 的 reference count就减为0, B 就被清除(deallocated), 内存就被释放。清除B的时候, 被B所用的对象的 reference count 也可能减小, 也可能使它们被清除。

最简单的解决方案是,将频繁执行的SQL分区拆解,分散竞争,如以下SQL通过注释将同一条SQL分解为2条,就分散了竞争: select /*SQL 1*/ a from t_a where id=?

select /*SQL 2*/ a from t_a where id=? 这种做法在Ebay、Papal、支付宝等公司被广泛采用。

在官方文档上这样解释:

A session waits for "cursor: pin S" when it wants a specific mutex in S (share) mode on a specific cursor and there is no concurrent X holder but it could not acquire that mutex immediately. This may seem a little strange as one might question why there should be any form of wait to get a mutex which has no session holding it in an incompatible mode. The reason for the wait is that in order to acquire the mutex in S mode (or release it) the session has to increment (or decrement) the mutex reference count and this requires an exclusive atomic update to the mutex structure itself. If there are concurrent sessions trying to make such an update to the mutex then only one session can actually increment (or decrement) the reference count at a time. A wait on "cursor: pin S" thus occurs if a session cannot make that atomic change immediately due to other concurrent requests. Mutexes are local to the current instance in RAC environments.

关键的部分指出:即使是以共享模式(S mode)获取一个Mutex,也需要在Mutex的数据结构上增加(或者减少)其引用计数,这是一个排他的原子操作。

可以看到在SQL解析部分,前3条SQL的执行频率非常高(采样为60分钟间隔),这些频繁的SQL执行是产生Pin S的源头:

这几条SQL的语句全文是:

select * from sw_PRODUCTS where ID=:ID select * from sw_SERIES where ID=:ID select f_sale_price from product_sale_price where f_product_id=:product_id and F_PRICE_BM='ECBJ'

典型的简单SQL反复执行,通过前面探讨的SQL改写方案将可以解决这里面临的Cursor: Pin S问题。

这也是一个过度软解析的负面影响案例,当然在CPU资源短缺或者极高的频度执行时,你才可能看到这种情况。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-06-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏微信终端开发团队的专栏

微信ANDROID客户端-会话速度提升70%的背后

image.png 背景 打开会话速度慢 在同一个会话有较多的历史消息下,各种查询,更新,删除等操作,速度明显下降。 在会话内有较大量历史消息情况下,进入...

3687
来自专栏练小习的专栏

CSS Hack整理

CSS Hack是在标准CSS没办法兼容各浏览器显示效果时才会用上的补救方法,在各浏览器厂商解析CSS没有达成一致前,我们只能用这样的方法来完成这样的任务. 我...

1878
来自专栏灯塔大数据

每周学点大数据 | No.68 Hadoop 实践案例——等值连接

No.68 Hadoop 实践案例——等值连接 Mr. 王 :我们再来看看另一个非常常见的例子。很多时候,我们关心的数据来自多个表。比如在某学校的教务系统中,有...

40810
来自专栏程序员的SOD蜜

隐藏在程序旮旯中的“安全问题”

    作为一个真正的程序员,必须有高度的“安全意识”,因为我们作出的软件运行在复杂的环境中,不能把不该有异常抛给用户,更不能把漏洞留给“黑客”,当然也不能把“...

2045
来自专栏IT技术精选文摘

如何加快MySQL模糊匹配查询

1315
来自专栏CSDN技术头条

解析大型.NET ERP系统 20条数据库设计规范

数据库设计规范是个技术含量相对低的话题,只需要对标准和规范的坚持即可做到。当系统越来越庞大,严格控制数据库的设计人员,并且有一份规范书供执行参考。在程序框架中,...

2207
来自专栏Spring相关

快速初步了解Neo4j与使用

Neo4j是一个高性能的,NOSQL图形数据库,它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎,但是...

831
来自专栏数说工作室

小明的 SQL 问题解决日志(1)

本系列仅为小明在写SQL过程中,由浅入深遇到的一些问题、以及最后解决方案。我知道这其中有些问题,高手在12岁的时候就已经知道答案了,小明可能比你们慢了一点。 ...

2755
来自专栏我的博客

Elasticsearch学习搜索的笔记

1.普通查询(全文搜索) 查询name=Smith的文档数据 GET /megacorp/employee/_search { "query" : { ...

1865
来自专栏玩转JavaEE

使用MyBatis轻松实现递归查询与存储过程调用

vhr部门管理模块更新啦!为了让小伙伴们快速理解部门管理模块实现思路,我想通过3篇短文来给大家介绍下大致的实现思路和核心代码。 项目地址:https://git...

3256

扫码关注云+社区