cursor: pin S产生原理及解决方法
2015-04-29 22:23
741 查看
转自:http://www.dbafree.net/?p=778
今天晚上在一个比较重要的库上,CPU严重的冲了一下,导致DB响应变慢,大量应用连接timeout,紧接着LISTENER就挂了,连接数也满了等一连串问题。
我们的监控抓取了当时系统的等待事件,ACTIVE SQL及SESSION_WAIT等待事件,所以问题比较容量定位,查看下监控,马上就发现出问题的时间点上出现大量的cusor:pin S,这个等待事件很常见。
再通过查询持有的等待事件cursor: pin S的会话正在执行的SQL语句发现仅是一条简单的SQL。通常内存中latch pin操作是相当快的,如果出现等待了,应该很可能就是该SQL执行的过于频繁。latch在Oracle中是一种低级锁,用于保护内存里的数据结构,提供的是串行访问机制,而mutex是Oracle 10gR2引入的,也是为实现串行访问控制的功能,并替换部分latch。
可以通过下面的SQL进行查询:
在每个child cursor下面都有一个mutexes这样的简单内存结构,当有session要执行该SQL而需要pin cursor操作的时候,session只需要以shared模式set这个内存位+1,表示session获得该mutex的shared mode lock.可以有很多session同时具有这个mutex的shared mode lock;但在同一时间,只能有一个session在操作这个mutext +1或者-1。+1 -1的操作是排它性的原子操作。如果因为session并行太多,而导致某个session在等待其他session的mutext
+1/-1操作,则该session要等待cursor: pin S等待事件。
当看到系统有很多session等待cursor: pin S事件的时候,要么是CPU不够快,要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。如果是硬件的问题,则可以升级硬件。
如果是SQL执行频率太高。最简单的做法是,将一条SQL拆分成多条SQL。增加SQL的版本数来降低并发。如一个SQL:
可以改为如下4个SQL,则并发的争用可以下降4倍。
另外,我们还会经常碰到另外一个等待事件“cursor: pin S wait on X”,这个等待事件主要是由硬解析引起的,解释如下:
“cursor: pin S wait on X” wait event is mostly related to mutex and hard parse.
- When a process hard parses the SQL statement, it should acquire exclusive
library cache pin for the corresponding LCO.
- This means that the process acquires the mutex in exclusive mode.
- Another process which also executes the same query needs to acquire the mutex
but it’s being blocked by preceding process. The wait event is “cursor: pin S wait on X”.
cursor: pin S,cursor: pin X,cursor: pin S wait on X这三个等待事件,实际上就是替代了cursor的library cache pin,pin S代表执行(share pin),pin X代表解析(exclusive pin),pin S wait on X代表执行正在等待解析操作。这里需要强调一下,它们只是替换了访问cursor的library cache pin,而对于访问procedure这种实体对象,依然是传统的library cache pin。
参考:
https://supporthtml.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=5051110464464000&id=1310764.1&_afrWindowMode=0&_adf.ctrl-state=fu77hl3v2_4 http://www.hellodb.net/2010/07/oracle-library-cache.html这篇文章不错,每次看都能有所收获。
今天晚上在一个比较重要的库上,CPU严重的冲了一下,导致DB响应变慢,大量应用连接timeout,紧接着LISTENER就挂了,连接数也满了等一连串问题。
我们的监控抓取了当时系统的等待事件,ACTIVE SQL及SESSION_WAIT等待事件,所以问题比较容量定位,查看下监控,马上就发现出问题的时间点上出现大量的cusor:pin S,这个等待事件很常见。
再通过查询持有的等待事件cursor: pin S的会话正在执行的SQL语句发现仅是一条简单的SQL。通常内存中latch pin操作是相当快的,如果出现等待了,应该很可能就是该SQL执行的过于频繁。latch在Oracle中是一种低级锁,用于保护内存里的数据结构,提供的是串行访问机制,而mutex是Oracle 10gR2引入的,也是为实现串行访问控制的功能,并替换部分latch。
可以通过下面的SQL进行查询:
--查询sql SELECT a.*, s.sql_text FROM v$sql s, (SELECT sid, event, wait_class, p1 cursor_hash_value, p2raw Mutex_value, TO_NUMBER (SUBSTR (p2raw, 1, 8), 'xxxxxxxx') hold_mutex_x_sid FROM v$session_wait WHERE event LIKE 'cursor%') a WHERE s.HASH_VALUE = a.p1 --Parameter说明 P1 Hash value of cursor P2 Mutex value 64 bit platforms 8 bytes are used. Top 4 bytes hold the session id (if the mutex is held X) Bottom 4 bytes hold the ref count (if the mutex is held S). 32 bit platforms 4 bytes are used. Top 2 bytes hold the session id (if the mutex is held X) Bottom 2 bytes hold the ref count (if the mutex is held S). P3 Mutex where (an internal code locator) OR'd with Mutex Sleeps
在每个child cursor下面都有一个mutexes这样的简单内存结构,当有session要执行该SQL而需要pin cursor操作的时候,session只需要以shared模式set这个内存位+1,表示session获得该mutex的shared mode lock.可以有很多session同时具有这个mutex的shared mode lock;但在同一时间,只能有一个session在操作这个mutext +1或者-1。+1 -1的操作是排它性的原子操作。如果因为session并行太多,而导致某个session在等待其他session的mutext
+1/-1操作,则该session要等待cursor: pin S等待事件。
当看到系统有很多session等待cursor: pin S事件的时候,要么是CPU不够快,要么是某个SQL的并行执行次数太多了而导致在child cursor上的mutex操作争用。如果是硬件的问题,则可以升级硬件。
如果是SQL执行频率太高。最简单的做法是,将一条SQL拆分成多条SQL。增加SQL的版本数来降低并发。如一个SQL:
select name from acct where acctno=:1
可以改为如下4个SQL,则并发的争用可以下降4倍。
select /*A*/ name from acct where acctno=:1 select /*B*/ name from acct where acctno=:1 select /*C*/ name from acct where acctno=:1 select /*D*/ name from acct where acctno=:1
另外,我们还会经常碰到另外一个等待事件“cursor: pin S wait on X”,这个等待事件主要是由硬解析引起的,解释如下:
“cursor: pin S wait on X” wait event is mostly related to mutex and hard parse.
- When a process hard parses the SQL statement, it should acquire exclusive
library cache pin for the corresponding LCO.
- This means that the process acquires the mutex in exclusive mode.
- Another process which also executes the same query needs to acquire the mutex
but it’s being blocked by preceding process. The wait event is “cursor: pin S wait on X”.
cursor: pin S,cursor: pin X,cursor: pin S wait on X这三个等待事件,实际上就是替代了cursor的library cache pin,pin S代表执行(share pin),pin X代表解析(exclusive pin),pin S wait on X代表执行正在等待解析操作。这里需要强调一下,它们只是替换了访问cursor的library cache pin,而对于访问procedure这种实体对象,依然是传统的library cache pin。
参考:
https://supporthtml.oracle.com/epmos/faces/ui/km/DocumentDisplay.jspx?_afrLoop=5051110464464000&id=1310764.1&_afrWindowMode=0&_adf.ctrl-state=fu77hl3v2_4 http://www.hellodb.net/2010/07/oracle-library-cache.html这篇文章不错,每次看都能有所收获。
相关文章推荐
- cursor: pin S产生原理及解决方法
- hashmap冲突的解决方法以及原理分析
- ARP攻击的原理,现象,和解决方法
- ARP攻击的原理与解决方法
- Linux编程之socket:tcp流协议产生的粘包问题及解决方法
- C# ASP.NET B/S模式下,采用lock语法 实现多用户并发产生不重复递增单号的一种解决方法技术参考
- Tomcat中文乱码问题的原理和解决方法
- μt产生红种的临时解决方法
- 机器学习中产生overfitting的可能性和解决overfitting的方法
- ASP的chr(0)文件上传漏洞原理和解决方法介绍
- COM组件中在工作线程中产生事件的解决方法。
- 网络转载:局域网安全:解决ARP攻击的方法和原理
- #大学#Java多线程产生死锁的原因和解决方法
- LoadRunner测试ajax框架,回放后系统中没有产生数据解决方法
- Linux的僵尸进程产生原因及解决方法
- TCP短连接产生大量TIME_WAIT导致无法对外建立新TCP连接的原因及解决方法—实践篇
- Dataguard-备机产生gap的解决方法
- vmware安装的网络连接禁用后产生的问题以及解决方法
- C# ASP.NET B/S模式下,采用lock语法 实现多用户并发产生不重复递增单号的一种解决方法技术参考
- Xshell在按delete,backspace键产生乱码的解决方法