RE: shutdown abort to move data files

  • From: "Bobak, Mark" <Mark.Bobak@xxxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 8 Jul 2004 14:03:04 -0400

shutdown normal -- wait for all users to disconnect.  Could be waiting a =
LONG time.
shutdown transactional -- wait for all open transactions to commit or =
rollback.  Again, could wait a long time.
shutdown immediate -- kill all sessions, rollback any aborted =
transactions.  Still could take a while, but generally faster than =
either of the first two.
shutdown abort --  go down right now.  Not much different than killing a =
background process.  Unlike last three, this will leave database in an =
inconsistent state.  Next startup will need to do instance recovery.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Goulet, Dick
Sent: Thursday, July 08, 2004 12:59 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: shutdown abort to move data files


OK, I stand corrected.  Immediate use to wait for current transactions =
=3D
to complete, shutdown transactional is the replacement in that case.  =
=3D
Shutdown normal waits for all sessions to close normally.  And I beg to =
=3D
differ on SMON cleaning up temp.  It is VERY fast at that task even if =
=3D
you have GB of temp in use.  On the other hand after an abort SMON will =
=3D
be one VERY busy puppy rolling back all those uncommitted transactions =
=3D
that you left around.  I use immediate a lot & don't have problems with =
=3D
it, except if we have to shutdown at an unaccounced/uncordinated time.  =
=3D
Then yes, it can take a significant amount of time to do it's thing.

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Satheesh Babu.S [mailto:satheesh.babu@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, July 08, 2004 12:44 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: shutdown abort to move data files


Dick,
  beg to differ with you. Shutdown immediate will not wait for the =3D
current
transaction to end, only shutdown normal will wait for the transaction =
=3D
to
end. The main reason shutdown immediate wait is , SMON will try to =3D
cleanup
the temp space before shutdown. Incase if you issue shutdown abort and =
=3D
upon
next time you startup, during initial period your SMON will be working =
=3D
hard
to cleanup the temp space.

Thanks and Regards,
Satheesh Babu.S
Bangalore.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Goulet, Dick
Sent: Thursday, July 08, 2004 10:06 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: shutdown abort to move data files


David,

        I believe I'd start asking why does a "shutdown immediate" take so =
=3D3D
long?  There are a number of answers, some of which you could fix, =3D3D
others that need "indoctrination".  First on the list is how big is the =
=3D
=3D3D
SGA?  If your DB_BLOCK_BUFFERS (since your on 8i) are REALLY huge then =
=3D
=3D3D
that could be one of the slowing factors.  Consider reducing them.  Next =
=3D
=3D3D
is how many end user sessions are busy at the time.  Remember an =3D3D
immediate will wait till their current transaction is finished before =
=3D
=3D3D
shutting down.  Can you get the owners of these sessions to agree to a =
=3D
=3D3D
date/time when you'll do maintenance.  Third are the number of dead or =
=3D
=3D3D
sniped sessions in your database.  This one really torques my jaws.  End =
=3D
=3D3D
users who start an application that uses the database & then walk away =
=3D
=3D3D
believing that it "will take care of itself".  Consider setting =3D3D
resource_limit=3D3D3Dtrue & setting up profiles with "reasonable" idle =
=3D
time =3D3D
periods.  Most of my end users have a 30 minute idle timeout, but I did =
=3D
=3D3D
have one that was set to 1 minute because he was a perpetual offender.  =
=3D
=3D3D
OH, then there's my personal favorite, the end user who starts his/her =
=3D
=3D3D
application and then powers their workstation down.  Windoze is not =
=3D3D
always graceful on this count.  All of these will cause an immediate to =
=3D
=3D3D
slow down.  Fix the problem, not the symptom.  Crashing the database may =
=3D
=3D3D
well cause more harm, read that as recovery time, than good.

Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA

-----Original Message-----
From: Nguyen, David M [mailto:david.m.nguyen@xxxxxx]
Sent: Thursday, July 08, 2004 11:48 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: shutdown abort to move data files


I need to shutdown oracle8i database to move data file to another disk
but it takes about 40 minutes to shutdown immediate.  Can I go ahead to
issue "shutdown abort" then move data file?  Does it hurt anything?
=3D3D20

Thanks,

David


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: