1. Running the RMAN Client Remotely or Locally

This allows you to run RMAN backups on disparate remote servers from one central location. When you run RMAN remotely, the backup files are always created on the target database server.

If you run RMAN remotely, you need to be sure the remote rman executable is compatible with the target database. For example, you may establish that the remote rman executable you are running is an Oracle Database 12c version of the RMAN client, and it is compatible with several earlier versions of Oracle database. If you run the rman client locally on the target server, there is never a compatibility issue because the rman client is always the same version as the target database.

2. Specifying the Backup User

3. Using Online or Offline Backups

Most production databases have 24-7 availability requirements. Therefore, your only option is online RMAN backups. Your database must be in archivelog mode for online backups. You need to consider carefully how to place archivelogs, how to format them, how often to back them up, and how long to retain them before deletion. These topics are discussed in subsequent sections.

4. Setting the Archivelog Destination and File Format

Enabling archive redo log mode is a prerequisite for making online backups (see Chapter 5 for a full discussion of architectural decisions regarding the archivelog destination and format and how to enable/disable archivelog mode).

If you do not use an FRA, and if you do not explicitly set the archivelog destination via a LOG_ARCHIVE_DEST_N initialization parameter, then by default the archivelogs are written to an OS-dependent location. On many Linux/Unix boxes the default location is the ORACLE_HOME/dbs directory. The default file name format for archivelogs is %t_%s_%r.dbf. The format is a shorthand to reference date, backup set number, etc. The %t is timestamp, %s is log sequence number and %r is reset logs ID.

Sometimes, DBAs use .dbf as an extension for both data files and archivelog files. I prefer to use .arc for the archivelog files. The .arc extension avoids the potentially confusing task of identifying a file as an archivelog file or a live database data file.

5. Configuring the RMAN Backup Location and File Format

6. Setting the Autobackup of the Control File

The automatic control file backup always goes into its own backup set. When autobackup of the control file is enabled, if you are using an spfile, it is automatically backed up along with the control file.

7. Specifying the Location of the Autobackup of the Control File

8. Backing Up Archivelogs

You should back up your archivelogs on a regular basis. The archivelog files should not be removed from disk until you have backed them up at least once. I usually like to keep on disk any archivelogs that have been generated since the last good RMAN backup.

Sometimes, if your database generates a great deal of redo, you may need to back up your archivelogs at a frequency different from that of the data files. DBAs may back up the archivelogs two or three times a day; after the logs are backed up, the DBAs delete them to make room for more current archivelog files.

In most situations, you do not need any archivelogs that were generated before your last good backup. For example, if a data file has experienced media failure, you need to restore the data file from a backup and then apply any archivelogs that were generated during and after the backup of the data file.

On some occasions, you may need archivelogs that were generated before the last backup. For instance, you may experience a media failure, attempt to restore your database from the last good backup, find corruption in that backup, and therefore need to restore from an older backup. At that point, you need a copy of all archivelogs that have been generated since that older backup was made.

9. Determining the Location for the Snapshot Control File

RMAN creates a snapshot copy of the current control file that it uses as a read-consistent copy while it is performing these tasks. This ensures that RMAN is working from a copy of the control file that is not being modified.

The default location of the snapshot control file is OS specific. On Linux platforms, the default location/format is ORACLE_HOME/dbs/[email protected]. Note that the default location is not in the FRA.

For most situations, the default location and format of the snapshot control file are sufficient. This file does not use much space or have any intensive I/O requirements. I recommend that you use the default setting.

10. Using a Recovery Catalog

RMAN always stores its latest backup operations in the target database control file. You can set up an optional recovery catalog to store metadata regarding RMAN backups. The recovery catalog is a separate schema (usually in a database different from that of the target database) that contains database objects (tables, indexes, and so on) that store the RMAN backup information. The recovery catalog does not store RMAN backup pieces—only backup metadata.

The disadvantage of using a recovery catalog is that this is another database you have to set up, maintain, and back up. Additionally, when you start a backup and attempt to connect to the recovery catalog, if the recovery catalog is not available for any reason (server down, network issues, and so on), you can continue with the backup without a recovery catalog.

