| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Tablespace Backup question
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-----
From: Rachel Carmichael [mailto:carmichr_at_hotmail.com]
Sent: Tuesday, June 06, 2000 7:00 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Tablespace Backup question
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).
-- 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 mayReceived on Tue Jun 06 2000 - 13:54:47 CDT
 |
 |