I have seen file corruption after a shutdown abort. Granted it was in
early 8i but it "
could" happen. Just think what an abort
actually is, the processes are killed and all shared memory segments
and semaphores are released. If a write operation or long running
checkpoint is in progress you stand a very good chance of file
corruption.
Test it out, create a situation that would require some length of time
to perform a checkpoint, or a rollback and shutdown abort (or crash,
cause thats what it is) the database.
Just my .02
Mike Haddon
The last time I checked, admittedly in the 8.1.7 world, oracle
stated that you could end up with file corruption on a shutdown abort
(note that is could, not would, I never had it happen), If they
have changed this and now say that a shutdown abort is as safe as a
shutdown immediate, I have not heard it. Does anyone have a
statement from oracle to that effect?
What happens if you have datafiles in backup mode and you try and do a
startup force?
I agree with
Jared, whats up with this? Yes, a shutdown abort assures that you will
be doing crash/instance recovery, but so what? If you are truly
concerned about that, do a checkpoint before you do the shutdown abort
(assuming that does not take forever). In what cases will a shutdown
require media recovery? I know of none unless you are planning on
rm'ing a bunch of datafiles afterwards.
One of the
beauties of Oracle, and a fact that seems little known, is the rule
with regards to checkpoints and redo logs. Everyone knows that a redo
log can not be reused in ARCHIVELOG mode until the archived redo log is
created. What seems less known is the rule that an online redo log can
not be reused until all dirty blocks associated with that online redo
log have been checkpointed and written to the datafiles. Thus, shutdown
abort should NEVER lead to a media recovery.
'If at first you dont succeed, dont take up skydiving.'
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jun 27 2007 - 20:20:57 CDT