You must also be aware of versioning aspects when using a recovery catalog. You need to make sure the version of the database you use to store the recovery catalog is compatible with the version of the target database. When you upgrade a target database, be sure the recovery catalog is upgraded (if necessary).

11. Using a Media Manager

A media manager is required for RMAN to back up directly to tape. Several vendors provide this feature (for a cost). Media managers are used in large database environments, such as data warehouses, in which you may not have enough room to back up a database to disk. You may also have a disaster recovery requirement to back up directly to tape.

If you have such requirements, then you should purchase a media management package and implement it. If you do not need to back up directly to tape, there’s no need to implement a media manager. RMAN works fine backing up directly to disk. The backup files can be copied off to tape for offsite storage and because of retention policies. If copying to tape, you can have a job run the RMAN backup and then initiate the copy to tape. The backup files need to be complete and not in the middle of a backup; otherwise there is the risk of only getting partial files copied to tape.

12. Setting the CONTROL_FILE_RECORD_KEEP_TIME Initialization Parameter

The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum number of days a reusable record in the control file is retained before the record can be overwritten. The RMAN metadata are stored in the reusable section of the control file and therefore are eventually overwritten.

If you are using a recovery catalog, then you do not need to worry about this parameter because RMAN metadata are stored in the recovery catalog indefinitely. Therefore, when you use a recovery catalog, you can access any historical RMAN metadata.

You can set the value to anything from 0 to 365 days. Setting the value to 0 means that the RMAN metadata information can be overwritten at any time.

The CONTROL_FILE_RECORD_KEEP_TIME parameter was more critical in older versions of Oracle, in which it was not easy to repopulate the control file with RMAN information, in the event that metadata were overwritten. The C command can be used to quickly make the control file aware of RMAN backup files.

If you run daily backups, then I recommend that you leave this parameter at 7 days. However, if you only back up your database once a month, or if, for some reason, you have a retention policy greater than 7 days, and you are not using a recovery catalog, then you may want to consider increasing the value. The downside to increasing this parameter is that if you have a significant amount of RMAN backup activity, this can increase the size of your control file.

13. Configuring RMAN’s Backup Retention Policy

14. Configuring the Archivelogs’ Deletion Policy

As of Oracle Database 11g, you can specify an archivelog deletion policy that is separate from that of the database backups. This deletion policy applies to archivelogs both outside and in the FRA.

15. Setting the Degree of Parallelism

You can significantly increase the performance of RMAN backup and restore operations if your database server is equipped with the hardware to support multiple channels. If your server has multiple CPUs and multiple storage devices (disks or tape devices), then you can improve performance by enabling multiple backup channels.

If you require better performance from backup and restore operations and have hardware that facilitates parallel operations, you should enable parallelism and perform tests to determine the optimal degree. If your hardware can take advantage of parallel RMAN channels, there is little downside to enabling parallelism.

This code configures four channels that write to separate locations on disk. When you configure separate channels for different locations, make sure you enable the degree of parallelism to match the number of configured device channels. If you allocate more channels than the specified degree of parallelism, RMAN only writes to the number of channels specified by the degree of parallelism and ignores the other channels.

16. Using Backup Sets or Image Copies

A backup set is the default type of RMAN backup. A backup set contains backup pieces, which are binary files that only RMAN can write to or read from. Backup sets are desirable because they are generally smaller than the data files being backed up. RMAN automatically attempts to create backup pieces with unused block compression. In this mode, RMAN reads a bitmap to determine which blocks are allocated and only reads from those blocks in the data files. This feature is supported only for disk-based backup sets and Oracle Secure Backup tape backups.

When you create a backup as a backup set, the binary backup piece files can only be manipulated by RMAN processes. Some DBAs view this as a disadvantage because they must use RMAN to back up and restore these files (you have no direct access to or control over the backup pieces). But these perceptions are not warranted. Unless you hit a rare bug, RMAN is dependable and works reliably in all backup and restore situations.

