In this blog
we’re 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’ll talk about DataPump in the future.
Why is backup
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
speaking, the three levels can be categorized as such:
HIGH - Best
suited for backups over slower networks where the limiting factor is network
- Recommended for most environments. Good combination of compression ratios and
LOW - Least impact
on backup throughput and suited for environments where CPU resources are the
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 the
database storage optimization adventure continues my next blog, in which we
will discuss three ILM-focused features of Oracle Database 12c.