Mechanism Following by Oracle when we taking hot backup

Hot backup means the system is Up and running and Updates are going on as usual

I would here explain Mechanism Following by Oracle when we taking hot backup

Manual Hotbackup

Manual hotbackup start with below command for a tablespace

alter tablespace USERS begin backup;

Few things happens at that time
1)DBWn checkpoints the tablespace (writes out all dirty blocks as of a given SCN)

2)CKPT stops updating the Checkpoint SCN field in the datafile headers and begins updating the Hot Backup Checkpoint SCN field instead
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.

3)LGWR begins logging full images of changed blocks the first time a block is changed after being written by DBWn
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 2K . 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 fractured block — the head and tail are from two points in time.
Oracle 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 atleast. We can recover it from there.

Important point in Hot backup

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

2) If the tablespace is in hotbackup mode and database get aborted. And then you try to start,it will complain about recovery as the datafile SCN of that tablespace will be older, then to start the database, we need to first end the backup of that tablespace. It simply updates the checkpoint SCN with the Hot Backup Checkpoint SCN
Recovery manager backup
We dont need to put the tablespace in hotbackup mode to take the backup using the hotbackmode
Since RMAN is Oracle tool,they know how to handle the fractured block case,so it doesn’t write block fragments or partial blocks to the backup, it writes the complete consistent block image to the backup media. So recovery manager doesn’t need to record the complete block to the redo log file.So it means huge saving in redo logging from manual hotbackup case

Also rman doesn’t freeze the datafile header, it continues to checkpoint just as regular, but it does perform a checkpoint to the tablespace.

RMAN backup notes down the starting SCN,Absolute Fuzzy SCN( which is same as starting SCN in the begining) when the backup begins and as the blocks are backup in the datafile, the block are checked for the SCN, if it is higher then starting SCN, Absolute Fuzzy SCN is updated with that number. Same goes for all the blocks,when the whole datafile is backup ,these both numbers are stored in backup header.

So whenever RMAN restored these backup ,they know it knows from what begining SCN to end SCN ,it has to recover datafile for sure

So basically there is no overhead like increased logging in RMAN hot backup.

Same is true for Image backup with RMAN