Chapter 6. Configuring and Recovering with RMAN

This chapter is probably going to be amongst the most ponderous chapters of the book—one that you will want to keep returning to. Any tool is only good if it has the ability to be optimized depending on the requirements of its user and the ability to perform the most important tasks that it's meant for. The same goes for RMAN as well; it can not only be customized to a great extent, but also has the ability to recover your database from a variety of crashes. In this chapter, we shall look at these two abilities of RMAN, that is, how to configure it and how to use it for database recovery. Sounds interesting, doesn't it? So let us get started, shall we?

In the chapter, we will be discussing the following topics:

• Listing the various configuration settings of RMAN

• Altering RMAN configurations using the CONFIGURE command

• Understanding the mechanics of database recovery

• Performing recoveries using RMAN

RMAN configuration – an introduction

There are numerous configurations that can be instrumental in extracting the best out of RMAN. Though RMAN is extremely flexible, the default configuration options available also fare very well in many cases.

There are two ways to list the configuration settings possible for RMAN: from the view V$RMAN_CONFIGURATION, or by executing the command SHOW ALL from the RMAN client. All the configuration settings, either default or modified, are stored in the target database's control file.

Using the V$RMAN_CONFIGURATION view

This can be one of the simplest ways to gather information about the configuration settings for RMAN. This view lists the persistent configuration settings made by the command CONFIGURE (which will be discussed later in the chapter). In other words, this view lists the non-default settings for RMAN. The following code is the output of this view:

SQL> SELECT * FROM V$rman_configuration;

  CONF# NAME                       VALUE           ...

Configuring the backup retention policy

It is imperative that the backups taken at a specific point in time do not occupy the storage space indefinitely. There ought to be a mechanism in place to identify and delete the archaic backups once they are of no significance to the recovery. The retention policy is the configuration from which RMAN identifies the backups which are not relevant to the recovery anymore. This is extremely useful as in a dynamic database, the older backups need to be removed from the storage space because it is the latest backups, containing more recent changes to the database, that will be more useful during recovery.

Based on the configured retention policy, RMAN will mark the old backups as obsolete.

Two mutually exclusive retention policies are available:

• Redundancy (the number of copies of the backups to be kept)

• Recovery window of n days (the number of days for which the backups need to be kept)

Let's take a look at these two retention policies in detail.

Redundancy...

Using backup optimization

Using this feature, the backup of files; that is, the data files, archived redo logs, and the backup sets which are already backed up to a destination device type will be skipped. Such optimization is very helpful to speed up the backups and reduce the size of the backup sets, especially for read-only tablespaces. Though this is something that should work with the normal BACKUP command, it doesn't! This option works only for the following commands:

• DATABASE

• ARCHIVELOG ALL/LIKE

• BACKUPSET ALL

• RECOVERY AREA

• RECOVERY FILES

• DATAFILECOPY

To see whether or not you have the backup optimization option on, you can use the SHOW command as follows:

RMAN> SHOW BACKUP OPTIMIZATION;

RMAN configuration parameters for database with db_unique_name ORCL12 are:
CONFIGURE BACKUP OPTIMIZATION OFF;

Since this is the default setting, let's take the backup of the archived logs and see whether they all come under the backup or not:

RMAN> BACKUP ARCHIVELOG ALL;

Since we have taken...

Configuring the device types for the backup

The next option is to configure the device types on which the backup can be done. The default destination will be FRA, if configured. Even if FRA is not configured, the default device type will still be a disk, as a default disk channel is preconfigured for use in the RMAN. FRA can be configured only over the disk device type but if you want, another tape drive device type can also be configured.

Note

We shall discuss FRA in an upcoming section.

To list the current device type in use, you can use the SHOW command again:

RMAN> SHOW DEVICE TYPE;

RMAN configuration parameters for database with db_unique_name ACDB are:
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

The second device type is the tape drive which is called as an SBT. To use it, a separate tape channel needs to be allocated along with a media manager software such as Oracle Secure Backup.

You can override the configured destination, whether it's FRA or a...

Configuring auto backup for the control file and SPFILE

Besides the data files and archived redo log files, it's very important to take a backup of the control file and the SPFILE. Both these files are automatically backed up with the backup of data file #1, but won't when any other tablespace or file is backed up. Attainment of the control file backup is possible using the command BACKUP with the option CONTROLFILE. The default setting is OFF and we can see it using the SHOW command:

