Oracle性能调优之超越表面分析法

    从基于命中率的优化方法转向基于等待事件的优化方法，显著地提升了我们诊断和oracle优化应用的能力。然而正如前面提到的，一味关注响应时间长的组件，可能导致下面几个不良后果。
    1、治标不治本。
    2、更倾向于选择硬件方案，而非更划算的调整配置或应用。
    3、只顾眼前，忽视长远及可扩展能力。
    为了规避基于等待事件调优的隐患.需要明确几个阶段。这几个阶段是由应用、数据库、操作系统的交互方式决定。总体来看，数据库进程按照下面几个层次运行。
    (I)应用以SQL语句的形式向数据库发出请求(包含PL/SQL请求)。数据库响应这些请求。并返回对应的返回码与结果集。
    (2)为了处理应用请求，数据库必须解析这条SQL语句。在最终执行它之前，还需要完成多个额外操作(安全、调度及事务管理)。这些操作要用到操作系统资源(CPU和内存)，可能会受并发执行的数据库会话之间争用的限制。
    (3)最后，这些数据库请求还需要处理(创建、阅读或变更)数据库中的部分数据。需要处理的确切数据量要视数据库设计(例如索引设计)和应用(例如SQL语句类别)而定。
    内存中会有部分被请求数据。这些数据块出现在内存中的概率主要由其中的数据被访问的频率以及可用来缓存数据块的内存总量决定。在内存中访问数据库数据的行为被称为逻辑I0。此外，执行排序和散列操作也需要使用内存。
    (4)如果数据块不在内存中，就必须到磁盘上读取，从而导致物理IO操作。物理IO是到目前为止所有操作中代价最高的.因此数据库会尽量避免不必要的旧操作。然而.有些磁盘读写是无法避免的。在排序和散列操作太大而不能在内存中完成时，也会发生磁盘10,
    以上每一层的活动都会影响对下一层的请求。例如，提交一条SQL语句由于某种原因不能有效利用索引，就需要执行大量的逻辑读操作，而这又将导致争用并最终引发大量的物理旧操作。看到如此大量的IO操作或争用时.你常常会忍不住用优化磁盘布局的方法直接清除这个症状。不过，如果按照层级的顺序来安排调优工作，更有可能抓住问题的根本，并在更低层级上化解性能问题。