Re: Why is on-line backup one tablespace a time?

"Dino Hsu" <dino1_nospam_at_ms1.hinet.net> wrote in message news:4m5jotc2v1rfe1ldspd369nphtmbfa2h6f_at_4ax.com...
> On Mon, 27 Aug 2001 06:00:52 +1000, "Howard J. Rogers"
> <howardjr_at_www.com> wrote:
>
> >snip
> >
> >Provided you retain all redo from the time the *first* tablespace went
into
> >hot backup mode, the fact that your backup copies are not from the same
> >timeslot is irrelevant for the purposes of recovery.
> >
> >Regards
> >HJR
> >
>
> Do you mean that the backup of datafiles + online redo logs will do
> for recovery even there are time-difference among the backed-up
> tablespaces?

Did I mention online redo? I said 'all redo since the time the tablespace went into backup mode'. That means all redo... you need backups of your online redo logs, for sure -and they are called archived redo logs.

The current log cannot be 'backed up', so that needs to be available too.

>In terms of transaction management or SCNs, please
> explain why this is recoverable?

Er... because the application of redo makes datafiles consistent one with another, and all with the controlfile. So provided all redo is available since the *first* datafile goes into backup mode, there cannot, by definition, be a datafile which cannot be rolled forward by the application of redo, and hence made consistent with the rest of the database.

>On the other hand, as long as redo
> logs are not backed up, the database is still unrecoverable. How can
> redo logs be backuped up without the instance down? (In the control
> file case, 'alter database backup controlfile' will do on-line
> backups)
>

Archived redo logs are the backup of online redo logs. Online redo logs can *never* be copied reliably by yourself. That's why we have ARCH.

> One practical question: do you do this in batch with a script or do it
> interactively? Thanks again.

Depends on the database, but scripts would be more usual.

Regards
HJR
>
> Dino
>
Received on Mon Aug 27 2001 - 05:29:55 CDT