1.cursor pin s是一个共享锁，一般情况下是因为发生在SQL短时间内大量执行
案例：在生产库中，突然出现大量的cursor pin s的等待，询问是否有动作后，同事说有编译存储过程（被误导了，如果是因为存储过程编译失效，大量调用，应该是library cache pin）
最后的原因是同时修了存储过程，里面有BUG，导致某个SQL短时间内大量执行导致的（每秒上万次），后来修改了一下存储过程，重新编译后，问题解决。
SELECT SQL_ID,EXECUTIONS,SYSDATE FROM V$SQLAREA WHERE SQL_ID='';
将发生等待的SQL带入上面的SQL，执行两次，即可大概估算出每秒执行的次数
2.cursor pin s wait on x是一个排他锁，一般情况下，是因为硬解析造成的（share pool的抖动，造成执行计划被踢出，多时间内大量硬解析）
案例：生产库突然出现大量的cursor pin s on x等待，这个等待一般是发生硬解析是产生，即SQL首先获取排他锁后，才可以在对应SQL HASH的bucket后面添加父节点和子节点（执行计划）
这时候如果出现大量的硬解析，就会出现这个等待。最终的原因是因为一个全表扫描导致oracle的SGA自动管理把share pool缩小来增大DB CACHE，踢出去了一部分的执行计划，最终导致硬解析增加，最后设置一个share pool的最小值，并增大SGA的大小解决。