DBAsupport.com Forums - Powered by vBulletin
Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: question about RMAN

  1. #11
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334

    Ah Hah!!!

    Found an answer:

    From NOTE 76736.1 on Metalink:

    Q: Why do tablespaces not require hot backup mode or extra logging when using RMan for backups?

    A: To understand why RMAN does not require extra logging or backup mode, you must first understand why those features are required for non-RMAN online backups.

    A non-RMAN online backup consists of a non-Oracle tool, such as cp or dd, backing up a datafile at the same time that DBWR is updating the file. We can't prevent the tool from reading a particular block at the exact same time that DBWR is updating that block. When that happens, the non-Oracle tool might read a block in a half-updated state, so that the block which is copied to the backup media might only have been updated in its first half, while the second half contains older data. This is called a "fractured block". If this backup needs to be restored later, and that block needs to be recovered, recovery will fail because that block is not usable.

    The 'alter tablespace begin backup' command is our solution for the fractured block problem. When a tablespace is in backup mode, and a change is made to a data block, instead of logging just the changed bytes to the redo log, we also log a copy of the entire block image before the change, so that we can reconstruct this block if media recovery finds that this block was fractured. That block image logging is what causes extra redo to be generated while files are in backup mode.

    The reason that RMAN does not require extra logging is that it guarantees that it will never back up a fractured block. We can make that guarantee because we know the format of Oracle data blocks, and we verify that each block that we read is complete before we copy it to the backup. If we read a fractured block, we read the block again to obtain a complete block before backing it up. non-Oracle tools are not able to do the same thing because they do not know how to verify the contents of an Oracle data block.

    Backup mode has another effect, which is to 'freeze' the checkpoint in the header of the file until the file is removed from backup mode. We do this because we cannot guarantee that the third-party backup tool will copy the file header prior to copying the data blocks. RMAN does not need to freeze the file header checkpoint because we know the order in which we will read the blocks, which enables us to capture a known good checkpoint for the file. ---
    Hope that clears things up a bit!

    Thanks for questioning this, Dapi. Sometimes I think we just accept things without knowing why. I feel more comfortable knowing the reason behind the "magic" now!

  2. #12
    Join Date
    Nov 2002
    Location
    Geneva Switzerland
    Posts
    3,142
    Good research Jodie - guess I owe you a beer.

    - - - - - - - - -


    Just realised, this means we haven't found an answer to learnin_bee's question.
    Last edited by DaPi; 02-20-2004 at 12:37 PM.

  3. #13
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    Originally posted by DaPi
    Good research Jodie - guess I owe you a beer.

    - - - - - - - - -


    Just realised, this means we haven't found an answer to learnin_bee's question.
    Great! I'll take you up on that beer if you're ever in Ohio, or I'm in Geneva!

    Well, Learning_bee's script should be splitting the files between each drive since he's doing a database backup and will obviously have more than 1 file. Maybe the DB is so small that RMAN decides to skip the second channel.

    Learning_Bee - Can you give us some specifics on your DB?

  4. #14
    Join Date
    May 2006
    Posts
    41
    I have doubt in the following lines,plz clear it,

    "When a tablespace is in backup mode, and a change is made to a data block, instead of logging just the changed bytes to the redo log, we also log a copy of the entire block image before the change, so that we can reconstruct this block if media recovery finds that this block was fractured. That block image logging is what causes extra redo to be generated while files are in backup mode."

    I studied that if it's in backup mode,if any change is made in a block,the whole block will be written to the redo log,thats why more redo log generation.but here,they've given "entire block image before the change",.

    1.I wants to know whether the changed block plus before image of that block are stored in redo log, or only changed block is stored.

    2. If before image is stored,what is the use of this,how it helps in recovery process.

    If anyone found,i've understood it wrong,please correct me.If possible,explain with a recovery scenario,so that i can understand this process very well.

    plz someone help me in clearing this doubt.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width