通过V$SQLAREA 查找有问题的查询

V$SQLAREA 视图提供了一种识别有潜在问题或者需要优化的SQL 语句的方法，从而可通过减少磁盘的
300
访问来优化数据库的综合性能。disk_reads 表示系统中正在执行的磁盘读取量。它和执行次数结合起来
(disk_reads/执行情况)就返回了SQL 语句，构成每一条语句执行时主要的磁盘访问率。上面程序清单中的
disk_reads 设置为100 000，但它在最终的产品系统(依赖于数据库)中也可以设置得更大或更小，以便仅
揭示系统中问题较大的语句。一旦确定问题以后，最上层的语句应当被重新检查并优化，以提高系统的综
合性能。一般情况下，问题语句都没有使用索引，或者执行路径限制语句无法使用正确的索引。
下面程序清单中的查询有一个部分可能会造成误导，即rds_exec_radio。它表示磁盘读操作的次数除
以执行过程的数目所得的值。实际上，一条语句可以一次使用100 个磁盘读操作来读取，然后再被强制清
出内存(如果内存空间不足的话)。如果再次读取的话，那么它将再次进行100 次磁盘读操作，而
rds_exec_radio 就是100(100+100 次磁盘读操作，再除以2 次执行过程)。但是，如果第二次读取它时，
该语句正在内存中(内存空间足够)，那么磁盘读操作将为0(第2 次)，所以rds_exec_radio 将是50(100+0
次磁盘读操作，再除以2 次执行过程)。在结果列表顶部的任何语句都存在问题，并需要被调整——定期调
整！
注意：
下面的代码已经经过格式化处理，以方便阅读。
select b.username username, a.disk_reads reads,
a.executions exec, a.disk_reads /decode
(a.executions, 0, 1,a.executions) rds_exec_ratio,
a.command_type, a.sql_text Statement
from v$sqlarea a, dba_users b
where a.parsing_user_id = b.user_id
and a.disk_reads > 100000
order by a.disk_reads desc;
USERNAME READS EXEC RDS_EXEC_RATIO STATEMENT
-------- ------- ---- -------------- ---------------------------------
ADHOC1 7281934 1 7281934 select custno, ordno
from cust, orders
ADHOC5 4230044 4 1057511 select ordno
from orders
where trunc(ordno) = 721305
ADHOC1 801715 2 499858 select custno, ordno
from cust
where decode(custno,1,6) = 314159
在前面语句中的DISK_READS 列可以用BUFFER_GETS 列来代替，以提供关于SQL 语句的信息，该SQL
语句拥有的磁盘访问率不高(尽管它们通常是这样)，但拥有的内存访问率很高(高于所期望的值)。这些语
句使用了大量的内存来分配给数据(DB _CACHE_SIZE)。问题不在于语句是在内存中执行的(这本身是好事)，
而在于该语句独占了大量的内存。许多情况下，问题出在当SQL 语句应做全表扫描或连接操作时，它却使
用了一个索引。这种类型的SQL 语句也可能牵涉到一个连接操作，该连接会强制使用一个并非所需的索引，
或者使用多重索引以及强制合并索引或数据。记住，大部分的系统性能问题是由于糟糕的SQL 或PL/SQL 语
句。
301
技巧：
V$SQLAREA 视图可发现有问题的查询(和用户)。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25198367/viewspace-707586/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25198367/viewspace-707586/