3 Replies Latest reply on Apr 26, 2011 6:57 PM by Tom

    Specifying SHUTDOWN options

      Version : 10gR2

      While i was shutting down a RAC DB , i have noticed that
      srvctl stop instance -d orcl -i orcl2 -- Without any options 
      is faster than
      srvctl stop instance -d orcl -i orcl2 -o immediate
      Which one shuts down the instance faster?

      ps: ABORT is not an option for me

      Edited by: Tom on Apr 26, 2011 9:00 AM
        • 1. Re: Specifying SHUTDOWN options
          Rajesh Lathwal
          IMHO , It should not make any difference because the default option is Immediate . because if you don't specify anything in srvctl , it takes immediate as default.

          Also You need to mention stop instead of start in srvctl syntax.

          1 person found this helpful
          • 2. Re: Specifying SHUTDOWN options
            Levi Pereira
            Which one shuts down the instance faster?
            Except SHUTDOWN ABORT the SHUTDOWN IMMEDIATE is to be the fastest.

            Immediate database shutdown proceeds with the following conditions:
            No new connections are allowed, nor are new transactions allowed to be started, after the statement is issued.
            Any uncommitted transactions are rolled back. (If long uncommitted transactions exist, this method of shutdown might not complete quickly, despite its name.)
            Oracle Database does not wait for users currently connected to the database to disconnect. The database implicitly rolls back active transactions and disconnects all connected users.

            However, in practice, some factors may occur and the SHUTDOWN IMMEDIATE can take long time to complete.
            In file ALERTLOG of Instance, appear the reason of Instance take long time to shutdown.

            Generally one of the three might be happening:
            Uncommitted transactions are being rolled back.
            SMON is cleaning temp segments or performing delayed block cleanouts.
            Processes still continue to be connected to the database and do not terminate.

            So, before issuing the shutdown immediate, it would be recommended to check the following views, especially when the database needs to be brought down for a very short period of time:

            1. for large queries:
            select count(*) from v$session_longops where time_remaining>0;
            2. for large transactions:
            select sum(used_ublk) from v$transaction;
            A result greater than 0 for the first query and a large value returned for the second one would mean a relatively long time to wait until the shutdown immediate completes.

            Isn't Oracle's recommendation, but whenever the Shutdown Immediate hang and I check if the problem is associated with long operations, so I kill all processes of sessions by the operating system. After that I start Instance in restricted mode and issue the shutdown (normal).

            I do follow these steps to force the clean shutdown.

            1. Check if there are any connection present at the database as:
            $ ps -eaf | grep LOCAL
            It will give you the OSPIDs of the client connected to database.

            2. Manually kill them as:
            # Kill -9 <OSPID>
            or you can use this script carefully.

            The Script below kill only remote sessions on Instance db10g1.
            for i in `ps -ef |grep "oracledb10g1 (LOCAL=NO)" |grep -v grep | awk '{print $2}'` 
             echo  kill -9  $i
            3. Follow the file ALERTLOG if instance is shutdown.

            You can use this useful docs to understand about "HANGs on SHUTDOWN IMMEDIATE":
            *What To Do and Not To Do When 'shutdown immediate' Hangs [ID 375935.1]*
            *How to Check Why Shutdown Immediate Hangs? [ID 164504.1]*
            *Shutdown Normal or Shutdown Immediate Hangs. SMON disabling TX Recovery [ID 1076161.6]*

            Levi Pereira
            • 3. Re: Specifying SHUTDOWN options
              Thanks for pointing that out Rajesh. I've corrected it.

              Thank you Levi.