In this blog we are going to discuss Advanced Compression backup compression, one of the many lesser known capabilities included with the Advanced Compression option.
In addition to compressing data/indexes stored inside the database, Advanced Compression also includes the capability to compress backed up data. Recovery Manager (RMAN) and DataPump are
two commonly used tools to backup the data stored inside an Oracle Database. In this blog we’ll just focus on RMAN, we will talk about DataPump in the future.
Why is backup compression useful?
The storage requirements for maintaining database backups and the performance of the backup procedures are directly impacted by database size. Advanced Compression includes RMAN compression technology that can dramatically reduce the storage requirements for backup data. A database already using data and/or index compression will generally require less storage and less I/O for the backup because compressed tables/partitions typically have fewer blocks to backup than if they were not compressed.
Three levels of RMAN compression with Advanced Compression
Due to RMAN’s tight integration with Oracle Database, backup data is compressed before it is written to disk or tape and doesn’t need to be uncompressed before recovery – providing a reduction in storage costs and a potentially large reduction in backup and restore times. RMAN Basic compression delivers a very good compression ratio, but can sometimes be CPU intensive and CPU availability can be a limiting factor in the performance of backups and restores.
There are three levels of RMAN Compression with Advanced Compression: LOW, MEDIUM, and HIGH. The amount of storage savings increases from LOW to HIGH, while potentially consuming more CPU resources. LOW / MEDIUM / HIGH compression is designed to deliver varying levels of compression while typically using less CPU than RMAN Basic Compression.
Generally speaking, the three levels can be categorized as such:
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 impact on backup throughput and suited for environments where CPU resources are the limiting factor.
As indicated above, if you are I/O-limited but have idle CPU, then HIGH could work best, as it uses more CPU, but saves the most space and thus gives the biggest decrease in the number of I/O’s required to write the backup files. On the other hand, if you are CPU-limited, then LOW or MEDIUM probably makes more sense – less CPU is used, and about 80% of the space savings will typically be realized (compared to Basic).
It is important to note that if the backups were I/O-bound before enabling RMAN backup compression, then the backups will likely go faster with compression enabled. If the backups were CPU-bound, then they will likely go slower with compression enabled.
Why is backup compression worth looking at?
Many user’s often say that the most important performance-related metric for their backups is recovery time: if they have an urgent need to recover a database, anything they can do to speed that up is helpful – and if their backups are 1/4th to 1/6th the size they were before compression, that can save a huge amount of time for database recovery.
If you haven’t thought about how compression can help your backup/recovery time it’s probably worth some time to look into it, but as usual, it’s always best to test on your systems with your data.
For now thedatabase storage optimization adventure continues my next blog, in which we will discuss three ILM-focused features of Oracle Database 12c.