SHUTDOWN: waiting for active calls to complete.
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 8 of 8

Thread: SHUTDOWN: waiting for active calls to complete.

Hybrid View

  1. #1
    Join Date
    Sep 2001
    Location
    London
    Posts
    26

    Cool

    Hi there

    I had a slight problem with my backup on my prod. dbase last night which ended when the database would not shut down before doing the cold backup. Looking thru the trace file revealed the line:

    SHUTDOWN: waiting for active calls to complete.

    I have checked through Metalink and this of course comes down to Oracle awaiting the clean-up of uncommitted transactions and/or the clean-up of existing processes. This is the first time this problem has happened in 18 months. Have others had this problem and what did they do to ensure it didnt happen. Thanks in advance

    Bruce

  2. #2
    Join Date
    Nov 2000
    Location
    greenwich.ct.us
    Posts
    9,092
    Are you using shutdown immediate or shutdown normal?
    Jeff Hunter
    marist89@yahoo.com
    http://marist89.blogspot.com/
    Get Firefox!
    "I pledge to stop eating sharks fin soup and will not do so under any circumstances."

  3. #3
    Join Date
    Sep 2001
    Location
    London
    Posts
    26
    its shutdown immediate. Sorry for not making it clearer. Any ideas???

  4. #4
    Join Date
    Aug 2000
    Location
    Chicago IL
    Posts
    586
    you will have to write a logic within your shutdown script to sleep your script for 15 mins after shutdown immediate...then check for pmon to see if its up and grep the alert_log for Shutdown: waiting for calls to complete. If true then shutdown abort...and wait about 2 mins then startup the database and email and page you.

    thats what i did.

    let me knwo if you find a workaround
    "High Salaries = Happiness = Project Success."

  5. #5
    Join Date
    Sep 2001
    Location
    London
    Posts
    26

    Smile

    Hi there

    Thanks for the reply. As I inherited this backup script which is quite complex I would need some help to sort it out. I like the idea which you have suggested. Metalink were not that helpful
    Before issuing the shutdown command issue:

    Alter session set events '10400 trace name context forever, level 1';
    shutdown immediate

    This will produce a few trace files in your "user_dump_dest" directory."user_dump_dest" is an "init.ora" parameter. The trace file will be a systemstate dump. Upload the trace files. From the trace files, it can be seen that what processes are still active.

    Many Thanks!

  6. #6
    Join Date
    Aug 2000
    Location
    Chicago IL
    Posts
    586
    you can setup that
    "Alter session set events '10400 trace name context forever, level 1'; shutdown immediate " in your shutdown script.
    "High Salaries = Happiness = Project Success."

  7. #7
    Join Date
    Aug 2001
    Posts
    64
    I've checked the alter session synthax out using Oracle8 the complete ref, but
    there's no reference to "event", could someone explain this synthax?
    Thanks.

  8. #8
    Join Date
    Sep 2001
    Location
    London
    Posts
    26
    Hi there

    I hope I have not confused anyone. The official line from Metalink is:

    This message is written to the alert log when the database is waiting for pmon to clean up processes, but pmon is unable to
    clean them. The client connections to the server are causing the shutdown immediate or normal to hang. The workaround in such a situation will be to kill such processes ( Refer Note:1039146.6).

    If there were no client connection at the time of issuing this command, then please do the following.

    Before issuing the shutdown command issue:

    Alter session set events '10400 trace name context forever, level 1';
    shutdown immediate

    This will produce a few trace files in your "user_dump_dest" directory."user_dump_dest" is an "init.ora" parameter. The trace file will be a systemstate dump. Upload the trace files. From the trace files, it can be seen that what processes are still active.

    The other workaround in this case will be to shutdown with:

    shutdown abort
    startup restrict
    shutdown normal

    Since it happened only once, I would suspect that there might be some long running transaction going on in any of the sessions that were present at the time of shutdown. This could have caused because the shutdown was waiting for this transaction to roll back completely. There are no known bugs on this. The other possibility of this could be that there are some blocking processes present in the system, which caused some of the other sessions to hang. The trace file generated by event 10400 will help to analyze such a scenario

    I hope this info helps. Thanks for your input.



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