AWR报告详解（二）

上一篇 / 下一篇  2016-04-16 23:05:52 / 个人分类：数据库

查看( 3320 ) / 评论( 0 ) / 评分( 0 / 0 )

SQL Statistics v$sqlarea

本节按各种资源分别列出对资源消耗最严重的SQL语句，并显示它们所占统计期内全部资源的比例，这给出我们调优指南。例如在一个系统中，CPU资源是系统性能瓶颈所在，那么优化buffer gets最多的SQL语句将获得最大效果。在一个I/O等待是最严重事件的系统中，调优的目标应该是physical IOs最多的SQL语句。

在STATSPACK报告中，没有完整的SQL语句，可使用报告中的Hash Value通过下面语句从数据库中查到：

 

SELECTsql_text

   FROMstats$sqltext

  WHEREhash_value=&hash_value

ORDERBYpiece;

 

Back to Top

SQL ordered by Elapsed Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

SQL ordered by CPU Time

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • % Total DB Time is the Elapsed Time of the SQL statement divided into the Total Database Time multiplied by 100

SQL ordered by Gets

  • Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
  • Total Buffer Gets: 16,648,792
  • Captured SQL account for 97.9% of Total

这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。

另外说明一点：大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100％的时候，很多时候就是SQL语句造成的，这时候我们可以分析一下这里逻辑读大的SQL。

SELECT*

 FROM( SELECTSUBSTR(sql_text,1,40)sql,

                buffer_gets,

                executions,

                buffer_gets/executions"Gets/Exec",

                hash_value,

                address

           FROMv$sqlarea

          WHEREbuffer_gets>0ANDexecutions>0

       ORDERBYbuffer_getsDESC)

 WHEREROWNUM<=10;

 

Open Toolbar