Oracle RMAN 11g Backup and Recovery (74 page)

Line 1 is an O/S error that was returned to Oracle. In this case, it doesn’t prove too helpful in resolving the problem. Lines 2 and 3 provide the answer and should be recognizable to Oracle DBAs. “ORA-27101: shared memory realm does not exist” means the database instance was not running, and therefore RMAN could not connect to the database.

The first example could happen whether or not you are using TSM. The next scenario will introduce an error only if you are using TSM. We begin with an RMAN run block that allocates a channel, backs up the archive logs, deletes them, and then releases the channel.

RMAN> RMAN> run

2> { allocate channel tdpo type 'sbt tape' parms

3> 'ENV (TDPO OPTFILE

4> /opt/tivoli/tsm/client/oracle/bin/tdpo.opt)';

5> backup database;

6> release channel tdpo;

7> }

RMAN-00571:

RMAN-00569:

ERROR MESSAGE STACK FOLLOWS

RMAN-00571:

ORA-19506: failed to create sequential file, name "rac 9ikk7ac3 1 1", parms ""

ORA-27028: skgfqcre: sbtbackup returned error

ORA-19511: Error received from media manager layer, error text:

ANS1353E (RC53) Session rejected: Unknown or incorrect ID entered

RMAN>

Again, starting with the bottom-up approach, we read the error messages starting with 1.

4. ORA-19506: failed to create sequential file, name=“a400_9ikk7ac3_1_1”, parms=““ 3. ORA-27028: skgfqcre: sbtbackup returned error

2. ORA-19511: Error received from media manager layer, error text:

1. ANS1353E (RC53) Session rejected: Unknown or incorrect ID entered

206
Part II: Setup Principles and Practices

ANS and ANU are errors returned by the TDPO library. Line 3 indicates RMAN received an error from the media management layer (TDPO library). Lines 2 and 1 are again RMAN saying that it failed to create the backup file of the archive logs. ANU and ANS errors can be time-consuming to troubleshoot because many configuration and parameter files and settings have to be checked as well as many different TSM errors that can be returned. From the error message returned in step 1, “Session rejected,” we can assume a connection was made from RMAN to TSM and TSM rejected the session. Many different causes may result in a session being rejected; in this case, it is a lack of a password file for the tdpo node. As mentioned earlier in the chapter, to back up or restore a RMAN backup, a tdpo node name and password are supplied to TSM. To quickly troubleshoot this error, check the tdpo options file for the tdpo name that RMAN is using, and then also check to ensure RMAN can access the password file for the tdpo name. Also look in the dsm.sys for the parameter ERRORLOGNAME. This will tell you the path to the file where TDPO will save error information and may provide more details. Your storage administrator may also be able to see if the session rejection message in the TSM logs fails and may be able to provide additional details.

Additional Troubleshooting

To turn on or off debug is a simple
debug on;
or
debug off;
command. Once debug is on, we need to inform RMAN what additional debug information is to be collected. On the
allocate
channel
command, trace=1 is used to create trace files in the user_dump_destination directory.

Also on the
allocate channel
command, the debug=2 instructs RMAN to send additional information to the sbtio.log file.

Summary

Once you perform the initial installation and setup of TSM and TDPO in a few easy steps, it’s a case mostly of “set it and forget it,” allowing you, the DBA, to focus more on the RMAN scripts themselves than on managing where and how TSM stores the backups. When problems do arise, by properly reading out an error, you will quickly be able to diagnose backup failures and whether the problem lies with the database or with TSM.

TSM and TDPO not only make it easy to back up your Oracle database using the familiar RMAN interface, but also reduce your enterprise’s storage management administrative costs because you can use a single storage manager—Tivoli Storage Manager—for all of your backup, recovery, and archival needs.

CHAPTER

10

Using the Recovery

Catalog

208
Part II: Setup Principles and Practices

racle maintains all of the metadata related to RMAN operations in the
RMAN

repository.
The RMAN repository is
always
stored in the control file of the target
O
databases. In some cases, you might want to store the RMAN repository for your database in another location. This location is called the RMAN
recovery catalog.

