Principles of Oracle Hot Backup

The following is my summary and my understanding about Oracle backup:

1. The data block size in Oracle is usually an integer multiple of the OS block size. The database is always available when the data file is directly copied to the backup media using system commands, oracle data blocks may be constantly modified and read/written. When copying data files using operating system commands, the data blocks are copied based on the size of the operating system blocks, that is to say, when you copy an operating system block, first lock the block, and then unlock the block after the copy is complete, so that the block is consistent with the copy before and after the copy. However, for an Oracle database, a block must be divided into several copies. It is possible that when the data block of an operating system is copied, the data block of another operating system is changed, as a result, the first half of oracle data blocks have not been changed after being copied to the backup media, and the last half have been changed. The status of the data blocks is inconsistent, at this time, backup is invalid, which is called the phenomenon of data block separation.

2. In order to fix the phenomenon of data block separation, when backing up a tablespace or data file, we first issue the begin backup command to notify the database that I am about to start the backup, before the end backup command is issued, as long as the process modifies the data blocks contained in the backup tablespace, oracle will generate redo records for all data rows contained in the data block and record them to the log file.

After the begin backup is issued, before the data row in the data block is modified for the first time, the data block before modification is recorded in the online redo log file, so that when data needs to be restored, if a data block is isolated, the entire data block is restored using the redo record data in the log file.

3. All data rows of all modified data blocks in the backup tablespace are stored in the online redo log file, instead of logging the modified data rows, therefore, during the hot backup process, you will find that the number of online redo log files generated is large, depending on the service busy. For example, if the DML volume is large, many logs will be generated.

4. After the begin backup command is issued, oracle will trigger the file-level Checkpoint Process for the data files corresponding to the backup tablespace, write all dirty data blocks in the memory that belong to the tablespace to the data file. After the checkpoint ends, the data file header (first and first data blocks) the checkpoint SCN and log serial number are not changed until the end backup is sent, and the SCN and log serial number in the data file header are updated.

5. During Hot Backup, the SCN and log serial number in the data file header are frozen, but the data file itself is still up-to-date and is updated and used in the same way as normal, DML updates a table and these updates are written to the data file. The SCN number and log serial number in the data file header are frozen to know where to apply redo records when hot backup is used for recovery in the future, that is, the SCN and log serial number recorded in the backup data file header are located in the log file, the starting SCN is found in the log file, and all log files are applied to it.

6. After the end backup command is issued, the SCN and log serial numbers of all data files are updated to the latest, because the data files are the latest.