oracle 查看内存参数配置,Oracle内存参数配置及版本问题

最新推荐文章于 2024-03-12 19:30:34 发布

艾斯歪一

最新推荐文章于 2024-03-12 19:30:34 发布

阅读量894

点赞数

文章标签： oracle 查看内存参数配置

本文探讨了Oracle数据库在32位系统下的内存配置问题，指出ORA-04030错误通常由PGA过度分配引起，并建议了SGA和PGA的合理配置比例。在64位系统中，建议预留20%内存给操作系统，其余分配给Oracle。此外，文章还提到一个复杂SQL导致CPU占用过高且无法正常结束的问题，通过升级Oracle版本得到解决。

摘要由CSDN通过智能技术生成

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