Classic row compression
Classic row compression, sometimes referred to as static compression , compresses data rows by replacing patterns of values that repeat across rows with shorter symbol strings.
The benefits of using classic row compression are similar to those of adaptive compression, in that you can store data in less space, which can significantly save storage costs. Unlike adaptive compression, however, classic row compression uses only a table-level dictionary to store globally recurring patterns; it doesn't use the page-level dictionaries that are used to compress data dynamically.
How classic row compression works
Classic row compression uses a table-level compression dictionary to compress data by row. The dictionary is used to map repeated byte patterns from table rows to much smaller symbols; these symbols then replace the longer byte patterns in the table rows. The compression dictionary is stored with the table data rows in the data object portions of the table.
What data gets compressed?
Data that is stored in base table rows and log records is eligible for classic row compression. In addition, the data in XML storage objects is eligible for compression. You can compress LOB data that you place inline in a table row; however, storage objects for long data objects are not compressed.
Turning classic row compression on or off
To disable compression for a table, use the ALTER TABLE statement with the COMPRESS NO option; rows that you subsequently add are not compressed. To extract the entire table, you must perform a table reorganization with the REORG TABLE command.
If you have a license for theDb2 Storage Optimization Feature, compression for temporary tables is enabled automatically. You cannot enable or disable compression for temporary tables.
Effects of update activity on logs and compressed tables
Depending upon update activity and which columns are updated within a data row, log usage might increase.For information about how to minimize the effects of update activity on logs, see Ordering columns to minimize update logging.
If a row increases in size, the new version of the row might not fit on the current data page. Rather, the new image of the row is stored on an overflow page. To minimize the creation of pointer-overflow records, increase the percentage of each page that is to be left as free space after a reorganization by using the ALTER TABLE statement with the PCTFREE option. For example, if you set the PCTFREE option to 5% before you enabled compression, you might change it to 10% when you enable compression. Increasing the percentage of each page to be left as free space is especially important for data that is heavily updated.
Classic row compression for temporary tables
Compression for temporary tables is enabled automatically with the Db2 Storage Optimization Feature. When executing queries, the Db2 optimizer considers the storage savings and the impact on query performance that compression of temporary tables offers to determine whether it is worthwhile to use compression. If it is worthwhile, compression is used automatically. The minimum size that a table must be before compression is used is larger for temporary tables than for regular tables.
You can use the explain facility or the db2pd tool to see whether the optimizer used compression for temporary tables.