昨天下午下班前瞄了一眼数据库一天运行情况，发现逻辑DG数据库会话数有些异动，取了一下当时的AWR报告，果然有些异常，但不算太严重，但是出现的等待事件很值得研究一下，具体信息如下： http://s16/mw690/001N2SGity6FCImhucDdf&690latch free" TITLE="AWR实战分析之---- latch free" />

从这部分来看，数据库负载并不算高，但是结合报表数据库业务情况，会话数有点异常，这也是我发现数据库有异常的依据，继续看TOP 5 Event
http://s8/mw690/001N2SGity6FCIxzuK317&690latch free" TITLE="AWR实战分析之---- latch free" />
果然出现了非空闲等待事件latch free和read by other session，因为read by other session我前面分析过，原因基本上就那么多，详细分析：http://blog.sina.com.cn/s/blog_61cd89f60102ef0s.html ，今天我重点分析一下latch free，这几天正在看盖国强的《深入解析Oracle.DBA入门进阶与诊断案例》是一本不错的书，已经买不到纸质的了，老盖分享了电子版，强列推荐有一定基础的DBA好好读一下，地址：http://www.eygle.com/archives/2013/12/hforacle_release.html ，现在来说说latch free这个等待事件，该等待事件是latch等待事件的一个汇总，出现该等待事件需要查询v$latch查看具体的等待，当然AWR也有详细的统计，就是Latch Sleep Breakdown部分http://s1/mw690/001N2SGity6FCImnixOa0&690latch free" TITLE="AWR实战分析之---- latch free" />

从上图我们可以看出，是热块引起的，cache buffers chains等待事件，重点关注逻辑读部分，latch：cache buffers chains该类等待事件的分析详见：http://blog.sina.com.cn/s/blog_61cd89f60102edum.html，处理方法都是一样的，我们看一下TOP SQL

http://s16/mw690/001N2SGity6FCImkYzBcf&690latch free" TITLE="AWR实战分析之---- latch free" />

http://s16/mw690/001N2SGity6FCMnmsmHaf&690latch free" TITLE="AWR实战分析之---- latch free" />
    SQL定位到了，重点是优化，SQL优化内容较多，但方法概括来讲就是查看执行计划，跟据执行计划具体分析，解决此类问题目标只有一个，减少逻辑读，提高SQL执行速度，因涉及公司核心后台表数据，具体分析过程不再列出。
    查看前面的分析，细心的朋友可能会问，为什么前的等待事件都显示latch:cache buffer chians，为什么本列中却显示了latch free这个汇总等待事件？不能把它和latch:cache buffer chians功为一类吧？应该还有其它原因，事实就是如此，我们继续分析，看一下数据库SQL 高版本情况

http://s4/mw690/001N2SGity6FCImlZNp23&690latch free" TITLE="AWR实战分析之---- latch free" />
前面两条有些异常，SQL高版本问题产生有两种常见的原因

第一种：修改cursor_sharing参数，导致curso无法共享

第二种：绑定变量不匹配

    但是从该库高版本问题来看，并不严重，但是从某种程序上讲，已经有所影响，我们可以排除第一种原因造成的高版本问题，因为该库没有修改后此参数，对于第二种原因，我们需要查询v$sql_shared_cursor视图查询不能共享的原因，重点关注为Y的列，在这个案例中为Y的列是BIND_MISMATCHED，也就是第二种情况，绑定变量不匹配，ORACLE官方解释该问题是一个bug，因绑定变量的字段长度不同，导致产生大量的子cursor，详细描述：High Version Count Due To BIND_MISMATCH (文档 ID 336268.1)

ORACLE官方针对该问题提供的解决方案，通过10503事件能够避免此类问题，具体方法如下：

ALTER SESSION SET EVENTS '10503 trace name context forever, level ';

ALTER SESSION SET EVENTS '10503 trace name context forever, level 4096';

方法都是理论上可行的，结合业务测试进行验证是关键！切记！