Why do tablespaces not require hot backup mode or extra logging

Q: Why do tablespaces not require hot backup mode or extra logging
when using RMan for backups?

A: To understand why RMAN does not require extra logging or backup mode,
you must first understand why those features are required for non-RMAN
online backups.

A non-RMAN online backup consists of a non-Oracle tool, such as cp or
dd, backing up a datafile at the same time that DBWR is updating the
file. We can't prevent the tool from reading a particular block at the
exact same time that DBWR is updating that block. When that happens,
the non-Oracle tool might read a block in a half-updated state, so that
the block which is copied to the backup media might only have been
updated in its first half, while the second half contains older data.
This is called a "fractured block". If this backup needs to be restored
later, and that block needs to be recovered, recovery will fail because
that block is not usable.

The 'alter tablespace begin backup' command is our solution for the
fractured block problem. When a tablespace is in backup mode, and a
change is made to a data block, instead of logging just the changed
bytes to the redo log, we also log a copy of the entire block image
before the change, so that we can reconstruct this block if media
recovery finds that this block was fractured. That block image logging
is what causes extra redo to be generated while files are in backup
mode.

The reason that RMAN does not require extra logging is that it
guarantees that it will never back up a fractured block. We can make
that guarantee because we know the format of Oracle data blocks, and we
verify that each block that we read is complete before we copy it to the
backup. If we read a fractured block, we read the block again to obtain
a complete block before backing it up. non-Oracle tools are not able to
do the same thing because they do not know how to verify the contents of
an Oracle data block.

Backup mode has another effect, which is to 'freeze' the checkpoint in
the header of the file until the file is removed from backup mode.
We do this because we cannot guarantee that the third-party backup
tool will copy the file header prior to copying the data blocks.
RMAN does not need to freeze the file header checkpoint because we
know the order in which we will read the blocks, which enables us to
capture a known good checkpoint for the file.