Oracle RMAN 11g Backup and Recovery (136 page)

Thus, the
validate
command is most often used for specific occasions where you want to check specific backup sets, or perhaps you want to check all backup sets in the flash recovery area.

The
validate
command does not check all database blocks. Those blocks that have never been used will not be checked. If you are running with compatibility set to 10.2 or greater, then blocks contained in locally managed tablespaces that were once used but are now unused will not be checked.

The
validate
command, by default, will only check for physical corruption, and logical corruption is not considered. If you wish to also check for logical corruption of the block, use the
check logical
option of the
validate
command. When the
validate
command has completed its checks, it will populate the V$DATABASE_BLOCK_CORRUPTION view. It might be a good idea, if you have configured monitoring of your databases, to include the count of the number of rows in this view in that monitoring. This way, you can tell if you have corruption issues you need to deal with.

The
validate
command will not discover certain types of corruption. Thus, it’s possible to run this command and still experience problems with your database. These situations are rare, but they do happen. One example of this is interblock corruption. This is corruption that occurs between two blocks, as might be the case in a block chaining situation. The
validate
command will not detect interblock corruption.

Here is an example of the use of the
validate
command to get the primary key of the backup set and validate that backup set. Note that you must pass the primary key ID of the backup set that you wish to validate. This primary key can be determined by running the
list backupset
summary
command.

RMAN> list backup summary;

List of Backups

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

2 B A A DISK 08 SEP 09 1 1 YES TAG20090908T025101

3 B F A DISK 08 SEP 09 1 1 YES TAG20090908T025112

4 B F A DISK 08 SEP 09 1 1 YES TAG20090908T025112

5 B A A DISK 08 SEP 09 1 1 YES TAG20090908T025311

6 B A A DISK 08 SEP 09 1 1 NO TAG20090908T025326

7 B F A DISK 08 SEP 09 1 1 NO TAG20090908T025328

8 B A A DISK 08 SEP 09 1 1 NO TAG20090908T025355

9 B A X DISK 08 SEP 09 1 1 YES TAG20090908T031112

10 B F X DISK 08 SEP 09 1 1 YES TAG20090908T031114

11 B A X DISK 08 SEP 09 1 1 YES TAG20090908T031116

12 B A A DISK 08 SEP 09 1 1 NO TAG20090908T032531

13 B F A DISK 08 SEP 09 1 1 NO TAG20090908T032815

14 B F X DISK 08 SEP 09 1 1 NO TAG20090908T032848

15 B F A DISK 08 SEP 09 1 1 NO TAG20090908T032850

Chapter 16: Maintaining RMAN
405

Note the different columns. These columns are defined in the Oracle Database Backup and Recovery Reference Guide (and there are a number of them). In this case, most of the columns are pretty self-explanatory except, perhaps, these:

■
Key
This is a unique identifier for each backup.

■
TY
This is the backup, either a backup set (B) or a proxy copy (P).

■
LV
This indicates the type of backup. A full database backup set is denoted with an F.

An archived redo log backup is denoted by an A. If the backup is an incremental backup, the LV column will contain a 0 for a base backup or a 1 for an incremental backup.

■
S
This indicates the status of the backup. This value can include A for available, U for unavailable, and X if all the backup set pieces have expired.

To make sure the backup is usable (not corrupted, as opposed to physically present), we can validate the backup set. In this case, it’s an archive log backup:

RMAN> validate backupset 2;

We can also validate all backups in the flash recovery area:

RMAN> validate recovery area;

Backup Retention Policies

In Chapter 3, we mentioned configuration of a retention policy for RMAN backups and copies. A
retention policy
is a method of managing backups and copies and specifying how long you want to keep them on your backup media. You can define two basic types of retention policies: the
recovery window backup retention policy
and the
backup redundancy backup retention policy.

We will talk more about those shortly.

Each redundancy policy is persistent until changed or removed (or until the control file is rebuilt using the
create controlfile
command). Additionally, the two redundancy policies are mutually exclusive. Finally, even with a redundancy policy, physical backup pieces are not removed until you use the
delete
command with the
obsolete
parameter to remove them.

Now, let’s look at each of these retention policies in more detail. After that, we will look at how we manage RMAN backups and copies that are made obsolete as a result of the retention policies.

Recovery Window Backup Retention Policy

The use of this type of retention policy is based on the latest possible date that you want to be able to recover your database to. With a recovery window backup retention policy, you can direct Oracle to make sure that if you want to be able to recover your database to a point in time two weeks ago, you will be able to do so.

For example, assume that today is Monday and you have three backups. The first backup was taken the day before, on Sunday; the second backup was taken on the previous Thursday; and the last backup was taken ten days ago, last Saturday. If the recovery window is set to seven days, then the first two backups (Sunday’s and Thursday’s) would be considered current. However, the backup taken ten days ago, on the previous Saturday, would be considered obsolete. If we

406
Part III: Using RMAN Effectively

wanted to establish this seven-day redundancy policy for RMAN, we would use the
configure
command with the
retention policy to recovery window
parameter:

configure retention policy to recovery window of 7 days;

Backup Redundancy Backup Retention Policy

When the backup redundancy backup retention policy is used, RMAN will maintain
x
number of database backups, starting with the most current backup. For example, suppose you have configured a backup redundancy of 3 and you did backups on Monday, Tuesday, Wednesday, and Thursday. Because the retention policy is set to 3, Oracle will obsolete the Monday backup as soon as the Thursday backup is successfully completed.

The backup window backup retention policy is enabled using the
configure
command with the
retention policy to redundancy
parameter. If you wanted to set the backup window backup retention policy to 3, you would use the following command:

configure retention policy to redundancy 3;

Retention Policy Maintenance

When a given backup or copy meets the criteria of a backup retention policy and becomes obsolete, what happens depends on whether you are using the flash recovery area (FRA) or a manual backup location. You may also want to change a backup so that its retention policy is different than the default retention policy. Let’s look at these options next.

Retention Policy Maintenance When Using the Flash Recovery Area
If you are using the flash recovery area, RMAN will eventually remove the backup set pieces, image copies, or archived redo logs (we will just call these backups for now) from the FRA based on space demands. This means that the backups will remain in place potentially for some time, until the space is needed by another backup or archive log. As a result, you might look at FRA space utilization and be concerned because it’s growing when you feel it should be steady state. You can determine the amount of FRA space that is consumed by obsolete backups by querying the V$RECOVER_FILE_DEST view column SPACE_RECLAIMABLE. By using this view, you can determine if you have allocated sufficient space to the FRA. Here is an example of a query against V$RECOVER_FILE_DEST: