Extra Redo generation during online backup

Why extra redo log is generated while the tablespace in backup mode?
The RMAN utility has the advantage of not generating this extra redo log while taking online tablespace backup. Why?

because redo is generated at block level instead of vector (a smaller unit)

Well, the true reason why during "normal" hot backup thre is usualy extra amount of readolog generated, why during hot backup generated by RMAN there is no additional amount of redo produced is because of so called "database block split" phenomenon that can ocur during normal hot backup while tablespace is in bacup mode. The whole thing is a bit complicated to be explained in a short answer, but there are quite a lot articles available on the net that explain this in detail.

In short, the problem is that the "smalest unit of data that can be read/written" for Oracle is the database block, while for the operating system the same thing is OS block. Now usualy DB block is larger than OS block, it is composed of several OS blocks.

Let's say DB block is 8K, while OS block is 512 bytes. While tablespace is in backup mode, all the data changes are normaly written to the database blocks, and in the same time the OS utility/program is performing copying of the database file to another location/media. Suppose that at time T0 OS starts copying the first OS block of particular database block. In time T1 it starts copying the second OS block of the same database block. Now suppose that in the same time T1 DBWR has to write some changes being qpplied to this same database block. It can't write only part of that database block, it allways has to write the whole DB block. So at time T2 when OS starts copying the third OS block of this database block, the whole database block has totaly different data that it has had at T0 when the first OS block of that DB block has been backed up. That means that once the whole database bock has been backed up, it actually contains some data form one point in time and some data that is from totaly different stage of that same block. So the data in that saved block is totaly inconsistent to any atual state that this database block has ever been in the database. If you would later restore that database block the data would be totaly inconsistent and unusable.

To prevent that data inconsystency because of DB block/OS block mismatch, Oracle has introduced a new concept of recording redo information while the datafile is in backup mode. Whenever the first cahnege to particular db block occurs once the tablespace has been put in backup mode oracle assures that the whole database block has been written (thus protected) in the redo log. Once this first change has been recorded as a whole block in the redo stream, there is no more need to save whole DB blocks for subsequent changes. So only the first change of the block after the start of the backup has to be recorded as an extra redo information, all subsequent changes are recorded totaly normaly in the redo as if the tablespace has not been put in the backup mode.

This way Oracle is assured that after the recovery, even if block splits occured during the backup process, the data in the recovered database is perfectly consistent.

Now why is this extra redo not generated while you perform backup with RMAN? Simply because of the fact that in this case Oracle has the total control of everything. In this case there is no OS copy (over which Oracle has no control nor can it comunicate with), the backup is performed by RMAN into a totaly proprietory file format and the unit of work for RMAN is the same as for the RDBMS - a database block. So each block read by RMAN is totaly consistent and there is no need for the total database blocks to be stored in redologs. This is also the reason while during RMAN hot backup tablespaces are not put in backup mode - there is simply no need for that!

Jmodic, that was great information. I thank you on behalf of Dba community.