| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Online backup: Backup online redologs?
"Charles J. Fisher" <cfisher_at_rhadmin.org> wrote in message
news:Pine.LNX.4.33.0106120845170.16907-100000_at_galt.rhadmin.org...
> On Tue, 12 Jun 2001, Howard J. Rogers wrote:
>
> > > Couchman has been wrong many times, but here are his comments from the
8i
> > > OCP book:
> > > "Oracle uses SCNs in control files, datafile headers, and redo
records.
> > > Every redo log file has both a log sequence number and low and high
SCN.
> > > The low SCN records the lowest SCN recorded in the log file, while the
> > > high SCN records the highest SCN in the log file. CKPT writes those
> > > numbers to the datafiles and to the control file. The checkpoint
number is
> > > also written to the redo log file. When the database starts, all
> > > checkpoint sequence numbers in all datafiles, redo log files, and
control
> > > files must match. If they do not, Oracle will not start, and you must
> > > perform media recovery on your database to get the files synchronized
and
> > > in a consistent state." (p. 669)
> > > This seems to imply to me that interrupting an in-flight checkpoint
with a
> > > shutdown abort can be deadly.
> > No, it's not deadly.
> > Shutdown abort requires an Instance Recovery every time, but that's not
a
> > problem, since the relevant redo will be available in the current redo
log.
> > There's nothing terribly magical about a shutdown abort: pull the plug
out
> > of your server and you've just performed a functionally-equivalent
shutdown.
> > So if shutdown abort could be 'deadly' then so could power failure be...
and
> > I doubt Oracle would have such a large market share if its principle
product
> > couldn't cope with intermittent power outages.
> > I think the real issue is that there is a difference between the SCN
> > assigned to each transaction as it's committed, and which gets written
into
> > the logs, and the sequence numbers that CKPT writes into the headers of
all
> > files at a checkpoint. Media failure means those CKPT numbers will be
out
> > of synch. Instance Failure means CKPT's numbers are perfectly
consistent
> > with each other... but there are still SCNs assigned *after* the last
CKPT
> > number.
>
> Well, the warning above sounds pretty scary. I do get into situations
> where a shutdown immediate hangs (somtimes if I wait 5 or 10 minutes, it
> will complete). I suppose that I could select from v$process in such a
> situation and I might find something to kill, but I've never tried it.
>
Well, the immediate option is supposed to take a while (I've seen one take 6 hours) because it has to kill processes off for you, and roll whatever they were in the middle of, back (there were about 120,000 pending transactions on the 6 hour job).
> In such a situation, with a hung shutdown immediate, I would like some
> method of ensuring that this information is synchronized between the
> datafiles before I proceed with an abort.
Wouldn't worry about it. Synchronization will happen next startup. Just don't lose your current redo log in between the shutdown and the startup!
>
> If Oracle doesn't want me to get skittish about this warning, then they
> shouldn't put such inflammitory things in the documentation. It is hard to
> accept such material as dogma when it is so full of holes.
>
True, but then Couchman isn't Oracle (neither is Oracle Press, though the exact nature of the relationship escapes me right now). But even re-reading the paragraph you quoted above, all he says is that 'media recovery will be needed'. Recovery is not a big deal (no, it's not nice, either!), provided you are doing everything right. Always bear in mind that, if you are doing things right, Oracle guarantees that you will *never* lose a committed transaction. However you do your shutdowns.
> p.s. Guess what, Howard? I passed the 8i OCP exam #2 last week. Heaven
> help us!
Congratulations. When's number three (there's no rest for the DBA!!)
Regards
HJR
>
> ----------------------------------------------------------------------
 |
 |