RE: I/O activity during HOT backups

From: Linda Wang <lwang_at_messagemedia.com>
Date: Fri, 23 Jun 2000 12:49:43 -0600
Message-Id: <10537.110318@fatcity.com>

Anil,

Super good info.

RMAN is also faster than other (begin/end) troublesome backup tools such as BMC ...
What is the best tape utility to work with RMAN? Legato, netbackup ....

Thanks.
Linda

-----Original Message-----
From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Anil Sikri Sent: Friday, June 23, 2000 10:48 AM
To: Multiple recipients of list ORACLE-L Subject: Re: I/O activity during HOT backups

Hi guys and gals,

There is a lot of confusion among DBA community regarding non-RMAN hot backups and books like Oracle Unleashed don't help either. Here is what happens during a non-RMAN hot backup ( RMAN backups are different which I will explain later ) :

When an ALTER TABLESPACE <tablespace_name> BEGIN BACKUP is issued, all the datafiles belonging to the tablespace are checkpointed. The checkpoint SCN is written into the respective data file headers.
The modifications to the datafile proceed normally as it was before the ALTER TABLESPACE.... BEGIN BACKUP was issued.
Once the checkpoint SCN is written into the datafile headers, during the course of the backup, the corresponding data file headers are frozen in time. This means that the SCN information in the data file headers is not incremented during the backup. Let's delve into this further and investigate why it is important to freeze the datafile headers belonging to the tablespace being backed up : Let's say tablespace t1 has 3 datafiles d1, d2 and d3. Now let us put t1 in the begin backup mode and let's assume that the headers of the datafiles d1, d2 and d3 are not frozen. Let's say t1 will be written to the backup set first. In the meantime, since the database is up and transaction are going on, there is a possibility that the files t2 and t3 are being written to and also being checkpointed. This results in the SCN information in headers of files t2 and t3 being different from that of t1. During the course of the backup, the files t2 and t3 are subsequently backed up. Now let's see what happens when there is a media failure and these files have to be restored from the backup : Oracle first refers the controlfile for the SCN info and matches those with the SCN info in the headers of the datafiles applied from the backup. Now since t2 and t3 have a different SCN compared to t1, the recovery will fail because the sanity check for SCN fails.

            That's the reason why all the datafiles belonging to the
            tablespace being backed up have their headers frozen during
            the course of the non-RMAN hot backup.

Now arises the question whether the checkpoints are blocked during a non-RMAN hot backup.
The answer is they are not. The checkpoints occur as usual but instead of incrementing the main SCN in the datafile headers, they increment another counter. When a ALTER TABLESPACE...END BACKUP is issued, the main SCN is incremented to the value of this counter.

4) Another interesting fact is that the amount of redo generated

    during the course of non-RMAN hot backups is huge. Why ??     Let's begin with the Unix file system block size which defaults to     512 bytes in most of the versions of Unix. Most of the present     databases have a block size of 8K or higher. Let's assume an 8K     database block size. So each Oracle block in fact comprises of 16     OS ( Unix ) blocks.
    During a non-RMAN hot backup, after the tablespace is put in     BEGIN BACKUP mode, an OS utility like tar or cp backs up the     datafiles to the backup media. Since cp ( or tar ) is an OS     utility, it backs up OS blocks and has no knowledge of existence of     Oracle blocks.
    So when cp backs up the first of the 16 OS blocks comprising of a     single Oracle block, there is a possibility that the second OS     block ( belonging to the same Oracle block ) is modified by a     server process since the database is open. This results in there     being inconsistencies within the same Oracle block, resulting in the     head of the Oracle block being different from its tail -- a     phenomenon called as a split block.
    To recover from the effects of a split blocks, Oracle logs the pre-     modified image of the entire Oracle block into the redo log files     so that during recovery in case of any split blocks, it can apply     the entire block from the redo logs. Oracle does this by setting an     undocumented parameter, _log_blocks_during_backup, to true.     The default is always true for this parameter. This results in a     lot of extra redo being generated since the     entire Oracle block has to be logged in the redo log files during     the course of hot backups.
    When no backups are taking place, Oracle always logs only the     changes to the blocks ( or the change vectors ) and not the entire     blocks as it does during a non-RMAN hot backup.

Now let's consider the case of RMAN hot backups. As already well explained by Gaja, RMAN is Oracle's own server process and it backs the Oracle blocks and not the OS blocks as explained above. This precludes any ALTER TABLESPACE...BEGIN BACKUP to be applied during an RMAN hot backups. Hence the split blocks do not come into the picture and the extra redo due to logging entire block images is not generated. This should be another reason to switch to RMAN for you folks not using it yet.

Just my 2 cents worth.

Let me know in case of any more questions.

Anil Sikri
Sr. Oracle DBA

>
>-----Original Message-----
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Date: Tuesday, June 20, 2000 9:23 AM
>
>
> >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 -----

Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

--
Author: Anil Sikri
  INET: anil_sikri_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 Fri Jun 23 2000 - 13:49:43 CDT