Section 16.4. Physical Backups with rman

16.4. Physical Backups with rman

rman offers a number of advantages over user-managed backups. The following is a quick list of them:

Full support from Oracle

While user-managed backups are supported by Oracle, you'll find that Oracle's interest goes up even more if you're recovering your database using its favorite tool.

Automatic creation of multiple simultaneous backup streams

If you've got a big database, this will come in very handy. All you have to do is specify how many simultaneous backups you need, and rman will generate them.

Incremental backups for all versions since 8i

rman performs a true incremental backup, sending only those blocks that have changed since the last backup.

Low-impact incremental backups for all versions since 10g

With 10g, incremental backups got much better. Prior to 10g, it took a lot of I/O to determine which blocks needed to be on the incremental backup. This saved a lot of space and bandwidth, but definitely didn't save I/O. 10g stores a record of changed blocks in a simple bitmap that's consulted by rman during incremental backups, making them much faster and creating much less work for the server.

Use of the flash recovery and flashback features

Flash recovery and flashback are integrated into rman, and you get to use these wonderful features if you use rman.

Backup optimization

Since rman is keeping track of all backups, you have the option of using backup optimization, which doesn't back up parts of the database it knows it already has a backup of, such as read-only tablespaces.

Restore optimization

Instead of having to figure out which datafiles need to be restored and selecting them from your backup software, you can simply tell rman to restore database. It then automatically determines which datafiles are in need of a restore and restores them.

During media recovery, rman comes in quite handy as well. Instead of having to figure out where your archived redo logs are, and restoring all of them to disk for the restore to work, rman completely automates retrieval of redo logs for media recovery. It can also be told to keep a certain amount on disk, automatically deleting the oldest versions from disk to bring in newer versions from tape.

If you use rman with a commercial backup utility, such as those covered in Chapter 8, it can actually deliver a completely integrated backup solution for all Oracle databases.

Since this book is focused on free and open-source backup methods, this chapter does not cover how to integrate rman with a commercial backup utility.

In addition to these rman features, a fully commercial solution would add these features:

Full support from your commercial backup product vendor

Don't expect your backup vendor to know anything about user-managed backups.

Direct backup to tape or virtual tape or other disk on your backup server (instead of being forced to back up to a filesystem accessible to the Oracle server)

If you're using rman without a media manager, you'll need to back up to a filesystem accessible on the database server. This can present a number of challenges to some environments. A media manager gives you the most flexibility when choosing backup targets.

Usage of full capabilities of backup product vendor

Commercial backup products have come a long way in the past few years and include a number of features that we discussed in Chapter 8. You get access to all these features for your rman backups as well.

A complete inventory of your backups, allowing a "point-and-click" restore

You can continue to restore things from the rman interface, or you can use your backup software's ability to perform the restore via its interface.

If you're interested in these features but have been intimidated by the pricing of enterprise-level backup software products, you may consider Oracle's Secure Backup product. It's got a very simple pricing structure. Oracle doesn't charge per client, per server, or per gigabyte; it charges only a certain amount per backup device.

Once a third-party backup software product, your rman script, or Oracle's Secure Backup initiates an rman backup, rman then does all the internal communication that it needs to do to supply the backup utility with n threads of data. rman records the time of the backup for future reference and passes it to the backup product if there is one. After things have been set up, it is also possible for a DBA to run the rman command from the command line. This command then calls the appropriate programs to connect with the backup utility or back up directly to disk. If sent to a backup utility, it responds to this as to any other backup request, loading volumes as necessary, and accepting the backup from rman.

rman is supported in Oracle 8i and following. You can specify to restore a tablespace, database, datafile, or even a block within a datafile. It knows what files comprise a tablespace or database, and then automatically selects and restores the most recent backup of those files. This really takes the guesswork out of the DBA's hands. The program knows what needs to be restored, it knows where the backups are, and it automatically goes through the process of restoring the appropriate items and can automatically apply media recovery against them as well. This is far better than having to do all this work yourself.

rman is too complex to be covered in detail in a chapter of this size; consult Oracle's documentation for an explanation of how rman works. What we can look at is a list of major features that have been added to rman since it was introduced in 8i, resulting in a much more powerful and usable backup command. I'll then provide some general guidance on the use of rman.

16.4.1. Important New rman Features

The following section lists important features of rman that have been introduced since it was originally released. Next to each feature is listed the version of Oracle that introduced it.

Crosscheck and delete functionality (8i)

Prior to these commands, the rman catalog could get out of sync with the media manager catalog. These commands automatically synchronize the two, including deleting rman catalog entries for backups that have been expired by the media manager.

create, upgrade, and drop catalog commands (8i)

These commands automate a number of important catalog operations, replacing a number of scripts and other commands in the process.

Automatic backup name generation (8i)

You no longer have to specify the format parameter with a backup. rman automatically creates a unique name for each piece.

Control file autobackups (9i)

If configure controlfile autobackup is set to on, rman automatically backs up the control file and server parameter file any time there is a structural change to the database or any time you issue a backup command.

Backup of server parameter files (9i)

Server parameter files are automatically backed up any time you issue the backup command, allowing you to issue the restore spfile command (if you enable the controlfile autobackup feature).

Backup of archived logs that need backups; deletion of those that don't (9i)

Previous methods of specifying which archived logs to back up were a bit clunky and required you to figure out which ones to back up. Now you can specify not backed up n times. Files that have not been backed up the specified number of times are backed up. You can also specify that files that have been backed up the appropriate number of times should be deleted.

