ORA-04030 解决方案

最新推荐文章于 2025-03-27 00:00:00 发布

cuixitao3818

最新推荐文章于 2025-03-27 00:00:00 发布

阅读量817

点赞数

文章标签：操作系统数据库

ORA-04030,ORA-04031错误都是由于oracle在内存分配上出现问题而报的错误,该问题也是很多DBA最头疼的问题,因为该问题的错误日志都在.trc的文件中(.trc文件一般是给oracle售后工程查看的).

我近期也遇到一个rman备份的时候报ORA-04030的问题,在此分享一下问题的解决方案.

1. 服务器软件环境:

i. 操作系统: windows server 2003 Enterprise SP2 . 32位. (已经设置/PAE).

ii. 物理内存: 8G.

iii. oracle数据库: oracle Release 11.1.0.6.0.

2. ORACLE内存分配

i. SGA :　1.64G.

ii. PGA: 1.5G.

3. 场景

i. 启用rman对一个数据库做全备(rman启用一个通道)备份报错.

ii. 当时在任务管理中查看oracle.exe进程, 已经占用内存约2.1G.

iii. 操作系统所有进程占用内存3.5G左右.

iv. 在RMAN备份前通过视图 v$process得到所有进程占用的的内存在250M左右.

v. 在RMAN启动备份通过视图v$process得到所有进程占用内存在320M左右,即启动一个rman通道占用60M左右的内存

4. 错误日志.

i. RMAN错误日志(详细日志见附件alert_cmcs.log)

ORA-04030: 在尝试分配 1049100 字节 (KSFQ heap,KSFQ Buffers) 时进程内存不足

Incident details in: d:\app\administrator\diag\rdbms\cmcs\cmcs\incident\incdir_35208\cmcs_ora_1020_i35208.trc

Incident details in: d:\app\administrator\diag\rdbms\cmcs\cmcs\incident\incdir_35162\cmcs_ora_4968_i35162.trc

ii. cmcs_ora_1020_i35208.trc日志(详细日志见附件).

d:\app\administrator\diag\rdbms\cmcs\cmcs\trace\cmcs_ora_1020.trc

ORA-04030: 在尝试分配 1049100 字节 (KSFQ heap,KSFQ Buffers) 时进程内存不足

========= Dump for incident 35208 (ORA 4030) ========

*** 2010-10-20 10:00:55.218

----- SQL Statement (None) -----

Current SQL information unavailable - no cursor.

----- Call Stack Trace -----

calling call entry argument values in hex

location type point (? means dubious value)

-------------------- -------- -------------------- ----------------------------

EnumerateLoadedModules64 failed with error 183

_skdstdst()+114 CALLrel _kgdsdst()+0 764A5668 2

_ksedst1()+91 CALLrel _skdstdst()+0

_ksedst()+50 CALLrel _ksedst1()+0 0 1

_dbkedDefDump()+298 CALLrel _ksedst()+0 0

_ksedmp()+40 CALLrel _dbkedDefDump()+0 3 2

_ksfdmp()+21 CALLrel _ksedmp()+0 3EB

_dbgexPhaseII()+254 CALLreg 00000000 7D1F0468 3EB

_dbgexProcessError( CALLrel _dbgexPhaseII()+0 71A30420 71A36DFC 764A6294

)+1391

_dbgeExecuteForErro CALLrel _dbgexProcessError( 71A30420 71A36DFC 1 0

r()+37 )+0 71A30420 71A36DFC

__VInfreq__dbgePost CALLrel _dbgeExecuteForErro 71A30420 71A36DFC 0 1 0

ErrorKGE()+101 r()+0

_dbkePostKGE_kgsf() CALLrel _dbgePostErrorKGE() 7D1F0468 74A12020 FBE

+49 +0

_kgeade()+268 CALLreg 00000000 7D1F0468 74A12020 FBE

_kgese

4E958B0

_ksfqbcre()+265 CALLrel _ksfqbalo()+0 71B90D04

_ksfqxc()+1378 CALLrel _ksfqbcre()+0 100000 4 0

_ksfqxcrx()+240 CALLrel _ksfqxc()+0 0 0 0 764A9DCC 0 75D00138

75D0013C 0 2000000 0 0 5 0

2000 11

_ksfqxcre()+46 CALLrel _ksfqxcrx()+0 0 0 0 764A9DCC 0 75D00138

75D0013C 0 2000000 0 5 2000

11 0 0

5. 解决方案.

i. 调整ORACLE组件大小

SGA: 1.64G

PGA: 1.2G.

Lager_pool: 初始化值 64M.

ii. 调整操作系统启动参数.

在服务器操作系统根目录下(c:\)找到BOOt.ini文件, 该文件为windows的启动文件. 找到字符串 /PAE , 在/PAE前串 /3GB 重启操作系统.

6. 总结一.

出现ORA-04030错误90%是因为oracle/操作系统无法为某个进程分配足够的内存.

通过场景3知道

(1) PGA中还有足够的内存来分配给rman的通道和相关服务器进程使用.

(2) 整个系统还有差不多4G的物理空闲内存.

为什么还是出现内存分配不足呢?

(1) 查资料得知,windows 32位操作系统默认最大能够识别的物理内存在3.25—3.75G左右, 在某些特定的windows操作系统(eg: windows server 2003 Enterprise),可以通过PAE(Physical Address Extensions)技术支持,使操作系统能够支持到更高的物理内存(最大值使操作系统不同而不同).在本环境中已经使用到PAE技术,使32位操作系统能够识别到8G的物理内存. 显然问题不在这里.

(2) 查资料得知, windows 32位操作系统最大能为每个进程分配4G的内存, 但是默认情况下这4G的分配为: 操作系统核心占用2G,应用进程占用2G.

(3) 通过(2)可以大概猜测到问题的所在, 因为oracle.exe只能为自己分配2G的内存. 即oracle应用本身的所有内存只和不能超过2G, 此处oracle.exe已经占用的2.1G(其中SGA1.64G, PGA270M, 其他用户进程还需要占用一些内存),由此可见,oracle引用本身占用的内存已经在2G的边缘, 在启动rman的时候,已经无法分配到内存(所有SGA:1.64g,pga:1.5g设置已经没有意义).

(4) 查资料得知, windows server 2003 Enterprise , 有 /3GB的特性, 即在默认情况下32位windows为每一个进程分配4G的内存, windows核心占用2G,应用进程占用2G. 可以通过/3Gb技术调整到:windows核心占用1G,应用进程占用3G (调整方案为: 在服务器操作系统根目录下(c:\)找到BOOt.ini文件, 该文件为windows的启动文件. 找到字符串 /PAE , 在/PAE前串 /3GB 重启操作系统.) 解决问题.