| RMAN Backup [message #236154] |
Wed, 09 May 2007 03:41  |
balaji1010
Messages: 35
Registered: March 2006
Location: London
|
Member |
|
|
Hi everyone,
I have doubt regarding RMAN backups.
I am aware of the fact that RMAN skips empty blocks while taking backups.
But, I believe RMAN backup can be slow because it has to read
every block in the datafile to make sure that block is empty or filled up and not every block is written to the backup location only eligible blocks for backups(filled up blocks) are backed up. (This is what i know)
When backingup locally managed tablespaces RMAN DOESNOT attempt to read all the blocks because it will get the information from the bitmap block of the datafile.(This is what i am not sure about).
If not true, can anyone please try to help me out with this.
Thanx in advance
|
|
|
|
|
|
|
|
|
|
|
|
| Re: RMAN Backup [message #236167 is a reply to message #236154] |
Wed, 09 May 2007 04:12  |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
| Quote: | I am aware of the fact that RMAN skips empty blocks while taking backups.
|
Actually RMAN skips unused rather than empty blocks while backing up.RMAN can only draw information about the contents of a block by reading either the file header or the block header. So, if we truncate a table (thereby resetting the HWM), all blocks that had information in them but are now empty will be backed up regardless. This is because RMAN only knows that a block has been initialized by a segment. It does not know that the block is empty.
Regards
|
|
|
|
|
|
|
|
|
|
| Re: RMAN Backup [message #236179 is a reply to message #236172] |
Wed, 09 May 2007 04:25 |
sriram717
Messages: 48
Registered: February 2007
Location: UNITED KINGDOM
|
Member |
|
|
Regarding excessive Redo Generation :
The Data files are being written or changed in "real time" just like normal.
Now while we are copying the files , we might get into the state where whilst we are copying a particular block, the database might also be overwriting it with a change. So we would end up with a corrupted block. To ensure that we can by pass this during a recovery, more information is written to the redo logs ie the before image of the blocks not the change vector . This is why you get more redo activity. So it is advisbile not to schedule a hot backup when there is a huge activity on the database.
Thanks
|
|
|
|
|
|
|
|
| Re: RMAN Backup [message #236204 is a reply to message #236196] |
Wed, 09 May 2007 05:15 |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
| Quote: | I know that excessive redo generation is done and i also understand the scenario why it happens.
|
Let me repeat 'excessive redo generation' is done only the first time a block is modified after a tablespace is put in hot backup mode. This behavior is not seen subsequently, i.e. you only get minimal redo for subsequent modifications to the block.
RMAN has two access points to the database:
1) The File header
2) The Block header
So, RMAN can only draw information about the contents of a block from either its own header or the file header.RMAN cannot be sure of getting any other information, because all of those is predicated on the database being open. And here is the punch line: RMAN just cannot bank on the database being open!
[Updated on: Wed, 09 May 2007 05:16] Report message to a moderator |
|
|
|
|
|
| Re: RMAN Backup [message #236208 is a reply to message #236207] |
Wed, 09 May 2007 05:22 |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
There is one more thing to add: RMAN reads the blocks, not the tablespaces. So, your understanding that RMAN looks up info. from the undo tablespace is not quite correct.
Regards
|
|
|
|
|
|
| Re: RMAN Backup [message #236235 is a reply to message #236229] |
Wed, 09 May 2007 06:47 |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
Michel,
Perhaps you missed what I was trying to say. Of course RMAN works with open databases. That's how it will work perhaps 90% of the time, but RMAN cannot be guaranteed that the database will remain open. FYI RMAN is available even when the database is not open--the database needs to be just in NOMOUNT state for RMAN to be available.And, as you know a lot remains unavailable wile you are in nomount state. So, the system that RMAN uses is 'read the blocks' and not depend upon the vagaries of the state of the database to do its job.
Regards
|
|
|
|
|
|
| Re: RMAN Backup [message #236244 is a reply to message #236239] |
Wed, 09 May 2007 07:06 |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
| Quote: | What i meant was RMAN would read the blocks from UNDO tablespace or UNDO datafile to get the read consistent image of the blocks at the time of open DML transaction.
|
You are absolutely correct. It is the block level access that sets apart RMAN from any other backup utility.And it is precisely this feature that derives all the benefits that RMAN actually does.
So, if your interviewer asked you about 'RMAN reading tablespaces', then I am afraid, that was very bad paraphrasing of the question.
Regards
|
|
|
|
|
|
| Re: RMAN Backup [message #236403 is a reply to message #236330] |
Wed, 09 May 2007 22:06 |
saibal
Messages: 111
Registered: March 2007
Location: India
|
Senior Member |
|
|
Let me briefly try to explain how RMAN works:
RMAN compiles a list of files to be backed up based on the information gathered using the two packages DBMS_RCVMAN and DBMS_BACKUP_RESTORE, as well as the algorithm rules that it is following.
Based on the number of channels you have configured and the degree of multiplexing that you are using, RMAN takes the preparatory step of creating buffers in oracle's shared memory segment, which is usually in the PGA, but there are circumstances where you may find the buffers in the SGA as well.
Now, RMAN starts reading the blocks, and at this point it takes no cognizance of the fact that the blocks are used, unused, full, empty, corrupt, whatever. It just reads them into the input buffers.
When the input buffer fills up, the blocks are pushed into an output buffer. It is only when input buffers are pushed into the output buffers that the actual checking takes place. RMAN performs a checksum, detecting corrupt, unused, and other blocks that do not meet RMAN's criteria for backing up. It is this intra-memory write that is crucial, because all the filtering takes place here. Once the output buffer is full, it is pushed to the backup location--a disk or tape, whichever it may be.
On another note, a hot backup made BY RMAN is ALWAYS CONSISTENT, because RMAN coordinates with the DBWR process to only write consistent blocks into the memory. This synchronization, between DBWR and RMAN produces the consistent blocks in memory AND NOT BECAUSE RMAN READS THEM FROM UNDO TABLESPACE/BLOCKS.
So, now let's look at your statements and analyze them:
| Quote: | RMAN backups are slow because every block header must be read to identify the status (unused or used) of the block
|
Not entirely true. backups may be slow/fast due to many reasons--such as multiplexing, backup optimization etc. While it is true that RMAN reads the header of each block, but it does so in memory and not while reading the blocks.
| Quote: | no of blocks written to the backup location are less
|
Could be true. Could be false. But mostly it ought to be true because no. of blocks written to the disk/tape shall be less than the no. of blocks read into memory, because of null compression, corrupt blocks, and blocks not passing the checksum.
| Quote: | restoration and recovery is fast
|
Depends. If you are using incremental backups, restoration will be decidedly slower than when you are not using incremental backups. And besides when you say 'restoration and recovery is fast', you must specify faster than what-- otherwise it is a very subjective assertion.
Hope this helps,
Regards
|
|
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