Persistent rman configurations (9i)

Previous to this, you had to specify a number of arguments to rman every time you ran a backup. Now you can create persistent values for things like automatic channels, channel parallelism, retention policies, and backup options.

Block media recovery (9i)

Block media recovery can perform media recovery on individual blocks in an individual datafile while the datafile remains online.

Flash recovery area (10g)

You can tell rman to use a single location on disk for the location of all backup and recovery files. This area is called the flash recovery area.

Optimization of incremental backups (10g)

Previous versions of rman required a number of reads of an Oracle database to determine which blocks should be included in an incremental backup, resulting in an I/O load that was actually higher than a full backup. As of 10g, Oracle keeps track of which blocks have changed in each datafile. (The DBA must enable this feature.) Now rman can simply ask for changed blocks, significantly reducing the I/O load of an incremental.

Incrementally updating backups (10g)

rman can apply the changes found in an incremental backup to a previous backup of a datafile, resulting in a new full backup of that file, without having to actually back up the entire file.

Backup set compression (10g)

Oracle can compress backups to better use disk space, reducing the space or bandwidth required by 50 to 75 percent. This is not the default option, but you can make it your default option using a persistent rman parameter.

Recovery through resetlogs (10g)

Prior to this feature, you were forced to take a backup after opening the database with the resetlogs option because you couldn't use backups prior to that time. This is no longer the case.

Global stored scripts (10g)

rman scripts can be stored in the rman catalog that can be accessed by any target database.

16.4.2. Automating rman

The following section contains some tips on automating rman backups, especially those in large environments.

This section is absolutely not a replacement for the rman documentation. We cannot cover in a few pages what they cover in an entire book.

Like all other Oracle commands, rman assumes you know the name of the instance that you're backing up. Therefore, you must first obtain a list of Oracle instances.

16.4.2.1. Create a recovery catalog

Yes, you can use rman without a recovery catalog. In fact, looking at the release notes shows that Oracle continues to enhance what you can do without a catalog. If you don't use a catalog, rman data is stored in the control file. Storing your recovery information inside the thing you want to recover is never a good idea. It would be much better to have a centralized recovery catalog that contains all the recovery information for all instances. It's also a good idea if this catalog is on a different server than any of the databases it is tracking.

It's also much easier to create the catalog now by just using the create catalog command in rman. Large environments might want to use more than one rman catalog and back up each of those catalogs using an rman instance that's connected to the other catalog. You might also consider performing a hot or cold backup of the rman catalog by some method that doesn't use rman.

Always keep a record of your DBID. This may come in very handy if you lose your control file, especially if you have multiple databases with the same name.

16.4.2.2. Create persistent parameters

Each persistent parameter that you create is one less parameter that you have to specify on the command line. The ultimate goal here is that you would simply be able to tell rman to backup database, and everything else would come from these parameters. The parameters that can be set persistently can be viewed by using the show all command in an rman session. It will list all of the parameters and show you which of them you have customized, and which of them are still set to the default values. Here is the example shown in Oracle's documentation:

RMAN> show all; RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/product/10.2.0/db_1/dbs/snapcf_orcl.f'; # default

Using persistent parameters greatly simplifies your rman scripts. To create or modify these parameters, simply connect to rman and issue commands like those shown here:

RMAN> configure backup optimization on; RMAN> configure device type disk backup type to compressed backupset; RMAN> configure controlfile autobackup on;

16.4.2.3. Create rman scripts

You can create rman scripts to back up an entire database, a tablespace, a datafile, a control file, or an archive log. These scripts can be stored in the filesystem, or they can be stored in the rman catalog, allowing all instances using that catalog to use the scripts. Once stored there, they can be executed by connecting to the catalog and issuing the rman command run script_name.

For space reasons, we'll cover only two very basic rman scripts that perform a full (level 0) and incremental (level 1) backup of the entire instance as well as switching logfiles and backing up any archived redo logs that were created during the backup. A full or level 0 backup backs up every byte of the database, whereas an incremental or level 1 backup backs up only those bytes that have changed since the last backup. This script assumes that you have controlfile_autobackup set to on.

Here is the rman command file used to perform a full backup. It creates a full (level 0) backup of the database to the default device. The plus archivelog option causes it to switch logfiles (using archivelog current) before the backup, back up any archived logs not backed up (if backup optimization is set to on), then back up the database, followed by another logfile switch and a backup of any redo logs that were created during the backup:

connect target userid/passwd@oracle_sid; connect catalog userid/passwd@rman_sid; backup incremental level 0 plus archivelog;

Oracle's documentation tells you to enter the rman password on the command line. This makes it available to anyone who can enter ps -ef. (The following scripts do not do this, but you can see that it was done by manually entering the passwords into the script.) If you follow this method, make sure you make the scripts readable only by Oracle.

Substitute the appropriate values for userid, password, and the SIDs for the target and catalog databases. (The target database is the one to be backed up.)

16.4.2.4. The database.inc.rman command file (level 1 backups)

This is an incremental companion to the full script shown previously. It performs an incremental backup of those bytes that have changed in the database since the level 0 backup was taken:

connect target userid /passwd@oracle_sid; connect catalog userid /passwd@rman_sid; backup incremental level 1 plus archivelog;

Long-time users of rman should note the missing allocate channel commands and the lack of an alter system archive log current command, and backup of the archive logs at the end. The former is handled with the persistent parameters, and the latter is handled by the plus archivelog argument.