Introduction to Oracle Rman maintenance (i) Maintenance of Rman

1. Cross-efficacy Rman backup

In the case where the Rman catalog and the physical backup destination are not synchronized, we can use the Crosscheck command to verify that the Rman information in the control file or recovery directory is the same as the actual physical backup set on the backup media.

When using the Crosscheck command, we care about the status of each backup set or replica. If you use a control file, the V$backup_set view for the backup set and the Status column in the V$databfile_copy view for the replica lists the state codes for each backup set or replica, and if you use the recovery directory, the rc_backup_ of the backup set The status codes for each backup set or replica are listed in the rc_datafile_copy of the set and replica. In different backup status codes, we are concerned with the following two states:

(1) A (Available: Available): RMAN determines that the item exists on the backup media

(2) X (expired: Unavailable): The Rman catalog (that is, the control file or recovery directory) stored on this backup set piece or replica, but is not physically present on the backup media.

The purpose of using the Crosscheck command is to set the status of the Rman catalog to available or expired. When performing crosscheck, Rman checks each backup set or copy listed in the directory and determines whether they exist on the backup media. If the backup set or copy does not exist on the backup media, it is marked as expired and cannot be used for any restore operation; If the backup set or copy exists on the backup media, it will maintain the available state. If the backup set or copy previously marked as expired is on the backup media again, the crosscheck command marks it back to available.

Rman> crosscheck Backup;

Replacing the recovery directory with the target database control file

Allocated channel: Ora_disk_1

Channel ora_disk_1:sid=25 Device Type =disk

Cross-check backup fragment: Found as ' AVAILABLE '

Backup fragment handle =f:/backup/bl_01li7bsc_1_1.bak recid=1 stamp=723758988

Cross-check backup fragment: Found as ' AVAILABLE '

Backup fragment handle =f:/backup/bl_02li7bsk_1_1.bak recid=2 stamp=723758997

Cross-check backup fragment: Found as ' AVAILABLE '

Backup fragment handle =f:/backup/bl_03li7bvk_1_1.bak recid=3 stamp=723759093

Can cross-parity data file backup, table space Backup, control file backup and server parameter file backup. In addition, you can choose to cross-efficacy and specific backups by identifying the tags associated with the backup. Based on the device used or based on a time period, we can even cross-check all the backups. Such as:

Crosscheck Backup of datafile 1;

Crosscheck Backup of tablespace users;

Crosscheck Backup of Controlfile;

Crosscheck Backup of SPFile;

Crosscheck backup tag= ' TEST ';

Crosscheck backup completed after ' sysdate-2 ';

Crosscheck backup completed between ' sysdate-5 ' and ' sysdate-2 ';

Crosscheck backup device type disk;

Cross-Validation Archive log Example:

Rman> crosscheck Archivelog All;

Replacing the recovery directory with the target database control file

Allocated channel: Ora_disk_1

Channel ora_disk_1:sid=24 Device Type =disk

Successful verification of the archive log

Archive log file name =d:/archivelog/bl_arc0000000005_0723658881.0001 recid=1 stamp=723756640

Successful verification of the archive log

Archive log file name =d:/archivelog/bl_arc0000000006_0723658881.0001 recid=2 stamp=723758988

Successful verification of the archive log

Archive log file name =d:/archivelog/bl_arc0000000007_0723658881.0001 recid=3 stamp=723759092

We can cross-check archived redo log backups based on a number or standard (including time, specific or specified range of SCN or log sequence numbers), and even use the like parameter to cross-test specific archived log backups. Such as:

Crosscheck archivelog like ' ARC001.log ';

Crosscheck archivelog ' D:/archivelog/arc023.log ';

Crosscheck archivelog like '%arc00012. LOG ';

Crosscheck Archivelog from Time "to_date (' 2010-7-10 ', ' yyyy-mm-dd ')";

Crosscheck Archivelog until Time "to_date (' 2010-7-10 ', ' yyyy-mm-dd ')";

Crosscheck Archivelog from Sequence 12;

Crosscheck Archivelog until sequence 522;

You can also cross-crosscheck copies using the Copy command. Includes a copy of the data file, a copy of the control file, an archive redo log copy, and an archived redo log on the disk. Such as:

Crosscheck copy of DataFile 5;

Crosscheck datafilecopy ' d:/app/administrator/oradata/bl/bl01. DBF ';

2. Validation of RMAN Backup

The validate command provided by RMAN allows viewing of a given backup set and validation to ensure that the backup set can be restored. Note that the validate command must obtain a primary key ID. This can be obtained using the list Backup summary command.

Rman> list Backup summary;

Backup List

===============

Keywords TY LV S device Type complete time segment number of replicas compression mark

------- -- -- - ----------- ---------- ------- ------- ---------- ---

1 B A a DISK July-July -10 1 1 NO tag20100707t200948

2 B F A DISK July-July -10 1 1 NO tag20100707t200956

3 B A A DISK July-July -10 1 1 NO tag20100707t201132

Rman> Validate Backupset 1;

Started validate in October-July-10

Using channel Ora_disk_1

Channel Ora_disk_1: Starting to validate archived log backup sets

Channel Ora_disk_1: Reading backup fragment F:/backup/bl_01li7bsc_1_1.bak

Channel Ora_disk_1: Segment handle = F:/backup/bl_01li7bsc_1_1.bak Mark = tag20100707t200948

Channel Ora_disk_1: Backup Fragment 1 restored

Channel Ora_disk_1: Verification completed, when: 00:00:03

Completed validate in October-July-10

3. Backup Save Policy

The Save policy (retention policy) is a way to manage backups and replicas and to specify their time to save on backup media. We can define two basic saving policies: the Recovery window Save policy (Recovery window backup retention policy) and the backup redundancy backup save policy (Backup redundancy backup retention policy ）。

Each redundancy policy remains known to be modified or deleted (or until the control file is rebuilt using the Create Controlfile command). The two redundancy policies are mutually exclusive. In addition, a physical backup slice can only be deleted when the delete command with the obsolete parameter is used, even if the redundancy policy is used.

(1) Recovery window backup Save policy

This save policy is customized based on the most recent date that you want the database to be restored to. Such as:

Configure retention Policy to recovery windows 7 days;

In this example, we saved the backup for nearly 7 days, and more than 7 days of backup is discarded.

(2) Backup redundancy backup Save policy

This backup strategy Rman retains n database backups starting with the latest backup. Such as:

Configure retention Policy to redundancy 3;

In this example, we save the last 3 valid backups.

(3) Maintenance of the preservation strategy

When a given backup or replica is discarded because of the criteria for the backup save policy, RMAN does not automatically delete the backup or copy, but simply mark it as obsolete. We can use the obsolete command to view backups that are marked as obsolete by Rman.