shutdown immediate 卡在SMON: disabling tx recovery

参照文档：ID 1076161.6

***Checked for relevance on 16-Dec-2011***


Description
===========
SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE hangs. 
In the alert.log, you see only the following:


Shutting down instance (immediate)
License high water mark = 12
Thu Dec  8 18:43:16 1994
alter database  close normal
Thu Dec  8 18:43:17 1994
SMON: disabling tx recovery
SMON: disabling cache recovery
or
        waiting for smon to disable tx recovery


There are no ORA- errors or trace files.






Scope & Application
===================
Informational


During a SHUTDOWN IMMEDIATE and SHUTDOWN NORMAL, SMON is cleaning up extents 
which are no longer needed and marking them as freed.


Either wait for SMON to clean up the free extents in the database as it 
shuts down or perform a SHUTDOWN ABORT to shutdown the instance. A SHUTDOWN
ABORT will not perform a clean shutdown.


Verify that temporary segments are decreasing
---------------------------------------------
To verify that the temporary segments are decreasing have an active session available 
in SQLPLUS during the SHUTDOWN IMMEDIATE. 
Issue the following query to ensure the database is not hanging, but is actually performs 
extent cleanup:


    SQL> select count(block#) from fet$;
    COUNT(BLOC
    ----------
             7


    SQL> select count(block#) from uet$;
    COUNT(BLOC
    ----------
           402  


After some time has elapsed, reissue the query and see that the values for fet$ 
have increased while the values or uet$ have decreased:


    SQL> select count(block#) from fet$;
    COUNT(BLOC
    ----------
            10


    SQL> select count(block#) from uet$;
    COUNT(BLOC
    ----------
           399


During shutdown the SMON process is cleaning up extents and updating the data 
dictionary tables with the marked free extents. As the extents are marked as 
freed, they are removed from the table for used extents, UET$ and placed on the
table for free extents, FET$.


How to Avoid creating many Temporary Extents
--------------------------------------------
Once the database has shutdown cleanly, to avoid creating many temporary
extents change the initial and next extent sizes on temporary tablespaces 
to a more appropriate size:


    ALTER TABLESPACE <temp> DEFAULT STORAGE (INITIAL <size>M/K NEXT <size>M/K);
 
Note:
=====
If the temporary tablespace is of type TEMPORARY, then this change will only 
affect temporary segments created after issuing the above command. 
Any existing temporary segments already in the TEMPORARY tablespace
will not be affected till the instance is restarted. On shutdown, existing temporary 
segments are dropped. If the TEMPORARY TABLESPACE is of type PERMANENT,
 then cleanup is performed by SMON after completion of the process using it.


Increasing the initial and next extent size will decrease the number of extents that 
are allocated to temporary segments. Since there are fewer extents to deallocate, 
the database should shutdown more speedily.


Take the following scenario:


A database was subject to large sorts with the following sort parameter in 
the "init.ora" file: 
 
         - sort_area_size=1000000 
 
The temporary tablespaces for this database were all created with initial and 
next extents sized at 50k and the total database size was about 300MB.  
 
Database sorts will utilize memory as much as possible based on the "init.ora"  
parameter "sort_area_size".  Once this memory-based sort area is filled, the  
database will utilize the temporary table space associated with the database  
user to complete the sort operation.  During a shutdown normal, the database  
will attempt to clean up the temporary tablespaces.   
 
If a small extent size is used, then a large number of extents will be created  
for a large sort.  The cleanup of the temporary tablespace takes much longer  
with a large number of extents.


Note:
=====
You have to do a shutdown abort and then bring the database back up 
to run the suggested queries.  


For other reasons for slow/hung shutdown see also these notes:

Note 375935.1 - What To Do and Not To Do When 'shutdown immediate' Hangs
Note 428688.1 - Bug:5057695: Shutdown Immediate Very Slow To Close Database.
   
References:
===========
Note 61997.1 - SMON - Temporary Segment Cleanup and Free Space Coalescing 
                      


Search Words:
=============
hanging
shutdown

说白了就是数据库在shutdown immediate的时候，需要释放已经使用的临时表空间，所以需要时间