Hybrid Columnar Compression - Oracle Exadata Recipes: A Problem-Solution Approach - page 473

type, on these columnar values and formats a collection of blocks into a logical construct called the compression unit
(CU) for ranges of rows to be inserted. Each CU contains multiple blocks, each of which contains columnar subsets
of the entire range of columns in the segment. When the first CU is filled with its rows (again, organized by column),
a second CU will be established, then a third, and so on until all of the rows are inserted. Using the test tables from
the solution of this recipe, which are based on SYS.OBJ$ , Figure 16-1 provides a simplified graphical representation of
how the CUs would be established in the case of QUERY HIGH compression.
Figure 16-1. Compression unit and block layout for HCC table
Figure 16-1 shows a logical representation of how the first two CUs are used on an HCC table. The sizes of each
column in the blocks for each CU indicate the number of distinct values for the column; the more distinct values, the
more space the columnar values use within each CU's block. When the CU's blocks become full, a new CU and new
set of blocks is formatted to store the data.
Technically speaking, a CU is physically stored in a chained row of a fixed-size pseudo-column. This column
is actually a CU-specific pseudo-column. The CU has a small header section that contains byte offsets to the
compressed columns, which store compressed values for your table's actual columns. When data is inserted
into a CU, Oracle creates a single chained row for a single CU column (not to be confused with the actual columns).
Each physical block inside the CU has a block header and row directory, and every row directory has an entry that
refers to the single row piece inside the block. Each row piece has a row header and, also, if it's not the last block in
the CU, a “next rowid” pointer to the next row piece. When accessing data from an HCC segment, Oracle will read the
entire CU in one I/O and, to read all of the actual columns in the row, it will be required to follow the chained row
from CU block to CU block until the last physical block is read.
In the example in Figure 16-1 , each CU stores roughly 6,368 rows and contains each of the columns defined in
the table. You can confirm the physical storage details of your HCC segments by performing a block dump. To do this,
determine your absolute file number and block number for a rowid in your table as follows:
SQL> select 'alter system dump datafile '||fno||' block '||blk||';'
2 from (
3 select dbms_rowid.rowid_to_absolute_fno(rowid,'D14','MYOBJ_COMPQH') fno,