今天在网上看到一个经典的SQL优化案例，优化思路值得学习和参考，在此做一下自己学习分析的过程，具体SQL如下，该SQL执行需要1分钟的时间，对该SQL进行优化。

select tpc.policy_id, 
       tcm.policy_code, 
       tpf.organ_id, 
       to_char(tpf.insert_time, 'YYYY-MM-DD') As insert_time, 
       tpc.change_id, 
       d.policy_code, 
       e.company_name, 
       f.real_name, 
       tpf.fee_type, 
       sum(tpf.pay_balance) as pay_balance, 
       c.actual_type, 
       tpc.notice_code, 

    对于树形查询的案例在我接触的系统中并不多见，只是在学习理论知识的时候知道有这么个东东查询，就好比一个公司的职员表，总经理下面有5位副总，副总下面有各有20个小弟，现在让查询总经理下面有多少小弟，这个时候就用到了树形查询，意思就是这么个意思，来看一下具体的优化案例。

select rownum, adn, zdn, 'cable'
  from (select distinct connect_by_root(t.tdl_a_dn) adn, t.tdl_z_dn zdn
          from AGGR_1 t
         where t.tdl_operation <> 2
           and exists (select 1
                  from CABLE_1 a
                 where a.tdl_operation <> 2
         

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

从这部分来看，数据库负载并不算高，但是结合报表数据库业务情况，会话数有点异常，这也是我发现数据库有异常的依据，继续看TOP 5 Event
http://s8/mw690/001N2SGity6FCIxzuK317&690
果然出现了非空闲等待事件latch free和read by other sess

http://s6/mw690/001N2SGity6FpffHDxj25&690

一、RAC后台进程
LMON:LOCK Monitor Processes 也被称为Global enqueue service monitor
  监控整个集群状况，维护GCS的内存结构
  监控非正常终止的进程和实例
  当实例离开和加入集群时，锁和资源的重新配置
  管理全局的锁和资源
  监控全局的锁资源、处理死锁和阻塞
LMSn:Lock Monitor Services也称作GCS（Global Cache Services）processes
  LMS进程主要用来管理集群内数据库的访问，并在不同实例的buffer cache中传输块镜像，当在某个数据块上

  发生一致性读时，LMS负责回滚该数据块，并将它copy到请求的实例上
  每个RAC节点至少有2个LMS进程

L

    该等待事件我在前面分析过，但是这次和上次产生的原因有些不一样，上次该等待事件的详细分析链接是：http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html ，本次原理和上次是一样的，但是引起的原因很典型，记录一下排查过程。

http://s3/mw690/001N2SGity6Fn9rlOM292&690

     结合发生的时间点，从上图我们可以看出，此时数据库负载相对较高，我们年看load profile部分情况
http://s14/mw690/001N2SGity6Fn9rntN36d&690

     从load profile模块来看，数据库解析比较严重，并

    今天早上刚到办公室，应用支撑侧同事打电话告诉我某某系统很慢并且有超时现像发生，让我分析一下数据库是不是有异常，登陆数据库后发现数据库日志中提示会话数ORA－00018 Maximum number of sessions exceeded超出最大会话数，该库正常情况下会话数在300-600之间，数据为设置session数量是1105，肯定发生了严重的等待事件，取出当时AWR报告进行分析，记录一下分析过程。

http://s6/mw690/001N2SGigy6FiEzmf6l45&690

    发现数据库由session原来的331直接上升至1020，验证了日志报错信息，不超才怪，但是以目前服务器配置来看，数据库负载并不算太高，再看看TOP 5等待事件