RMAN does not require the recovery catalog for most operations, so often it is truly an optional component. Because the recovery catalog is largely optional, RMAN actually defaults to a configuration with no recovery catalog. In this section, first we look at what the recovery catalog is and when you need to use it. Then, we look at how you create a recovery catalog and discuss backup and recovery of the recovery catalog.

What Is the Recovery Catalog?

The
recovery catalog
is an optional component of RMAN that stores historical backup information from RMAN backups. Unlike the database control file’s RMAN information, the recovery catalog data is not purged on a regular basis. Thus, the historical information in the recovery catalog tends to be more comprehensive and to date further back than the historical information in the control file. Using a recovery catalog does have a few additional benefits over just using the database control file:

■ You must use a recovery catalog if you wish to use stored RMAN scripts.

■ A recovery catalog offers a single, enterprise-wide repository of RMAN information. This provides an easier and more flexible central repository of enterprise backup information.

■ A recovery catalog allows more flexibility when doing reporting, since you can report on the target database at a time other than the current time.

■ With a recovery catalog, certain default database RMAN channel configuration information will still be maintained.

If you are an old hand at RMAN, you may have noticed some bulleted items missing here.

First, since version 10
g,
Oracle Database has easily supported recovery through
resetlogs
without a recovery catalog. Also, if you are using control file autobackups (which we strongly suggest), the need for a recovery catalog for control file recoveries is pretty much removed.

NOTE

If you are not going to use a recovery catalog, keep a record of your
database DBIDs. While this is not required, and you can work around

it, having the DBIDs for your databases will make recovery operations
much easier.

Should you use a recovery catalog? If you have just a few databases, then the recovery catalog is probably not worth the extra effort and hassle. If you have a database environment with many databases in it, you should consider using a recovery catalog. Generally, the added flexibility and centralized enterprise-wide reporting benefits of the recovery catalog outweigh the maintenance

Chapter 10: Using the Recovery Catalog
209

and administrative requirements that are added with the use of a recovery catalog. One downside to using a recovery catalog, though, is that if the catalog database is down,
your backups will all
fail
unless you have coded your backup scripts to perform a backup without the recovery catalog in cases where the first backup with the recovery catalog fails.

Additionally, a recovery catalog is an essential part of a Data Guard backup environment and split mirror backups. In these configurations, when you back up the database from the backup host, the recovery catalog is considered the most current information, so it is the brains behind the strategy and becomes a single point of failure if not maintained properly. The bottom line is that you need to decide for yourself whether your environment calls for a recovery catalog.

When connecting to RMAN, you must use the
catalog
command-line parameter to indicate that you want RMAN to connect to a recovery catalog. By default, RMAN uses the
nocatalog
option, which indicates that a recovery catalog will not be used. After using the
catalog
parameter, indicate the userid and password of the recovery catalog schema that contains the recovery catalog objects. Here is an example of connecting to the recovery catalog by using the RMAN

command line:

RMAN target 'sys/robert as sysdba@robt'

catalog 'cataloguser/password@bcatalog'

Creating the Recovery Catalog

As you might expect, some setup is required before we can actually connect to the recovery catalog. First, we need to create the recovery catalog user and grant it the appropriate privileges.

Then, we need to connect to it and create the recovery catalog schema objects. Let’s look at each of these steps next.

Configuring the Database for the Recovery Catalog

The recovery catalog database should, if possible, exist on its own database. However, in our experience, many sites use an active database as the recovery catalog database, which is fine as long as you take precautions when backing up that database.

Oracle makes the following suggestions with regard to space allocations for a recovery catalog database that would maintain recovery catalog records for one year:
Tablespace Name

Size Requirement

SYSTEM

90MB

TEMP

5MB

UNDO

5MB

RECOVERY CATALOG SCHEMA

15MB per registered database

ONLINE REDO LOGS

1MB per online redo log file

Creating the Recovery Catalog User

Generally, the recovery catalog should reside in its own database, because the recovery catalog is pretty useless if it is in the same database that you are trying to recover. The next RMAN Workshop provides a set of detailed instructions on creating the recovery catalog user account.