RMAN> SHOW CONTROLFILE AUTOBACKUP;
RMAN configuration parameters for database with db_unique_name ORCL12 are:CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default

We can see that an automatic backup for the control file isn't enabled. Auto backup of the control file is important because having it available makes the restore operation for a lost control file very easy. A simple command like RESTORE CONTROLFILE FROM AUTOBACKUP is enough for RMAN to automatically locate the correct backup of the control file and...

Configuring RMAN channels

Channels in RMAN perform all the tasks involving I/O, that is, backup, restore, and recover. Each channel will be responsible for the I/O stream that's going to either read from the disk while doing a backup or write to the disk while performing a restore. To make things easier, if you are taking a backup on the disk, RMAN configures a channel with the device type configured as disk by default. In addition to this, a default channel is also configured for maintenance-related commands such as CROSSCHECK, CHANGE, and so on. Let's see the nexus of the channels with RMAN via a figure:

In the previous figure, we have two channels: one for disk and another for SBT, to talk to a target database and make a connection to it. As channels are essentially sessions spawned within the target database, any task executed from the RMAN client will be executed from within the database by them.

Note

If desired, you can still allocate the maintenance channel manually using the ALLOCATE...

Creating duplexed backups

By default, RMAN will create only a single copy of the backup but it is always advisable to have more than one copy of the backup because, as Murphy's law says, if something can go wrong, it will. To safeguard from a situation where you have lost the one and only copy of the backup, you can create multiple copies of the backup piece within your backup set with a maximum of four copies allowed.

Note

The option for duplexed backups is possible only for backup pieces and not for image copies. Also, the auto backup of the control file is never duplexed.

To understand this feature, let's configure the duplexed backup to two copies for a tablespace and take its backup:

RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;

The previous command configures the number of backup copies to 2 and uses DISK as the destination device.

Note

It is important to mention the device type which is going to store the duplexed copies of the backups. The reason for this is though...

Configuring encrypted backups

As necessary as it is to ensure that backups (and restores) are performed without spending much time, making these backups secure is also very important. You may ask why and the answer is that if someone gets their hands on the backup of a database, creating a duplicate database from it wouldn't be very tough. That's the reason why backups must be encrypted, to prevent such indirect stealing of databases. As you may have guessed already, RMAN can certainly do this.

From Version 10.2 onwards, RMAN has the option of creating the encrypted backups which will be decrypted during the restore and recover operations. To do so, the decryption keys are required which are stored individually within every backup piece. Also, for each backup set, there will be a separate key generated.

To perform encryption, you need to enable the option using the command CONFIGURE ENCRYPTION FOR DATABASE ON.

There are three modes which are available for encryption:

• Transparent encryption

• Password...

Configuring compression for backups

Compression comes in handy as it enables us to reduce the storage space for the backups taken. However, compression is a double-edged sword. Where using it enables us to save storage space, it may also burn the CPU from an acceptable percentage to a very high value, based on many factors. Because RMAN has inbuilt compression, there shouldn't be a requirement to seek this feature from any third party tool(s).

RMAN offers various types of compression schemes with different kinds of compression ratios using different amounts of system resources. The available options for compression are as follows:

• None

• Basic

• Low

• Medium

• High

You can configure the default or basic compression mode using the CONFIGURE command:

RMAN> CONFIGURE COMPRESSION ALGORITH 'BASIC';

In order to use any other mode of compression, the same command can be used along with the name of the mode, as shown in the following example:

RMAN> CONFIGURE COMPRESSION ALGORITHM 'LOW';

As we have already...

Configuring the snapshot control file

It is common knowledge that data files can be backed up when the database is open. This option is called the hot backup or open database backup. It is possible because even when the files are being constantly modified and are inconsistent, they can be made consistent by using archived log files in the recovery stage. Creating a consistent file is imperative as otherwise the database can't be opened. Archived logs are self-contained anyway, so taking their backup with an open database is not an issue. However, in the case of the control file that always gets updated, a hot backup of it won't be usable at all. This presents an interesting issue, but fortunately, a solution to tackle it is available with RMAN in the form of a snapshot control file!

