Oracle Server – Enterprise Edition – Version: 11.1.0.6 to 11.1.0.7 – Release: 11.1 to 11.1
Symptoms

 

/dev/shm is being filled up with files in the format JOXSHM_EXT_???_SID_???? and eventually causing the DB to restart. Oracle is not automatically cleaning those files.

Please note that it is OS specific whether such segments are visible on a filesystem or not, and if so where they get placed. eg: On Solaris shm_open() internally creates a file in /tmp with the prefix .SHMD and less the leading “/” from the shm_open argument whereas on Linux it creates an entry in /dev/shm

Changes
Most probably the database has not been closed cleanly.
Cause
This issue has been described in
<< Bug.6820987 >> /DEV/SHM IS NOT BEING CLEANED UP ON NODE 1
which was closed as duplicate of
Unpulished Bug.6662381 JOXSHM_EXT LEFT AFTER SHUTDOWN IMMEDIATE
which was closed as duplicate of
Unpublished Bug 9021155 APPSST GSI 11G: NATIVE PL/SQL CACHE FILES MAKES /TMP SLOW AND UNUSABLE

It has been determined by development that the cause of such issue is due to the fact that the database has not be closed cleanly at some point in time.

This has also been documented in the following documentation:
http://download.oracle.com/docs/cd/E17116_01/doc/readmes.112/e11015/toc.htm#BABBCFHJ
Solution
The shared object files are only freed up by the oracle executable if you do a normal shutdown.

They will build up if you shutdown abort or shutdown immediate.

This behaviour is NOT changed in any version – or changed by the fix for unpublished Bug 9021155.

1. Check if the one off Patch 9021155 is available on My Oracle Support for your Oracle version and platform. The fix for Bug 902115 allows you to specify a directory so that if you have more then one instance on a machine you are able to identify the shared files associated with a particular instance, so that you do not inadvertently clean up files from another running instance.

OR

2. Use one of the workarounds provided below:

a. Rebooting the server from time to time as this clears those files
OR
b. In 11.1.0.7 the “id” part of the name is the shared memory id of the shared memory for the instance.
eg: “ipcs -ma” ID column value is the “id” part of the name. This is not documented / guaranteed but does
give a way to see if a file corresponds to a running instance. For the files that you have you should first check
if the tail number matches to a valid SHM ID (as reported by ipcs -ma) .If not then the files are probably stale old copies and you can go ahead and delete those files. If so then those files are related to a currently running instance and deleting those files can lead to unpredictable results. Instead you can add the following code before you startup or after you shutdown the instance:

rm -f /dev/shm/JOXSHM_EXT_*_<instance name>_*
rm -f /dev/shm/PESHM_EXT_*_<instance name>_*

Again please note that the directories referenced above are OS specific and should be modified according to your OS. The above applies to Linux.