Re: I/O activity during HOT backups

When the Alter tablespace begin backup command is issued a global database checkpoint occurs.This means that the current system change number is logged to the redo log stream in a checkpoint record,and all buffers in the buffer cache modified prior to that scn must be flushed down to the datafiles.Once the checkpoint completes then the header block of each datafile in the tablespace is frozen,meaning that the header will not be updated to record the scn of future checkpoints.
However the writing of database block to the body of the datafiles is not changed in any way.During future checkpoints,while the tablespace remains in backup mode,blocks continue to be written to the datafiles,just like normal. When the Dbwr process flushes blocks to the datafiles outside of checkpoint processing, this continues in the datafiles belonging to the tablespace being backed up,just like normal.

Meanwhile,while this normal i/o occurs to and from the tablespace in backup mode,some type of operating-system utility is copying the datafiles,backing them up,The files are being changed,as they are being saved to the backup media.To put it another way the datafiles that are being backed up are not consistent and in one sense of the word are CORRUPT. AND WE DONT CARE.
Because should a recovery situation occur, the datafiles will be recovered from the point in time specified by the scn logged in the file header.That scn represents the point in time of the checkpoint that was triggered by the ALTER TABLESPACE BEGIN BACKUP command .Thus should the database crash before the ALTER TABLESPACE end backup command, all changes to the datafile since the scn in the header would be reapplied .In the event that the datafile being backup up was itself lost,it could be restored from a previous backup copy,and all changes from that point in time would be reapplied.
The point is,freezing the scn timestamp in the datafile header keeps the datafile safe while backups are occuring.Also should the backup up datafile be restored in a recover situation,all the changes from the point in time of BEGIN BACKUP would be applied fro the redo logs.The so called INCOSISTENT OR CORRUPTED DATAFILE,backup up while it was in flux,provides just a baseline from which redo log information can be applied.Thus it permits the datafile to be recovered safely,regardless of the changes made while it is being backup up.

I think the above answers the Q's which was floating around This was picked out from the Tusc white paper.

>From: "Vidya Kalyanaraman" <kvidya13_at_hotmail.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: Re: I/O activity during HOT backups
>Date: Tue, 20 Jun 2000 07:07:22 -0800
>
>William,
>That book you are refering has erroneous descriptions of hot backup.
>Pls read this article by Jeremiah...I have already posted this link to
>list....
>This article talks mainly about "Oracle Unleashed...." book and its
>misleading hot backup concepts.
>Thanks
>Vidya
>
>
>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Date: Tue, 20 Jun 2000 05:57:30 -0800
>
>The following is a quote from my favorite Oracle reference boot titled
>"Oracle Unleashed, Edition 2" by SAMS Publishing.
>
>When you place a tablespace in backup mode, the Oracle instance notes that
>a
>backup is being performed and internally compensates for it. As you know,
>it
>is impossible to make an authentic copy of a database file that is being
>written to. Upon receipt of the command to begin the backup, however,
>Oracle
>ceases to make direct changes to the database file. It uses a complex
>combination of rollback segments, buffers, redo logs, and archive logs to
>store the data until the end backup command is received and the database
>files are brought back to sync. .... What you should understand is that the
>trade-off for taking a hot backup is increased use of rollback segments,
>redo logs, archive logs, and internal buffers within the SGA.
>
>You must be running the database in Archive mode to perform a hot backup.
>Archive logs assure data consistency when backing up only pieces of a
>database at a time.
>
> >>> "Eric Lansu" <eric.lansu_at_quicknet.nl> 06/20/00 09:11AM >>>
>Am I wrong, or am I wrong?
>
>But as far as I know you have to do a log-switch BEFORE starting the
>HOT-backup, and one AFTER the HOT-backup. The tape containing the
>database-files should also contain the archive-log-files created between
>the
>log-switches. This way you can roll-forward (recover) the database to the
>point-in-time after completion of the backup, and thus bringing it all in a
>consistent state. ( yes, yes, not from a book.... )
>
>Still the question remains; how can the OS make a copy of a datafile if
>Oracle is still writing in it? Better, how does Oracle know what to update
>after recovery?
>
>Eric Lansu
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
>Sent: Tuesday, 20 June 2000 11:03
>
>
> > Wow! your explanation is wonderful.
> >
> > Thanks Rachel.
> >
> >
> > Bhat
> >
> > -----Original Message-----
> > Sent: Tuesday, June 20, 2000 4:19 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Lisa,
> >
> > I'm sorry but you are wrong. Writes to the datafiles continue during hot
> > backup.....
> >
> > take a hypothetical situation:
> >
> > you have 3 redo logs
> > you have put every tablespace in your database into hot backup mode
> > you do a LARGE dataload (enough to cycle through all your redo logs
>several
> > times)
> >
> >
> > so... if Oracle does NOT write to the datafiles, then the changes you
>have
> > been making to the blocks get overwritten in the redo logs after the
>logs
> > are archived. Once you take the tablespaces out of backup mode, given
>your
> > thinking, Oracle would have to then write all the blocks to the database
> > files at once. But where would it get them from? The archived redo logs
>are
> > NOT re-read, nor are the redo logs.
> >
> > So...... writing continues to the database files.
> >
> > Rachel
> >
> > >From: Lisa_Koivu_at_gelco.com
> > >Reply-To: ORACLE-L_at_fatcity.com
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >Subject: Re: I/O activity during HOT backups
> > >Date: Mon, 19 Jun 2000 11:50:37 -0800
> > >
> > >No! The command below stops all writes to the datafiles in the
>tablespace
> > >for
> > >the duration of the backup, to ensure consistency.
> > >
> > >The i/o overload I see during backups is the data being copied out to
>our
> > >backup
> > >server. And it is usually very high: like 80% of all current
>activity.
> > >
> > >Lisa
> > >
> > >
> > >
> > >
> > >
> > >Dan.Hubler_at_midata.com on 06/19/2000 01:18:14 PM
> > >
> > >Please respond to ORACLE-L_at_fatcity.com
> > >
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >cc: (bcc: Lisa Koivu/GELCO)
> > >
> > >
> > >
> > >
> > >
> > >Please settle a discussion amongst our DBA team:
> > >
> > >Is there ANY I/O that takes place to the database files (*.DBF)
> > >during a HOT backup? (That is, ALTER TABLESPACE BEGIN BACKUP).
> > >
> > >If not, how does the process work?
> > >
> > >Thanks.
> > >
> > >
> > >
> > >
> > >???
> > >
> > >
> > >--
> > >Author:
> > > INET: Dan.Hubler_at_midata.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: Lisa_Koivu_at_gelco.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: LBhat_at_LEVI.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: Eric Lansu
> INET: eric.lansu_at_quicknet.nl
>
>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: William Beilstein
> INET: BeilstWH_at_obg.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: Vidya Kalyanaraman
> INET: kvidya13_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
Received on Tue Jun 20 2000 - 10:15:09 CDT