Oracle-L: RE: RMAN - Some basic Qs.

From: VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com>
Date: Wed, 02 Apr 2003 22:28:35 -0800
Message-ID: <F001.00579032.20030402222835@fatcity.com>

Gaja ,

Good indeed to see you back on the List .

My Qs. in CAPITALS below :-

-----Original Message-----
Sent: Wednesday, April 02, 2003 2:14 AM
To: Multiple recipients of list ORACLE-L

All,

The primary reason why RMAN does not generate excessive redo is because because it does not put the tablespace in "hot backup mode". Thus any blocks belonging to a given tablespace that are modified before the END BACKUP command is processed, do not require block-level before and after images. Hence the reduction in redo generation.

So how does RMAN backup without "hot backups"?

RMAN is aware of the format of an Oracle datafile, and reads datafiles for the backup in DB_BLOCK_SIZE chunks. This is not the case with most OS utilities (tar, cpio, cp, dd etc.), which read files in 512-byte OS blocksize chunks.

IS BACKUP DATA AS AT POINT-OF-TIME OF START OF RMAN BACKUP ? IF SO , HOW IS DATA INTEGRITY ACROSS DATAFILES MAINTAINED ? HOW ARE BLOCK DATA VALUES AS AT POINT OF BACKUP MAINTAINED WITHOUT STOPPING DMLs TO IT ?

As a result, the issue of a fractured block (for which block-level before/after images are taken) on the destination where the backup is done, does not come into play in RMAN.

MY UNDERSTANDING OF HOT BACKUP :- ASSUME 1 TABLESPACE HAS 2 DATAFILES & DMLs HAPPENING ONLY TO FILE 2. AFTER SWITCHING TABLESPACE TO BEGIN BACKUP . ASSUMING SEQUENTIAL O.S. BACKUP OF DATAFILES , WHILE BACKUP OF THE 1ST FILE IS UNDERWAY , BEFORE IMAGES OF ALL DMLs HAPPENING TO FILE 2 ARE BEING ARCHIVED . THEREAFTER FILE 2 IS BACKED UP .
FINALLY TABLESPACE END BACKUP IS ISSUED. THUS USING THE BEFORE IMAGES OF BLOCKS OF FILE 2 , THE TABLESPACE CAN BE BROUGHT TO DATA EXISTING AS AT POINT OF START OF HOT BACKUP. Hope that helps,

Gaja

"Goulet, Dick" <DGoulet_at_vicr.com> wrote:
> 1: RMAN does not generate excessive redo because it
> does not use the 'alter tablespace ... begin backup'
> command. It instead coordinates with dbwr, somehow,
> to be sure it is getting a consistent view of the
> tablespace.
>
> 2: The concept of an incremental backup is that you
> only backup the database blocks that have changed
> since the last incremental of the same or higher
> level. Somehow the date that the block changed is
> being managed, probably in the header somewhere.
>
> 3: If your reading a block for backup purposes, it's
> pretty easy to checksum it and compare with what's
> in the header just like the Oracle kernel does.
>
> 4: I've tried before with OmniBack and it's fairly
> simple. You only have to relink Oracle including a
> MML library file. The package you want to integrate
> with should have instructions.
>
> Dick Goulet
>
> -----Original Message-----
> Sent: Tuesday, April 01, 2003 10:19 AM
> To: Multiple recipients of list ORACLE-L
>
>
>
> Qs.1 Why is NO excessive Redo Generated wsing RMAN
> Backups unlike HOT Backups
> when taking backup of an OPEN Database which is
> undergoing User Transactions ?
> (Or am i mistaken ?)
>
> Qs.2 How does RMAN manage Incremental Database
> Backups ? What is the Concept behing it ?
>
> Qs.3 How does RMAN Check for Block Corruption while
> taking backup ?
>
> Qs.4 Is it easy to integrate 3rd part tools like
> Legato etc with RMAN for enabling taking
> of backups onto backup devices OR does it need an
> extensive setup ?
>
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> --
> Author: VIVEK_SHARMA
> INET: VIVEK_SHARMA_at_infosys.com
>
> Fat City Network Services -- 858-538-5051
> http://www.fatcity.com
> San Diego, California -- Mailing list and web
> hosting services
>

> 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).
>
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.net
> --
> Author: Goulet, Dick
> INET: DGoulet_at_vicr.com
>
> Fat City Network Services -- 858-538-5051
> http://www.fatcity.com
> San Diego, California -- Mailing list and web
> hosting services
>

> 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).
>

Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Gaja Krishna Vaidyanatha
  INET: oraperfman_at_yahoo.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: VIVEK_SHARMA
  INET: VIVEK_SHARMA_at_infosys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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 Thu Apr 03 2003 - 00:28:35 CST