ANBOB™

 Oracle 19c hot backup mode? (一)

Hot Backups
To take hot backups, the database must be in ARCHIVELOG mode. If you are using RMAN, the tablespace does not need to be put into backup mode.

Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the data file header checkpoint because it knows the order in which the blocks are read, which enables it to capture a known good checkpoint for the file.

Mechanisms of hot backup:

1. datafile checkpoint structure is frozen
2. backup is transparent to usrs.
3. Block splits during hot backups:
4. data block is written by DBW0 while it is read by the O/S copy utility.
5. Can cause fractured or split blocks.
6. Redo for whole blocks is logged to the redo stream.
7. More redo is generated during hot backups.
8. Tablespace should be taken out of backup mode as soon as the file copy is completed.

Fractured blocks may occur when there is an update to a database block while the block is being backed up at the OS level. Because Oracle blocks normally consist of more than one OS block, it is possible that part of the block is backed up, the block is changed, and then the rest of the block is backed up. The two halves of the block are not consistent with each other.

To prevent this, Oracle copies the entire block to the redo logs. During recovery, the block is copied from the redo log and any further changes logged in the redo are applied to the recovered block.

if the database crashes during a hot backup , file in hot backup mode will require media recovery on startup:
take datafiles out of hot backup mode.V$BACKUP shows data files that are in hot backup mode.

if any redo logs are missing, recovery is impossible.

to take a tablespace out of backup on startup, mount the database and issue the following commond:
alter database datafile ‘xxxx’ end backup;
This updates the data file header and control file..

Alternatively, you can issue the RECOVER DATABASE command but this will involve checking all the redo logs for missing transactions since the hot backup started.

When taking hot backups, securing all the redo necessary to restore the datafiles to a consistent point in time is critical. To do this, follow these steps:
1. Alter system switch logfile. Make note of the current log.
2. Put tablespaces in backup mode one by one and copy at OS level.
3. After all files have been backed up, make a backup copy of the control file.
4. Issue an ARCHIVE LOG CURRENT so that all changes in the online logs are archived. Make note of the last log to be archived.

The backup set now consists of all datafiles, the control file backup, and all the archive logs from the current log in step 1 to the last archived log in step 4. These are all archive logs that could possibly contain information needed to recover the backup set.

why is alter tablespace … begin backup to freeze the SCN of the file header?

This is primarily the starting SCN for the recovery of the data file later, after the begin backup is released, the system will perform a checkpoint on the tablespace and solidify all the transaction applications before that checkpoint to the data file, and then freeze the SCN until end backup is used, so that the backup process ends. Update to the new SCN, the reason for the freeze is because when copying a data file using operating system commands, he cannot guarantee that the first read block is the data file header, if not frozen, it may start from the backup, the file header has been updated several times, and the file header has not been copied, so that the file header is copied, His SCN is far greater than the SCN of other data blocks in the data file, so it is unrealistic to locate the recovery starting point from the SCN of the file header.

As can be seen from the above, hot spare and Rman online backup is an essential difference, Rman is to connect the target database, generate Oracle user process, call his own process package, interacting with DBWR, using Oracle’s SGA or PGA for backup, In this way, he will first ensure that each block is consistent, there will be no hot stele phenomenon, thus reducing the production of redo records, and he does not need to freeze the file head SCN, because Rman can always read the data file header block first.”From:http://www.cnblogs.com/froster/archive/2005/11/16/277633.html”

Restore From a Hot Backup
When taking hot backups, the file header is frozen while the file is being copied. This means that each data file can have a different checkpoint in your backup set. To make the backup set consistent, all files need to be recovered until their SCNs match again and the fuzzy bits have been reset.

Backup scn, time: Updated when executing BEGIN BACKUP on the tablespace. RMAN does not update this field.
(The next few lines in the dump are incorrectly indented, erroneously suggesting they belong to the backup SCN.)

select fhfno,fhscn,fhbcp_scn from x$kcvfh;

Checkpoint Structure
Records the last checkpoint information
Frozen when file is in hot backup mode
Backup checkpoint SCN
Updated during hot backups
Used in conjunction with the alter database end backup command

