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

On Mon, 27 Aug 2001 20:35:00 +1000, "Howard J. Rogers" <howardjr_at_www.com> wrote:

>Cut to the chase.
>
>File 1 gets backed up when its sequence number is 17001. File 2 when its
>sequence number is 18003, File 3 when its sequence number is 19003, and file
>4 when its sequence number is 20005.
>
>All archives are available since time 17001, and the current redo log is
>multiplexed and is thus safe and sound.
>
>The current database sequence number is 23456.
>
>File 3 blows up. You restore it. SMON, at startup notices that 19003
>doesn't agree with the controlfile & other files at 23456. It will prompt
>for recovery -ie, the application of the transactions related to sequence
>19004. Can you supply it? Yes -it's in the archive logs. Can you supply
>19006? Yup. 19907? Yup. And so on. And as those transactions are
>re-applied to file 3, so it gets closer and closer to time 23456.
>
>There comes a point where file 3 IS at time 23456. Media Recovery Complete,
>Alter Database Open.
>
>This is reasonably basic stuff. You need to read up on it. Please see
>http://www.geocities.com/howardjr2000, and navigate to Courses, Backup and
>Recovery, and download the 70 page document I posted there.
>
>Regards
>HJR
>
>

This clerifies my question. I will try to re-phrase it as follows: A datafile (not all datafiles of a tablespace) is an atomic entity of recoverability, or 'unit of recovery' (as is 'unit of work' for transaction). SMON can synchronize datafiles of t1, t2, t3, ... tn (t1<t2<t3<...<tn), as long as logs (archived or on-line) between t1 and tn are there. Typically in a recovery scenario, all datafiles are of tn (the moment of crash) except on or more datafiles are of tm, m in (1,n-1), and SMON will synchronize it or them up to tn, thus complete the recovery.

Both SCNs and sequence#s are increasing numbers with time, a sequence# corresponds to a log file while an SCN corresponds to a transaction. A log file (sequence#) contains one or more transactions (SCNs). The t1...tn mentioned above can be thought of as sequence#s. (Anyone knows what makes a log switch, thus sequence# change?)

One interesting topic in this architecture is the max. possible loss. At the moment of the crash, the current log is acutally tn+1 (not t(n+1), but tn plus one), since when log is switched from tn to tn+1, log tn has been archived first (when automatic archival is true). I don't know whether the partial or non-archived log tn+1 will be utilized; if it is used, the database can be recovered up to tn+1, if not, the database can only be recovered up to tn; in either case, the log buffer, the memory counterpart of log, is definitely lossed. On the other hand, if automatic archival is false or for some reason some logs are swithed off but not archived yet, will the non-archived logs be utilized too?

Dino Received on Mon Aug 27 2001 - 21:35:48 CDT