cursor: pin S wait on X 等待事件

例行巡检 做了awr报告，发现在top 5 timed events 中有这样一个等待事件
cursor: pin S wait on X。  同时在 top sql 中发现一条异常的sql语句。一条简单的
insert 语句 竟然会耗费很长的时间

1.通过 v$session_wait_history 查找事件cursor: pin S wait on X 的会话
联机文档中是这样描述的
cursor: pin S wait on X

A session waits for this event when it is requesting a shared mutex pin
and another session is holding an exclusive mutex pin on the same cursor object
大致意思应该是 在同一个游标对象上 ，一个会话在请求一个共享的mutex pin ,已经有一个会话以排他形式
持有mutex pin 。至于什么是mutex 以后再做讲解。以下是联机文档对其解释
A mutual exclusion object (mutex) is a low-level mechanism that prevents an object in memory from aging out or from being corrupted
when accessed by concurrent processes. A mutex is similar to a latch, but whereas a latch typically protects a group of objects, a mutex protects a single object
三个参数如下

P1	Hash value of cursor
P2	Mutex value (top 2 bytes contains SID holding mutex in exclusive mode, and bottom two bytes usually hold the value 0)
P3	Mutex where (an internal code locator) OR'd with Mutex Sleeps

2.从p1 参数可以知道 p1值是sql语句的hash_value
从v$sqlarea 中查找到此sql语句，发现和awr中异常语句是一个，
且v$sqlarea.plan_hash_value 是0
通过以下语句查看holding sid

SELECT decode(trunc(p2/4294967296),  

         0,trunc(p2/65536),  
        trunc(p2/4294967296)) SID_HOLDING_MUTEX  

 FROM dual; 

3.通过 sql_id从v$sql_plan 中找不到执行计划

4.在v$sql_shared_cursor 中找到此语句 说明这条语句不能被共享，每次执行都hard parse

5.另外 v$mutex_sleep 中 kkslce这个值很大
mutex_type   location                   sleeps           wait_time
Cursor Pin    kkslce [KKSCHLPIN2]   33641743   2016421211

6.分析语句 也没有什么异常啊 怎么会花费这么长时间呢，为什么会一直做 hard parse 呢
现在对于解决这个还没有什么思路 请高手指教