Beruflich Dokumente
Kultur Dokumente
Compression
AISHWARYA KALA
Compression Modes
Block Structure
Row Structure
In the row each column within the
row is preceded by a byte specifying
the length of the column.
Here we have 4 columns in a row
the first is 3 bytes in length, the
second column is 5 bytes in length,
the third is NULL and the fourth is 2
bytes in length
If the value of the byte is 0xFF (255) it
means the column is NULL in other
words there is no data for this column
of the row.
The format of a data block that uses basic and OLTP table compression is essentially
the same as an uncompressed block.
The difference is that a symbol table at the beginning of the block stores duplicate
For an Uncompressed block, there will be no symbol table , its just look like
For an compressed block, there will be a symbol table, here we have rows with
names , John, Doe, Jane, Smith which are repeated values.
The original data has been replaced with symbols , and the original data is stored
i.e. the values Jane , Doe, Smith etc .
Basic Compression
This feature is available starting Oracle 9i and it allows us to store 2x, 3x, 4x or more data
per block.
It only works during direct path operations such as insert /*+APPEND*/, alter table t move,
create table as select, sqlldr direct=y.
It does not PREVENT you from using normal insert/update/delete statements - it just means
that the results of those statements will result in some non-compressed data.
A single table may have some blocks compressed and some blocks not compressed .
The original basic compression still exists in 11g for enterprise edition users, and there is the
new advanced compression option (OLTP).
Few Examples
1. Baseline CTAS
create table t1 as select * from all_objects where rownum <= 50000;
2. CTAS with basic compression enabled
create table t1 compress basic as select * from all_objects where rownum <= 50000;
OLTP Compression
Compression that allows data to be compressed during all types of data manipulation
operations, including conventional DML such as INSERT and UPDATE.
One significant advantage is Oracles ability to read compressed blocks directly without
having to first un-compress the block. Therefore, there is no measurable performance
degradation for accessing compressed data.
Columnar Compression
Storing column data together, with the same data type and similar characteristics,
dramatically increases the storage savings achieved from compression. However, storing
data in this manner can negatively impact database performance when application
queries access more than one or two columns as well as during DMLs
As the name implies, this technology utilizes a combination of both row and columnar
methods for storing data.
A logical construct called the compression unit (CU) , which is nothing but a collection
of blocks, is used to store a set of hybrid columnar-compressed rows
When data is loaded, column values for a set of rows are grouped together and
compressed. After the column data for a set of rows has been compressed, it is stored in
a compression unit. So its a Logical structure spanning multiple database blocks.
Updated rows are moved, as in a delete + insert, and this row automatically migrates to
OLTP Compression
Queries with Hybrid Columnar Compression only decompress necessary columns to satisfy
query. Data can remain compressed in the buffer cache.
Performing DML operations could result in a reduction of the HCC compression ratio. It
is recommended that HCC be enabled on tables or partitions with no or infrequent
DML operations.
Warehouse Compression
COMPRESS FOR QUERY HIGH High Compression ratio without affecting query times
but some data load performance hit