【数据库】解读OracleAWR性能分析报告
1、什么是A WR？
AWR (Automatic Workload Repository) 是⾃动负载信息库的英⽂缩写，AWR报告是Oracle 10g以后版本提供的⼀种性能收集和分析⼯具，能提供⼀个时间段内整个系统资源使⽤情况的报告，通过报告可以了解⼀个系统的整个运⾏情况，⽣成的报告包括多个部分。
AWR每⼩时对v$active_session_history视图(内存中的ASH采集信息，理论为1⼩时)进⾏采样⼀次，并将信息保存到磁盘中，并且保留7天，7天后旧的记录才会被覆盖。这些采样信息被保存在wrh$_active_session_history视图(写⼊AWR库中的ASH信息，理论为1⼩时以上)中。⽽这个采样频率（1⼩时）和保留时间（7天）是可以根据实际情况进⾏调整的，这就给DBA们提供了更加有效的系统监测⼯具。
2、什么情况下会⽤到A WR？
DBA对数据库运⾏状态及状况的监控了解、测试过程中发现数据库出现瓶颈但⽆法定位到具体原因时，可以借⽤AWR报告进⾏分析定位。
数据库出现性能问题，⼀般都在三个地⽅：IO、内存、CPU，这三个地⽅⼜是息息相关的。假设这个三
个地⽅都没有物理上的故障，当IO负载增⼤时，肯定需要更多的内存来存放，同时也需要CPU花费更多的时间来过滤这些数据。相反，CPU时间花费多的话，有可能是解析SQL语句，也可能是过滤太多的数据，倒不⼀定是和IO或内存有关系。
CPU：解析SQL语句，尝试多个执⾏计划，最后⽣成⼀个数据库认为是⽐较好的执⾏计划，但不⼀定是最优的。因为关联表太多的时候，数据库并不会穷举所有的执⾏计划，这会消耗太多的时间，oracle怎么知道这条数据是你要的，另⼀个就不是你要的呢，这是需要cpu来过滤的。
内存：SQL语句和执⾏计划都需要在内存保留⼀段时间，还有取到的数据，根据LRU算法也会尽量在内存中保留，在执⾏SQL语句过程中，各种表之间的连接，排序等操作也要占⽤内存。
IO：如果需要的数据不在内存中，则需要到磁盘中去取，就会涉及到物理IO了，还有表之间的连接数据太多，以及排序等操作内存放不下的时候，需要⽤到临时表空间，也会消耗物理io了。
这⾥说明下，ORACLE分配的内存中PGA⼀般只占20%，对于专⽤服务器模式，每次执⾏SQL语句、表数据的运算等操作，都在PGA中进⾏的，也就是说只能⽤ORACL分配内存的20%左右，如果多个⽤户都执⾏多表关联，⽽且表数据⼜多，再加上关联不当的话，内存就成为瓶颈了，所以优化SQL很重要的⼀点就是，减少逻辑读和物理读。
3 如何⽣成A WR报告
第⼀步，登录ORACLE数据库服务器，记住当前⽬录或者切换⾄AWR想要保存的⽬录；
第⼆步，SQLplus ⽤户名/密码@服务连接名，连接oracle数据库实例，如下图所⽰；
image
第三步，执⾏@?/rdbms/admin/awrrpt;，会出现提⽰，
可以⽣成以下⼏种类型AWR报告，⼤部分情况下都是⽣成本实例的AWR报告
@?/rdbms/admin/awrrpt; 本实例AWR包括
@?/rdbms/admin/awrrpti; RAC中选择实例号
@?/rdbms/admin/awrddrpt; AWR ⽐对报告
@?/RDBMS/admin/awrgrpt; RAC全局AWR报告
输⼊⽣成AWR报告的格式是html的，如下图所⽰：
image
输⼊天数： 根据实际情况输⼊（如1，代表当天，如果2，代表今天和昨天，以此往前推）如下图所⽰：
image
输⼊开始值与结束值：（输⼊天数后会列出，snap值）
输⼊AWR报告的名称：名称⾃定义 回车后就开始⾃动⽣产AWR报告，如下图所⽰：
oracle登录命令image
这⾥说明⼀下快照节点可以⼿⼯创建，根据实际情况执⾏如下命令：
exec dbms_ate_snapshot；就可以⼿⼯创建⼀个快照。
image
结束后就可以去指定⽬录下照AWR报告⽂件，⽂件为 test_awr.lst，如下图所⽰：
image
修改扩展名为HTML，下载到Windows平台即可查看，即可⽤IE打开AWR报告，如下图所⽰：
image
4 解读AWR报告
AWR报告内容很丰富这⾥选其中⼀⼩部分来讲解，分析AWR报告前先了解⼀下Oracle的硬解析和软解析，⾸先说⼀下Oracle对SQL的处理过程。当你发出⼀条SQL语句交付Oracle，在执⾏和获取结果前Oracle对此SQL将进⾏⼏个步骤的处理过程：
1、语法检查(syntax check)
检查此SQL的拼写是否语法。
2、语义检查(semantic check)
诸如检查SQL语句中的访问对象是否存在及该⽤户是否具备相应的权限。
3、对SQL语句进⾏解析(prase)
利⽤内部算法对SQL进⾏解析，⽣成解析树(parse tree)及执⾏计划(execution plan)。
4、执⾏SQL，返回结果(execute and return)
其中，软、硬解析就发⽣在第三个过程⾥。
Oracle利⽤内部的hash算法来取得该SQL的hash值，然后在library cache⾥查是否存在该hash值；
假设存在，则将此SQL与cache中的进⾏⽐较；
假设“相同”，就将利⽤已有的解析树与执⾏计划，⽽省略了优化器的相关⼯作。这也就是软解析的过程。
当然，如果上⾯的2个假设中任有⼀个不成⽴，那么优化器都将进⾏创建解析树、⽣成执⾏计划的动作。这个过程就叫硬解析。
创建解析树、⽣成执⾏计划对于SQL的执⾏来说是开销昂贵的动作，所以，应当极⼒避免硬解析，尽量使⽤软解析。
打开AWR报告头如下图所⽰：
image
Elapsed快照监控时间：如果为了诊断特定时段性能问题则Elapsed不宜过长15分钟~2、3个⼩时。如果是看全天负载那么可以长⼀些，最常见是60分钟后者120分钟。
DB Time：不包括Oracle后台进程消耗的时间，如果DB Time远远⼩于Elapsed时间，说明数据库⽐较空闲。
DB Time= cpu time + wait time（不包含空闲等待） （⾮后台进程），DB Time就是记录的服务器花在数据库运算(⾮后台进程)和等待(⾮空闲等待)上的时间，DB time = cpu time + all of nonidle wait event time在79分钟⾥（其间收集了3次快照数据），数据库耗时11分
钟，RDA数据中显⽰系统有8个逻辑CPU（4个物理CPU），平均每个CPU耗时1.4分钟，CPU利⽤率只有⼤约2%（1.4/79），说明系统压⼒⾮常⼩。
但是对于批量系统，数据库的⼯作负载总是集中在⼀段时间内，如果快照周期不在这⼀段时间内，或者快照周期跨度太长⽽包含了⼤量的数据库空闲时间，所得出的分析结果是没有意义的，这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。