A snapshot control file is the point-in-time copy of the current control file when its backup is initiated in the open database mode. This is not really the backup of the control file (though it can be used as...

Configuring the archived log deletion policy

Archived redo logs may consume a mammoth portion of the storage space. That's why it would be handy if obsolete archived logs could be identified and deleted automatically. This is possible using the archived log deletion policy.

There is no default policy to control the automatic deletion of archived logs (the default policy value is NONE). That's why, by default, archived redo logs are considered to be eligible for deletion if they are moved to a remote destination using the parameter LOG_ARCHIVE_DEST_N and, as per the recovery window retention policy, they are marked as obsolete. If FRA is configured, the stored archived redo logs must be backed up at least once, either to a tape or a disk-based location. It's important to remember that only the archived redo logs which are stored in FRA will be automatically deleted. If you are not using FRA, the files will need to be deleted manually using a deletion command such as DELETE ARCHIVELOG ALL.

There...

Configuring the FRA

FRA was first introduced with the database release 10g as an Oracle-managed location for storing backup files and other files such as archived logs, control files, and so on. FRA simplifies the management of these files stored within it as the names of these files are auto-assigned, and those which are not needed, become candidates for auto-deletion and would be removed on a periodic basis.

There are two kinds of files that can be created in the FRA: persistent and transient. The following figure shows all the files that can be created in the FRA. In it, the dark colored circles represent the persistent file types while the rest represent the transient file types.

You can see that, except for the multiplexed copies of the control files and online redo logs, the rest of the files are transient in nature. Based on conditions such as space constraints in FRA and the retention policy, these transient files will be automatically deleted.

To enable FRA, you will need to set two...

Configuring authentication for RMAN

RMAN, being a database tool, needs to connect with the user using a valid username that has proper privileges and roles to perform backups. The user needs to be authenticated as well, and RMAN supports two types of authentications:

• Operating system (OS) authentication

• Password file authentication

Let's see how to set up OS authentication first.

Operating system authentication

OS authentication validates the username, using the operating system user and group(s). For a RMAN connection, two things need to be set: the first is the Oracle Home and the second is the OS user which must be part of either the DBA group or the OSBACKUPDBA group; this is required for connecting to the new SYSBACKUP role. This role is designated for those who want to work on either RMAN or SQLPLUS to manage the tasks of backup and recovery only.

The default privilege used is sysdba for RMAN. If you want to connect using OS authentication and the SYSBACKUP privilege, you need to explicitly...

Crash and media recovery

In general, database recoveries can be categorized into two broad domains:

• Crash recovery

• Media recovery

Crash recovery (a.k.a. instance recovery) is a more subtle form of database recovery because all that is lost is the database instance. Since it's just the instance that's lost and not any physical file of the database, the recovery won't need any physical file(s) to be restored. The background process SMON will initiate the recovery automatically at the time of the next database startup. In this recovery, only the online redo logs belonging to a single thread (for a single instance) or of multiple failed threads are used for a Real Application Cluster (RAC) database.

Note

Many DBAs often use the terms instance and crash recovery interchangeably. However, it is actually wrong to do so. In a single instance, the loss of one instance is going to bring down its database as well. So a recovery in this case can be called either an instance or a crash recovery. But in an...

Key terms related to recovery

There are many internal structures that play a very important role in the recovery of the database and also in its internal workings. In the following list, we shall look at the most important key terms which are a must for you to understand:

• Data block: It is the smallest unit among the storage structures of the database and is used for storing user data. An example is the infamous table EMP which contains the employee data. Thus, for an employee AMAN, block #100, for example, would contain the data in the form of a row belonging to it.

• Dirty block: When a database block's content is modified by a DML, as long as that transaction is not completed with either a ROLLBACK or COMMIT command, the data is termed as inconsistent and correspondingly, that block is marked as a dirty block. A dirty block would need to have its transaction status updated with either a ROLLBACK or COMMIT command to finally become a clean block.

• Change vectors: The changes done over the...

Summary

In this chapter, we took a look at the numerous options for RMAN configurations and also the recovery scenarios of different kinds of possible crashes. Although it's not tough to perform recovery, when there is an actual crash, it's quite possible that panic may strike if you are not comfortable with the process to resolve the issue. Thus, I would strongly suggest that you don't wait for the crash to happen in your production database, but that you practice recovery for these cases more than once, such that you can recover from either of them, even with your eyes closed.

The next chapter will discuss two very important concepts: how to use RMAN for reporting the metadata that it has collected, and the creation, management, and usage of RMAN's recovery catalog.