Contrast the backup set with an image copy. An image copy creates a byte-for-byte identical copy of each data file. The advantage of creating an image copy is that (if necessary) you can manipulate the image copy without using RMAN (as with an OS copy utility). Additionally, in the event of a media failure, an image copy is a fast method of restoring data files, because RMAN only has to copy the file back from the backup location (there is no reconstructing of the data file, because it is an exact copy).

The size of the backup to disk is almost always a concern. Backup sets are more efficient regarding disk space consumption. Because backup sets can take advantage of RMAN compression, there is also less I/O involved, compared with an image copy. In many environments, reducing the I/O so as not to impact other applications is a concern.

However, if you feel that you need direct control over the backup files that RMAN creates, or you are in an environment in which the speed of the restore process is paramount, consider using image copies.

17. Using Incremental Backups

Incremental backup strategies are appropriate for large databases in which only a small portion of the database blocks change from one backup to the next. If you are in a data warehouse environment, you may want to consider an incremental backup strategy, because it can greatly reduce the size of your backups. For example, you may want to run a weekly level 0 backup and then run a daily level 1 incremental backup.

The only difference between the prior two commands is that an incremental level 0 backup can be used in conjunction with other incremental backups, whereas a full backup cannot participate in an incremental backup strategy. Therefore, I almost always prefer to use the INCREMENTAL LEVEL=0 syntax (as opposed to a full backup); it gives me the flexibility to use the level 0 incremental backup along with subsequent incremental level 1 backups.

18. Using Incrementally Updated Backups

Incrementally updated backups are an efficient way to implement an image copy backup strategy. This technique instructs RMAN to first create image copies of data files; then, the next time the backup runs, instead of creating a fresh set of image copies, RMAN makes an incremental backup (changes to blocks since the image copy was created) and applies that incremental backup to the image copies.

If you have the disk space available for full image copies of your database and you want the flexibility to use the image copies directly, in the event of a media failure, consider this backup strategy.

One potential disadvantage of this approach is that if you are required to restore and recover to some point in the past, you can only restore and recover to the point at which the image copies were last updated with the incremental backup.

19. Using Block Change Tracking

This feature keeps track of when a database block changes. The idea is that if you are using an incremental backup strategy, you can enhance performance, because by implementing this feature, RMAN does not have to scan each block (under the high-water mark) in the data files to determine whether it needs to be backed up. Rather, RMAN only has to access the block change tracking file to find which blocks have changed since the last backup and directly access those blocks. If you work in a large, data warehouse environment and are using an incremental backup strategy, consider enabling block change tracking to enhance performance.

20. Configuring Binary Compression

The default compression algorithm proves to be quite efficient. For a typical database, the backups are usually approximately four to five times smaller than the regular backups. Of course, your compression results may vary, depending on your data.

Why not compress all backups? Compressed backups consume more CPU resources and take longer to create and restore from, but they result in less I/O, spread out over a longer period. If you have multiple CPUs, and the speed of making a backup isn’t an issue, then you should consider compressing your backups.

In my experience the prior compression algorithms are very efficient, both in compression ratios and time taken to create backups.

21. Configuring Encryption

You may be required to encrypt backups. Some shops especially require this for backups that contain sensitive data and that are stored offsite. To use encryption when backing up, you must use the Oracle Enterprise Edition and possess a license for the Advanced Security option.

Encrypted tablespaces will remain encrypted in the backup sets. The configuration for backup encryption does not need to be on for this, but only the tablespaces that are encrypted will remain encrypted.

You can query V$RMAN_ENCRYPTION_ALGORITHMS to view details regarding the encryption algorithms available for your release of the database.

22. Configuring Miscellaneous Settings

You may need to configure any of these settings when you need to make RMAN aware of some OS or hardware limitation. You will rarely need to use these parameters but should know of them.

23. Configuring Informational Output

This is useful during troubleshooting, especially when RMAN fails, because we can use the exact date/time information for when the RMAN error occurred and compare it with the alert.log and OS/MML logs to verify what other events occurred in the database/server.

Also consider executing SET ECHO ON to ensure that RMAN commands are displayed within the log before the command is executed. Execute SHOW ALL as well to display the current settings of RMAN variables. These settings are useful when troubleshooting and tuning.