Shutdown Abort！！！

owen · 发表于 2001-11-15 21:05

做过很多次shutdown abort ，每次都胆战心惊的怕起不来，
今天又干了一会，我觉得有必要总结一下，大家也可以共同
提高。
   我今天的步骤:
      1.shutdown immediate
      2.  five minutes later
      3. 发现alert.log中出现了
  SHUTDOWN: waiting for active calls to complete.
      4.kill  corresonding server process
      5. seven minutes later
      6. 发现alert.log中出现了
  Waiting for smon to disable tx recovery.
      7.我没招了只有abort
alert.log:
Shutting down instance (immediate)
License high water mark = 163
Thu Nov 15 12:31:18 2001
SHUTDOWN: waiting for active calls to complete.
Thu Nov 15 12:33:03 2001
ALTER DATABASE CLOSE NORMAL
Thu Nov 15 12:38:07 2001
Waiting for smon to disable tx recovery.
Thu Nov 15 12:43:30 2001
Shutting down instance (abort)
License high water mark = 163
Instance terminated by USER, pid = 20092

请问:
tx recovery 什么?
shutdown 不了的原因是什么

Yong Huang · 发表于 2001-11-16 03:25

Whenever you can't shutdown immediate, shutdown abort. Don't worry any more. It's a myth that shutdown abort causes Oracle to be unrecoverable.

There're many reasons shutdown immediate hangs. Most likely it's just rolling back transactions that takes too long. Just be patient. If you're not, shutdown abort and startup.

Yong Huang

最初由 owen 发布
[B] 做过很多次shutdown abort ，每次都胆战心惊的怕起不来，
今天又干了一会，我觉得有必要总结一下，大家也可以共同
提高。
   我今天的步骤:
      1.shutdown immediate
      2.  five minutes later
      3. 发现alert.log中出现了
  SHUTDOWN: waiting for active calls to complete.
      4.kill  corresonding server process
      5. seven minutes later
      6. 发现alert.log中出现了
  Waiting for smon to disable tx recovery.
      7.我没招了只有abort
alert.log:
Shutting down instance (immediate)
License high water mark = 163
Thu Nov 15 12:31:18 2001
SHUTDOWN: waiting for active calls to complete.
Thu Nov 15 12:33:03 2001
ALTER DATABASE CLOSE NORMAL
Thu Nov 15 12:38:07 2001
Waiting for smon to disable tx recovery.
Thu Nov 15 12:43:30 2001
Shutting down instance (abort)
License high water mark = 163
Instance terminated by USER, pid = 20092

请问:
tx recovery 什么?
shutdown 不了的原因是什么
[/B]

owen · 发表于 2001-11-16 11:23

我做shutdown之前都是先kill session, kill server process, alter system
switch logfike , alter system checkpoint 完成后才做shutdown的啊，
rollback 的问题可以排除，我不解的是 tx 是什么东东

chao_ping · 发表于 2001-11-16 12:30

kill session, switch logfile, checkpoint之后，不用rollback吗？肯定还是要的！
tx recovery 我觉得应该是transaction recovery吧？猜的，正在检索过程中....

owen · 发表于 2001-11-16 12:46

我知道要rollback，不过我是说可以等一段时间，先停tns,
估计差不多了再down啊？

oramind · 发表于 2001-11-16 12:51

technically, shutdown abort crashes the database. but sometimes if you don't want to wait for a long rollback, then just do it. i haven't had problem with it. though i did have problem with very long shutdown immediate (hours), and i got a little impatient

in general, knowing that i have good cold backup and all archive logs, i am not too too worried.

also this excerpt from kevin looney:

For example, deadlocked users can prevent a SHUTDOWN IMMEDIATE from working. Also, "memory leaks" can keep the database in a suspended mode - in which the only solution is to SHUTDOWN ABORT.

chao_ping · 发表于 2001-11-16 13:15

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 Server Manager during the SHUTDOWN IMMEDIATE. Issue the following
query to ensure the database is not hanging, but is actually perform extent
cleanup:

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

SVRMGR> 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:

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

SVRMGR> 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> 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.

References:
===========
[NOTE:61997.1] SMON - Temporary Segment Cleanup and Free Space Coalescing

owen · 发表于 2001-11-16 21:19

if the type of TEMPORARY TABLESPACE is PERMANENT , smon
must cleanup it and free extents before instance shutdown;
but when we use TEMPORARY tbs, how would ORACLE do?
besides, what is 'disabel tx recovery' is not clear now, who can tell me?

chao_ping · 发表于 2001-11-18 21:24

"Disable tx recovery': seems like free up temporary segment.
From the note:
During a SHUTDOWN IMMEDIATE and SHUTDOWN NORMAL, SMON is cleaning up extents
which are no longer needed and marking them as freed
Not sure.
If temporary tablespace is "temporary",Oracle still have other things to do

opcer · 发表于 2006-9-21 10:11

Shutdown Abort！！！

Re: Shutdown Abort！！！

关于 TX recovery：