如何解读执行计划(下)

与IO有关等待在两方面是否有问题：
1. IO速度是不是慢，导致我们IO等待。
2. 做某一个操作时候，它还没有完成。
3. 是不是对数据库做了很多无效IO操作。
4. IO等待次数是不是相对应用规模是否太多。例如：读了10条记录，确来1千万IO等待，这是不正常的。因为至少1千万个IO请求，最好情况发起10次IO请求。这种情况，数据访问路径出现了问题（可能缺失索引）。
Tablespace IO Stats（Av Rd(ms)）延迟：读之前，存储响应它的请求花了多长时间。数据库把这个IO请求发给OS，OS返回说存储已经接受IO请求这个时间。
对于 Tablespace IO Stats来讲，平均延迟高、读的次数高说明存在IO性能问题，同时SQL Statistics也适用这个方法（SQL执行频繁，buffer gets高）。对于比较空闲表空间、数据文件可能得到比较大的读延迟的值（Av Rd(ms)），对于这种情况应用忽略这个表空间、数据文件性能没问题。因为，这个很大值可能因为硬盘自寻引起的，并没有太大参考意义。它既然满足了高延迟，但是它不满足这个表空间所在数据文件读写次数多。
诀窍是能够评估引起这些等待的语句是否使用了最优的访问路径。
SQL是否有性能问题也适用IO分析方法：
1. SQL执行要频繁
2. 每一次执行相关指标要高（buffer gets）
例如：1张表1G，而每次执行获取buffer块数乘以8K，已经超出了1G，可能存在性能问题。Total Buffer Gets: 4,745,943,815 乘以 8K，大约4T，如果数据库没有这么大，说明sql性能存在问题。
load profile说明数据库整体负载情况，Recursive Call %：99.19代表执行调用这个命令时候它并没有解析，而是去执行了，这就是我们所说的软解析。
Redo size：
Per Second(每秒)产生4,585,414.80，四百万redo块，乘以512K，大约每少产生2G。
Per Transaction(每事物)产生3,165,883.14，三百万redo块，说明数据库在运行大事物。
Instance Efficiency：
Buffer Nowait：请求某个buffer没有产生等待，通常情况下达到95%以上就很好了。
Buffer Hit：想要读取的数据有多少是在buffer cache里面被读到。
No-Parse CPU：99.00：说明99.00% SQL在执行（此参数最有用）。
DBA_HIST_WR_CONTROL
DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
如果latch相关等待很严重，那么我们需要查看latch sleep breakdown里面sleeps是不是很高。对于一个进程如果抢不资源就要sleep，过了多少毫秒以内，这个sleep进程被唤醒，然后再次去抢这个资源等等。 通常在top 5里面看到latch有关的，这个系统cpu使用率肯定非常高。换句话说，我们在某个时间内，出现latch有关等待session数达到我们物理cpu数的话，我们系统cpu就会达到百分之百，而且这个百分之百基本上所有都在top、topas里面看到属于us%在使用。