AWR实战分析之--- cursor: pin S

AWR实战分析之--- cursor: pin S

 

----http://blog.sina.com.cn/s/blog_61cd89f60102eep2.html

     早上刚到办公室，负责主机的兄弟急急忙忙跑过来说数据库cpu使用率比较高，一直是90%以上，上周五晚上项目组刚发版，周一大早上就出现cpu使用率较高，估计和发版有一定的关系，不管怎么样，先定位问题再说

    先查看数据库等待事件有没有异常

    select sql_id,event from v$session where wait_class#<>6 order by sql_id

    

    发现同一条SQL产生大量的cursor: pin S等待事件，从目前接触到的CPU使用率较高问题来看，大部分都是pin和latch相关，这些操作是最消耗CPU资源的，其实这条查询就已经确认了SQL，但是为了安全考虑，还是决定取一下AWR报告，看看有没有其它信息。

    
    会话数明显比以前多了近200个，原因就是因为查询没及时返回，新的查询不断建立连接所致，再看TOP 5
    
    从TOP 5上看，cursor:pin S排在第一位，跟我们前面用SQL查询到的等待事件一致，我们再看看TOP SQL

    从TOP SQL来看，排在第一位的SQL_ID和我们前面查询到的是同一条SQL，同时发现该SQL是执行次数最多、逻辑读最多、消耗CPU也是最多的，从执行次数上看，一小时内执行了1亿7千万次，结合本系统实际，明显是异常的，SQL定位到了，下面就看怎么解决了，解决之要明白cursor: pin S等待事件原理

    cursor: pin S等待事件原理：
   Oracle10g中引用的mutexes机制一定程度的替代了library cache pin，其结构更简单，get&set的原子操作更快捷。它相当于，每个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等待事件。

   cursor: pin S处理方法：

 第一种方法：增加cpu或购买更高配置服务器（不是什么好方法，极端情况会有人会用）

 第二种方法：修改应用程序，降低并发访问数量（但是业务就是高并发，业务上无法优化）

 第三种方法：添加注释改变SQL数量，功能不变，不同模块调用不同SQL                

             select  注释 object_name from table_name where object_id=?
             select  注释 object_name from table_name where object_id=?
             select  注释 object_name from table_name where object_id=？

  问题和方法都有了，发给项目组进行修复，等待反馈！