Oracle RMAN Myth Busting

Background: Database Administration Challenges
Managing Oracle database backup and recovery is a critical operational requirement for database administrators (DBAs). With increasing database sizes and Service Level Agreements (some requiring 24×7-database availability), DBAs need to effectively design and manage data protection solutions to minimize performance impact on production databases.

Below are key operational goals that DBAs need to focus on in Oracle environments:

• Minimize performance impact on the production database when executing backup/restore operations
• Configure backup tasks to achieve the highest efficiencies
• Configure database restore and recovery tasks to achieve optimal Recovery time
• Efficiently use all storage, server, and network resources while meeting quality of service requirements
• Minimize DBA/system administrator time requirements for managing backup and recovery processes.

Oracle RMAN is a good solution to effectively achieve these goals concurrently.

Myths about Oracle RMAN 

While Oracle RMAN is a solid solution to minimizing performance impact on production databases, a number of myths surround its use. Below are some of the top Oracle RMAN myths we’ve come across, and what is actually occurring.

Myth 1

Delete All Input: This applies when archive logs are duplexed. There is a significant difference between …DELETE INPUT; and …DELETE ALL INPUT.

Pro Tip: Including the ALL keyword means that after backing up any one copy of an archive log, all copies of it will be deleted. That does not provide redundancy in the backup. If the single backup of a critical archive log is missing or corrupt, there is no second chance. Without the ALL keyword, only the copy that was just backed up is deleted, the other copy remain for subsequent backups to handle.

Myth 2

Backup Optimization: This feature causes RMAN to skip files that have already been backed up. If that’s okay and you are willing to rely on one (hopefully good) copy of a data file or archive log, then go for it.

Pro Tip: Leave this feature off so that each backup includes all candidate files each time unless you’re willing to rely on a single backup copy.

Myth 3

Rely on RMAN Stored Configuration: RMAN can store a set of default parameters that will be applied to all subsequent operations. This is not good, because eventually someone will need to make a change and if the production backups were going to the wrong place, even worse mistakes can take place.

Pro Tip: Explicitly set all required parameters at the start of the backup script. Even better, use a run {} command and override the required parameters for the duration of the job.

Benefits of using Oracle RMAN

Now that we’ve clarified common myths associated with Oracle RMAN, below are the top five benefits of using Oracle RMAN:

1. Provides a comprehensive foundation for efficiently backing up and recovering the Oracle database.
2. Is designed to work intimately with the database server, providing block-level corruption detection during backup and restore.
3. Optimizes performance and space consumption during backup with file multiplexing and backup set compression, and integrates with Oracle Secure Backup, as well as third party media management products, for tape backup.
4. Provides a common interface (freeing dependency on OS and SQL*Plus scripts) via command line and Enterprise Manager for backup tasks across different operating systems.
5. Offers features such as block-level incremental backup, parallelization of backup/restore data streams, database-aware retention policies, and detailed history of all backups.

Related Posts

• Oracle RMAN Best Practices
• Proactive Maintenance of Your Oracle Database – Key Considerations
• Oracle Control File Recreation
• Boost Database Performance with a Comprehensive Health Check
• Top 3 Communication Skills for IT Support Providers