1、先看三篇帖子：
www.itpub.net/thread-137600-1-1.html
http://www.itpub.net/thread-124424-1-1.html
http://blog.itpub.net/post/96/14353
执行下面的语句：
SQL> show parameter area_size;
NAME TYPE VALUE
------------------------------------ ----------- ---------------
bitmap_merge_area_size integer 1048576
create_bitmap_area_size integer 8388608
hash_area_size integer 131072
sort_area_size integer 65536
workarea_size_policy string AUTO
我们只要知道一个问题，在这里sort_area_size=64K 和 hash_area_size=128K 是针对每个会话的，并不是针对整个数据库的。
1G内存的服务器上，内给到400--500M 给SGA。。2G 能给到1G； 8G 能给到5G。。通常用一个参考的公式来表达这个问题：
os使用内存+SGA+并发进程数*（sort_area_size+hash_area_size+2M） < 0.7* 总内存
不过现在10g ，11g中先后推出了SGA自动管理，内存自动管理。基本不用dba手动设置了。。
2、一个调优的案例分析
这个看了书上的一个调优的案例，总结出来的，具体的内容没有写（参照《oracle数据库性能优化》盖国强等著P69），主要是想同个自己看的第一个例子，来熟悉一般的调优过程。
问题表述：应用是一个后台新闻发布系统，前端展现的是一个大型网站。java开发应用，通过中间件连接池连接数据库。通过连接访问新闻网页极其缓慢，后台发布管理具有同样的问题。通常需要十几秒才能返回。这种性能是用户不能忍受的。
解决过程：
1、检查并跟踪数据库进程：在前台单击相关的新闻条目页面，同时进行后台进程跟踪。
SQL> select sid ,serial# ,username from v$session;
SID SERIAL# USERNAME
------- ---------- ------------------
135 21065
137 13248 SYS
141 1793
147 157
157 1
159 3
160 9
162 9589
163 1
164 1
165 1
SID SERIAL# USERNAME
------- ---------- ------------------
166 1
167 1
168 1
169 1
170 1
除了sys及后台进程外，其他的使我们诊断的目标，要对几个进程启用相关的进程SQL_TRACE
SQL>exec dbms_system.set_sql_trace_in_session(sid, serial#,,true);
.......
在这里要跟踪不止一个后台的进程，反正只要认为可疑的进程都要跟踪的。此时，前台的页面进行刷新，等待一段时间。然后关闭SQL_TRACE
SQL>exec dbms_system.set_sql_trace_in_session(sid, serial#,,false);
2、检查TRACE文件：在udump目录下找到相应的跟踪文件，用tkprof工具查看。看到有一个问题，经过了3892次查询，才查询出一条对应的数据记录。在执行计划里，看到这条语句用的全表扫描。（现在要思考为什么不是走的索引？）
3、登陆数据库检查相应的表结构：发现每次查询所用的articleid 列 有索引，但是没有被用到
。为什么呢？检查表结构发现 articleid列时 VARCHAR2类型的数据。而我们查询时，articleid=20224456565这是一个数值的类型。Oracle在执行这个sql查询时，发生了潜在的数据类型转换（把表中的article转换为 number类型，然后和20224456565这个值比较，相同则取出。）很明显，这样需要全表的转换，执行了全表的扫描。。
4、解决办法：解决的办法超级简单，只需要在查询语句中数字两侧加上引单号：articleid=’ 20224456565 ‘ 对于用单引号引起来的数字，oracle会认为是字符串、这样就消除了隐式类型的转换。再次查询，只需要查询2次，即可查询出一行。问题解决。