Re: Online backup: Backup online redologs?

"Charles J. Fisher" <cfisher_at_rhadmin.org> wrote in message news:Pine.LNX.4.33.0106100922500.13875-100000_at_galt.rhadmin.org...
> On Fri, 8 Jun 2001, Ravi Sista wrote:
>
> > PS : I tend to agree with Howard on this one. I don't think the way you
> > shut the database down matters (as long as it is down, when you started
> > the cold backup) when it comes to the validity of your cold backups. Any
> > one else with an opinion on this one? Thanks in advance.
>
> 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.

>
> In an apparent contradiction, he goes on to say:
>
> "A point was made earlier that SMON will perform instance recovery if it
> detects that the datafiles are not synchronized. Recall that part of the
> work done in a checkpoint is to write the SCN to datafile headers and copy
> data in the buffer cache and log buffer to their respective disk files.
> This process synchronizes all Oracle files. If the instance crashes, these
> files will not be synchronized because Oracle did not have the opportunity
> to synchronize them before the instance failed. SMON will synchronize them
> for you automatically." (p. 678)
>
> To me, it is unclear where out-of-phase checkpoint information requires
> instance recovery (SMON) or media recovery.

On the Backup and Recovery course, I put it this way. Media Recovery is what you do when the SCNs don't agree with each other (because you've restored a file from last night's backup). Instance Recovery is what happens when SMON spots (at startup) that whilst all the files have the same SCN, there are transactions hanging off the point of the last checkpoint. That can never normally happen (since the last thing that happens to a database during any clean shutdown is that a checkpoint is issued). It's the presence of those transactions after the last checkpoint that prompts SMON to automatically replay them (ie, perform Instance Recovery).

Now, none of that may be spot on technically accurate, but it's close enough and points out the essential difference.

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.

Regards
HJR Received on Tue Jun 12 2001 - 01:51:17 CDT