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

Dino Hsu wrote:
>
> 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

If you lose the current online log you will definitely lose some data during recovery (this is the main reason Oracle doesn't want you to back them up just in case you subsequently restored over them).

You'll never "lose" the log buffer because its flushed for each commit - and anything that is not committed you didn't want anyway (from a recovery perspective)

hth
connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."