Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: rman failure ORA-04030 indicates memory issue
Okay,
-one backup doesn't work because it is getting an error indicating a
connection problem but I KNOW IT ISN'T A CONNECTION PROBLEM
-one backup doesn't work because I get the ORA-04030 error
-I know that this is indicating an issue with the user getting enough
user process memory - i.e. pga. However, the aggregate target should be
across all instances. I am playing with pga_aggregate_target using
alter system ...but to no avail.
-I also feel that my ulimits should likely be set to unlimited and I am
wondering if this is playing into this at all.
-Finally, I am wondering if the sga_max_size (unrelated to this
particular error but very scary) and this Sun bug is an issue.
-----Original Message-----
From: Stankus, Paula G=20
Sent: Tuesday, October 05, 2004 5:31 AM
To: Stankus, Paula G; 'tim_at_sagelogix.com'; 'Oracle-L_at_Freelists. Org
(E-mail)'
Subject: RE: rman failure ORA-04030 indicates memory issue
I also ran across some references that indicate there is a problem with dynamic memory allocation on Solaris 8/9 and a bug patch. I found that users had disabled sga_max_size (i.e. dynamic sga) until the patch was applied. =20
Has anyone else dealt with this issue? =20
-----Original Message-----
From: Stankus, Paula G=20
Sent: Tuesday, October 05, 2004 5:18 AM
To: Stankus, Paula G; 'tim_at_sagelogix.com'; 'Oracle-L_at_Freelists. Org
(E-mail)'
Subject: RE: rman failure ORA-04030 indicates memory issue
Also noticed the following: process stack was set to 8192 and nofiles to 256. I am wondering if these should be set to unlimited as I understand they would only be used if needed. Also, if I use a ulimit to reset the values when do these settings take place? Immediately?? =20
time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 8192 coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited
time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) unlimited coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited
-----Original Message-----
From: Stankus, Paula G=20
Sent: Tuesday, October 05, 2004 4:58 AM
To: Stankus, Paula G; 'tim_at_sagelogix.com'; 'Oracle-L_at_Freelists. Org
(E-mail)'
Subject: RE: rman failure ORA-04030 indicates memory issue
I am also wondering if the batch processes are somehow holding onto memory. Some appeared to fail and they should have completed long before the backup failed.
-----Original Message-----
From: Stankus, Paula G=20
Sent: Tuesday, October 05, 2004 4:43 AM
To: 'tim_at_sagelogix.com'; Oracle-L_at_Freelists. Org (E-mail)
Subject: rman failure ORA-04030 indicates memory issue
Rman fails with:
I notice that=20
A. A number of batch processes were added to database and likely using
a good deal of "sort" area as large batch processes often do
B. Volume of data added last night.
C. This error occurred along with another error:
ORA-12540: TNS:internal limit restriction exceeded
ORA-04030: out of process memory when trying to allocate 524824 bytes (pga heap,KSFQ Buffers)
I looked at TOP on Solaris while running the job that failed with ORA-04030 and out of 8 Gb, 4Gb of RAM were still showing as available.
I decreased the filesperset in rman from 10 to 4 and am concerned with the degradation of runtime for my backup processes.
The pga_aggregate_target is set at pga_aggregate_target=3D1610612736
sga_max_size=3D2147483648
processes=3D150.
I plan to look at the pga_aggregate_target related views. I also noticed in the alert.log the following:
ORA-07445: exception encountered: core dump [0000000101D51DF0] [SIGBUS]
[Object
specific hardware error] [0xFFFFFFFF7CA9FE90] [] []
Along with a trace file with a specific SQL statement. =20
Question: How appropriate/inappropriate are the pga_aggregate_target, sga_max_size given 8Gb RAM and that this is the only database on the system?
-- http://www.freelists.org/webpage/oracle-lReceived on Tue Oct 05 2004 - 04:36:43 CDT
![]() |
![]() |