Database Storage Optimization best practices, tips and tricks and guidance from Database Compression Product Management

Oracle Advanced Compression Compared to Storage-Based Compression – The Important Differences

Gregg Christman
Product Manager

Customers often
ask if they should use Advanced Compression for their database data instead of
storage-based compression. While this blog discusses the points I usually make
on this topic, please note that this blog isn’t intended to suggest that Oracle
Advanced Compression replace storage-based compression for all general
application uses, instead, we’ll discuss why Oracle Advanced Compression is
better suited for compressing Oracle Database data.

compression/deduplication and Oracle Advanced Compression are two technologies
that share the concept of compression and together, as well as separately, can
often provide significant storage cost savings. While storage-based solutions
are ideally suited to provide compression for a wide range of applications and
uses, storage-based compression solutions can be characterized as being
“database-unaware” -- meaning that they lack the application awareness that is
needed to truly optimize the storage and use of Oracle Database data. With
deduplication and compression enabled at the storage level, the two operations
are executed with no knowledge of the use or value of incoming data. Without true application awareness of the
data value and use, duplicate data is deduplicated, and any compressible data
is compressed, without regard for rehydration or decompression impacts on data

Because an
effective storage-based deduplication/compression strategy requires fully
hydrated and uncompressed data to be sent to the storage device, the database
data would either have to be not compressed or would have to be uncompressed
before going to storage. If the database is not compressed, then all the
advantages of compression (reduced storage, reduced I/O, reduced memory use in
the buffer cache etc...) won’t be available on the database servers.

Compression is integrated at all levels of the stack - it gives compression
benefits at storage level, compression benefits to buffer cache, compression
benefits in making table scans faster, backups faster, database cloning faster
and it can help entire tables/partitions fit completely in memory. Additionally, the data compression format and
algorithms are specifically designed so that queries can run directly on
compressed data (without having to uncompress it first) - making scans and
reporting run faster.

On the other
hand, storage-based compression (and de-duplication) gives some of the storage
benefits, but gives nothing for the rest - no benefits to the buffer cache
(since data remains uncompressed in memory), scans are not faster (likely
slower), database backup is not faster (likely slower), database cloning is not
faster (likely slower) and the memory footprint of the database remains
unchanged. Queries will now have to decompress before accessing the data,
making them likely run slower.

But again, just
to be clear, the point of this blog isn’t to suggest that Oracle Advanced
Compression replace storage-based compression for all general application uses
– Advanced Compression can co-exist with storage solutions, we just believe
that our database-aware compression is better suited for the database than 3rd
party storage-based compression.

But for now the
database storage optimization adventure continues my next blog, in which we
will discuss enabling compression on existing partitions, a topic which I
mistakenly forgot to include in an earlier blog.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.