Configuring DD Boost

posted June 26, 2014, 8:20 PM by

Jeff Stonacek, Principal Architect

What is DD Boost?

DD Boost is a Data Domain product specifically designed for database backup integration. In the case of Oracle, DD Boost has a plugin that integrates directly into RMAN. The DD Boost plugin integrates with RMAN as a tape library sub-system. Instead of performing database backups directly to Data Domain (as a directory path), the RMAN backup is taken to a tape channel. RMAN streams the backup through the DD Boost plugin to the backend Data Domain.

How DD Boost Speeds Up Your Backup

Where the “boost” comes into play is by offloading the de-duplication and compression work to the Oracle database server. In a traditional Data Domain backup, Oracle is unaware that any de-duplication is going on. Oracle merely streams the backup to the Data Domain backend device. This is true for hot backups as well as with RMAN. With DD Boost, before sending a block of data to the Data Domain backend, the plugin first checks with the Data Domain server to see if the block is unique. If it is unique, then the plugin compresses the block on the database server before sending it on to the Data Domain backend. That way only a fraction of the blocks are ever sent over the wire, and those that are sent are compressed. This reduces network resource utilization by a large amount. Figure 12 below is a pictographic representation of the difference between traditional Data Domain and DD Boost.

Figure 12: DD Boost

Configuring DD Boost

Below is a summary of the configuration.
The backend Data Domain server configuration is pretty straightforward, requiring only a few commands to enable the feature.

# user add rmantest password <password>


The username rmantest is used as an example.

# ddboost set user-name rmantest

# ddboost storage-unit create rmantest

# ddboost enable

# ddboost access add clients <hostname>


That is it as far as the backend Data Domain configuration goes.
The next step is to install and configure the DD Boost plugin for RMAN on the Oracle server. Merely copy the plugin tar file to the database server and untar it.

cd <plugin directory>

export ORACLE_HOME=<oracle home>



Once the plugin is installed, there are configurations required from an RMAN perspective to get DD Boost to work properly. Here are the details.
First, configure the RMAN tape channel:

rman target /


TRACE <trace-level> PARMS 'BLKSIZE=1048576,





Set the appropriate environment variables and run a backup. These steps are covered in the Data Domain Boost Administration


$ export

$ export STORAGE_UNIT=rmantest

$ rman target /

Recovery Manager: Release - Production on Thu Feb 13 18:51:33 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: DOMSD013 (DBID=2874824943)

RMAN> run

2> {

3> allocate channel c1 type sbt_tape;

4> backup archivelog all;

5> release channel c1;

6> }


using target database control file instead of recovery catalog

allocated channel: c1

channel c1: SID=10 device type=SBT_TAPE

channel c1: Data Domain Boost API


Starting backup at 13-FEB-14

current log archived

channel c1: starting archived log backup set

channel c1: specifying archived log(s) in backup set

input archived log thread=1 sequence=95 RECID=94 STAMP=839433891

input archived log thread=1 sequence=96 RECID=95 STAMP=839434029


After reading this post, you should have a better understanding of how DD boost integrates directly into RMAN and can help you reduce network bandwidth for Oracle backups.

