@?/rdbms/admin/awrrpt.sql
http://blog.itpub.net/31397003/viewspace-2138943/
等待事件（入口）-->db file sequential read （如果时间比较久排名靠前）-->索引 -->I/O问题 -->SQL语句
思路：面-->线-->点
DB Time 大于Elapsed Time，是因为它是所有用户执行时间总和。
Instance Efficiency Percentages (Target 100%)
本节包含了Oracle关键指标的内存命中率及其它数据库实例操作的效率。其中Buffer Hit Ratio 也称Cache Hit Ratio，Library Hit ratio也称Library Cache Hit ratio。同Load Profile一节相同，这一节也没有所谓“正确”的值，而只能根据应用的特点判断是否合适。在一个使用直接读执行大型并行查询的DSS环境，20%的Buffer Hit Ratio是可以接受的，而这个值对于一个OLTP系统是完全不能接受的。根据Oracle的经验，对于OLTPT系统，Buffer Hit Ratio理想应该在90%以上。
Buffer Nowait%表示在数据缓冲区中获取的buffer时，未进行等待的比率，越高越好。
buffer hit%表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般的OLTP系统，命中率通常在95@以上，如果此值低于80%，应该给数据库分配更多的内存，考虑加大db_cache_size。在数据仓库OLAP环境中，数据缓冲命中率不是一个重要的指标，因为OLAP数据库主要是物理读，甚至是直接读，该命中率不可能高。
Redo NoWai%t表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。
library hit%表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。Sql语句在库缓冲中能否找到相应的解析计划，如果library hit ratio低于90%，可能需要调大shared pool区，或检查是否有硬编码现象。
Latch Hit%：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可,表示内部结构维护锁命中率。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。
Parse CPU to Parse Elapsd：表示解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。在实际繁忙的系统中，该值可能因为等待资源而不会太高。
Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。说明解析时间所占比率过高，需要考虑提高sql语句重用性。
Execute to Parse：是语句执行与分析的比例,表示sql语句解析后被重复执行的命中率，计算公式=100*（1-Parses/Executions）,如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，根据实际情况，可以考虑调整session_cached_cursors参数，有些报告中这个值是负的，看上去很奇怪，事实上这表示一个问题，sql如果被age out的话就可能出现这种情况 ，也就是sql老化，执行alter system flush shared_pool
如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。
Soft Parse%：SQL语句软解析占整个分析的命中率，如果低于95，需检查是否有硬编码现象，如果低于80，说明sql语句基本没有重用性=soft/(soft+hard)
In-memory Sort：在内存中排序的比率，即有多少排序在内存中进行的，如果过低说明有大量的排序在临时表空间中进行，性能肯定不好，考虑调大PGA参数，sort_area_size。
Soft Parse：软解析的百分比（softs/softs+hards），近似当作sql在共享区的命中率，太低则需要调整应用使用绑定变量。
SQL Statistics
SQL ordered by Elapsed Time：记录了执行总时间最长的Top SQL，其中Elapsed Time = CPU Time + Wait Time
-------------------------------------------------------------------
CPU Time 指的是CPU在忙于执行当前任务的时间，其并没有考虑等待时间，如IO等待，网络等待等，而Elapsed Time 则是执行当前任务所花费的总时间，也就是说这两者之
问的关系统可以表示为：Elapsed Time = Cpu Time + Wait Time 但是在多核处理器的情况下，由于多个CPU同时处理任务所以可能会出现Cpu Time 大于Elapsed Time 的情况
- CPU Time：对于单线程程序来说，CPU TIME指的是该线程在一个逻辑处理器（单核）上所花费的时间总量；对于多线程程序来说，CPU TIME指的是所有线程的CPU TIME之和；应用程序的CPU时间指的是该程序所有线程的CPU TIME之和。
- Wait Time：特定线程等待一定事件发生的时间，这些事件可以是同步等待，I/O等待。
- Elapsed time:该程序运行的平台时间，即：应用程序结束的时刻-应用程序起始时刻。
通过下面这个例子能够更好的说明几个概念之间的区别：
从这张图中，我们可以看到一共有三个线程，Thread1，Thread2，Thread3，其分别的起始时刻为0,1,2。则统计：
- Elapsed time: 程序共执行6秒，故Elapsed time为6sec；
- Cpu time:对于多线程程序，其cpu time为所有线程时间之和，故cpu time=1+3+2+2=8sec;
- Wait time：等待时间，故wait time=2+3+2=7sec;
值得注意的是：Elapsed
time, Cpu time, Wait time这三者并没有大小关系，比如并不一定elapsed time就一定大于cpu time；
总结一下：
- 对于单线程程序，cpu time, wait time可能或等于elapsed time。
- 对于多线程程序，elapsed time有可能比另外二者大，也有可能小，关键在于到底有多少个线程在运行和这些线程的运行状态。
-----------------------------------------------------------
SQL ordered by CPU Time：记录了占CPU时间最长的Top SQL
SQL ordered by User I/O Wait Time：记录了执行过程中等待IO时间最长的Top SQL
SQL ordered by Gets：记录了执行最多逻辑读（逻辑IO）的Top SQL
通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。
SQL ordered by Reads：记录了执行最多物理读（物理IO）的Top SQL
SQL ordered by Executions：记录了执行次数最多的Top SQL，即使单条SQL运行速度飞快，任何被执行几百万次的操作都将耗用大量的时间。
SQL ordered by Parse Calls：记录了软解析次数最多的Top SQL
在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。
-----------------------------------------------------------华丽分割符-----------------------------------------
解读AWR报告Advisory Statistics
对于Oracle的内存参数的设定存在很多争议，当然具体的设置需要根据系统的情况进行调整，不能一概而论，因此内存参数的设置也就成为了一个难点。但是Oracle 10g、11g的自动内存管理功能还是很强大的，对于负载一般的系统，即使内存参数设置不太合理，也是足以支撑系统正常运行的。下面就AWR报告中给出的几个关键内存参数的建议章节进行解读。
一、 Buffer Pool Advisory部分：
| P | Size for Est (M) | Size Factor | Buffers (thousands) | Est Phys Read Factor | Estimated Phys Reads (thousands) | Est Phys Read Time | Est %DBtime for Rds |
|---|---|---|---|---|---|---|---|
| D | 1,712 | 0.10 | 205 | 1.53 | 3,505,559 | 1 | |
| D | 3,424 | 0.20 | 410 | 1.22 | 2,795,440 | 1 | |
| D | 5,136 | 0.30 | 615 | 1.04 | 2,370,578 | 1 | |
| D | 6,848 | 0.40 | 820 | 1.01 | 2,304,414 | 1 | |
| D | 8,560 | 0.50 | 1,026 | 1.00 | 2,293,899 | 1 | |
| D | 10,272 | 0.60 | 1,231 | 1.00 | 2,291,144 | 1 | |
| D | 11,984 | 0.70 | 1,436 | 1.00 | 2,290,386 | 1 | |
| D | 13,696 | 0.80 | 1,641 | 1.00 | 2,289,668 | 1 | |
| D | 15,408 | 0.90 | 1,846 | 1.00 | 2,288,459 | 1 | |
| D | 17,120 | 1.00 | 2,051 | 1.00 | 2,287,476 | 1 | |
| D | 17,168 | 1.00 | 2,057 | 1.00 | 2,287,465 | 1 | |
| D | 18,832 | 1.10 | 2,256 | 1.00 | 2,287,099 | 1 | |
| D | 20,544 | 1.20 | 2,461 | 1.00 | 2,286,662 | 1 | |
| D | 22,256 | 1.30 | 2,667 | 1.00 | 2,285,914 | 1 | |
| D | 23,968 | 1.40 | 2,872 | 1.00 | 2,284,719 | 1 |
字段解释：P 池类型
'D' - Default buffer cache (always present),
'K' - Keep buffer cache (if db_keep_cache_size parameter is defined),
'R' - Recycle buffer cache (if db_recycle_cache_size parameter is defined),
- Caches for non-default block sizes (if defined with parameters db_k_cache_size)
Size for Est(M) Oracle估算Buffer pool的大小
Size Factor 估算值和实际值的一个比例，比如0.9就是估算值是实际大小的90%，1.0表示buffer pool的实际大小
Buffers for Estimate 估算的buffer的大小（数量）
Est Phys Read Factor 估算的物理读的影响因子，即物理读和实际物理读的一个比例，1.0表示实际的物理读
Estimated Physical Reads 估算的物理读次数
这部分，主要从Size Factor、Est Phys Read Factor 都等于1.00的行开始，然后往上看，观察当Size Factor减小时，Est Phys Read Factor是不是明显变化，如果变化不明显，说明可以减小当前的buffer pool设置，相反则表示不能减小；然后往下看，观察当Size Factor增大时，Est Phys Read Factor是不是明显变化，如果变化不明显，说明没必要增大buffer pool设置，相反，则表示增大buffer pool可以提高系统性能。如上面的例子，则可以将buffer pool减小一半。（Estimated Phys Reads ）
二、Shared Pool Advisory
| Shared Pool Size(M) | SP Size Factr | Est LC Size (M) | Est LC Mem Obj | Est LC Time Saved (s) | Est LC Time Saved Factr | Est LC Load Time (s) | Est LC Load Time Factr | Est LC Mem Obj Hits (K) |
|---|---|---|---|---|---|---|---|---|
| 2,832 | 0.50 | 647 | 56,549 | 49,473,753 | 1.00 | 828,263 | 1.19 | 1,625,502 |
| 3,408 | 0.60 | 1,217 | 83,674 | 49,508,711 | 1.00 | 793,305 | 1.14 | 1,629,796 |
| 3,984 | 0.70 | 1,792 | 125,003 | 49,539,932 | 1.00 | 762,084 | 1.10 | 1,633,920 |
| 4,560 | 0.80 | 2,367 | 164,818 | 49,566,787 | 1.00 | 735,229 | 1.06 | 1,637,948 |
| 5,136 | 0.90 | 2,942 | 203,135 | 49,589,092 | 1.00 | 712,924 | 1.03 | 1,641,975 |
| 5,712 | 1.00 | 3,509 | 233,746 | 49,608,065 | 1.00 | 693,951 | 1.00 | 1,646,016 |
| 6,288 | 1.10 | 4,084 | 273,456 | 49,624,630 | 1.00 | 677,386 | 0.98 | 1,650,045 |
| 6,864 | 1.20 | 4,654 | 302,313 | 49,639,210 | 1.00 | 662,806 | 0.96 | 1,653,951 |
| 7,440 | 1.30 | 5,226 | 339,089 | 49,652,041 | 1.00 | 649,975 | 0.94 | 1,657,632 |
| 8,016 | 1.40 | 5,801 | 378,921 | 49,663,316 | 1.00 | 638,700 | 0.92 | 1,661,036 |
字段解释：Shared Pool Size(M) 估算共享池的大小
SP Size Factr 估算共享池的影响因子
Est LC Size (M) 估算的库高速缓存占用的大小（LC，library cache）
Est LC Mem Obj 高速缓冲区命中的对象数
Est LC Time Saved (s) 需要额外将对象读入共享池的时间
Est LC Time Saved Factr 影响因子
Est LC Load Time (s) 分析所花费的时间
Est LC Load Time Factr 分析花费时间事件的影响因子
Est LC Mem Obj Hits 内存中对象被发现的次数
与Buffer Pool Advisory类似，从 SP Size Factr = 1.00的行开始，上下观察，当减小或增大shared pool时对Est LC Time Saved (s)的影响是否明显。
三、PGA Memory Advisory
| PGA Target Est (MB) | Size Factr | W/A MB Processed | Estd Extra W/A MB Read/ Written to Disk | Estd PGA Cache Hit % | Estd PGA Overalloc Count | Estd Time |
|---|---|---|---|---|---|---|
| 200 | 0.13 | 16,428,793.42 | 5,102,532.19 | 76.00 | 534,361 | |
| 400 | 0.25 | 16,428,793.42 | 536,861.65 | 97.00 | 4,935 | |
| 800 | 0.50 | 16,428,793.42 | 229,497.06 | 99.00 | 0 | |
| 1,200 | 0.75 | 16,428,793.42 | 229,497.06 | 99.00 | 0 | |
| 1,600 | 1.00 | 16,428,793.42 | 229,161.86 | 99.00 | 0 | |
| 1,920 | 1.20 | 16,428,793.42 | 127,983.29 | 99.00 | 0 | |
| 2,240 | 1.40 | 16,428,793.42 | 127,983.29 | 99.00 | 0 | |
| 2,560 | 1.60 | 16,428,793.42 | 127,983.29 | 99.00 | 0 | |
| 2,880 | 1.80 | 16,428,793.42 | 127,983.29 | 99.00 | 0 | |
| 3,200 | 2.00 | 16,428,793.42 | 127,983.29 | 99.00 | 0 |
字段解释：PGA Target Est (MB) PGA的估算大小
Size Factr 影响因子，作用和buffer pool相同
W/A MB Processed Oracle为了产生估算处理的数据量
Estd Extra W/A MB 处理数据中需要物理读写的数据量
Estd PGA Cache Hit % 估算的PGA命中率
Estd PGA Overalloc Count 需要在估算的PGA大小额外分配内存的次数
同理，从 Size Factr = 1.00的行开始，上下观察当减小或增大pga的时候对Estd Extra W/A MB Read/Written to Disk的影响是否明显。
四、SGA Target Advisory
| SGA Size Factor | Beg Snap SGA Target Size(M) | End Snap SGA Target Size(M) | Est DB Time (s) | Est Physical Reads |
|---|---|---|---|---|
| 0.25 | 5,000 | 5,000 | 3,835 | 4,257,806 |
| 0.50 | 10,000 | 10,000 | 3,190 | 2,556,275 |
| 0.75 | 15,000 | 15,000 | 3,179 | 2,553,213 |
| 1.00 | 20,000 | 20,000 | 3,175 | 2,551,682 |
| 1.25 | 25,000 | 25,000 | 3,173 | 2,548,876 |
| 1.50 | 30,000 | 30,000 | 3,125 | 2,256,847 |
| 1.75 | 35,000 | 35,000 | 2,632 | 1,994,255 |
字段解释：SGA Target Size (M) 估算SGA大小
SGA Size Factor SGA大小的影响因子
Est DB Time (s) 估算的SGA大小计算出的DB Time
Est Physical Reads 物理读次数
从SGA Size Factor = 1.00的行开始，上下观察减小或增大SGA时对 Est Physical Reads的影响是否明显。