<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1802238426732960&amp;ev=PageView&amp;noscript=1">


The World’s Great Mysteries...Women, the Meaning of Life, and Oracle Database Backups!


I will leave the topic of women to Dr. Oz and the meaning of life to Douglas Adams.As for Oracle Database Backups, this topic could fill up the rest of the blogosphere, so I am going to arbitrarily limit the scope of this posting to Oracle RMAN backups with EMC Data Domain (DD). Even when limiting Oracle backups to DD, there are many backup methods and many factors involved in the decision process – available disk space, restore time requirements, backup window requirements, etc. This article addresses Full Backups, Incremental Backups, Incrementally Updated Disk Backups, and Archive Redo Log backups.

Full Backups

This has always been the DBAs favorite method to perform backups, not only because the backups are speedy, but because the restores are also very fast. The backups are fast because the database engine merely picks up data and delivers it to the backup application without looking for data that has changed, and the restores are quicker because the recovery of incremental backups is avoided – the entire database is restored and then the recovery of the redo logs is executed (assuming they are available). The downside is that performing full backups and retaining them for long periods of time results in an associated increase in storage costs, as the space required to retain the backups is directly proportional to the size of the database. That was true until deduplication backup appliances, like Data Domain, became available. These appliances made keeping backups on disk for a moderate retention period affordable and made replicating the backup offsite feasible.

With Data Domain, the original options were to perform the full backups to an NFS share, a CIFS share, or a Virtual Tape Library via a backup application such as Oracle Secure Backup, EMC NetWorker, Symantec NetBackup, etc. This past year EMC added a fourth option – the Boost protocol. Boost has been part of Data Domain for years, but in 2012 the Boost plug-in for Oracle RMAN was released for Windows, Linux, and Solaris, with AIX and HP-UX to follow “soon”. The introduction of this protocol brings an important benefit to the full backup; it reduces the amount of data sent over the network during a backup by implementing its own style of source-based deduplication (a.k.a. Distributed Segment Processing). Although a full backup still requires time to scan the entire database, a significant amount of time can be saved by the reduction of cycles spent on sending backup pieces over the network. If you like to keep things simple, and database scan times are not an issue in your environment, consider performing daily full database backups via DD Boost for RMAN.

Incremental Backups

The incremental backup is available to reduce the backup storage requirements normally required by full backups, but with a deduplication appliance such as Data Domain the space savings are not quite as pronounced. So why consider incremental backups as all? If the backups are being performed via NFS/CIFS (maybe you are running an older version of Oracle not supported by Boost), then incremental backups can still provide the benefit of reducing the bandwidth pain inflicted on your network by database backups. Whether you use Boost or not, you may still be left with the long scan times of your databases, especially the larger ones. The answer is Block Change Tracking (BCT), a feature available for incremental backups that tracks the data blocks have been modified in each data file since the last incremental backup. When the next incremental backup is performed, the step of scanning the database for changed blocks is bypassed altogether! With incremental backups you have the choice of implementing either differential backups (traditionally require less backup storage) or cumulative backups (faster restore times). Since Data Domain provides deduplicated storage and Data Domain Boost provides deduplication at the source, consider cumulative backups. The combination of Data Domain Boost and incremental backups with Block Change Tracking will give you the benefits of reduced database scan times and reduced network bandwidth required to send backup pieces to Data Domain. With these benefits in mind, consider multiple daily incremental backups to reduce the number of archive logs that must be applied during a recovery.

Another important feature of Data Domain Boost integration with RMAN is that when two backup copies are requested, the Data Domain Boost plug-in will have the local Data Domain appliance replicate the data (post dedupe) to the second remote DD appliance while keeping RMAN aware of the existence of both copies. Although backups to NFS/CIFS shares can be replicated by Data Domain, the replicas do not benefit from the RMAN “awareness” that the Data Domain Boost integration with RMAN provides.

Incrementally Updated Disk Backups

