Oracle RMAN 11g Backup and Recovery (77 page)

view to determine which incarnations you wish to remove. Record the DBINC_KEY value for each incarnation you wish to remove. Then, to remove the incarnation, use SQL*Plus and issue a
delete
command to remove the incarnation from the DBINC table using the DBINC_KEY values you previously recorded. Here is an example of the
delete
SQL command that you would use: DELETE FROM dbinc WHERE dbinc key 2;

Backing Up the Recovery Catalog

The procedure for using RMAN to back up a database can be found in Chapter 9, and it just so happens that it is perfectly okay to use RMAN to back up your recovery catalog database. Just make sure you have a sound recovery strategy, so you can restore your recovery catalog as quickly as possible. Also, remember that losing the recovery catalog is not the end of the world.

Even if you are using a recovery catalog, you can still recover your databases later without it. All you really need is a backup of the database control file (or, in a really bad situation, some fancy work with DBMS_BACKUP_RESTORE!). The really important thing to note is that you need to test your entire recovery strategy. Only then can you know, and be comfortable with, your ability to recover your databases.

Chapter 10: Using the Recovery Catalog
217

Recovery Catalog Views

The recovery catalog provides a series of views that can be used to explore the metadata being produced by your RMAN backup strategy. These views have base tables that are populated when you register your database, and then populated on any subsequent
resync
command from the catalog. The naming convention for these views is RC_*; for example, RC_BACKUP_SET or RC_

BACKUP_REDOLOG.

As RMAN operations have grown increasingly independent of the recovery catalog, many of the views that previously were unique to it have been incorporated into tables in the target database control file. This means that there is now a corresponding v$view for most RC_* views in the catalog. For instance, if the recovery catalog view is RC_BACKUP_SET, the v$view would be V$BACKUP_SET. The only difference would be a primary key column in the recovery catalog that does not exist in the v$view.

Next, we provide a list of the critical RC_* (and corresponding V$) views in the catalog, along with brief explanations. It is beyond the scope of this book to give a complete rundown of each column in each view; the Oracle-provided documentation does this excellently. Instead, we give a brief explanation of what the view might mean to you and how you might use it. We’ve left out all views that deal with proxy copies, because they are not covered in this book, and have left out all views that deal with stored scripts.

Having access to these key views is a critical tool when setting up and refining a backup strategy; no doubt you will also want to access them prior to any restore and recovery operation.

It is extremely useful to put together a series of scripts that you can run on demand, or even to schedule a report output on a regular basis. We provide an example of a few catalog queries that can prove useful to you during backup and recovery operations.

It is worth noting that some of the examples in this chapter select against the v$view of the target database, while others refer to the RC_* views in the catalog. If you are making selections against the catalog and have more than one database registered, you always need to limit your query based on the DBID or the DB_NAME (if it’s unique within the catalog). Otherwise, you will get information for more than one database, which won’t be that useful unless you are trying to gather enterprise-wide information.

RC_ARCHIVED_LOG (V$ARCHIVED_LOG)

The archive log history in V$ARCHIVED_LOG will be one of the most heavily utilized views you have at your disposal. Due to the confusing nature of backing up archive logs and restoring them for recovery purposes, having access to their metadata is critical. Bear in mind that RC_

ARCHIVED_LOG does not hold information about any backups you have of your archive logs (see RC_BACKUP_REDOLOG for that); it holds only information about all archive logs that have been generated by the target. Because archive logs are constantly being generated, whereas catalog resyncs are relatively less frequent, you will find yourself most often at the V$ARCHIVED_

LOG version of this view, instead of at RC_ARCHIVED_LOG. The kind of code that would give you the most out of this view would look something like this:

column name format a50

column completion time format a25

alter session set nls date format 'DD-MON-YYYY:HH24:MI:SS';

select name, sequence#, status, completion time

from rc archived log;

218
Part II: Setup Principles and Practices

RC_BACKUP_CONTROLFILE (V$BACKUP_DATAFILE)

This view provides information about backups you have taken of your control file. This does not include control file copies; there is a different view for copies that have been made with the
copy
command or cataloged with the
catalog
command. This view is an excellent source to reference if control file restore operations are behaving strangely, particularly if you are trying to duplicate for standby database creation.

To review control file copies in V$BACKUP_DATAFILE, you would look at records with a file number of 0—this represents the control file:

select file#, creation time, resetlogs time,

blocks, block size, controlfile type

from v$backup datafile where file# 0;

The following query would give you information about all the control file backups for the database V102, with the completion time, the status, the type of control file (B for a normal backup and S for a standby control file backup), and the date of the autobackup (this will be null if you do not have the control file autobackup configured):

column completion time format a25

column autobackup date format a25

alter session set nls date format 'DD-MON-YYYY:HH24:MI:SS';

select db name, status, completion time, controlfile type,

autobackup date from rc backup controlfile

where db name 'V102';

RC_BACKUP_CORRUPTION (V$BACKUP_CORRUPTION)

This view lists the corruption that exists in datafile backups. To tolerate corruption, the value of MAXCORRUPT must be set to a non-zero value, which indicates how many corrupt blocks RMAN will back up before it throws an error and aborts. The corrupt blocks are not discarded, but rather are backed up as is.

Do not confuse this view with RC_DATABASE_BLOCK_CORRUPTION (described later in this chapter), which lists blocks that are corrupt in the database based on the last backup operation (or
backup validate
). RC_BACKUP_CORRUPTION lists blocks that are corrupt in the backup, not in the database itself.

The following code provides a list of corrupt blocks, with block number, file number, backup piece in which the corruption exists, and the type of corruption for the database V102: select db name, piece#, file#, block#, blocks, corruption type

from rc backup corruption where db name 'V102';

RC_BACKUP_DATAFILE (V$BACKUP_DATAFILE)

This view has extensive information about datafiles that exist in backup sets. If you are interested in viewing specific information about datafiles that have been backed up, use this view.

RC_BACKUP_FILES (V$BACKUP_FILES)

This view most completely corresponds to the information provided by the commands
list backup
and
list copy
from the RMAN command-line interface. This view provides details about all backup