DBAsupport.com Forums - Powered by vBulletin
Results 1 to 7 of 7

Thread: alter tablespace begin backup

Hybrid View

  1. #1
    Join Date
    Oct 2004
    Location
    Chennai
    Posts
    13

    alter tablespace begin backup

    when a tablespace is in backup mode lot of redo is generated since redo generated for the entire block . but why shoul redo be generated for the entire block?
    Thanx
    Vijay

  2. #2
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Because while your OS might be split-copying your database blocks during the bacup operation of your datafile.

    Suppose your database block size is 8K. And let's suppose your OS does read 4K OS blocks at a time while copying a file from one location to another. Let's say the OS reads first half of your database block Bx at time T0 and starts copying it to the backup location. At time T1, the database writer changes some data located in the second half of your database block Bx. At time T2 the OS finishes copying the first half of your database block and starts copying the second half of yor database block Bx. So in the backup file, the first and the second half of your database block are from diffrent times - in other words, your database block Bx is inconsistent. Yet it represent the foundation for your media recovery. So if Oracle is to deal with this block inconsistency, it has no other choice as to record *the intire database block* in the archive log file *whe the first change occurs in this block* if the file is in backup mode.

    Note however that the entire block must be archived only when *the first* change to the block is made after the file has been put in a backup mode. Any further changes to that particular block will cause only vector changes to be recorded in archlogs, just as during the normal operation of the database.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  3. #3
    Join Date
    Feb 2004
    Location
    Russia
    Posts
    13
    Originally posted by jmodic
    Note however that the entire block must be archived only when *the first* change to the block is made after the file has been put in a backup mode. Any further changes to that particular block will cause only vector changes to be recorded in archlogs, just as during the normal operation of the database.
    It is not completely true:

    During hot backup...
    1. DBWR has written down the dirty block on a disk and this buffer in buffer cache has become free
    2. Server process have read again this block from disk
    3. Server process has made changes in the block and the block has become dirty again
    4. Entire block must be archived again

    P.S. Sorry for my bad english.

  4. #4
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by Markelenkov
    It is not completely true:

    During hot backup...
    1. DBWR has written down the dirty block on a disk and this buffer in buffer cache has become free
    2. Server process have read again this block from disk
    3. Server process has made changes in the block and the block has become dirty again
    4. Entire block must be archived again
    ????

    I'm not sure what are you trying to say.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  5. #5
    Join Date
    Feb 2004
    Location
    Russia
    Posts
    13
    Look for example:

    1. We have hot backup (alter tablespace ... begin backup
    2. Server process changes block 23 of datafile 3 of this tablespace
    3. ALL this block must be archived in online redo
    4. DBWR writes this dirty block 23 of datafile 3 on disk
    5. Any server process reads again this block into buffer cache and changes it
    6. This server process sees that the block belongs to a datafile, in which header was set hot backup bit
    7. ALL this block must be archived in online redo AGAIN because server process does not know
    that this block already was written completely in online redo already



    Rama Velpuri:
    ...[Platform-dependent option]: It starts block before-image log-
    ging for the file. During block before-image logging, all
    instances log a full block before-image to the redo log prior to
    the first change to each block of the file (since the backup
    started, or since the block was read anew into the buffer
    cache)...
    Regards.

  6. #6
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by Markelenkov
    7. ALL this block must be archived in online redo AGAIN because server process does not know
    that this block already was written completely in online redo already
    But of course the server process knows exactly that this block was allready completely logged! In other words, it knows exactly if the modification of the block is the first one since the datafile was put in backup mode or if it's not he first change since then.

    To determine this is very simple. When the datafile header is frozen at the beginning of the backup, it also contains the last SCN written to that file. Before the database block is modified, Oracle only has to compare its current SCN to that in the file header. If block's SCN is lower than that of the file header, then this is the first change since the backup begun and it must archive that block as a whole. But if the block's SCN is higher than the one in file header, then Oracle knows that this is not the first change of that block since the backup, hence it has to log only changes and not the whole block.

    Bottom line:
    When datafile is in backup mode, only the first cahnge of the block cause the whole block to be archived. Any subsequent changes to this same block cause only change vectors to be written to the archlog, not the whole block again.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  7. #7
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    =======
    Bottom line:
    When datafile is in backup mode, only the first cahnge of the block cause the whole block to be archived. Any subsequent changes to this same block cause only change vectors to be written to the archlog, not the whole block again.


    __________________

    This is partially true.
    As long as the block is in the SGA after the full image has been written into redo log, oracle writes only changed vector for that block.
    Imagine the following situation.
    Oracle has written full image of file 10 block 20 after tablespace was put into backup mode b/c of a change in the block.

    A new server process reads many blocks from a data file and puts them in to buffer cache. During this process oracle removes the unwanted blocks to accomodate new blocks. DBWR writes this block into disk. So there is a possibility that file 10 block 20 could be removed from the buffer cache.

    Now another process reads the file 10 block 20 for a DML operation b/c the block is not in buffer cache. And it reads from the disk and puts the file 10 block 20 into the buffer cache. It updates/inserts/deletes a row. In this situation, oracle again writes a FULL IMAGE of the block into redo log.

    Why is oracle writing the full image of file 10 block 20 again?
    I do not know the right answer.
    My guess is:
    1. May be the version number (due to vector change) gets duplicated once the block is removed from the buffer cache.
    2. Oracle may think that the new change in the block 20 of file 10 was done by another instance, in case parallel server is running.
    3. During the recovery process Oracle may find it easy to recover from the full image (of 2nd copy) of the block and applying vector change.
    4. I may be missing something.

    That is why hotbackup should be done when there is less DML operations going on in the database.

    Tamil
    Oct 20, 2004

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