Taking a physical backup of an Oracle database is no simple task. For years, DBAs depended on complex shell scripts that would extract lists of all the files that needed backup, build SQL and Unix commands to put tablespaces into backup mode and copy files, and monitor the process for exceptions. Backups for large databases could run for hours because the process simply made a copy of each database file, and there was no provision for incremental backups. Perhaps the deepest, darkest fear of any DBA was to perform a database recovery and realize that the entire plan was invalid due to the lack of one small, yet crucial, file.
Enter Recovery Manager, or RMAN, introduced with Oracle 8. RMAN is a feature-rich tool that allows an Oracle database to be backed up through a series of simple commands. It also interfaces easily with tape backup devices, and has provisions for four levels of incremental backup, among other things.
Although a full treatment of RMAN is enough to fill a book and thus well beyond the scope of this article, I will describe the basic steps required to use RMAN to take a full or incremental backup of a database, which will work with any version of Oracle -- from Oracle 8 through Oracle10g. I've successfully used these techniques to perform backups of Oracle databases on a variety of platforms, including HP-UX, Solaris, and Red Hat Linux.
RMAN vs. Scripted Backups
RMAN offers several advantages over scripted backups, the most significant of which is that its syntax is simpler and easier to learn and use. And because RMAN is supported by Oracle, any problems you encounter with RMAN backups or commands can be taken directly to Oracle for support. Simply put, RMAN is a less complex, proven, and more reliable method of achieving the same goal. Other advantages include:
• Reduced overhead. With scripted backups of online tablespaces, you must first place the tablespace into backup mode. Doing so causes any activity on that tablespace to be recorded as redo activity. For busy or large databases, this could become quite significant. With RMAN, that necessity is eliminated and the overhead is reduced.
• Smaller backup footprint. RMAN backups are often smaller than scripted file copies, because RMAN only backs up changed data blocks below the high water mark of a datafile.
• Support for incremental backups. There is no way with a simple file copy strategy to backup only the data that has changed since the last backup. With RMAN, five levels of incremental backups are available, potentially saving hours of backup time each week.
• Automated recovery. RMAN knows which files it needs to recover a database and restores only what it needs. Contrast this to a manual recovery, where queries against the database dictionary must be performed to identify which files are needed, followed by manual restores of those files. RMAN will simply recover your database in less time, with less intervention, and do it more safely than you could with a scripted backup of the database.
• All files are included automatically in a full backup. With scripted backups, the database files that need to be backed up must be manually coded in your backup scripts, or queries against database tables must be performed to identify which files need to be backed up. Any change to the database represents a change in your backup scripts that must somehow be managed. With RMAN, that file management is internalized and automatic.
• Verification of your backup's veracity. With RMAN, you can simulate a recovery without actually restoring your files and be confident that, should disaster strike, your database will be recoverable.
• Automated management of your backup files. By setting a retention policy, RMAN can purge obsolete backups from your system and even be used to manage archived log files. Using a retention policy, RMAN will never remove a backup set that is required to recover your database fully. So even if a backup fails and the last valid files are beyond the retention period, RMAN will leave them intact. RMAN can also be used to manage your archive log files.
Logging into RMAN
RMAN is invoked through the rman executable under ORACLE_HOME/bin and is part of the standard installation of Oracle. You must provide RMAN with some basic information before you can get started. RMAN needs the login information to the target database (which is the database we'll perform backups against) and information about the recovery catalog that will be used.
A recovery catalog is an Oracle database that stores information about RMAN backups. In the absence of a recovery catalog, recovery information is stored in the database control file. Most Oracle installations do not use a separate recovery catalog, and the included scripts reflect this. However, it is a simple matter of changing the connection strings to utilize a recovery catalog if you wish to do so.
If ORACLE_HOME is in your PATH, invoke RMAN as:
rman target user/password nocatalog (without a catalog)
Or:
rman target user/password catalog rmanuser/rman_password@catalog (with a catalog)
Those familiar with SQL*Plus will recognize the connect strings that identify the username, password, and database alias. Note that the login to the target database must be as a user with SYSDBA privileges.
RMAN also supports the use of OS-authenticated logins. OS-authenticated users provide an extra layer of security and convenience for batch operations. Consider the following login string, which can be executed at either the command prompt or within a shell script:
rman target system/manager nocatalog
Now, from another session, execute:
bash-2.03$ ps -ef | grep rman | grep -v grep
oracle 14547 13399 0 12:01:57 pts/1 0:01 rman target system/manager nocatalog
There's the username and password for the world to see! If this is being run via a script, somewhere on the system will be a file with a hard-coded password. With an OS-authenticated account, a login to RMAN is simply:
rman target / nocatalog
No password information shows up under ps -ef, and access is controlled by OS authentication, where it is much easier to enforce strong passwords.
Backing Up a Database
Now that we've successfully logged into RMAN, let's take a look at a typical RMAN login and backup command:
bash-2.03$ rman target / nocatalog
Recovery Manager: Release 10.1.0.2.0 รป Production
Copyright © 1995, 2004, Oracle. All rights reserved.
Connected to target database: ORA10G (DBID=3190394834)
Using target database instead of recovery catalog
RMAN> run {
2> allocate channel d1 type disk maxpiecesize=2000M;
3> backup database plus archivelog;
4> }
The first thing we see is the run block. In versions prior to Oracle9i, it is necessary to enclose most RMAN commands within a run { } block. (Beginning in Oracle9i, the run { } block is still supported syntax but is not necessary.) There is no performance loss incurred by using the run block, so I prefer this syntax because it is compatible across all installations.
The first step within the run block is to allocate a channel for RMAN to use for the backup command itself. Allocating a channel allows us to limit the size of any file created (in the example it is limited to 2,000MB) and define the location to which the files will be backed up. It also determines whether the output of the following commands will be directed to disk or to a tape drive. Allocating a second or third channel will cause RMAN to parallelize the operation whenever possible (provided you're using the Enterprise Edition of the database).
Each channel allocated will also result in one or more backup sets being created. A backup set is a file that contains backup information for one or more Oracle datafiles or archive log files. The elegance of RMAN is that a backup set is often smaller than the sum of its parts. For example, consider a datafile that is 500MB, but only contains 250MB of data. A straight file copy results in a 500MB file. But in RMAN, that file will be significantly smaller because the empty space is not written -- only the data.
The backup command can be used to backup an entire database, a control file, archive log files, or one or more individual datafiles or tablespaces. Where once pages of scripts took tablespaces in and out of backup mode and copied files, a backup of your entire database using RMAN is now potentially as simple as:
backup database plus archivelog;
Of course, although it could be that simple, it usually isn't. Often we'll want to extend more control over the backup process. This is a more typical set of commands to back up a database:
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup full
filesperset 5
tag full_backup
format
'rman_%d_%t_%U.bus' database include current controlfile;
sql 'alter system archive log current';
backup filesperset 50
archivelog all
format
'rman_%d_%t_%U.bar';
release channel c1;
release channel c2;
}
Although slightly more complicated than the previous example, this set of commands is still fairly straightforward. The differences between this and the previous simple run block are the addition of the filesperset, tag, and format options, the inclusion of the control file in the backup set, the addition of a SQL command, and a separate command to back up the archive log files.
None of these are Earth-shattering changes. filesperset limits the number of datafiles included in each backup set. The tag is a way of naming a backup so that queries against the recovery catalog will make a little more sense to the operator. The format command defines how the files generated by the backup will be named. In this case, there are three wildcard options used in the filename. %d and %t insert the database SID and current time, respectively, and %U adds a unique identifier. RMAN offers several other wildcards besides these as well.
The include current controlfile clause does just that -- it includes the current control file in the database backup set. The control file contains information about the current state of Oracle's database files and is required to restore the database. I suggest that you include it in any backup that you perform, since changes to the physical and logical structure of the database are included in the control file. You will be unable to restore your database if you're using an older or obsolete version of the control file that does not reflect such changes.
As shown in the example, we can include regular SQL commands within RMAN, too. The SQL command included here causes the current redo log file to be written to disk, so the backup of all the archive log files will enable a full and consistent recovery of the database. Once the redo logs are flushed to the archive logs, we take a backup of all the archive log files.
Note that RMAN is a very verbose tool. Most successful commands will generate a large volume of informational messages, which is often disquieting to users new to RMAN. If you're used to SQL*Plus or the Oracle alert log, which return ORA-nnnnn errors to indicate a problem with the database or failure of a command, RMAN will definitely surprise you. Don't be alarmed. You can identify a failure in an RMAN command by looking for the RMAN-00569 condition, which is a general indication that an error stack will follow. When running RMAN from within a shell script, you simply test the exit status for a non-zero value. Listing 1 provides an example of testing the exit status of RMAN from within a shell script.
Incremental Backups
Note that the database backup command in the previous run block specifies "full". It is also possible to perform incremental backups of an Oracle database using RMAN. RMAN offers five incremental levels of backup. Level 0 is the equivalent of a full backup. Levels 1 through 4 provide fine-grained control over the amount of data that is backed up. For example, a level 1 backup only records changes made to the database since the last full backup. A level 2 backup only backs up data changed since the last level 1 backup, and so on.
Incremental backups allow you to perform full backups less frequently, while still being protected against data loss and minimizing both the time required to back up the database and the space on disk or tape to store the backup.
File Copies
If you are used to or prefer file copies, RMAN can accommodate you as well. Without RMAN, to get a consistent copy of a datafile, you would have to place the tablespace into backup mode, copy the file using OS commands, then take the tablespace out of backup mode.
With RMAN, the whole process is handled automatically and simply through the copy command:
RMAN> copy datafile '/u02/oradata/ora10g/system01.dbf'
2> to '/u12/backups/ora10g/system01.dbf';
The copy command can only be used to copy files to disk, and it copies the file bit-for-bit, so the advantages of potentially smaller backup sizes from the backup command are lost. However, if you prefer file copy operations, the copy command is far superior to the alternative hot backup method.
Putting It to Work
Listing 1, rman_backup, includes a basic RMAN run block as part of a shell script that can be used to perform a full or incremental hot backup of your database. It accepts three command-line parameters. The first is the database SID and is required. The second is the destination for the backups. This can be a full path to a disk directory or simply the value TAPE if you are writing the backups to a tape drive. Third is the incremental backup level. The default is to perform a full (level 0) backup if no value is provided. It can be called from a cron job using syntax similar to the following:
00 1 * * 0 /home/oracle/dba/rman_backup ora10g TAPE 0 > \
/home/oracle/logs/rman_backup.log
Included near the top of the script is an email address to which administrative alerts are to be sent. If either of the RMAN commands in the script fails, the DBA (or other responsible party) is notified via email or pager alert.
The script verifies that the database SID being called is legitimate, then lists information about the environment, including database connections, disk space (for disk backups), and memory before beginning the backup itself. The backup command utilized is very similar to the one shown above. Once the backup is complete, the same diagnostic information is listed for comparison purposes and can be used to identify problems with the RMAN process.
Listing and Validation
Once the backup is complete, the script invokes RMAN a second time to list and validate backups on the system. The listing of the backups is informational only, but the following command:
restore database validate
causes RMAN to emulate a restore of the database to make sure that the backup is complete and valid. This is useful as a sanity check of the process and verifies that the backup sets that have been created could actually be used to recover your database if needed.
This script calls the file in Listing 2, oracle_env. oracle_env, which sets up the environment for Oracle to use when the parent script is called through a cron job.
Space Management
One feature that makes Oracle such a robust database is its ability to recover right up until a failure. Oracle uses archive log files to store every change made to a database. These are written to a location on disk known as the archive log destination. Left unattended, they will eventually consume all the space on the drive. If this happens, Oracle will, by design, stop working until space has been freed up on the system.
Oracle DBAs used to either manually purge these files or write a shell script to automatically delete files older than a few days, but there was no check to make sure that the files deleted were genuinely obsolete. RMAN, however, offers a few options to more efficiently manage archive log files.
Beginning in Oracle9i, the DBA can set a retention policy for backup sets as a whole. This includes database backups and archive log backups:
RMAN> configure retention policy to recovery window of 3 days;
When a backup becomes older than three days, RMAN will mark it as obsolete. Deleting these old backups is as simple as allocating a maintenance channel (similar to allocating a disk or tape channel) and telling RMAN to delete them. The beauty of this method is that RMAN knows whether a backup older than three days is still needed for a full recovery. If so, it won't be marked as obsolete (and won't be deleted):
RMAN> run {
2> allocate channel for maintenance device type disk;
3> delete obsolete;
4> }
This method is convenient if you're storing backups and archive log files on disk.
The second method works well when your backup policy writes files to tape and is available for all versions of RMAN. It simply requires the addition of the option delete input to the archive log backup command. For example:
backup filesperset 50
archivelog all
format
'rman_%d_%t_%U.bar' delete input;
Once the archive log file is backed up, Oracle deletes the files automatically. This command can be added to the rman_backup script, which can be run at a regular interval not only to back up the database and archive log files but to keep the archive log destination clean.
Another solution is included in Listing 3, which mimics the functionality of setting a retention policy for pre-Oracle9i installations. It requires two parameters -- the database SID, and a retention period (in days) inside which files are to be kept. This script calls SQL*Plus to identify files that are outside the retention period and that are not needed to fully back up the database in the event of failure. It then removes these files using the OS rm command.
Once the files are removed from the system, they need to be removed from the recovery catalog. This is accomplished by allocating a maintenance channel then performing the two crosscheck commands. Crosscheck verifies that the files in the recovery catalog are actually available in their expected location. When a backup piece is missing, RMAN marks it as "EXPIRED".
The RMAN delete command can then be used to remove recovery catalog references to expired files. In the script, this is accomplished with three commands:
delete noprompt expired backup of database;
delete noprompt expired backup of controlfile;
delete noprompt expired backup of archivelog all;
Summary
Oracle's RMAN is a robust and feature-rich application that simplifies backing up Oracle databases and managing the files created by the backups. It should be the tool of choice for those responsible for managing backup and recovery of Oracle databases. RMAN's ability to interface with popular media management tools, such as those offered by Veritas and HP, makes it as easy to back up to tape as to disk.
The multiple levels of incremental backups make RMAN an excellent tool for managing backups of large databases, as well as high-transaction environments where a minimal performance impact from backups is required. The simplicity of commands makes it accessible to every DBA, regardless of their level of experience, and puts a successful backup policy within their grasp.
No comments:
Post a Comment