Additional Redo Generation During Online(HOT) Backup

In this article I'll describe you the reason, why there are excessive (additional) redo information generate when we take the online Database/Tablespace backup.

Going further let me clear one thing, during online backup the database performs normal read write operation on datafile and generates online redologs but with some additional/excessive information.  

When we put the Database/TBS in backup mode by the below command.

alter database begin backup;

or

alter tablespace test begin backup;

Oracle immediately flushes all the earlier changes from SGA memory (Buffer cache) to physical disk (oracle blocks) and then checkpoints the tablespace.

Now the datafile header of the tablespace is frozen i.e. the SCN is marked and it will not increase by any of the update in datafile. This helps oracle to find out when tablespace datafile has the last consistent data and what archive redo log files might be needed to fully recover that file.

When a block changed for the FIRST time in a datafile, Oracle writes the ENTIRE BLOCK into the redo log files inspite to write only the changed bytes. Normally Oracle writes only the changed bytes into the online redolog. Now we have the ENTIRE BLOCK of the redo vector in redo logfile, when the same block is get updated by NEXT time then only changed redo vector would get written down into the online redolog inspite of the ENTIRE BLOCK. The reason behind it is, might be the DBWR and copying process is working over the same block simultaneously.

Lets clear it by the below situation.

In Linux, filesystem have a default blocksize of 2k, while Oracle's is 8k. This means that the filesystem read factor is 2k at a time. The backup program goes to read 8k Oracle block. The OS already copied the 4k of the block, meanwhile DBWR has called to rewrite the same block. The entire 8k block is rewritten. The backup program reads the last 4k of the block. 

Above situation is, where the DBWR's written activity happend over block  at the same time backup process is copying that block. In this case backup copy of the DB block could contain FRACTURED BLOCK.

Hence Oracle log the ENTIRE block image in the redologs for event of recovery, if there is any fractured block it will be totally rewritten from redologs and will be consistent.