Oracle Recovery Internal principle: Hot backup

A hot backup is a copy of a data file when it is in use. During the replication process, DBWR is also in progress, so backups may receive some "inconsistent" backups:

Some data blocks may be older than the other blocks

The SCN of some blocks may be earlier than the SCN on the head of the data file

Some blocks may contain a partial update of the redo record, and other parts may be on the data file or on other data files

Some blocks of data may be corrupted because the head and tail of the block are replicated at different times.

The backup set from the above replication is not available after the restore and when the media is restored. When media is restored, the SCN is hot-prepared from the start of the data file (see step two in 4.1) until the recovery process is complete (full or incomplete recovery). Such data files are consistent in terms of transactions.

Hot backup A total of three steps:

Execute command: ALTER tablespace ... BEGIN BACKUP.

The replication tool that invokes the operating system replicates all data files in the tablespace.

Execute command: ALTER tablespace ... End BACKUP

4.1 BEGIN BACKUP

The BEGIN Backup command actually carries out the following operations on all data files in the tablespace (no order is required):

A hot backup fuzzy flag bit is set at the head of each data file to indicate that the data file is in a hot backup state. The header of the data file with this tag indicates that the backup is a hot backup. The purpose of the logo is to freeze the checkpoint at the head of the data file (the SCN at the beginning of the start Backup command). The value is that when the backup is restored, the media recovery can reapply the redo log from the SCN, which is sufficiently early. Because we cannot guarantee that the header of the data file is copied first, the check point of the data file header is frozen during hot backup to support the end of the hot backup. This standard also freezes the checkpoint of the data file (and the checkpoint of the records in the control file) to avoid being updated by the thread checkpoint. After version 7.2, the data file header has a new backup checkpoint to receive updates that originally belonged to the frozen checkpoint.

2. A data file checkpoint was done to capture the checkpoint information at the beginning of the hot standby, including the SCN that started the hot standby. When a data file is checked, all instances refresh the dirty data associated with the data file. If an instance recovery is required at this point, the checkpoint waits for the recovery to complete before continuing. A checkpoint on the data file at the start of a backup ensures that during a hot backup, only the blocks modified in the time after the Hot backup command is issued may be written to the data file.

3. [With platform-related, optional]: After hot backup start the data block before the mirror record. During the recording process, all instances are recorded in the redo log for each complete block, rather than a modification vector, to modify the block. This is to prevent the recovery from encountering fragmented blocks (inconsistent blocks), which occur when the size of the data block is larger than the operating system block, and the update block causes the previous part and the latter part to be replicated at different times respectively. After a hot backup the recovery process can build blocks of data using the full front mirror of the records in the redo log.

4. Set the checkpoint on the head of the data file in line with the checkpoint at the beginning of the hot backup and freeze it until the end BACKUP command is issued.

5. Clear the online fuzzy bit mark of the data file. The status bit is always cleared during a hot backup until the end BACKUP command is issued.

4.2 Copying files

Replication is done by the tools of the operating system. The administrator must ensure that the replication occurs between "Bengin backup" and "End backup" or when the file is not in use.