This option precludes the use of Data Domain Boost for RMAN because the Data Domain Boost plug-in is implemented as a media management library is presented to Oracle RMAN as a System Backup to Tape (SBT) instead of an NFS or CIFS share, but Data Domain can still be a valuable addition to this type of backup. The incrementally updated disk backups (also referred to as incremental merge in some papers) have the benefit of the short backup window of the incremental backup with BCT while simultaneously having the benefit of the short restore window of a full backup. The incrementally updated backup works by rolling forward the current full backup to the new current point in time. This has the downfall of preserving only the current full backup or maintaining N versions of full backups – as we discussed earlier, keeping multiple full backups can be an expensive proposition, but this increase in storage requirements is mitigated by Data Domain deduplication. In addition, the current full backup can be ‘copied’ out to an alternate path on the DD appliance. By ‘copied’, I am referring to the DD CLI command ‘fastcopy’, which in essence is copying the necessary metadata to indicate that said data is now in and - the latter could be 30 directories named by instance and date to contain one month of backups. This combination of Oracle incrementally updated backups with Data Domain’s ‘fastcopy’ provides for a very attractive solution, especially when cycles are not available for the simpler strategy of always performing full backups. Jeff Browning provides a great explanation and example Solaris shell script.

Archived Redo Log Backups

Retaining backups of the archived redo logs is critical if recovering to a point in time between database backups is a requirement, and is a critical step in your backup strategy unless your database is relatively static in nature. This section serves as a word of caution when attempting to back up the logs to Data Domain:

  • Do not expect normal deduplication rates for the archived redo logs, as the logs generally contain mostly new data having little in common with data backed up previously.
  • Mind your stream count – Data Domain appliances are often sized for capacity and performance requirements, but stream count requirements are often forgotten. Data Domain stream count limitations range from 16 streams for a DD160 to 90 streams for a DD860 to 540 streams for a DD990. If you are running a rather large Oracle shop, like some of my customers that have 100 instances running, it can be easy to step out of bounds. If you exceed the stream count limitations of a DD appliance, any further backup connections requested will be refused.
  • If you have a large number of Oracle instances that require frequent archive log backups, evaluate the backup schedule and estimate how many instances maybe backing up logs simultaneously and how many channels each will be using. Each channel will count as a stream to the Data Domain. Compare this to the rated write stream count for your Data Domain appliance - you may find that you need to make adjustments to your schedule or invest in additional Data Domain units.


Several options have been presented in this post: Full vs. Incremental, and NFS/CIFS vs. DD Boost. Table 1 indicates differences between the protocols NFS/CIFS and DD Boost, and Table 2 outlines some of the benefits or requirements of the different backup methods.

Table 2:  Backup Method Comparison

Table 2: Backup Method Comparison

Remember that the restore window refers to the process of copying backups to production, while recovery refers to the process of applying the redo logs to roll the database forward to a desired point-in-time which lands in between backups. Since the backup times for both Incremental backups and Incrementally Updated to Disk backups can be dramatically reduced with BCT, these two methods can be scheduled to perform multiple backups a day to reduce your recovery times later.

Hopefully this article has helped to clarify what some of your Oracle backup options are when it comes to backing up to EMC Data Domain. If you are currently struggling with your database backups or simply want to further investigate your options, reach out to RoundTower - we are here to assist with your backup issues, including Oracle.

I apologize for leaving you up in the air regarding women and the meaning of life. Now that you have your Oracle backup matters straightened out you’ll have time to blog about those topics yourself. Please send me a URL when you do!

  1. EMC Corporation. (2011). Oracle RMAN Best Practices with Data Domain [White paper]
  2. Oracle Corporation. Oracle Database Backup-and-Recovery Best Practices and New Features [White paper]
  3. Oracle Corporation. Oracle Database Backup and Recovery Basics 10g Release 2 (10.2). [Chap 4.4.]
Share this Post:
« Cloud Security & Compliance Not Just for the Highly Regulated
The Year of the Desktop »

We've moved! Check out our new HQ office at the Kenwood Tower

It's official, we are up and running in our brand new office space! Schedule a tour of our beautiful new facility located on the third floor of the Kenwood Tower at 5905 E Galbraith Rd, Cincinnati.