信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的SQL，硬盘读取次数最多的SQL，找到SQL，对于SQL进行优化。看看有没有发生全表扫描的地方。
一般发生全表扫描，极有可能是没有建立合理的索引，或者索引由于左边引用函数或其它原因造成索引失效。
对于运行一年多的系统，最好要自己写一个自动重建索引的程序，定时重建索引。
或者使用TOAD工具帮你重建索引。
另外在看一下数据库的CPU占用率，如果占用率在经常在80%－100%，那一定要是SQL或存储过程及trigger中写的不好。
不需要从应用层找SQL，方向性错误，太累，也看不出效果。
而应当使用pl/SQL, toad等工具，分析出最bad的SQL语句，一看到这些语句后，再修改应用层的查询就是了。又快又方便。
-- 逻辑读多的SQL
select * from (select buffer_gets, sql_text
from v$sqlarea
where buffer_gets > 500000
order by buffer_gets desc) where rownum<=30;
-- 执行次数多的SQL
select sql_text,executions from
(select sql_text,executions from v$sqlarea order by executions desc)
where rownum<81;
-- 读硬盘多的SQL
select sql_text,disk_reads from
(select sql_text,disk_reads from v$sqlarea order by disk_reads desc)
where rownum<21;
-- 排序多的SQL
select sql_text,sorts from
(select sql_text,sorts from v$sqlarea order by sorts desc)
where rownum<21;
--分析的次数太多，执行的次数太少，要用绑变量的方法来写sql
set pagesize 600;
set linesize 120;
select substr(sql_text,1,80) "sql", count(*), sum(executions) "totexecs"
from v$sqlarea
where executions < 5
group by substr(sql_text,1,80)
having count(*) > 30
order by 2;
9i里的statspack和10 g里的AWR, 都可以给出一段时间里所有SQL的统计， 比如
SQL ordered by Elapsed Time
SQL ordered by CPU Time
SQL ordered by Gets
SQL ordered by Reads
SQL ordered by Executions
SQL ordered by Parse Calls
posted on 2006-07-05 13:07
坚持学习，每天进步一些 阅读(489)
评论(0) 编辑 收藏 所属分类:
DB