当系统运行了一段时间后，系统基本也趋于稳定了，SQL调优也变了DBA的一个主要的工作内容，很多时候都是通过查看awr报告来检查出有性能瓶颈的SQL语句，通过这个可以很清晰的看到具体运行多少时间、次数、CPU、IO的比例。
但是每次都去查看awr报告是一件很繁琐的事情，如果可以单独的查看哪些有问题的sql，就不用每次都去生成一个awr报告了。dba_hist_sqlstat这个视图记录了每次snap_id里面的sql信息，这里帮大家把整个脚本编写出来了。
这个脚本是查找m
.max_elapsed
>
=300（这边的单位是秒），也是5分钟的时间，可以根据系统的实际情况进行定义；
可以看出sql_id值为d1ftvurv76hct运行一次，这次运行的时间为1199s，占总体消耗的36%。
【另】可以通过运行定时job执行这条sql语句，然后发送有问题的sql信息到用户的邮箱；
但是每次都去查看awr报告是一件很繁琐的事情，如果可以单独的查看哪些有问题的sql，就不用每次都去生成一个awr报告了。dba_hist_sqlstat这个视图记录了每次snap_id里面的sql信息，这里帮大家把整个脚本编写出来了。
点击(此处)折叠或打开
- SELECT v.SQL_TEXT,m.* FROM (select distinct snap_id,
- sql_id,
- EXECUTIONS_DELTA,
- trunc(max(ELAPSED_TIME_DELTA)
- OVER(PARTITION BY snap_id, sql_id) / 1000000,
- 0) max_elapsed,
- trunc((max(ELAPSED_TIME_DELTA)
- OVER(PARTITION BY snap_id, sql_id)) /
- (SUM(ELAPSED_TIME_DELTA) OVER(PARTITION BY snap_id)),
- 2) * 100 per_total
- from dba_hist_sqlstat t WHERE T.snap_id IN (SELECT MAX(snap_id) FROM dba_hist_sqlstat) ) M,v$sql v
- where m.sql_id=v.sql_id and m.max_elapsed>=300
可以看出sql_id值为d1ftvurv76hct运行一次，这次运行的时间为1199s，占总体消耗的36%。
【另】可以通过运行定时job执行这条sql语句，然后发送有问题的sql信息到用户的邮箱；
