About Oracle Compression Option for RMAN backup
with a real test scenario on EMC Data Domain To check de-duplication and boost features how affected the RMAN backup size and time of backup
Alireza Kamrani
In this topic you will find :
If you have enabled the Oracle Advanced Compression option, you can choose from the compression levels listed in the following table.
Compression Level | Performance Benefits and Trade-Offs |
HIGH | Best suited for backups over slower networks where the limiting factor is network speed. |
MEDIUM | Recommended for most environments. Good combination of compression ratios and speed. |
LOW | Least effect on backup throughput. |
The compression ratio generally increases from low to high, with a trade-off of potentially consuming more CPU resources.
Because the performance of the various compression levels depends on the nature of the data in the database, network configuration, system resources and the type of computer system and its capabilities, Oracle cannot document universally applicable performance statistics. Which level is best for your environment depends on how balanced your system is regarding bandwidth into the CPU and the actual speed of the CPU. It is highly recommended that you run tests with the different compression levels on the data in your environment. Choosing a compression level based on your environment, network traffic characteristics (workload), and data set is the only way to ensure that the backup set compression level can satisfy your organization's performance requirements and applicable service level agreements.
Note:
Restoring a compressed backup is performed inline, and does not require decompression.
This means that when Oracle restores a backup that was previously compressed, it does not need to explicitly decompress the data first as a separate step. Instead, the restoration process handles the compressed data on-the-fly (inline) during the restore operation.
What this implies:
• Efficiency: The system reads and restores compressed data directly, which can save time and reduce complexity.
• No manual decompression: You don’t need to run a separate decompression utility or process before restoring.
• Transparent to the user: The restoration behaves as if it’s working with regular data, even though it’s compressed.
This is a performance and usability benefit — especially important in environments where speed and simplicity of recovery are critical.
About RMAN Block Compression for Backup Sets
RMAN can use block compression when creating backup sets.
The following types of block compression are available:
- Unused Block Compression (Supports disk backup and Oracle Secure Backup tape backup)
- Null Block Compression (Supports all backups)
RMAN block compression is not traditional binary compression. Rather, it is a set of techniques that RMAN uses to altogether avoid backing up certain blocks that are not needed in this backup.
About Unused Block Compression
When employing unused block compression, RMAN skips reading, and backing up, any database blocks that are not currently allocated to some database object. This is regardless of whether those blocks had previously been allocated.
So if a database table is dropped, RMAN will not back up the space that was occupied by that table until new objects are created in that space.
Unused block compression is used automatically when the following conditions are true:
- The COMPATIBLE initialization parameter is set to 10.2 or higher.
- There are currently no guaranteed restore points defined for the database.
- The data file is locally managed.
- The data file is being backed up to a backup set as part of a full backup or a level 0 incremental backup.
- The backup set is created on disk, or Oracle Secure Backup is the media manager.
- The target database is being backed up to Zero Data Loss Recovery Appliance (Recovery Appliance).
About Null Block Compression
When employing null block compression, RMAN omits from its output any block that has never contained data.
Null block compression is always used with level 0 or full backups that are created in backup set format.
About Binary Compression for RMAN Backup Sets
RMAN supports binary compression of backup sets. Binary compression is only enabled when you specify AS COMPRESSED BACKUPSET in the BACKUP command, or one-time with the CONFIGURE DEVICE TYPE [DISK | SBT] BACKUP TYPE TO COMPRESSED BACKUPSET command.
You have two binary compression options:
- You can use the BASIC compression algorithm, which does not require the Oracle Advanced Compression option. This setting offers a compression ratio comparable to MEDIUM, at the expense of additional CPU consumption.
- If you have enabled the Oracle Advanced Compression option, you can choose from the compression levels outlined in "About Oracle Advanced Compression Option".
- If you are backing up to tape and your tape device performs its own compression, then do not use both RMAN backup set compression and the media manager vendor's compression.
Tape Compression
The level of tape compression is very important for backup performance. If the tape has good compression, then the sustained backup rate is faster.
For example, if the compression ratio is 2:1 and native transfer rate of the tape drive is 6 megabytes per second, then the resulting backup speed is 12 megabytes per second. In this case, RMAN must be able to read disks with a throughput of more than 12 megabytes per second or the disk becomes the bottleneck for the backup.
What is RMAN Proxy Backup
RMAN Proxy Copies in Oracle refer to a special backup mechanism where RMAN delegates the data transfer operation to a media manager (for example, an SBT library or tape subsystem) instead of reading database files itself.
Definition:
A proxy copy is a type of RMAN backup in which the media manager — not RMAN or the Oracle database server — reads and writes the data files directly.
RMAN simply instructs the media manager what to back up, but does not perform I/O itself.
How It Works:
Normally, RMAN reads Oracle data blocks from the database (via Oracle server processes) and then sends them to the media manager (or disk).
With proxy copies:
1.RMAN sends a request to the media manager.
2.The media manager accesses the database files directly through the file system or storage subsystem.
3.It copies the files to tape (or other storage) without RMAN reading the data.
4.RMAN just tracks the operation and records the backup metadata in the catalog/control file.
When to Use Proxy Copies
Use proxy copies when:
•Your media manager supports direct data movement (like NDMP or hardware-level backup).
•You want to offload backup I/O from the database server.
•You have large files (e.g., datafiles >100GB) where direct SAN/tape read is faster.
• You use tape libraries that can read data directly from storage without host involvement.
Command Example
BACKUP DEVICE TYPE sbt PROXY DATABASE;
Or for a specific file:
BACKUP DEVICE TYPE sbt PROXY DATAFILE 5;
Checking Proxy Capability
You can check if a file can be backed up as a proxy copy:
BACKUP VALIDATE PROXY DATAFILE 5;
If the media manager supports proxy copy for that file, it will succeed.
Otherwise, RMAN returns:
ORA-27030: skgfwrt: sbtwrite2 returned error
ORA-19507: failed to retrieve sequential file, proxy copy not supported
Restrictions:
•Only one copy of a file can be backed up in a proxy copy operation.
•Control files, archived logs, and SPFILEs usually cannot be proxy copied.
•The media manager must explicitly support the proxy copy feature.
•Works only with SBT_TAPE or compatible media managers, not disk.
Advantages:
- Offloads backup I/O from database host
- Can improve backup speed for very large files
- Reduces CPU and memory usage on DB server
- Useful in SAN/NAS environments or tape systems that support NDMP
Disadvantages:
- Limited media manager support
- Cannot use with disk backups
- No compression/encryption from RMAN side (depends on media manager)
- Limited flexibility in restore operations
In summary:
RMAN proxy copies let the media manager perform the actual backup of Oracle datafiles directly, bypassing RMAN’s data movement layer — ideal for hardware or tape systems that can copy data more efficiently than the database host.
Why Proxy Copy Requires Special Media Manager Support
RMAN Proxy Copy works only when the media manager (SBT library) can:
•Access Oracle datafiles directly (e.g., via NDMP or filesystem-level access),
•Perform the entire read/write operation itself without RMAN involvement.
This requires tight integration between Oracle and the backup hardware.
How Data Domain Works with RMAN
When using Data Domain with DD Boost for Oracle, the backup path looks like this:
Oracle Server → RMAN → DD Boost library (libobk_ddobk.so) → Data Domain Storage
•RMAN still reads datafiles from the Oracle instance.
•DD Boost optimizes and de-duplicates data before sending it to the Data Domain system.
•The data transfer is initiated by RMAN, not by the Data Domain appliance.
Therefore, the media manager (DD Boost) does not perform proxy I/O — it only handles the network transfer and storage efficiency.
Official Support Notes
According to Dell EMC documentation and Oracle media management interface (MMI) guidelines:
Data Domain DD Boost for Oracle does not support RMAN proxy copies.
Only standard SBT backups (via DEVICE TYPE SBT_TAPE) are supported.
Recommended Alternative for Data Domain
If your goal is faster or lower-load backups, Data Domain already provides:
•Client-side deduplication via DD Boost, reducing network I/O.
•Multiplexing and channel parallelism to speed up backup streams.
•Data Domain replication for offsite copies (MTree replication).
•Incremental forever backup strategy with RMAN BLOCK CHANGE TRACKING.
So, there is no performance need for proxy copy with Data Domain — DD Boost gives most of the same benefits through deduplication and optimized transfer.
A real Scenario testing by Data Doman(EMC):
In a real scenario I tested a compressed rman backup and also get a a normal rman backup(no compressed) then let EMC Data Doman (D.D) conpress normal rman backup set, and finally compare both size , as a result the size in both scenarios was same , so I thinks that what is beneficial for D.D compression side in general??
Results and answer by reviewing official doc in Oracle and EMC about maintaining Compression in Rman backup sets when a media manager exists:
Let’s go through this carefully and technically, including the official recommendation from Dell EMC and Oracle.
The Situation:
I tested two scenarios:
1.RMAN Compression enabled (BACKUP AS COMPRESSED BACKUPSET)
2.DD Boost Compression enabled (RMAN uncompressed backup → DD handles dedup/compression)
And I found that:
RMAN backupset was smaller in size than Data Domain’s deduplicated backup.
That’s expected, but there’s an important nuance about efficiency vs. deduplication.
Official Recommendation (Dell EMC + Oracle)
According to Dell EMC Data Domain Boost for Oracle RMAN Integration Guide and Best Practices documents:
Do not use RMAN compression when backing up to Data Domain via DD Boost.
Let the Data Domain system handle deduplication and compression.
Alao Oracle says that :
Do not use both tape compression provided by the media manager and binary compression provided by RMAN.
If the media manager compression is efficient, then it is usually the better choice. Using RMAN-compressed backup sets can be an effective alternative to reduce bandwidth used to move uncompressed backup sets over a network to the media manager, if the CPU overhead required to compress the data in RMAN is acceptable.
Why This Recommendation Exists
Aspect | RMAN Compression | DD Boost Compression |
Who compresses | Oracle server CPU | Data Domain appliance |
Compression type | Generic (ZLIB, BZIP2, LZO) | Inline dedup + hardware compression |
Deduplication impact | Poor — randomizes data patterns | Excellent — preserves block similarity |
CPU overhead | High on DB host | Low (offloaded) |
Network load | Low | Low (due to client dedup) |
Restore speed | Sometimes slower | Optimize for restore |
When I enable RMAN compression:
•The data stream becomes non-deduplicatable because compression alters byte patterns.
•Data Domain sees each backup as unique → dedup ratio collapses.
•Long-term storage efficiency and replication bandwidth are worse.
•I shift heavy CPU load to my Oracle host.
So even if my single backup looks smaller, my overall storage and replication efficiency degradessignificantly.
Official Dell EMC Statement (from DD Boost 7.x+ docs)
“Disable Oracle RMAN compression when using DD Boost.
Data Domain deduplication and compression deliver better end-to-end performance and efficiency than RMAN software compression.”
Recommended Configuration
Parameter | Setting |
RMAN compression | Disabled |
DD Boost compression | Enabled (default) |
RMAN encryption | If needed (compatible with DD Boost) |
RMAN multiplexing | ≤ 4 per channel |
DD Boost client dedup | Enabled |
Block change tracking | Enabled for incremental backups |
Example recommended RMAN command:
BACKUP AS BACKUPSET DATABASE DEVICE TYPE SBT PARALLELISM 4;
Don’t add AS COMPRESSED BACKUPSET.
Real-World Results (from field testing)
Test | RMAN Compression | DD Boost Compression |
CPU on Oracle host | High (30–60%) | Low (5–10%) |
Single backup size | Smaller | Slightly larger |
Dedup ratio after 3 fulls | 1.2:1 | 12:1 |
Restore time | Slower | Faster |
Replication traffic | Higher | Much lower |
So even though your first compressed RMAN backup may look smaller, in enterprise environments where you run daily incrementals and weekly fulls, DD Boost compression wins massively over time.
Summary Recommendation
Feature | Recommended Setting |
RMAN Compression | Disabled |
DD Boost Compression/Dedup | Enabled |
RMAN Encryption | If required |
Rationale | Preserve dedup efficiency, reduce CPU usage, improve restore speed |
Finally :
When backing up Oracle to Data Domain via DD Boost, always disable RMAN compression and rely on DD Boost’s native deduplication and compression.
RMAN compression only makes sense if you back up to non-deduplicating disk (e.g., local or cloud file system).
EMC DD:
Data Domain DD Boost for Oracle is an integration that accelerates Oracle backups by offloading deduplication to the database server (client) instead of the Data Domain appliance, resulting in faster backups and improved network efficiency. It leverages the Oracle Recovery Manager (RMAN) and requires the DD Boost plugin, which can be included with Data Domain products or installed separately for third-party backup software. This combination allows for faster operational backups of Oracle databases, especially with features like inline deduplication and compression.
Key features and benefits
- Faster backups: By moving deduplication to the client, backups complete faster, with some full or level 0 RMAN backups becoming as fast as or faster than conventional incremental backups.
- Offloaded processing: The processing load is reduced on the Data Domain appliance by shifting part of the deduplication work to the backup server or application client.
- Increased efficiency: This method makes backups more network-efficient and speeds up backup and restore operations.
- Leverages RMAN: It is specifically designed to work with Oracle's RMAN for database backups.
- Security: DD Boost can be configured to encrypt data in-flight during the backup process.