Share with your networkTweet about this on TwitterShare on LinkedInShare on FacebookDigg thisEmail this to someone


  • John T says:

    Watch out that you keep the DD Boost clients up-to-date. Bad things happen if you don’t. Without warning.

    Also, you need to consider using on-disc primary backup with archiving to DD Boost. A restore from DD Boost can take more than ten times the time your backup takes and is much slower than restoring from a DD Boost CIFS mount or similar.

  • I have read through this several times, and I am still trying to decide if there is an anything to gain with this. You decrease the network load to some extent, but at the expense of CPU on the database server. Your Oracle software is likely licensed based on the CPU of your database server, so using some of that CPU for backup when not required seems problematic. At the same time, I see where this could substantially reduce your network bandwidth usage. So, I think you need to make a serious cost-benefit analysis before you use this plug-in.

    • Jeff Stonacek says:

      Andy you’re correct, a cost benefit would need to be performed to assess the benefit of implementing DD Boost. However, most times backups are scheduled during non-peak hours so consuming some CPU at those times is usually not a costly proposition. If the CPU can be utilized by the database server during a time of low CPU utilization it will benefit the DataDomain server by offloading the work from the centralized backup system. In that respect, using DD Boost may allow for more clients to use the DataDomain, thereby reducing costs there.

      Bottom line, an assessment would need to be conducted to determine if DD Boost is right for your organization.

    • Ronnie says:

      Andrew, I think you’re selling this a little short. Having deployed this to several hundred servers, we have found that there is a considerable savings across the board.

      First and most important, the backups that typically required eight hours now require 45 minutes. That is substantial in our environment. What matters most (assuming we do not impact production) is securing a solid backup each day. Our databases are not getting smaller, our backup windows are not getting any longer and we’re not adding staff as quick as our environment is growing. So the biggest advantage is simplifying the backup and doing it faster, reducing the impact to the servers, storage and production applications. It’s also convenient when a backup fails, we have time to address it and try again in the same night as opposed to just missing the backup for the day. The best part? We were able to stop doing incremental backups and we now do fulls every night.

      You mention decreasing the network load “to some extent” but in reality it’s 95% (or better) and that’s more than just “some” reduction. When you consider the aggregate effect from using DD Boost for NetBackup, MSSQL, DB2 and SAP has allowed us to avoid upgrading much of the network equipment. Prior to deploying Boost, that aging equipment was our bottleneck for backup performance in most cases. The WAN bandwidth savings are identical and we’re now able to replicate EVERYTHING offsite without WAN circuit upgrades. This has made quarterly audits much less hassle and we’re pleased to say that we’re now tape free!

      I will admit, I too dismissed the idea of distributed deduplication, in ignorant fear for the CPUs in the servers. Consider, if you will, the simple math. If the server (Data Domain) has four processors and you have 500 servers to protect, each with at least two processors, that’s 1000 processors. Sharing the load over 1000 processors just makes sense and extends the useful life of the Data Domain. But at what cost to the database servers, you ask? In our early testing, we were surprised to see that a traditional full backup that took eight hours consumed considerable memory and processor resources for most of the eight hours. The 45-minute backup via DD Boost used only slightly more CPU cycles, but did so for a much shorter period. Memory consumption was actually lower. The Data Domain engineers explained that calculating a single hash for the deduplication process is extremely lightweight and if the data is duplicate, there is nothing more to do with that block of data. If the packet is unique and needs to be sent to Data Domain, compression is applied using LZ compression and that’s done in hardware on modern processors. So if 95% of the database is duplicate (assuming a 5% change rate–most of ours are 2-3%) then only 5% of the database needs to be transmitted. Compression cuts that in half and now only 2.5% of the database size needs to be sent. That’s not a lot of processing! Most of the time spent for the backup is simply reading from the database files on production storage.

      You stated “ using some of that CPU for backup when not required seems problematic” but I think what you’re forgetting is that the tradition backup already uses that CPU and a lot of it. As described above, this plug-in is actually more lightweight.

      So consider the cost-benefits:

      Substantially reduced LAN requirements
      Substantially reduced WAN requirements
      Substantially reduced backup windows
      Substantially reduced time to replicate offsite
      Substantially reduced load on the servers
      Substantially reduced load on the Data Domain backup appliance, allowing it to handle considerably more backups in a single appliance

      We were also able to eliminate backup software licenses since our database can now backup directly to the Data Domain appliances. Huge improvement in cost and the simplification of not having to involve the backup administrators for a restore.

      After our initial testing, I became an instant fan and I never want to go back to the dark ages!

  • Syed Hasan says:

    Could you please guide how we take RMAN backup from Exadata without DDBoost to DD VTL. In mean how we physically connect i.e., (FC, IP) Exadata with DD VTL.

    • Jeff Stonacek says:

      Exadata does not have Fibre Channel capabilities, so the only way to take a backup with RMAN to storage not located on the Exadata is to do it over your IP network.

  • Laurentiu says:

    Hi Jeff,
    You forget to add the ‘send’ sequence to first use of allocate channel command, with ddboost username, like in:
    SEND ‘set username password servername ‘;
    This sequence will save this information in $ORACLE_HOME/config/ddboost.config encrypted file

  • Jeff Stonacek says:

    In response to Scott D’s question, the client was responsible for downloading the plugin from their EMC account prior to configuring on the Oracle servers. Contact your EMC representative to inquire about getting the plugin.


  • Scott D says:

    Did you have to have a password to unzip the RMAN plugin file after you downloaded it from EMC – for installing on your DB servers that you want to back up using DDBoost?

Leave a Reply

Your email address will not be published. Required fields are marked *


Share with your networkTweet about this on TwitterShare on LinkedInShare on FacebookDigg thisEmail this to someone