Oracle的内存配置与Oracle性能息息相关。从总体上讲，可以分为两大块：共享部分(主要是SGA)和进程独享部分(主要是PGA)。在 32 位操作系统下 的Oracle版本，不时有项目反馈关于内存的错误(如ORA-04030、04031错误)都是十分令人头疼的问题。查阅资料了解到，ORA-04030的问题一般是PGA过度分配造成的(对应的操作是sort/hash_join)。在Oracle中pga_aggregate_target指定了所有session总共使用的最大PGA上限。经测试验证，32位Oracle版本使用的物理内存保持在 1.6G以下为佳(SGA+PGA)，超过 1.7G左右系统开始不稳定，推荐的内存配置为：SGA=1200M，PGA=360M；
调整内存参数的命令示例如下：
alter system set sga_max_size=1200M scope=spfile;alter system set sga_target=1200M scope=spfile;alter system set pga_aggregate_target=360M scope=spfile;
另外，建议使用的Oracle版本：10.2.0.5、11.2.0.3/4；对于64位版本，建议先把20%的内存留给操作系统，剩余80%分配给Oracle(其中SGA=物理内存*80%*80%，PGA=物理内存*80%*20%)。
曾经在多个项目上发现过奇怪的现象，一个较复杂的SQL，直接执行或查看执行计划，操作系统中可以看到CPU立刻飙到99%，而且即使等待很长时间(比如2分钟，对于一个各表数据量小于10K的查询，哪怕都走全表扫描也应该执行完的，2分钟实在是太久了)，CPU也不会降下来，SQL命令也无法正常结束，只能强制终止该会话或Oracle进程。该SQL访问的所有表的数据量都不是很大(小于10K)，更新统计信息等都没有效果。我分别在Windows和Linux平台下的测试环境验证过，问题都能够重现，当然如果将SQL脚本简化也能解决，但没有明显的规律、规则，感觉应该是Oracle的bug，最后都是通过升级到最新版本解决的。
如分页SQL脚本(MV_118_CTLIST_03为视图)：
SELECTMV_118_CTLIST_03."CTLIST_Name"
, MV_118_CTLIST_03."CTLIST_Depart_LSBMZD_BMMC"
, MV_118_CTLIST_03."CTLIST_Value"
, MV_118_CTLIST_03."CTLIST_Handler_LSZGZD_ZGXM"
, QRY_WORKITEM.STARTEDDATE
, QRY_WORKITEM.COMPLETEDDATE
, QRY_WORKITEM.PROCESSINSTANCEID
, QRY_WORKITEM.ACTIVITYDEFINITIONID
, QRY_WORKITEM.PROCESSDEFINITIONID
, QRY_WORKITEM.ActivityInstanceId
, QRY_WORKITEM.WORKITEMID
, QRY_WORKITEM.WORKTYPEFROMQRY_WORKITEMJOIN MV_118_CTLIST_03 ON ROOTPROCINSTID =MV_118_CTLIST_03."CTLIST_SPID"JOIN (SELECTPKFROM (SELECTPK, rownum rowNumberFROM (SELECT WORKITEMID ASPKFROM QRY_WORKITEM
JOIN MV_118_CTLIST_03 ON ROOTPROCINSTID =MV_118_CTLIST_03."CTLIST_SPID"WHERE QRY_WORKITEM.Participant = ‘5b181b7c-8ea8-45a5-b35d-a90aed0725dc‘
AND QRY_WORKITEM.State = ‘2‘
AND QRY_WORKITEM.BIZPROCID = ‘0fad699e-a787-4fb6-bbff-8d3382f6d37f‘
ORDER BYSTARTEDDATE)WHERE rownum <= 20)WHERE rowNumber >= 1) tblPK ON workitemid =tblPK.PKWHERE QRY_WORKITEM.Participant = ‘5b181b7c-8ea8-45a5-b35d-a90aed0725dc‘
AND QRY_WORKITEM.State = ‘2‘
AND QRY_WORKITEM.BIZPROCID = ‘0fad699e-a787-4fb6-bbff-8d3382f6d37f‘
ORDER BY STARTEDDATE
原文：http://www.cnblogs.com/zhaoguan_wang/p/4604241.html
