分析库缓存锁问题

查询sql造成库缓存锁 library cache lock，在ash报告中出现library cache lock 就是底层数据结构锁了，原因有其他事件在获取S或者X锁，该事件发生事件较长，影响到了业务。

通过AWR报告可以看出，这条SQL执行时间太长了

记录了执行总和时间的TOP SQL

记录了SQL占用library cache的大小的TOP SQL

打开游标数量也非常高

 通过oracle的AWR报告发现这条sql语句执行时间非常之长，占用库缓存的比重非常之大，打开子游标数量也非常高

 通过ASH报告，library cache lock，还有cursor:pin S wait on X

造成这种原因就是

1.Shared pool设置过小，或者由于自动内存管理导致

2.频繁的硬解析

3.子游标太多

分析：

通过AWR，ASH报告，定位到SQL，找到代码，发现调用这个SQL特别频繁，而且数据量巨大，虽然通过SQL的执行计划看到SQL都走了索引，代码中看到SQL语句有一部分不是通过?进行替换的，而是通过+'值'+的方式进行拼接的，如果通过+号拼接的代码SQL走的是硬解析，没有走软解析。

硬解析:

硬解析是指Oracle在执行目标SQL时，在库缓存中找不到可以重用的解析树和执行计划，而不得不从头开始解析目标SQL并生成相应的父游标和子游标的过程。

硬解析实际上有两种类型：一种是在库缓存中找不到匹配的父游标，此时Oracle会从头开始解析目标SQL，新生成一个父游标和一个子游标，并把它们挂在对应的HashBucket中;另外一种是找到了匹配的父游标但未找到匹配的子游标，此时Oracle也会从头开始解析该目标SQL，新生成一个子游标，并把这个子游标挂在对应的父游标下。

select * from TEXT where id=20; 

软解析：

软解析是指Oracle在执行目标SQL时，在Library Cache中找到了匹配的父游标和子游标，并将存储在子游标中的解析树和执行计划直接拿过来重用而无须从头开始解析的过程。

select * from TEXT where id:id;