cursor: pin S产生原理及解决方法

转自: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进行查询:

点击(此处)折叠或打开

  1. --查询sql
  2. SELECT a.*, s.sql_text
  3. FROM v$sql s,
  4. (SELECT sid,
  5. event,
  6. wait_class,
  7. p1 cursor_hash_value,
  8. p2raw Mutex_value,
  9. TO_NUMBER (SUBSTR (p2raw, 1, 8), ‘xxxxxxxx‘) hold_mutex_x_sid
  10. FROM v$session_wait
  11. WHERE event LIKE ‘cursor%‘) a
  12. WHERE s.HASH_VALUE = a.p1
  13. --Parameter说明
  14. P1 Hash value of cursor
  15. P2 Mutex value
  16. 64 bit platforms
  17. 8 bytes are used.
  18. Top 4 bytes hold the session id (if the mutex is held X)
  19. Bottom 4 bytes hold the ref count (if the mutex is held S).
  20. 32 bit platforms
  21. 4 bytes are used.
  22. Top 2 bytes hold the session id (if the mutex is held X)
  23. Bottom 2 bytes hold the ref count (if the mutex is held S).
  24. P3 Mutex where (an internal code locator) OR

在每个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产生原理及解决方法

时间: 2024-10-07 19:32:21

cursor: pin S产生原理及解决方法的相关文章

Tomcat中文乱码问题的原理和解决方法

自从接触Java和JSP以来,就不断与Java的中文乱码问题打交道,现在终于得到了彻底的解决,现将我们的解决心得与大家共享. 一.Java中文问题的由来 Java的内核和class文件是基于unicode的,这使Java程序具有良好的跨平台性,但也带来了一些中文乱码问题的麻烦.原因主要有两方面,Java和JSP文件本身编译时产生的乱码问题和Java程序于其他媒介交互产生的乱码问题. 首先Java(包括JSP)源文件中很可能包含有中文,而Java和JSP源文件的保存方式是基于字节流的,如果Java

网站被CC攻击的原理与解决方法

作为站长或者公司的网站的网管,什么最可怕?显然是网站受到的DDoS攻击.大家都有这样的经历,就是在访问某一公司网站或者论坛时,如果这个网站或者论坛流量比较大,访问的人比较多,打开页面的速度会比较慢,对不?!一般来说,访问的人越多,网站或论坛的页面越多,数据库就越大,被访问的频率也越高,占用的系统资源也就相当可观. CC攻击是DDoS(分布式拒绝服务)的一种,相比其它的DDoS攻击CC似乎更有技术含量一些.这种攻击你见不到虚假IP,见不到特别大的异常流量,但造成服务器无法进行正常连接,一条ADSL

SQL注入原理与解决方法代码示例

一.什么是sql注入? 1.什么是sql注入呢? 所谓SQL注入,就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令,比如先前的很多影视网站泄露VIP会员密码大多就是通过WEB表单递交查询字符暴出的,这类表单特别容易受到SQL注入式攻击.当应用程序使用输入内容来构造动态sql语句以访问数据库时,会发生sql注入攻击.如果代码使用存储过程,而这些存储过程作为包含未筛选的用户输入的字符串来传递,也会发生sql注入. 黑客通过SQL注入攻击

kdump报错原理及解决方法

kdump是Linux内核崩溃转储机制.在系统崩溃时,kdump创建一个内存映像(vmcore),可以帮助确定崩溃原因.启用kdump需要你通过kdump专用储备系统存储器的一部分.这段内存不可用作其他用途.这和以前的diskdump,netdump是同样道理.cent 5之后的版本出现的. systemctl status kdump [server]-[[email protected] etc]$systemctl status kdump ● kdump.service - Crash

Android检测Cursor泄漏的原理以及使用方法(转)

简介: 本文介绍如何在 Android 检测 Cursor 泄漏的原理以及使用方法,还指出几种常见的出错示例.有一些泄漏在代码中难以察觉,但程序长时间运行后必然会出现异常.同时该方法同样适合于其他需要检测资源泄露的情况. 最近发现某蔬菜手机连接程序在查询媒体存储(MediaProvider)数据库时出现严重 Cursor 泄漏现象,运行一段时间后会导致系统中所有使用到该数据库的程序无法使用.另外在工作中也常发现有些应用有 Cursor 泄漏现象,由于需要长时间运行才会出现异常,所以有的此类 bu

高DPI下界面错乱的解决方法和原理

来源: http://bbs.csdn.net/topics/370177760 我在win32 + c写的界面中解决办法,就是把字体的字号给固定了,这样做的结果就是,不管dpi是否有改变,界面中控件的文字的字号不变,就不会出现文字换行的情况. 但像菜单文字的字号就变大了,combobox(右三角),checkbox(选择框)变大一点点,显的有点不协调. 但至少不影响使用. 下面是判断当前系统的dpi,然后重置字体的字号. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

shared_ptr造成的循环引用&&解决方法和原理(弱引用&&强引用)

 弱用指针的方式解决shared_ptr造成的循环引用防止内存泄漏! <***>循环引用就是由于智能指针shared_ptr造成的,下面就是shared_ptr的使用造成循环引用的图解: <****>举个例子来说下shared_ptr造成的循环引用: (选题背景双向链表) <span style="font-size:18px;">#include<memory> #include<iostream> using namesp

多线程下ArrayList类线程不安全的解决方法及原理

ArrayList类在多线程环境下是线程不安全的,在多线程读写情况下会抛出并发读写异常(ConcurrentModificationException): 1 import java.util.ArrayList; 2 import java.util.List; 3 import java.util.UUID; 4 5 public class NoSafeArrayList { 6 public static void main(String[] args) { 7 8 List<Strin

【转】Java 集合系列04之 fail-fast总结(通过ArrayList来说明fail-fast的原理、解决办法)

概要 前面,我们已经学习了ArrayList.接下来,我们以ArrayList为例,对Iterator的fail-fast机制进行了解.内容包括::1 fail-fast简介2 fail-fast示例3 fail-fast解决办法4 fail-fast原理5 解决fail-fast的原理 转载请注明出处:http://www.cnblogs.com/skywang12345/p/3308762.html 1 fail-fast简介 fail-fast 机制是java集合(Collection)中