The Advantages of Oracle RMANby Scott Schulze, coauthor of Oracle RMAN Pocket Reference
Although RMAN has been around for awhile, many organizations have been slow to adopt it. Change can be difficult, especially when tried-and-true database backup mechanisms have already been implemented. And no self-respecting database administrator wants to be blind-sided when it comes to backup and recovery situations. But RMAN (recovery manager) offers numerous advantages over traditional backup techniques and it should be seriously considered when designing and implementing backup strategies. This article briefly describes the advantages behind several of RMAN's features.
A Central Repository
Traditional backup techniques require that the DBA record the specifics of each backup operation. What tablespace or database file was backed up? When did the backup take place? What is the location of the backup? RMAN, on the other hand, logs each and every backup operation to the control files of the database that is being backed up. Since the control files log all of the pertinent information, file restoration is more of an automated procedure. With Oracle9i, a database file restoration can be as simple as one command:
RMAN> restore database;
RMAN will not only know where to look for the files associated with the backups, but will also determine which database files are necessary for a successful recovery.
Also, the backup information contained within the control files can be easily queried and reported against using RMAN's listing and reporting features. These features greatly enhance database risk management because simple commands can be used to report a variety of risk-related issues. For example, to report on datafiles that would require at least ten days of archived redo logs, you could issue the RMAN command:
RMAN> report need backup days=10;
All in all, RMAN's syntax allows for a variety of reporting and listing scenarios.
And if your organization has multiple databases, you may want to consider using the optional RMAN recovery catalog. The catalog will enable you to consolidate backup operations to a central repository. Additionally, the catalog provides you with the ability to expand your reporting options.
RMAN has a powerful and flexible incremental backup mechanism that only backs up those database blocks that have changed since a prior backup. Why is this important? Because the time and resources required to perform either a backup or a restore can be significantly diminished. Using this incremental feature ensures that the resources required to perform a backup are proportional to the transactional activity that has taken place within the database, and not to the size of the database. Sure, each block is read, but only modified blocks are written. For large databases, this provides a significant advantage over the traditional backup methods.
Additionally, there are two different types of incremental backups that introduce a greater level of flexibility when designing a backup and recovery architecture. Depending on your service-level agreement or mean time to recovery, you have the opportunity to choose between a differential or a cumulative backup. Differential backups require less time and space to perform, but require more time for restore. Cumulative backups, on the other hand, require more space and time to perform, but require less time for restore.
Remember the requirement to put datafiles into and out of backup mode prior to and subsequent to an online backup? And all that extra redo log activity? Aaarrrgggh! Well, no more with RMAN. This is because it's an Oracle process (and not an operating system process) that is responsible for performing the datafile backup; so the fractured block phenomenon is no longer an issue. This means a more efficient online backup with less overhead and resource contention.
Database corruption can elevate the blood pressure of many database administrators, and heaven knows it needs to be detected early before it finds its way into a series of backup files. We not only need to trust our backup process, but we also need to know that, if required for recovery, our backup is free from corruption. Prior to RMAN, a common technique would be to execute a full export while redirecting the resulting dump file to an operating system bit bucket. For Unix platforms this would look like:
$> exp userid=sys/change_on_install file=/dev/null full=y log=full_exp.log
While the full export would touch every database block, the operation, in and of itself, is expensive. Another technique would be to use the DBVERIFY utility, but it has a list of limitations, and on some platforms it cannot be used against an open database.
With RMAN, however, remember that each block is read during the backup process. This enables RMAN to detect corruption while the backup is being performed. And if found, corruption information is written to several V$ tables. But what if corruption is limited to just a few blocks? Sure, you could follow the usual recovery avenues, but RMAN has been enhanced in Oracle9i to perform block-level recovery. This could be a major time savings when performing a restore.
What I've listed here is just the top of the RMAN pyramid; there are plenty of other features that could make your already busy life just a tad easier. The ability to clone databases, features to enable point-in-time recovery for tablespaces, the ability to make database file image copies: The list just goes on and on and on ....
O'Reilly & Associates recently released (November 2001) Oracle RMAN Pocket Reference.
For more information, or to order the book, click here.
Scott Schulze has worked with Oracle technologies since 1990, both as a developer and as a database administrator.
Return to the O'Reilly Network.