If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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 ModicASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?

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

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 ModicASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?

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

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 ModicASCII a stupid question, get a stupid ANSI
24 hours in a day .... 24 beer in a case .... coincidence?

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