Creation SCN is when the file was created. No redo exists prior to this SCN for this file. Backup taken at SCN is updated at BEGIN BACKUP and indicates when a hot backup started.

Resetlogs Data lists the timestamp of the most recent resetlogs and the SCN of the file after resetlogs. This information is compared with controlfile ( database entry ) information when the file is brought online.
Status Definition ( from kcv3.h )
#define KCVFHHBP 0x01 /* hotbackup-in-progress on file (fuzzy file) */
#define KCVFHOFZ 0x04 /* Online FuZzy because it was online and db open */
#define KCVFHMFZ 0x10 /* Media recovery FuZzy – file in media recovery */
#define KCVFHAFZ 0x40 /* Absolutely FuZzy – fuzzyness from file scan */

A hot or online backup is taken when the database is open. ARCHIVELOG mode is a prerequisite. For manual hot backups, the involved tablespaces must be placed in backup mode. With RMAN online backups, a different mechanism ensures block consistency. Thus you do not place tablespaces into any special mode for backup. There are usually two steps to a perform a media recovery: The optional first step is restore, which is a simple copying of files from the backup system to the database locations.
(RMAN may need to assemble the file from several incremental RMAN backups.) The second step is the recover step, when the server applies the archive and online redo logs. Normally when people refer to recovery, they are referring to the restore phase.

Hot backup in progress ( Bit 0X01 ) : Applies only to hot backups made using utilities outside the kernel. This flag indicates that the file is in fuzzy state from its checkpoint until its end hot backup marker. It is set at begin hot backup. Recovery clears this flag when it crosses the end of hot backup marker.
Online fuzzy ( Bit 0X04 ) : Indicates that the file is in fuzzy state from its checkpoint until the crash recovery marker. It is set when the data files is first open or online or made read-write. It is cleared when the datafile is close , offline ( normal ) or made read-only.

The database cannot be shut down cleanly if a tablespace is in hot backup mode:
ORA-01149: cannot shutdown – file 1 has online backup set
ORA-01110: data file 1 : ‘/u02/oracle/or8i/system01.dbf’

open

SQL> startup
ORACLE instance started.

Total System Global Area 1073738888 bytes
Fixed Size                  9143432 bytes
Variable Size             792723456 bytes
Database Buffers          268435456 bytes
Redo Buffers                3436544 bytes
Database mounted.
ORA-10873: file 1 needs to be either taken out of backup mode or media recovered
ORA-01110: data file 1: '/u01/app/oracle/oradata/ANBOB19C/system01.dbf'

Solution:

SQL> alter database end backup;
Database altered.

SQL> alter database open;
Database altered.

kcvfhsta 

#define KCVFH_FUZZY (KCVFHHBP|KCVFHOFZ|KCVFHMFZ|KCVFHAFZ|KCVFHPCP|KCVFHSBY)
#define KCVFH_OOFUZZY (KCVFHHBP|KCVFHMFZ|KCVFHAFZ|KCVFHPCP|KCVFHSBY)
#define KCVFH_NMFUZZY (KCVFH_FUZZY^KCVFHMFZ^KCVFHSBY) /* non-MR fuzzy */
#define KCVFHBCP 0x100 /* Bad Checkpoint – no enabled thread bitvec */
#define KCVFHFMH 0x200 /* Freshly Munged Header. resetlogs not finished */
#define KCVFHXCH 0x400 /* eXternally CacHed by operating system */
#define KCVFHZBA 0x800 /* Zeroed Blocks Allowed */
#define KCVFHPCP 0x1000 /* Proxy Copy in Progress */
#define KCVFHRBS 0x2000 /* does kcvfhrdb point to bootstrap$ ? */
#define KCVFHSBY 0x4000 /* media rcv fuzzy due to standby apply */
#define KCVFHL0C 0x8000 /* Incremental level 0 copy */
/* bits that can be set in kcvfh_status2 for move datafile */
#define KCVFH_SECONDARY 0x01 /* secondary file for datafile move */
#define KCVFH_NOT_CURRENT 0x02 /* file not current after datafile move */
#define KCVMAXBKSEC 256 /* maximum sections in a multi-section backup */

打赏

微信扫一扫，打赏作者吧～