There is not excessive redo generated, there is additional information logged into the online redo log during a hot backup the first time a block is modified in a tablespace that is in hot backup mode. In hot backup mode only 2 things are different:
The first time a block is changed in a datafile that is in hot backup mode, the ENTIRE
BLOCK is written to the redo log files, not just the changed bytes. Normally only the
changed bytes (a redo vector) is written. In hot backup mode, the entire block is logged
the FIRST TIME. This is because you can get into a situation where the process copying
the datafile and DBWR are working on the same block simultaneously. Lets say they are
and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time).
The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile --
DBWR has asked to rewrite this block. the OS schedules the DBWR write to occur right
now. The entire 8k block is rewritten. The backup program starts running again
(multi-tasking OS here) and reads the last 4k of the block. The backup program has now
gotten an impossible block -- the head and tail are from two points in time. We cannot
deal with that during recovery. Hence, we log the entire block image so that during
recovery, this block is totally rewritten from redo and is consistent with itself at
least. We can recover it from there.
The datafile headers which contain the SCN of the last completed checkpoint are NOT
updated while a file is in hot backup mode. This lets the recovery process understand
what archive redo log files might be needed to fully recover this file.
To limit the effect of this additional logging, you should ensure you only place one
tablepspace at a time in backup mode and bring the tablespace out of backup mode as soon
as you have backed it up. This will reduce the number of blocks that may have to be
logged to the minimum possible.
