This note apply to Oracle Database Enterprise Edition – Version 184.108.40.206 to 220.127.116.11
The system appears to be running very slowly and defunct processes can appear.
Errors are seen in the alert log or Trace log :
ORA-04031: unable to allocate 4160 bytes of shared memory (“shared pool”,”unknown object”,”sga heap(1,0)”,”modification “)
Incident details in: /u01/app/oracle/diag/rdbms/prod/prod1/incident/incdir_1080893/prod1_m000_26285_i1080893.trc
Errors in file /u01/app/oracle/diag/rdbms/prod/prod1/trace/prod1_m000_26285.trc (incident=1080894):
ORA-04031: unable to allocate ORA-04031: unable to allocate 4160 bytes of shared memory (“shared pool”,”unknown object”,”sga heap(1,0)”,”modification “) bytes of shared memory (“”,””,””,””)
Incident details in: /u01/app/oracle/diag/rdbms/prod/prod1/incident/incdir_1080894/prod1_m000_26285_i1080894.trc
2. PGA getfail
AUTO MEM: PGA getfail 13 for 38, 11, 1, 67108864, 13555990528, 2550136832, 38, 16106127360, 2
AUTO MEM: backup fail a, 0, 67108864, 202, 202, 0, 86
ORA-00445: background process “m001” did not start after 120 seconds
Incident details in: /opt/u01/app/oracle/diag/rdbms/incident/incdir_3721/db1_mmon_7417_i3721.trc
ERROR: Unable to normalize symbol name for the following short stack (at offset 2):
Tue Jun 21 03:03:06 2011
ORA-00445: background process “J003” did not start after 120 seconds
4. Waited for process W002
Waited for process W002 to initialize for 60 seconds
Recent linux kernels have a feature called Address Space Layout Randomization (ASLR).
ASLR is a feature that is activated by default on some of the newer linux distributions.
It is designed to load shared memory objects in random addresses.
In Oracle, multiple processes map a shared memory object at the same address across the processes.
With ASLR turned on Oracle cannot guarantee the availability of this shared memory address.
This conflict in the address space means that a process trying to attach a shared memory object to a specific address may not be able to do so, resulting in a failure in shmat subroutine.
However, on subsequent retry (using a new process) the shared memory attachment may work.
The result is a “random” set of failures in the alert log.
You can verify whether ASLR is being used as follows:
# /sbin/sysctl -a | grep randomize
kernel.randomize_va_space = 1
If the parameter is set to any value other than 0 then ASLR is in use.
On Redhat 5 to permanently disable ASLR:
Add/modify this parameter in /etc/sysctl.conf
You need to reboot for kernel.exec-shield parameter to take effect.
Note that both kernel parameters are required for ASLR to be switched off.
There may be other reasons for a process failing to start, however, by switching ASLR off, you can quickly discount ASLR being the problem. More and more issues are being identified when ASLR is in operation.
Good Luck !