Oracle性能调：一种.docVIP

Oracle性能调优：一种系统化方法 Oracle性能调优已经出现好多年了，但多数时候仍然以一种杂乱无章或者低效的方式在进行着。先看看下面这个警示故事。 有个关键的业务系统出现了性能问题。作为一名富有经验的Oracle性能专家，你被请来诊断这个问题。你首先检查了数据库的等待时间，以了解数据库大部分时间都在做什么。稍后我们将看到，通过查询视图v$system_event与v$sys_time_model，可以轻松得到这些信息。 通过查看这些视图，你发现了两个问题。第一，读取磁盘设备花费了最多的数据库时间。第二，从磁盘读取数据块耗费的平均时间大大超过你对硬盘的预期。 你猜，可能是磁盘阵列没有足够的IO带宽来满足应用需要。也就是说，磁盘阵列的物理磁盘数目不足以支持所需的IO速度。经过快速的计算，你建议将磁盘数量扩容四倍。除了耗费不菲的美金，以及将数据分配到新磁盘所需的宕机时间。尽管如此，事情仍然得做，因此管理层认可了这笔花销以及相对应的宕机时间。扩容完成之后，用户反馈说他们对性能很满意，你也谦虚地接受了所有的赞扬。 升级很成功？你认为是，但…… 没过几个月，性能问题又出现了，磁盘IO仍然是罪魁祸首。 公司请来了另一位Oracle性能专家，他认为修改一下索引就可以解决原来的问题，一分钱不用花也不用系统宕机。 新索引创建好之后，IO请求降低到你最初被请来时观察到的1/10。管理层准备在eBay上卖掉富余的磁盘设备，并且给你的咨询记录打上“不再续聘”的标签。 你的恋人离开了你，嫁给了一名Oracle销售人员。最后，你剃度做了和尚。 经过几年的苦思冥想，你终于明白，自己已经正确地找出了数据库里最耗费时间的活动，然而却没有分清什么是因什么是果。所以，你错误地去处理这个结果——高的IO请求率，而忽略了真正的原因——索引的缺失。 本章将介绍一种方法，确保你将精力集中在导致Oracle性能问题的根源上。这样可以避免重复地试错（大量性能调优工作都是在试错），并确保在调优过程中能获得最大的性能提升。 1.1　Oracle性能调优简史 在20世纪90年代早期，Oracle数据库调优并不像今天这么有章法。事实上，那时的性能调优仅限于几条知名的“经验准则”。 这些准则中最泛滥的当属“应该优化缓冲区高速缓存命中率”（Buffer Cache Hit Ratio）。这个命中率是指在内存中找到SQL语句请求的数据块（相匹配的数据块）的比例。如果请求了10个数据块，其中9个可以从内存中找到，那么命中率就是90%。最常见的建议标准是，提高缓冲区高速缓存的大小，直到命中率达到90%或者95%。其他一些比例，如闩锁（Latch）命中率，也有类似的建议标准值。 “基于命中率”的技术虽然反映了Oracle内部的效率问题，但这些命中率与使用数据库的应用的性能问题关系并不密切。例如，虽然在内存中找到对应的数据块明显更好（更高的命中率），但是SQL语句反复低效地访问同一个数据块通常也会带来更高的命中率。实际上，非常高的命中率常常是SQL调优水平太差的一个征兆。 Oracle版本7.1中出现的等待事件接口提供了另一种性能调优的方法。这些等待信息显示出Oracle会话等待几个不同事件所花费的时间，如等待锁变得可用或者磁盘IO完成。通过集中分析在总等待时间中占比最大的等待事件，可以更有效地完成优化。 系统化Oracle性能调优的先驱们，包括Anjo Kolk——著名的另一种性能剖析方法”（YAPP，Yet Another Performance Profiling）方法论的作者，都力挺这一技术。 基于等待事件的调优技术从出现到变成主流，经过了非常长的时间：从等待事件接口的最初发布，到这项技术被广泛接受，差不多用了5~10年。虽然现在几乎所有Oracle专业人员都很熟悉基于等待事件的优化方法。 1.2　超越表面分析法 从基于命中率的优化方法转向基于等待事件的优化方法，显著地提升了我们诊断和优化Oracle应用的能力。然而正如前面提到的，一味关注响应时间长的组件，可能导致下面几个不良后果。 治标不治本。 更倾向于选择硬件方案，而非更划算的调整配置或应用。 只顾眼前，忽视长远及可扩展能力。 为了规避基于等待事件调优的隐患，需要明确几个阶段。这几个阶段是由应用、数据库、操作系统的交互方式决定。总体来看，数据库进程按照下面几个层次运行。 (1) 应用以SQL语句的形式向数据库发出请求（包含PL/SQL请求）。数据库响应这些请求，并返回对应的返回码与结果集。 (2) 为了处理应用请求，数据库必须解析这条SQL语句。在最终执行它之前，还需要完成多个额外操作（安全、调度及事务管理）。这些操作要用到操作系统资源（CPU和内存），可能会受并发执行的数据库会话之间争用的限制。 (3) 最后，这些数据库请求还