08/16/2018 02:41:19.451 INFO (Exec Task Consumer#5) [com.aveksa.server.xfw.UnificationExecutor] Failed method=Process subTask=CompleteMergeTasks Default User Population, 67673
com.aveksa.server.db.PersistenceException: java.sql.SQLException: ORA-04030: out of process memory when trying to allocate 64544 bytes (sort subheap,sort key)
ORA-06512: at "AVUSER.UNIF_RAWDATA", line 82
ORA-06512: at "AVUSER.UNIFICATION_PROCESSOR", line 277
ORA-04030: out of process memory when trying to allocate 64544 bytes (sort subheap,sort key)
ORA-06512: at line 1
An ORA-4030 error can arise due to the following situations:
Tue Aug 21 10:24:53 2018
Starting ORACLE instance (normal) (OS id: 89733)
Errors in file /u01/app/oracle/diag/rdbms/acmprd01/ACMPRD01/trace/ACMPRD01_j001_1234.trc (incident=23241😞
ips pack incident <incident#> in /tmp
opatch lsinventory
For further assistance after collecting the above information, please engage RSA Customer Support by logging a new Case for RSA-provided database, or engage your local Oracle DBA for customer-supplied database (also called "Remote DB").
On the Linux platform, there is a known issue relating to the max map count setting, located in the file /proc/sys/vm/max_map_count.
The procedure for confirming that the Oracle process has exceeded the value in the max_map_count file is documented in Oracle Support Note 1325100.1 :PLSQL Procedure Causing ORA-4030 Errors.
Simply put, what needs to be confirmed is how many lines are between the following two tag lines in the ORA-04030 trace file:
----- Process Map Dump -----
******************* End of process map dump ***********
This count then needs to be compared to the value in the file: /proc/sys/vm/max_map_count.
# more /proc/sys/vm/max_map_count
65530
# sysctl -w vm.max_map_count=131060
vm.max_map_count = 131060
If the Oracle database is running on a non-Linux platform (for example, IBM AIX), then it is not supplied by RSA, so please contact your local Oracle DBA.
Over-allocation is when the memory allocated to the Oracle database, and the memory consumed by non-Oracle processes, exceeds the memory available to the operating system. For example (true story):
# free
total used free shared buffers cached
Mem: 18405600 18215380 190220 0 224244 6843656
-/+ buffers/cache: 11147480 7258120
Swap: 8388604 2964 8385640
In this example, the system the system has 18,405,600 bytes, or 16GB of RAM.Use the following command to determine the virtual memory size of all the non-Oracle processes.
vsz is the virtual memory size of the process in KiB (1024-byte units).
ps -e h -o ruser,vsz |grep -v oracle | awk '{total = total + $2}END{print total}'
ps -e -o ruser,group,pid,vsz,comm | grep -v oracle > virt_mem_size.txt
Use the following command to show the virtual memory size of the Oracle Java/WildFly process.
ps -e -o ruser,group,pid,vsz,comm | grep java
The Java -Xmx setting is the maximum Java heap size. Confirm the -Xmx setting for the Oracle Java/WildFly processes by using the following command:
ps -ef | grep java
oracle 7258 1 1 Aug11 ? 16:58:16 /usr/lib64/jvm/java/jre/bin/java ... -Xmx512m ...
This can then be compared to the results from step 3. If the WildFly memory usage is significantly greater than the maximum Java heap size, then there may be a Java leak.
SQL> set linesize 128
SQL> show parameter sga_target
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
sga_target big integer 7584M
SQL> show parameter pga_aggregate_target
NAME TYPE VALUE
------------------------------------ -------------------------------- ------------------------------
pga_aggregate_target big integer 4072M
While still connected to the database, issue the following SQL statement to show the actual PGA being used.
SQL> SELECT SUM(PGA_ALLOC_MEM)/1024/1024 "Total PGA Allocated (Mb)" FROM v$process p, v$session s WHERE p.addr = s.paddr;
However, it's not only user processes that use memory, there is also something called Shared Memory Segments. To determine the Shared Memory Segments, please use the following command.
ipcs -m
If there is only one Oracle database, the result may look like this:
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 20021251 oracle 640 2940928 94
0x00000000 20054020 oracle 640 7046430720 47
0x00000000 20086789 oracle 640 13836288 47
0x85e757a0 20119558 oracle 640 32768 47
If there are Shared Memory Segments where the owner column has a user other than oracle" then take note of how many bytes the Shared Memory Segments are using.
Now we can add up all the pieces of information, and then compare it to the amount of RAM the operating system has available.
The formulas are:
If the non-Oracle memory consumption + Oracle memory allocation is GREATER THAN the RAM (step 1), then the memory on the system has been over-subscribed.
To resolve the problem, then the choices are;
The PGA limit in an Oracle database is set by the Oracle database parameter PGA_AGGREGATE_TARGET. When an Oracle process exceeds the PGA limit, there are specific memory allocation names reported in the parentheses () of the ORA-04030 error. However, the RSA Identity Governance & Lifecycle product does not use the PL/SQL language components that can exceed the PGA limit.