Lesson 9

This module discussed command-line options and initial operations using Recovery Manager.
Specifically, you learned how to:

1. Issue the command to start RMAN
2. Start RMAN without recovery catalog
3. Register a target database into your recovery catalog
4. Discuss the use of the reset command
5. Demonstrate how to resynchronize a target database using the resynch command
6. Identify other situations where the resynch command is needed
7. Use the change command to alter the information in your recovery catalog
8. Use the delete command to remove data from your recovery catalog and the validate command to check the validity of your recovery catalog

It is highly recommended that you use the recovery catalog. Though you may spend time using the recovery catalog initially, you will be rewarded when you need to restore your database. However, there may be few instances where it is unadvisable to use a recovery catalog, such as having a local Oracle database on your machine. Often these local databases do not contain critical information or contain information that is easily re-created. Even then, if you are on a network and your data is important, it is safer to manage your database in the manner that you manage all other production Oracle database.

RMAN (Recovery Manager) and a Recovery Catalog have a close relationship when it comes to backing up an Oracle database. Here's a breakdown:

• What is RMAN?: RMAN is Oracle's powerful tool for backing up, restoring, and recovering databases. It provides features like incremental backups, compression, encryption, and more.
• What is a Recovery Catalog?:
  A Recovery Catalog is a separate Oracle database schema that acts as a central repository for RMAN metadata. This metadata includes information about:
  • Database backups: types, locations, timestamps, etc.
  • Database structure: tablespaces, datafiles, etc.
  • Archived redo logs
  • RMAN configurations
  
  
• How do they work together?:
  1. Backup Information: When RMAN performs a backup, it records metadata about that backup in both the target database's control file and the Recovery Catalog.
  2. Centralized Management: The Recovery Catalog provides a centralized location to manage backups for multiple databases. This simplifies administration and reporting.
  3. Long-term Retention: Control files have limited space for historical backup information. The Recovery Catalog allows you to store backup metadata for much longer periods.
  4. Enhanced Restore and Recovery: The Recovery Catalog is crucial for complex recovery scenarios. If you lose your control file, the Recovery Catalog can be used to identify available backups and perform a complete recovery.
  5. Improved Performance: RMAN can use the Recovery Catalog to quickly identify the necessary files for restore and recovery operations, potentially speeding up the process.

Key Benefits of Using a Recovery Catalog:

• Centralized management: of backups for multiple databases
• Long-term retention: of backup metadata
• Improved restore and recovery: capabilities, especially in disaster scenarios
• Increased reliability: by providing a backup of your RMAN metadata
• Simplified reporting: on backup status and history

In essence: RMAN is the tool that performs the backups, while the Recovery Catalog acts as a detailed and organized record keeper for all your backup activities. This combination provides a robust and reliable framework for protecting your Oracle database.

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. Therefore, the RMAN metadata 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:

1. You must use a recovery catalog if you want to use stored RMAN scripts.
2. You want to use the keep forever option when performing an RMAN backup.
3. You must use a recovery catalog if you are using one or more standby databases.
4. You must use a recovery catalog if you are using a split-mirror backup model.
5. 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.
6. A recovery catalog allows more flexibility when you are doing reporting because you can report on the target database at a time other than the current time.
7. With a recovery catalog, certain default database RMAN channel configuration information will still be maintained without you needing to manually recover it in the event of a control file failure.

Since version 10g, 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.

Problem: You are new to Oracle and wonder how to connect to your database via SQL*Plus so that you can perform basic commands, such as starting and stopping your database and enabling archivelog mode.
Solution: Before you connect to an Oracle database, you must establish operating system variables before connecting to the database, and you also need access to either a privileged OS account or a database user granted the appropriate privileges (via a password file). These topics are discussed in the following subsections.
Establishing OS Variables The OS environment variables are usually set when you log on to your database server. DBAs typically set these variables automatically in a startup file (such as .bashrc on Linux/Unix). Minimally, you need to set:

1. ORACLE_SID to the name of your target database
2. ORACLE_HOME to the parent directory where you installed the Oracle RDBMS software (binaries)
3. PATH to include ORACLE_HOME/bin

In a Linux/Unix environment, Oracle provides an oraenv script for the Korn/Bash/Bourne shells and coraenv for the C shell to set the required OS variables. For example, you can run the oraenv script from the operating system prompt as follows:

$ .oraenv

You will be prompted for the name of your database. You can verify the settings of these variables as follows:

$ echo $ORACLE_SID
$ echo $ORACLE_HOME
$ echo $PATH

If the need arises, you can override these settings by establishing OS environment variables from the command line. Here is an example of manually establishing these variables in a Linux/Unix environment:

$ export ORACLE_SID=o12c
$ export ORACLE_HOME=/u01/app/oracle/product/12.1.0.1/db_1
$ export PATH=$ORACLE_HOME/bin:$PATH

Keep in mind the prior code is just an example. You will need to modify the prior commands to match the target ORACLE_SID and ORACLE_HOME in your environment.
Note: In Windows the operating system variables are set in the registry. After you have established your operating system variables, you need to connect to the database with the proper privileges. You can do this in one of two ways: using OS authentication or using a password file. Using OS Authentications If your Linux/Unix account is a member of the dba group (your shop might use a different group name, but dba is the most common), you can connect to your database with the required privileges via SQL*Plus by virtue of being logged in to your Linux/Unix account. On Windows, the OS user must be part of either the ora_dba group or the ora_oper group. On Linux/Unix you can quickly verify the operating system groups that your account belongs to using the id command without any parameters:

$ id
uid=500(oracle) gid=500(oinstall) groups=500(oinstall),501(dba),502(oper),503(asmdba),
504(asmoper),505(asmadmin),506(backupdba)

The prior output indicates that the oracle user is included in several groups, one of which is dba. Any user who belongs to the dba group can connect to the database with sysdba privileges. A user with sysdba privileges can start and stop the database. This example uses OS authentication to connect to your database as the user sys:

$ sqlplus / as sysdba

No username or password is required when using OS authentication (hence just the slash without a user/ password) because Oracle first checks to see if the OS user is a member of a privileged OS group, and if so, connects without checking the username/password. You can verify that you have connected as sys by issuing the following:

SQL> show user

USER is "SYS"
In the next module you will learn about using the recovery catalog.

The following terms were introduced in this module:

1. resetlogs: Used to reapply the archive log files to your database.
2. Incarnation number: Unique number that is used to identify a version of the database.

The following section discussing RMAN syntax in greater detail.

Click the Quiz link below to review your understanding of the information presented in this module.
Recovery Catalog Maintenance - Quiz