RE: Tablespace Backup question

Colin,

What you said. Thank you :).... and yes, the SCN in header and footer is what I meant.

RMAN writes in Oracle blocks, not operating system blocks so there is no problem of split.

Rachel

>From: Colin.Shaw_at_phs.com
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: RE: Tablespace Backup question
>Date: Tue, 06 Jun 2000 12:08:08 -0800
>
>Sean:
>
>It's actually quite simple really, and sensible when you think about it.
>If
>Oracle stopped writing to the file (which some books say they do), then you
>have a massive problem with keeping those updates somewhere. So basically
>all Oracle does is keep writing to the datafile(s), but not keep updating
>the file header checkpoint SCN(s). Also, to prevent split block problems,
>full blocks are written to redo, instead of change vectors. (Split blocks
>can happen because Oracle is writing "Oracle" blocks (e.g. 8k) whereas your
>hot backup is reading "disk" blocks (e.g. 512 bytes.) When you take the
>tablespace out of hot backup, the checkpoint SCN(s) is/are updated to the
>same as the others because the tablespace is actually in a consistent
>state.
>If the database dies during the hot backup, you have full blocks in the
>redo
>so you can recover (if necessary) any blocks modified during the hot
>backup.
>Yes, the tablespace would probably be in an inconsistent state, but you
>have
>the means - full Oracle blocks - to recover it.
>
>That's why you need to apply all of the redo logs created during a hot
>backup to get a "new" database. The "old" database was only fully
>consistent to the point in time you started the hot backup. To get it
>fully
>consistent again to the point in time you finished your backup you have to
>apply all of the redo. The datafile backups you have are not logically
>consistent and I think that's what leads some people to misunderstand the
>hot backup process.
>
>I think what Rachel is alluding to is the fact that there's an SCN in the
>header of each Oracle block and another in the footer. If they're
>different
>(in the hot backup file) then you know you've got a split (Oracle) block
>and
>you need the full Oracle block from the redo when (if) you recover.
>
>All this is not necessary when using RMAN because an RMAN backup is done by
>Oracle (as opposed to the operating system) and so no ALTER command or full
>block logging is necessary. But that's another story....
>
>Colin.
>
>-----Original Message-----
>Sent: Tuesday, June 06, 2000 7:00 AM
>To: Multiple recipients of list ORACLE-L
>
>
>I need to bring in the backup class notes from the internals classes.
>
>Colin is right.... and Oracle keeps both a header and footer section where
>the information is used to reconcile which blocks need "recovery"
>
>this is from memory, I'd have to look up my notes to be certain
>
>Rachel
>
>
> >From: sean.hull_at_pobox.com
> >Reply-To: ORACLE-L_at_fatcity.com
> >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> >Subject: RE: Tablespace Backup question
> >Date: Mon, 05 Jun 2000 23:15:35 -0800
> >
> >
> >On Mon, 5 Jun 2000 Colin.Shaw_at_phs.com wrote:
> >
> > > Actually, no. Oracle continues to write to the file *exactly* the
>same
> >when
> > > in hot-backup mode, with the exception of the checkpoint SCN. Also,
> >full
> > > blocks (not change vectors) are written to the redo log. You can find
> >more
> > > details about this at various web sites or in Velpuri's Backup
>Handbook.
> > > Not sure if it's discussed in the Oracle Docs.
> >
> >I believe what you're saying, though I would like to at least confirm
> >this. It seems *QUITE* weird to me. What if half a block (say 16k
> >blocksize) had been written, and the OS context switches and then the
> >other process starts reading the file. I mean how does Oracle avoid
> >datafile corruption?
> >
> >Perhaps based on the SCN, Oracle knows that it needs to cleanup those
> >datafiles for all transactions after a certain point, so doesn't worry
> >about it. When you startup the db from the hotbackup, the files *ARE*
> >corrupted then, but Oracle knows from the SCN where to recover from, and
> >starts reading the redologs and writing those changes to the right places
> >in the datafiles. I guess that might make some sense.
> >
> >I need to do some reading.
> >
> >Sean
> >
> >--
> >Author:
> > INET: sean.hull_at_pobox.com
> >
> >Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> >San Diego, California -- Public Internet access / Mailing Lists
> >--------------------------------------------------------------------
> >To REMOVE yourself from this mailing list, send an E-Mail message
> >to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> >the message BODY, include a line containing: UNSUB ORACLE-L
> >(or the name of mailing list you want to be removed from). You may
> >also send the HELP command for other information (like subscribing).
>
>________________________________________________________________________
>Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>--
>Author: Rachel Carmichael
> INET: carmichr_at_hotmail.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
>
>
>
>--
>Author:
> INET: Colin.Shaw_at_phs.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).
Received on Tue Jun 06 2000 - 20:37:53 CDT