AWR报告是数据库性能评估和优化的重要参考，将数据库的问题已量化的形式展现出来，给DBA带来了很多便利。然而AWR中的内容是非常多的，如何才能以最佳的方式解读AWR报告，最高效地找出数据库的性能问题所在呢？
在刚刚过去的OOW2017大会上，AWR之父Graham 做了一个主题分享，名为“AWR Analysis for Admins, Developers and Architects” 运维、开发及架构师都应该一读的AWR报告分析。演讲ppt已在oow官网公开，接下来我们简单解读一下分享的主要内容。希望对大家有所帮助和借鉴。
注：原ppt可以关注数据和云（OraNews）回复关键字2017oow 获取。
以下是对该ppt的解读
真实环境下，性能问题的根源有以下几种：
1、数据库没有按照预期设计的目的被使用
2、应用的架构或代码设计不佳
3、数据库中存在一些不良的算法可能会引发问题
对于大部分人来说，都会讲优化的目标集中在一些小细节上，比如某一条SQL的性能比较差，shared pool的某一组件设置不合理等等。对于这些细节的调整，一般会带来小幅度的性能提升，而大部分人则满足于此。
RWP团队一直追求千倍以上极致的性能提升，对于他们来说，每一个性能问题，都应该找到根源，从最有效的角度解决问题，而不是满足于小幅度的性能提升。
在他们的工作当中，一般性能优化会涉及到以下几个方面的处理：
代码的改写，应用的逻辑修改，保证被正常地使用，bug的修复等。通过多个维度的调整和修改，最终实现系统性能千倍的提升。
发现数据库性能问题的方法很多，而不只是简单地看wait event 和 top SQL。事实上，我们需要的很多数据都可以从AWR报告中获取，同时，我们也需要了解系统架构的设计方式、实现原理。在我们的经验中，很多性能问题都是架构设计不合理或者应用代码的逻辑问题导致的。
接下来我们分享如何通过AWR的解读来定位问题，在AWR报告中应该关注哪些重要的信息，有效地利用报告中的数据，从而发挥AWR的真正价值。
首先看AWR报告的头部。要关注的部分如图中黄色标记所示。首先我们看到系统中有4个socket，总共32核，CPUs显示为64，应该是开了超线程。session值很高，在采样时间内还不断增长。
猜测：可能是会话泄露或者是连接风暴。
知识点补充
会话泄露：当应用程序断开连接而数据库中对应的会话还处于活动状态的时候，就会发生会话泄露。对于应用来说，就意味着程序的丢失。一般都是由于应用程序的异常导致的，在数据库中没有正常地执行commit或者rollback的时候失去了与数据库的联系。
在session本身很高的时候，每个session中的cursor值也从8增加到了26。这说明会话中游标耗尽，
猜测：可能存在游标泄露的问题。
再看详细负载信息
DBtime达到260，就意味着同一时间的活动会话数量达到260，DB CPUs大于系统CPU核数（32）。
Logons 为10.5，每秒有10+的会话登录，这个值是非常高的，在正常情况下，一般系统可能在1左右。这说明系统存在异常，再次推测可能是会话泄露或连接风暴等原因，与前面的信息相符。
60%的用户事务在做回滚。（图中写40%应该是误写，40%的事务是做提交）这也是不正常的。
接下来我们来看数据库的一些参数的设置。
我们看到数据库中块的大小是非默认块16k。同时将cursor_sharing设置为Force。
知识点补充
cursor_sharing 参数有 exact和Force两个选项，force 选项指的是优化器会将所有的文本值用系统生成的绑定变量替换，如果在使用绑定变量之后SQL语句一样的话，优化器就会使用同样的执行计划。
在一般情况下不建议将参数设置为Force。这很可能会引发SQL注入的风险，对于SQL中的函数来说，在一些直接使用文本而非绑定变量更优的情况下，如果使用系统生成的绑定变量，可能会对执行计划产生负面的影响。
因此系统一般建议设置为EXACT，只有在特殊情况下才设置为Force。详情请参考官网（http://docs.oracle.com/database/122/TGSQL/improving-rwp-cursor-sharing.htm#TGSQL-GUID-6C3AFFA0-21DD-41BC-8DEE-5FC9A58B0954）
DB_file_multiblock_read_count 默认值对应于可以高效执行且与平台相关的最大I / O大小 。此处与系统CPUs核数相等，说明IO没有问题。
open_cursors 参数指定一个会话一次最多可以打开的游标的数量，默认值为50.现在设置为2000，这是很高的，说明系统存在异常。
而从db_recovery_file_dest参数的设置是哪个，我们看到存储类型为ASM，ASM是支持异步IO的，在支持异步IO 的情况下，open_cursor达到2000也是不正常的。
DB_Writer_processes的默认值为1或者CPU_count/8,取较大者。此时设置为12，比默认值大，应该是手动调整过。
前面的信息判断，系统应该是2个节点的RAC，processes推荐值为 50*2+50=150. 此时达到5500，而sessions默认值为processes*1.5+22=8272，图中的值应该也是手动调整过。 而调整的原因，推测是8272也不够用。这是很不正常的。
接下来是等待事件的分析。看到系统大部分处于等待。
以下是对于具体的top SQL的分析描述。
因此，综合上述的信息，推测系统可能是出现会话泄露和游标泄露的问题。对于会话泄露，一般是由于应用的异常导致，不能直接通过数据库层面的分析得出结论也不能单纯从数据库的层面解决。
以上，针对一份具体的AWR报告，我们看到哪些问题是最需要我们关注的，是能够帮助我们最有效地分析出系统的问题所在的。希望对大家有借鉴意义
