标签：
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为视图）：
SELECT MV_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.WORKTYPE FROM QRY_WORKITEM JOIN MV_118_CTLIST_03 ON ROOTPROCINSTID = MV_118_CTLIST_03."CTLIST_SPID" JOIN (SELECT PK FROM (SELECT PK, rownum rowNumber FROM (SELECT WORKITEMID AS PK FROM 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 BY STARTEDDATE) WHERE rownum <= 20) WHERE rowNumber >= 1) tblPK ON workitemid = tblPK.PK WHERE 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
