Oracle数据库优化技术详解

1、Oracle数据库优化技术详解技术创新，变革未来智慧IT010203目 录Contents基于方法论（OWI）的优化方法详解ORACLE优化工具基于命中率的优化方法01传统数据库的分类DB-Engines 发布了 2018 年 4 月份的数据库排名，排名前 三的依然是 Oracle、MySQL 和 Microsoft SQLServer 。前 20 名的数据库中，本月 排名出现上升的有 Elasticsearch ，从上个月的 第 9 名上升至第 8 名。 MariaDB 数据库从上个月的 15 上升到 14 名。01常规诊断性能问题性能突变整体慢部分慢操作系统资源使用是否 正常（cpu,内存

2、使用率， 磁盘，网络延迟是否正 常。）是否锁等待、sql执行计 划异变。业务、程序、数据库 是否有调整收集并分析故 障和正常时期 的awr报告优化sql并或调整应用是否硬件或 者网络故障修理硬件异常会话持有锁未释放杀掉异常会话数据库性能问题最 直观的表现就是响 应时间变慢01什么是方法论SGARedo log buffer cacheShared poolLibrarycacheData Dict. cacheInstancePMONSMONDBWRLGWRCKPTOthersUser processServerprocessPGAControl filesData filesArchived

3、log filesParameterfilePassword fileRedo log filesDatabaseDatabase buffer cache01什么是方法论Oracle InstanceAn Oracle instance:Is a means to access an Oracle databaseAlways opens one and only one databaseConsists of memory and process structuresBackground structuresMemory structuresSGARedo log buffer cache

4、Database buffer cacheShared poolLibrary cacheData Dictionary cacheInstancePMONSMONDBWR LGWRCKPTOthers01数据库优化方法论1基于局部命中率分析的性能优化方法3基于流程分析和响应时间的性能优化方法论Oracle数据库经过十数年的发展，已经被很多的企业所应用， 整体机制已逐渐完善，针对Oracle数据库优化的方法也经过 数据库运维人员不断的改进逐渐形成了完整的体系。下面罗 列Oracle数据库的各种优化方法：2基于资源瓶颈分析的性能优化方法论4基于OWI的性能优化方法01什么是基于命中率？基于命中率

5、的优化即为根据响应的命中率指标，对命中率涉及的区域进行重点优化01什么是基于命中率？基于命中率调优的方法的局限性和不足：命中率分析仅仅关注和作用于自身，不关心外部信息。命中率分析方法通过全局平均和模糊了个体，而大部分性能问题都是基于个体的。简单说：不是低命中率数据库就一定有问题 不是高命中率数据库就一定没问题01基于资源瓶颈的性能优化Oracle要做优化，大部分人首先就 会想到瓶颈在哪里？资源瓶颈分析是 如此之普及，以至于无论懂还是不懂 的人都知道瓶颈这个术语，都知道性 能优化首先要找到这个瓶颈，然后消 除这个瓶颈。数据库系统的资源主要 包括：CPU、内存和虚拟内存、I/O 子系统、网络子系统

6、。CPU资源内存资源I/O资源01基于资源瓶颈的性能优化CPU资源：CPU资源是否紧张我们可以通过检查CPU的利用率及等待运行的进程数来了解，一般来 说CPU 的运算速度主要受主频和高低缓存大小的影响。OLAP系统由于进程数量少，所以其性能和CPU的频率关系较大。OLTP系统由于进程数量多，所以其性能和CPU的数量关系较大。Oracle会根据系统的CPU数量自动调节参数（CPU_COUNT）和进程数量（LMS进程等）。提示：CPU使用率不是越低越好，我们需要做到的是，在不出现资源阻塞的情况下，充分发挥CPU资源的能力01基于资源瓶颈的性能优化CPU资源紧张的征兆：操作系统IDLE很低，等待队列

