Thank you for your response. It is apparent that I do not have a good
understanding of the matter.
"Howard J. Rogers" <howardjr_at_www.com> wrote in message
news:3b8b932f_at_news.iprimus.com.au...
> Of course it knows how much of the update was completed... it makes the
> database consistent as per the last checkpoint number.
>
> There is nothing, but nothing, that will get between you and an openable,
> consitstent database provided your redo logs (archived and online) are all
> intact.
>
> Regards
> HJR
>
>
> "Randy" <harrisr_at_bignet.net> wrote in message
> news:tom3b6fs0ftf0d_at_corp.supernews.com...
> > I would appreciate it if you could clarify this for me, I don't wish to
be
> > argumentative, I truly want to understand.
> >
> > Should the server happen to be in the midst of a large update when the
> > instance is aborted, per the Oracle docs, processing is immediately
halted
> > and uncommitted transactions are not rolled back. It seems to me that,
on
> > restart, SMON can indeed make the instance consistent as of the last
> > checkpoint and recover with the redo log, but it would have no way of
> > determining how much of that update was completed prior to the abort. I
> > think, under these circumstances, there could be a loss of data.
> >
> >
> > "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> > news:3b8aafa0_at_news.iprimus.com.au...
> > > Remember that a record is kept all the time of which checkpoint
sequence
> > > numbers are issued, and to what redo log sequence they relate. SMON
> > should
> > > therefore be very easily able to tell that all required redo for
> recovery
> > of
> > > an aborted mid-flight checkpoint is available in the current redo log,
> and
> > > perform automatic recovery itself without further intervention.
> > >
> > > Regards
> > > HJR
> > >
> > > "Charles J. Fisher" <cfisher_at_rhadmin.org> wrote in message
> > > news:Pine.LNX.4.33.0108271051340.9132-100000_at_galt.rhadmin.org...
> > > > On Sat, 25 Aug 2001, Howard J. Rogers wrote:
> > > >
> > > > > Conceivably, it would be possible to abort whilst a checkpoint is
> > > actually
> > > > > being issued, and CKPT has only got round to timestamping half the
> > data
> > > > > files... that would indeed require media recovery, but once again,
> > since
> > > all
> > > > > requisite redo is available in the current redo log, it wouldn't
be
> a
> > > big
> > > > > deal.
> > > >
> > > > So, has anybody ever seen this in practice?
> > > >
> > > > I assume that, were this to occur, Oracle would complain that
> datafiles
> > > > were in need of recovery and fail to start. Hopefully, the problem
> could
> > > > be resolved by a simple "recover automatic database" since the redo
> > would
> > > > be available (sans additional archived redo).
> > > >
> > > > It seems to me, however, that this is the ONLY case where a shutdown
> > abort
> > > > would result in an (immediately) unusable database assuming that the
> > media
> > > > is intact.
> > > >
> > > > If no one has ever actually seen this in the real world, then SMON
> must
> > > > have some way of automatically "rolling back" an in-flight
checkpoint.
> > > >
> > > > I myself use shutdown aborts in the cluster management software for
my
> > > > systems, and I read earlier in this thread that Oracle-supplied HA
> > scripts
> > > > do the same. However, I would be hesitant to do a nightly shutdown
> abort
> > > > for fear of a checkpoint problem.
> > > >
> > > > It would be interesting to have a definitive answer to this
question.
> > > > It's a shame that Oracle developers don't really seem to participate
> in
> > > > this forum.
> > > >
> > >
> > ---------------------------------------------------------------------
> > > -----
> > > > / Charles J. Fisher | A bad design with a good
> > > presentation /
> > > > / cfisher_at_rhadmin.org | is doomed eventually. A good
> > design
> > > /
> > > > / http://rhadmin.org | with bad presentation is
doomed
> > > /
> > > > / | immediately.
> > > /
> > >
> >
>
> --------------------------------------------------------------------------
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Received on Tue Aug 28 2001 - 23:28:31 CDT
