信息系統訪問量又不大，瓶頸一般不會出現在應用層，極有可能在數據庫這一層，不用急著看程序。先找出邏輯讀取次數最多的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;
posted on 2006-05-18 22:53
老妖 閱讀(732)
評論(0) 編輯 收藏 所屬分類:
轉載