-
Hi,
I am trying to start a database I am getting the below error.
SVRMGR> startup
ORA-00600: internal error code, arguments: [SKGMBUSY], [1], [0], [0], [0], [], [], []
ORA-27123: unable to attach to shared memory segment
HP-UX Error: 22: Invalid arg
I appreciate if some one can help me in solving this.
Total I have 2 database on this machine. The SGA for the first one is 350 MB
Thanks in advance
JG
-
Found on Metalink :
Problem Description:
====================
You are trying to start an instance with Oracle v8.0.4, and you receive the
following errors:
SVRMGR> connect internal
Connected.
SVRMGR> startup nomount
ORA-00600: internal error code, arguments: [SKGMBUSY], [1], [0], [0], [0],
[], [], []
ORA-27123: unable to attach to shared memory segment
HP-UX Error: 22: Invalid argument
SVRMGR>
Solution Description:
=====================
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
the command:
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
Oracle user.
*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.
Explanation:
============
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.
References:
===========
Search Words:
=============
ora-600, 600, Server Manager
Regards
Gert
-
SVRMGR> oradebug ipc
When execute the above commnd I am getting the below error.
ORA-00600: internal error code, arguments: [SKGMBUSY], [1], [0], [0], [0], [], [], []
ORA-00600: internal error code, arguments: [SKGMBUSY], [1], [0], [0], [0], [], [], []
Thanks
Jagdish
-
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.
% svrmgrl
3. Connect internal
svrmgrl> connect internal
4. List the semaphores and shared memory segments currently running on this
machine.
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.
Sam
Thanx
Sam
Life is a journey, not a destination!
-
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.
HTH,
Ravi
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|