SQL优化是重点

信息系统访问量又不大，瓶颈一般不会出现在应用层，极有可能在数据库这一层，不用急着看程序。先找出逻辑读取次数最多的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;

谢谢你贡献的SQL!

呵呵, Oracle就是好啊, 有这么多方便的工具机制, 这是一个成熟软件的核心价值所在!

长见识了,感谢楼主的贡献的SQL

一个系统出现性能瓶颈，往往是设计阶段的问题，sql调优不能根本解决问题。

这话说得有些太过片面了啊……

谢谢
有对sql server,mysql,,,优化的SQL吗?

80%的性能问题，是由20%的糟糕的sql所导致的。sql调优可以解决一大部分的性能问题。

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

另外可以用DBMS_SQLTUNE对SQL进行分析， 他会自动给出改进意见， 比如数据表需要用dbms_stats.gather_schema_stats来统计一下， 或需要加index,  很方便的