Author: Scott Schulze

Many organizations have been slow to take on RMAN although it has been around for a while. Change can be hard especially when 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.

Traditional backup techniques:

Traditional backup techniques require that the DBA record the particulars 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 record all of the relevant information, file restoration is more of an automated procedure. With Oracle9 i , a database file restoration can be as simple as one command:

RMAN: Database Files

RMAN will not only know where to look for the files associated with the backups, but will also decide 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 improve database risk management because simple commands can be used to report a variety of risk-related issues. For example, to report on data files that would need at least ten days of archived redo logs, you could issue the RMAN command:

All in all, RMAN's syntax allows for a diversity 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 facilitate you to merge backup operations to a central repository. Additionally, the catalog provides you with the capability to expand your reporting options.

RMAN: Backup Mechanism

RMAN has a flexible and powerful incremental backup mechanism that only backs up those database blocks that have changed since a preceding backup. This is important because the time and resources required to perform either a backup or a restore can be considerably reduced. Using this incremental feature makes sure that the resources required to perform a backup are relative 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 major advantage over the traditional backup methods.

RMAN: More Flexible Backup Mechanism

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 chance to choose between a differential or a cumulative backup.

Differential backups:

Differential backups require more time for restore but less time and space to perform.

Cumulative backups:

Cumulative backups, on the other hand, require less time for restore but more space and time to perform.

RMAN: Data file backup

Putting data files into and out of backup mode prior to and subsequent to an online backup and the extra redo log activity is no more required with RMAN. This is because it's an Oracle process and not an operating system process that is responsible for performing the data file backup; so the fractured block phenomenon is no longer an issue. This provides a more proficient online backup with less overhead and resource contention.

Database Corruption:

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:

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.

RMAN: Block-Level Recovery

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.

Final Thoughts:

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 bit easier. The ability to clone databases, the 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 that I will be discussing in my future articles.

 More Oracle Articles, Database Articles and DBA Tips
   Database Security: Step by step guideline
   Great Tips for Protecting Oracle Listener!!
   Releasing Oracle Unused Space: Quick & Efficient Solution!!
   Beware of over-creating Indexes!!
   Improve performance by Optimizing SQL!!