ORA-27123: unable to attach to shared memory segment
HP-UX Error: 22: Invalid argument
You need to remove the shared memory for this instance.
One way to get the shared memory and semaphore identifiers from production
instances that cannot be brought down is as follows:
1. Log in to svrmgrl for each separate instance, connect internal, and issue
SVRMGR> oradebug ipc
This will return the following information for the instance:
-------------- Shared memory --------------
Seg Id Address Size
529 c8b77000 5140480
Total: # of segments = 1, size = 5140480
-------------- Semaphores ----------------
Total number of semaphores = 50
Number of semaphores per set = 50
Number of semaphore sets = 1
Semaphore identifiers: 23260
2. Record the Seg Id and Semaphore identifiers numbers for that instance. Do
this for each running instance that cannot be brought down, compare these
with the output of: (Do this at the Unix prompt.)
% ipcs -b
and the semaphore and shared memory id numbers that are owned by the
*NOTE: Do NOT remove any numbers that showed up in oradebug, these are
currently being used by your production instances. The remaining
shared memory and semaphores (owned by Oracle) are the ones that
need to be removed. These were reserved when your instance tried
to come up and were not removed when it did not mount successfully.
3. To remove these, do the following VERY CAREFULLY CHECKING YOUR NUMBERS
against the ones from oradebug:
% ipcrm -s [for Semaphores]
% %ipcrm -m [for Shared Memory]
4. Try to bring up your instance again.
*NOTE: Instances can have more than one semaphore set and/or shared memory.
Be SURE that you get ALL the id numbers for each instance, do not
assume that there is only one per instance.
There is a piece of shared memory still allocated for this particular instance.
Oracle 8.0.4 does not always clean up it's resources when an instance does not
successfully mount and they must be removed manually.
Can you afford to bounce the server? If so make increase the SEMMSL value in the etc/system file and bounce the server and retry starting it. On the other hand if you cannot do that, follow the folloing steps to deallcate some of the semaphores.
If you have two or more instances on your machine, perform the following
steps to ensure you do not remove the shared memory segments and semaphores on
the instances that are running.
1. At the os level, list the shared memory segments and semaphores for the
instance that you cannot start.
% ipcs -b
2. Log into svrmgrl.
3. Connect internal
svrmgrl> connect internal
4. List the semaphores and shared memory segments currently running on this
svrmgrl> oradebug ipc
5. Remove the shared memory segments and semaphores with PID's not associated
with the instances that are currently running on this machine as displayed
by the previous svrmgrl command.
% ipcrm -m /* remove shared memory segments
% ipcrm -s /* remove semaphores
But looking at the state looks like you have reached the max limit and there are no way for you to even try the deallocation. One way bounce the server after adding the changes. Then restart the instances. That should fix you the problem.
Here is another way (at least on Solaris): Look in the directory $ORACLE_HOME/dbs. You will find an entry like lkRAVITEST. Note the time of creation. Then run ipcs -a command and you will see bunch of shared memory segments. See for the one which was created at the same time as the lkRAVITEST above. Remove this shared memory segment by using the command ipcrm -m from the list you got from ipcs -a command. Be careful to note the correct id, otherwise you may end up damaging other databases.