DBAsupport.com Forums - Powered by vBulletin
Results 1 to 5 of 5

Thread: Not able to startup the database

  1. #1
    Join Date
    Jul 2000
    Posts
    9
    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

  2. #2
    Join Date
    Aug 2000
    Location
    Belgium
    Posts
    342
    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

  3. #3
    Join Date
    Jul 2000
    Posts
    9
    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

  4. #4
    Join Date
    Oct 2000
    Location
    Saskatoon, SK, Canada
    Posts
    3,925
    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!


  5. #5
    Join Date
    Apr 2001
    Posts
    6
    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
  •  


Click Here to Expand Forum to Full Width