RE: shutdown abort to move data files
- From: "Goulet, Dick" <DGoulet@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 8 Jul 2004 12:59:30 -0400
OK, I stand corrected. Immediate use to wait for current transactions =
to complete, shutdown transactional is the replacement in that case. =
Shutdown normal waits for all sessions to close normally. And I beg to =
differ on SMON cleaning up temp. It is VERY fast at that task even if =
you have GB of temp in use. On the other hand after an abort SMON will =
be one VERY busy puppy rolling back all those uncommitted transactions =
that you left around. I use immediate a lot & don't have problems with =
it, except if we have to shutdown at an unaccounced/uncordinated time. =
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 =
current
transaction to end, only shutdown normal will wait for the transaction =
to
end. The main reason shutdown immediate wait is , SMON will try to =
cleanup
the temp space before shutdown. Incase if you issue shutdown abort and =
upon
next time you startup, during initial period your SMON will be working =
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 =3D
long? There are a number of answers, some of which you could fix, =3D
others that need "indoctrination". First on the list is how big is the =
=3D
SGA? If your DB_BLOCK_BUFFERS (since your on 8i) are REALLY huge then =
=3D
that could be one of the slowing factors. Consider reducing them. Next =
=3D
is how many end user sessions are busy at the time. Remember an =3D
immediate will wait till their current transaction is finished before =
=3D
shutting down. Can you get the owners of these sessions to agree to a =
=3D
date/time when you'll do maintenance. Third are the number of dead or =
=3D
sniped sessions in your database. This one really torques my jaws. End =
=3D
users who start an application that uses the database & then walk away =
=3D
believing that it "will take care of itself". Consider setting =3D
resource_limit=3D3Dtrue & setting up profiles with "reasonable" idle =
time =3D
periods. Most of my end users have a 30 minute idle timeout, but I did =
=3D
have one that was set to 1 minute because he was a perpetual offender. =
=3D
OH, then there's my personal favorite, the end user who starts his/her =
=3D
application and then powers their workstation down. Windoze is not =3D
always graceful on this count. All of these will cause an immediate to =
=3D
slow down. Fix the problem, not the symptom. Crashing the database may =
=3D
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?
=3D20
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
-----------------------------------------------------------------
Other related posts:
