ZDLRA: Changes in the Protection Policy Compression Algorithms (Doc ID 2654539.1)
First I wanted to go through a little background on how compression works for archive logs.
As you probably know, database backups are automatically compressed. That is not necessarily the case for archive logs.
Archive logs can reach the ZDLRA by 2 different methods.
- Real-time redo,
- Log sweeps.
Regardless of how the Archive Logs reach the ZDLRA, they are stored as backup files.
Log Sweeps
Now for log sweeps, the backupset of archive logs is stored exactly as they are sent.
if you follow the best practices for backups, you send over archive logs as
- Plus archive logs not backed up filesperset=32;
As you can figure out, this creates a single, or multiple backupsets each backupset contains multiple archive logs up to a total of 32 archive logs per backupset.
Also note, that that by default the archive log backupsets are NOT compressed. You can RMAN compress the archive log backups (if you have the ACO license), but be careful because it is not recommended to compress the datafile backups.
Real-time redo
Real-time redo is where this MOS note takes affect. Up to the current release of ZDLRA, archive logs sent via real-time redo were compressed using basic compression. A "standby redo" log would mirror the redo log for the protected database, and a "BACKUP_ARCH" task would be queued to create a backupset from the "standby redo log". In the process of creating the RMAN backupset, basic compression was applied and a compress RMAN backupset is created.
This does a few things that I want to point to out.
- During the creation of the archivelog backupset, CPU is used to compress the backupset, and the final result is a smaller backupset.
- During the validation of backups for a database, CPU is used to uncompress the RMAN backupset to validate it. NOTE: this would also occur if you RMAN compress the archive logs during a log sweep.
- When recovering a database, the compressed RMAN backupset is sent over the network (less network traffic), and the Database Host uncompresses the backupset to read the archive logs.
If you read this carefully, you will see that there a CPU cost for compression, and there is a space savings when using it.
New Feature to control log compression!
The new feature allows you to control the log compression for archive logs sent through real-time redo.
NOTE: When using compression on the ZDLRA, you don't need the ACO license.
Below is the information from the documentation.
log_compression_algorithm
The setting for the archivelog compression feature.
This setting is used to adjust the compression level of NZDL/polled archivelog backups.
OFF means that the archivelogs will not be compressed.
BASIC means the BASIC compression alogorithm will be used to compress the backups.
LOW means the LOW compression alogorithm will be used to compress the backups.
MEDIUM means the MEDIUM compression alogorithm will be used to compress the backups.
HIGH means the HIGH compression alogorithm will be used to compress the backups.
This is a great lever to control what happens with archive logs.
Medium compression can be used if you have ample CPU and are concerned about space, OFF can be used if you have CPU concerns and ample space.
Remember, the deeper the compression, the higher the CPU. Like most things in IT, there are tradeoffs .