Bookmark and Share
RSS

Recent Posts

The Evolution of Compression: Db2 10

December 05, 2017

My backgrounder on compression continues with Db2 for z/OS Version 10. This release brought compression support to SMF trace data and provided an availability option to activate data compression without placing the table space in REORG pending.

The volume of Db2 trace records written to SMF can be very large, so compression can be a big cost-saver in this area. Laboratory measurements show that SMF compression generally saves 60-80 percent of the space for Db2 SMF records and requires less than 1 percent in CPU for overhead to do it. ?The DSNZPARM SMFCOMP, new with Db2 10, activates compression of Db2 trace records destined for SMF using the z/OS compression service (CSRCESRV2). The parameter is specified in DSNTIPN panel field COMPRESS SMF RECS and the default is OFF. ?If this parameter is enabled, any data after the SMF header for the SMF100, 101, and 102 records is compressed. In a data sharing environment, the SMFCOMP parameter has member scope.

Prior to Db2 10, activating compression for a table space using the ALTER TABLESPACE command required Db2 to build the compression dictionary.  

Db2 10 NFM allowed compression to be activated with the ALTER statement at any time. The compression dictionary could be built by executing these statements:
  • INSERT statements
  • MERGE statements
  • LOAD SHRLEVEL CHANGE
Additionally, when loading XML data, a dictionary could be built specifically for the XML table space. This enabled XML data to be compressed under these circumstances:
  • The table space or partition is defined with COMPRESS YES.
  • The table space or partition has no compression dictionary built yet.
  • The amount of data in the table space is large enough to build the compression dictionary.
  • The threshold is about 1.2 MB, which is determined by reading the RTS statistics in memory.
When the threshold was reached, Db2 would build the dictionary asynchronously and issue this message:

DSNU241I csect-name DICTIONARY WITH n ENTRIES HAS BEEN SUCCESSFULLY BUILT FROM m ROWS FOR TABLE SPACE tablespace-name, PARTITION part-number


The DSNU241I message would be issued in this case because the table space was partitioned. For a non-partitioned table space, DSNU231I would be issued. These messages are issued on the console only by compress on insert. Once the dictionary was built, Db2 would insert the data in compressed format.
Generally, you can use the DSN1COMP utility, which is available since Db2 V3, to estimate the space savings that can be achieved by Db2 data compression in table spaces and indexes.

Read more about Db2 10 for z/OS: Next week, I’ll continue this recap of the compression evolution with a look at Db2 Version 11.

Posted December 05, 2017 | Permalink

comments powered by Disqus