7、很高可以通过vmstat,top/topas等工具观察01基于资源瓶颈的性能优化CPU资源紧张原因:SQL执行计划异常,大量全表扫描latch（内存锁）或者mutex争用高并发的SQL解析CPU硬件资源不足bug01基于资源瓶颈的性能优化内存资源操作系统内存消耗主要用 于数据库（SGA）和进程 消耗（PGA）,为计算型内 存资源。01基于资源瓶颈的性能优化SGA和PGA分配规则SGA(共享全局区域）是一块大的共享内存区域，主要用于缓冲数据块，存放SQL解析记 录，数据字典信息和日志条目。PGA（进程全局区域）平均每个进程消耗内存5MB左右内存。OLTP数据库：高并发，实时响应SGA=系统内存7

8、0%80%， PGA=SGA (10%20%)OLAP数据库：低并发，批业务SGA=系统内存80%60%， PGA=SGA (45%65%)01基于资源瓶颈的性能优化内存不足的症状系统产生大量交换，进一步可能导致本地硬盘100% 繁忙严重情况下，会导致系统无法响应（登录）。在RAC中，由于进程长时间得不到内存派生，则容易引起脑裂（Brain split）01基于资源瓶颈的性能优化内存不足常见的原因:SGA设置过大操作系统参数设置不合理，如AIX 5L的maxperm%大量的连接进程PGA异常增长RMAN备份内存硬件资源不足bugAIX 5L的maxperm参数设置01基于资源瓶颈的性能优化存储

9、优化吞吐量和IOPS是考察存储性能的两个主要指标。传统存储的最终瓶颈在于磁盘寻道时间， 转速越快，磁盘数量越多，存储性能越高。固态硬盘是很重要的里程碑，是解决磁盘瓶颈的重要技术。01基于资源瓶颈的性能优化存储异常症状硬件错误，如存储不可写。这类错误往往会在警告日志错报错。存储性能缓慢，该类错误需要DBA预估值，相对比较难发现。01基于资源瓶颈的性能优化导致IO性能的原因分析SQL执行计划异常，如大量的全表扫描。DB CACHE配置不合理（过小）。异步I/O参数配置不足。存储硬件配置不足。条带设计不合理。访问热点。BUG。硬件错误磁盘队列深度不足硬件本身如转速较低01基于资源瓶颈的性能优化木桶原

10、理：“木桶效应”指的是一个由长短 不同的木板组成的木桶，决定其 水容量的大小的并非木桶中最长 的一块木板或者所有木板的平均 值，而是取决于最短的那块木板01基于资源瓶颈的性能优化案例：SGA参数设置过大，导致系统交换严重某客户业务高峰期经常出现性能问题，主要表现为latch: library cache和latch:shared pool，重启无效，如图1所示。经过检查，发现系统有较多的swap in/out产生。经分析， 果断将数据库参数sga_max_size和shared pool设小，系统恢复正常，如图2所示。如果 此时去分析shared pool各类组件，可能就耗时了优化前优化后01

11、基于资源瓶颈的性能优化基于资源瓶颈分析的优化方法论具有以下局限性：充分的资源并不能保证业务系统具备高性能。资源之间的瓶颈会相互转化，CPU瓶颈的消失会导致I、O瓶颈，内存瓶颈的消 失会导致CPU瓶颈。资源利用率过高是性能不佳的滞后性指标表现，它只是其他藏在后面的真实原 因的最后表现（治标不治本）。01基于资源瓶颈的性能优化场景描述一：一个大量行锁冲突的系统，可以发现冲突严重的时候CPU和I/O会极度空闲，而这个时候业务 会几乎挂起。场景描述二：一个高吞吐量事务提交的系统，可以发现整体I/O资源空闲，某块磁盘I/O特别紧张，你会发现无法利用大量空闲的I/O资基源于。OWI的优化方法论场景描述三：

12、 一个资源极为空闲的系统，系统吞吐量不佳，而且发现就是无法增加资源利用率以提高系统吞吐量。场景描述四：一个资源空闲的系统，响应时间总是无法满足。01基于OWI的优化方法论OWI，Oracle Wait interface的简称。最开始OWI并不是为了性能优化而出现的， 而是出于调试的目的，用来明确当前正在发生什么事情，在Oracle 7中它就已经 以初级的方式存在了。当Oracle 8i极其明确地把OWI引入性能优化时，数据库 性能优化方法论就出现了划时代的飞跃，在Oracle的性能优化，OWI的重要性 再怎么强调都不过分。OWI跳出部件构成性能的视野，以一个旁观者的角度或者业务流程的角度来

13、考虑问题01基于OWI的优化方法论OWI方法是快速优化Oracle性能的最有效方式，OWI的精准定位使性能优化不再需要到处 进行衡量。某种程度上，OWI方法论类似于故障处理的思路，处理焦点在局部，使优化者 不需要了解业务流程，不需要进行全局流程的协调，降低了对性能优化者的能力要求。方向过于局限，适合处理紧急性能优化，不适合解决大型数据库的渐变性 能和复杂性能问题01基于OWI的优化方法论1.基于Session的Oracle Wait Event实时以及统计信息当前实时的Wait Event信息：v$session、 v$session_wait、v$session_wait_class最近10

14、次的Wait Event信息：v$session_wait_history100ms到秒级别的快照信息：v$active_session_history时间范围快照：wrh$_active_session_history抽样：dba_hist_active_sess_history启动以来的事件统计信息：v$session_event01基于OWI的优化方法论基于对象的Oracle Wait event的信息启动以来对象的实时统计信息：V$SEGMENT_STATISTICS时间范围快照：WRH$_SEG_STAT3.基于实例|全局的Oracle Wait event的信息分钟级别的实时统计信

15、息：v$eventmtric、v$WAITCLASSMETRIC基于时间范围快照的统计信息： wrh$_system_event 、 wrh$_bg_event_summary 、DBA_HIST_WAITSTAT启 动 以 来 的 事 件 统 计 信 息 ： v$system_event 、 $SYSTEM_WAIT_CLASS 、V$SERVICE_EVENT01基于OWI的优化方法论基于SQL的等待事件描述实时的事件信息：v$session实时的事件信息：v$sql_monitor100ms1s级别的事件信息：v$active_session_history基于快照和抽样：wrh$_ac

16、tive_session_history、dba_hist_wait_history、wrh$_sqlstat启动以来的统计：v$sql, v$sqlarea，v$sqlstat01基于OWI的优化方法论Oracle 10gR2共有12个事件分类，合计事件数量：874个（如图2-2所示）。01基于OWI的优化方法论Oracle 11gR2共有13个事件分类，合计事件数量：1116个（如图2-3所示）。01基于OWI的优化方法论OWI ORACLE WAIT INTERFACE:等待事件 ORACLE 7 :104个ORACLE 8:140个，ORACLE 8I:220 ORACLE9I:400

17、ORACLE10G:800 ORACLE11G:1367 ORACLE12c:1811ORACLE18c:188401基于OWI的优化方法论OWI ORACLE WAIT INTERFACEOWI是面向问题的OWI是定量的OWI是征兆学的OWI是不断进步完善的OWI 最强有力的表现形式-AWR报告01基于OWI的优化方法论基于OWI的优化方法论中的等待事件详解01基于OWI的优化方法论OWI事件之高速缓冲区什么是高速缓冲区（buffer cache） 相关等待事件：Latch cache buffer chainsLatch cache buffer lru chainsBuffer busy

18、 wait/read by other session 4.Write complete waits5.free buffer waits01基于OWI的优化方法论OWI事件之高速缓冲区Is part of the SGAHolds copies of data blocks that are read from data filesIs shared by all concurrent usersPMONARCnRECOOthersDBWnLGWR SMONCKPTDatabase buffer cacheShared poolData dictionary cacheLibrary cac

19、heSGARedo log bufferShared Pool01基于OWI的优化方法论01基于OWI的优化方法论latch：cache buffers chains：保护Hash Chain 在扫描特定块的进程，必须先获取相应的CBC latch，多个进程同时检索buffer 发生争用， 在此过程中等待CBC latch备注：oracle 9i开始对于只读操作，允许cbc latch 以只读获取，而对于buffer 获得和释放buffer block 时候， 则需要以独占模式获取一个cbc latch 只能同时被一个进程获取一个cbc latch 能够同时管理多个hash chain一个ha

20、sh chain 只能被一个cbc latch管理问：在执行只读过程中，是否可能发生cbc latch01基于OWI的优化方法论latch：cache buffers chains 形成的原因：低效的SQL语句：低效SQL是发生cbc latch 争用的最重要也是最主要的原因， 多个进程同时扫描大范围的索引或者表解决思路：优化SQL热块争用：块被频繁的读取写入导致的争用解决思路：针对表：打散热块：赋予较高的pctfree，或者对表做hash 分区 针对索引：提高pctfree01基于OWI的优化方法论LRU列和LRUW列组成一个 working Set oracle中包含多 个工作组，一个ca

21、che buffers lru chain 管理一个工 作组LRU（替换列）：-主列：已经使用的缓存区-辅助列：空闲缓冲区LRUW（记录列）：-主列：已修改的缓冲区列-辅助列：当前通过dbwr写入的缓冲区列Oracle通过cache buffer lru chain 来管理所有的工作组01基于OWI的优化方法论latch：cache buffers LRU chains 形成的原因：低效的SQL语句：低效SQL是发生cbc latch 争用的最重要也是最主要的原因，多个进程同时扫描大范围的索引或者表解决思路：优化SQL备注：latch cbc 和latch cblruc 不一样，如果多个会话同

22、事扫描一个表或者多个表，则发生cbc latch争用的概率会非常高 因为是对相同的一个chain发生了争用，但是多个会话同时扫描不同的表或者索引，则发生cbc lru latch 的等待会高很多， 因为多个会话将各不相同的会话载入到内存中，空闲内存的申请将会大大增加，争用也会更加明显。Cache buffer LRU chains 锁争用的另一个现象就是伴随着非常高的物理IO。 低效索引扫描：1.db file sequential read和lru latch争用不必要的全表扫描：db file scattered read 和lru latch 争用01基于OWI的优化方法论缓冲区检索：获

23、取CBC latch共享、独占检索hashchain确认块获得bufferblock共享、独占块存在争用Buffer busywaitWrite complete waits逻辑读成功获取cache buffer lru chainCBC lru chain等待失败读取空闲块检索空闲块失败读入数据块等待latch cbcRead by other session01基于OWI的优化方法论Buffer busy wait 形成的原因：假设row 1 和row 2 位于同一个块中，块已经在内存中，两个不同的用户分别对两行数据做update当以 独占模式获得buffer lock锁的过程，即等待Bu

24、ffer busy waitRead by other session形成的原因：假设row 1 和row 2 位于同一个块中，块不在内存中，两个不同的用户分别对两行数据做update当把块读到内 存中时候，需要获取buffer lock 过程中发生争用，即等待read by other session01基于OWI的优化方法论OWI事件之Shared PoolPMONSMONOthersInstanceRECOARCnDBWnLGWRCKPTShared SQL areaLibrary cacheData dictionary cacheOtherDatabase buffer cacheS

25、hared poolData dictionary cacheLibrarycacheSGARedo log bufferIs a portion of the SGA Contains:Library cacheShared SQL area 3.Data dictionary cache 4.Control structuresShared pool 中，最具代表性的即为 library cache和row cache ，对于共享池 Oracle采用堆形式管理01基于OWI的优化方法论OWI之库高速缓冲区什么是库高速缓冲区管理SQL语句的执行相关的所有信息区域最关键相关等待事件： Latc

26、h:shared_pool Latch:library cacheLibrary cache lock/library cache pin01基于OWI的优化方法论OWI事件之行高速缓冲区什么是行高速缓冲区 相关等待事件：Row cache lockenq:SQ-contention 3.DFS lock handle01基于OWI的优化方法论执行SQL语句语句是否 在库高速 缓存中是不是数据块是 否在缓冲 区中进行软解析进行硬解析执行生成的执 行计划运算数据读取磁盘数据不是是Library cache pinLatch shared poolLibrary cache lock01基于OWI

27、的优化方法论Shared pool 中最重要的 latchsharedpoolLatchshared pool：保护shared pool 中的内存堆：检索空闲列，查找free chunk分配适当的chunk 分割空闲的chunk特点：唯一的，不存在多个最容易发生的场景：过多的硬解析，shared pool 碎片严重解决思路：尽量采用绑定变量01基于OWI的优化方法论Shared pool 的子池概念Oracle 从9i开始，采用子池管理模式，即一个共享池被分割成多个子池管理，子池作 为独立的共享池，具有独立的空闲列，LRU列，shared pool latch等_kghdsidx_count

28、参数控制子池数量Oracle 10g开始为了更加缓解latch shared pool 又将子池划分为多个mini heap-perm类型的内存块只存在于每个sub pool的第1个min heap中Oracle在启用了SGA自动管理的模式下，为了便于在shared pool与buffer cache或其他内存之间动态调整大小，规定 了在每一个mini heap中分配内存按照duration来进行。perm类型的内存块，就是分配后不能释放，只能用于相同组 件的重用。比如gcs resources这种组件的内存是perm类型，这种内存被分配后，只能给其他的gcs resource使用。 按DUR

29、ATION分配内存时，perm类型的内存就只能从每个sub pool的第1个mini heap中分配。而其他类型的内存通常在 sub pool的第2-4个mini heap中分配。由于perm类型的内存不能释放，也不能被其他组件的内存重用，所以里面的内 存会越用越少参考文档01基于OWI的优化方法论Library cache lock 和library cache pinLibrary cache lock：访问或修改库高速缓冲区的对象时候，对于对象句柄锁的获取过 程中发生争用，则等待library cache lockLibrary cache pin：访问或修改库高速缓冲区的对象时候，对于

30、对象内容读取获取过 程中发生争用，则等待library cache pin访问对象时，首先必须获取handle上的lock，然后将访问的数据pin在内存中。lock的 作用是控制进程间的并发访问，而pin的作用是保证数据一致性，防止数据在访问时 被交换出去简单说：library cache lock 保护LCO（library cache object）Library cache pin 保护LCO内容为什么对于LCO对象不采用一个锁，而需要采用两个？01基于OWI的优化方法论在业务高峰期尽量避免编译存储过程在业务高峰期尽量避免执行ddl语句在业务高峰期尽量避免添加数据文件大量的library

31、 cache lock等待事件大量的cursor失效大量的lock冲突。01基于OWI的优化方法论OWI事件事务上的等待事务运行过程中可能的等待：1.enq:TM-contention 2.enq:TX-row lock contention3.enq:TX-allocate ITL Entry 4.enq:TX-index contention01基于OWI的优化方法论OWI事件段上的等待段在数据库运行过程中可能的等待：1.enq:HW-contention 2.enq:ST-contention3.enq:TT-contention 4.enq:US-contention01基于OWI的优

32、化方法论OWI事件IO上的等待体现在IO上的等待： 1.db file scattered read 2.db file sequential read 3.Direct path read 4.Direct path write5.db file parallel write 6.Control file parallel write01基于OWI的优化方法论OWI事件在重做缓冲区上的等待体现在REDO上的等待1.latch:redo writing,latch:redo allocation,latch:redo copy 2.Log file sync3.Log file paralle

33、l write 4.Log buffer space5.Log file switch completion,log file switch,checkpoint incomplete01基于OWI的优化方法论Log file sync -最有意思的等待事件磁盘IO 慢导致LGWR进程将redo buffer的信息写入redo log file速度慢。事务过度的提交，即应用程序过度commit或者rollback本地或者远程服务器CPU资源不足，导致LMS和/或者LGWR不能及时得到CPU调度，不能正常工作。RAC私有网络进程LMS同步commit SCN慢。RAC节点之间CR块传递。控制文件

34、争用ORACLE BUG.一次 log file sync 分析01基于OWI的优化方法论OWI事件在网络上的等待体现在REDO上的等待1.SQL*Net message from/to client 1.SQL*Net more data from/to client1.SQL*Net message from/to dblink 1.SQL*Net more data from/to dblink010203目 录Contents基于方法论（OWI）的优化方法详解ORACLE优化工具基于命中率的优化方法01详解ORACLE性能优化工具自动化性能优化工具自动化性能优化是一个趋势。但是Orac

35、le的建议只能当做一个工具。在越来越自动化的今天，对DBA要求其实更高了。01详解ORACLE性能优化工具性能优化的三大利器AWR(Automatic Workload Repository)AWR是Oracle 10g中的一个新特性，类似于10g以前的statspack。不过在使用上要比 statspack简单，提供的性能指标要比statspack多很多，能更好的帮助DBA来发现数据库的性能瓶颈ASH (Active Session History)ASH以V$SESSION为基础，每秒采样一次，记录活动会话等待的事件。不活动的会话不会采样，采样工作由新引入的后台进程MMNL来完成$ORAC

36、LE_HOME/rdbms/admin/rdbms/ashrpt.sqlADDM (Automatic Database Diagnostic Monitor AWR)是Oracle内部的一个顾问系统，能够自动的完成最数据库的一些优化的建议，给出SQL的优化，索引的创建，统计量的收集等建议01详解ORACLE性能优化工具什么是AWRAWR (Automatic Workload Repository)一堆历史性能数据，放在 SYSAUX 表空间上， AWR 和 SYSAUX 都是 10g 出现的，是Oracle 调优的关键特性；大约 1999 年左右开始开发，已经有 15 年历史默认快照间隔

37、1 小时， 10g 保存 7 天、 11g 保存 8 天; 可以通过DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS 修改AWR 程序核心是 dbms_workload_repository 包 运行脚本：?/rdbms/admin/awrrpt 本实例?/rdbms/admin/awrrpti RAC 中选择实例号手动执行一个快照：exec dbms_workload_repository.create_snapshot;01详解ORACLE性能优化工具详解AWR使用方法生成报告命令：SQL?/rdbms/admin/awrrpt.sql-普

38、通AWR报告 SQL?/rdbms/admin/awrgrpt.sql-采集RAC集群报告SQL?/rdbms/admin/awrrpti.sql-采集RAC二节点报告报告汇总信息，涵盖最基本也是最直观的AWR新能信息， 包括内存配置，参数指标，数据库命中率，等待事件等高负载SQL，按CPU 处理时间，逻辑读，物理读，执行次 数，解析次数，高版本等多个方面展现数据库高负载SQL数据库指标统计，涵盖IO，内存advisory，等待事件，undo统计，latch 统计参数文件内容，包括各种系统参数，隐含参数，event等 的设置01详解ORACLE性能优化工具详解AWR使用方法01详解ORACLE

39、性能优化工具Load Profile部分指标定义redo size单位 bytes， redo size 可以用来估量 update/insert/delete 的频率，大的 redo size 往往对 lgwr 写日志，和 arch 归档造成 I/O 压力， Per Transaction 可以用来分辨 是 大量小事务， 还是少量大事务。如上例每秒 redo 约 1MB ，每个事务 800 字节，符合 OLTP 特征Logical Read单位 次数*块数，逻辑读耗CPU，主频和 CPU 核数都很重要，逻辑读高则 DB CPU 往往高，也往往可以看到 latch: cache buffer

40、chains 等待。 大量 OLTP 系统 (例如 siebel)可以高达几十乃至上百 GbytesBlock changes单位 次数*块数，描绘数据变化频率Physical Read单位次数*块数，物理读消耗 IO 读，体现在 IOPS 和吞吐量等不同纬度上；但减 少物理读可能意味着消耗更多CPU。好的存储每秒物理读能力达到几GB，例如Exadata。 这个physical read 包含了 physical reads cache 和 physical reads direct01详解ORACLE性能优化工具Load Profile部分指标定义Physical writes单位 次数*块

41、数，主要是 DBWR 写 datafile，也有 direct path write。 dbwr长期写出慢会导致定期 log file switch(checkpoint no complete) 检查点无法完成的前台等待。 这 个 physical write包含了 physical writes direct +physical writes from cacheUser Calls单位次数，用户调用数， more details from internalParses解析次数，包括软解析+硬解析，软解析优化得不好，则夸张地说几乎等于每秒 SQL 执行次数。 即执行解析比 1:1，而我们希

42、望的是 解析一次 到处运行哦！Logons登陆次数， logon storm 登陆风暴，结合 AUDIT 审计数据一起看。短连接 的附带效应是游标缓存无用Executes执行次数，反应执行频率01详解ORACLE性能优化工具Load Profile部分指标定义Rollback回滚次数， 反应回滚频率， 但是这个指标不太精确，参考而已，别太当真Transactions每秒事务数，是数据库层的 TPS，可以看做压力测试或比对性能时的一个 指标，孤立看无意义% Blocks changed per Read每次逻辑读导致数据块变化的比率；如果redo size, =block changes =pc

43、t of blocks changed perread三个指标都很高，则说明系统正执行大量 insert/update/delete;pct of blocks changed per read = (block changes ) /( logical reads)Load Profile,负载指标 在本环节提供了2个维度per second 和per transactionper Second:主要是把快照内的delta值除以快照时间的秒数，是我们审视数据的主要维度， 任何性能数据脱离了时间模型则毫无意义。per transaction : 基于事务的维度， 与 per second 相比

44、 是把除数从时间的秒数改为了该段时间内的事务数01详解ORACLE性能优化工具命中率部分：上述所有指标的目标均为 100%，即越大越好，在少数 bug 情况下可能超过 100%或者为负值Buffer Nowait % 会话申请一个 buffer(兼容模式)不等待的次数比例。 需要访问 buffer 时立 即可以访问的比率，不兼容的情况在9i 中是buffer busy waits，从 10g 以后 buffer busy waits 分离为 buffer busy wait 和 readby other session2 个等待事件buffer HIT%: 经典的经典，高速缓存命中率，反应物理

45、读和缓存命中间的纠结，但这个指 标即便 99% 也不能说明物理读等待少了01详解ORACLE性能优化工具Redo nowait%: 会话在生成redo entry时不用等待的比例，redo 相关的资源争用例如redo space request 争用可能造成生成redo 时需求等待。此项数据来源于v$sysstat 中的(redo log space requests/redo entries)，一般来说10g 以后不太用关注log_buffer 参数的大小，需要关注是否有十分频繁的 log switch ，过小的 redo logfilesize 如果配合较大的 SGA 和频繁的 commi

46、t 提交都可能造成该问题。 考虑增到 redo logfile 的尺寸 : 14G 每个，710 组都是合适的。同时考虑优化 redo logfile 和 datafile 的 I/OIn-memory Sort%:这个指标因为它不计算 workarea 中所有的操作类型，所以现在越来越鸡肋了，纯粹在内存中完成的排序比例。Library Hit%: library cache 命中率，申请一个library cache object 例如一个 SQL cursor 时，其已经在library cache 中的比例Soft Parse: 软解析比例，无需多说的经典指标Execute to Par

47、se% 指标反映了执行解析比其公式为 1-(parse/execute) , 目标为 100% 及接近于只执行 而不解析01详解ORACLE性能优化工具命中率部分：Latch Hit%: willing-to-wait latch 闩申请不要等待的比例。Parse CPU To Parse Elapsd:该指标反映了 快照内解析 CPU 时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time)； 若该指标水平很低，那么说明在整个解析过程中实际在 CPU 上运算的时间是很短的，而主要的解析时间都耗费在各种其他非空闲的等待事件上了%Non-Parse CPU 非解析cpu 比例，公式为 (DB CPU Parse CPU)/DB CPU， 若大多数 CPU 都用在解析上了，则资源存在没有合理利用现象01详解ORACLE性能优化工具TOP等待部分：01详解ORACLE性能优化工具时间模型部分：parse time elapsed、