For continuous monitoring, a particularly beneficial practice is to activate DB2 accounting classes 1, 2, 3, 7, and 8 and statistics classes 1, 3, 4, 5, and 6 destination SMF. But in some cases, this can be just too much load for the System Management Facility (SMF).
SMF is a critical piece of a z/OS environment: it is used to collect information about resource utilization, performance, security and billing, for example. SMF records can be written to  Direct Access Storage Devices (DASD) datasets or to system logger-managed log streams.

A common practice is to collect SMF records on DASD datasets. The minimum configuration requires 2 of these datasets, but it is desirable to work with 3 of them for improved availability.
If the arrival of generated SMF data is too high or if the I/O rate on the datasets is too slow, SMF temporarily stores its records in buffers.
If the arrival of information is continuously high or if the I/O poor performance persists, these buffers will eventually fill and this can result in loss of SMF data. This situation will generate messages in the system console and in the DB2 MSTR address space as illustrated in following example:

IEE366I NO SMF DATA SETS AVAILABLE--DATA BEING BUFFERED
*IEE986E SMF HAS USED 25% OF AVAILABLE BUFFER SPACE
*IEE986E SMF HAS USED 31% OF AVAILABLE BUFFER SPACE
...
*IEE986E SMF HAS USED 93% OF AVAILABLE BUFFER SPACE
*IEE986E SMF HAS USED 100% OF AVAILABLE BUFFER SPACE
*IEE979W SMF DATA LOST - NO BUFFER SPACE AVAILABLE
DSNW133I -DBAT DSNWVSMF - TRACE DATA LOST, SMF NOT ACCESSIBLE RC=28
...
DSNW123I -DBAT DSNWVSMF - TRACE RECORDING HAS BEEN RESUMED ON SMF

Accumulation of Accounting provides a way to reduce the number of DB2 accounting trace SMF records by accumulating the information based on an accumulation interval and on an aggregation criteria.
The system parameter ACCUMACC controls whether and when DB2 accounting data is accumulated. ACCUMACC=NO is the default. This parameter can be set to a number from 2 to 65535 like in ACCUMACC = n, where n defines the accumulation interval. ACCUMUID defines the aggregation criteria and its value goes from 0 to 17. For example ACCUMACC=10 and ACCUMUID=1 will result in 1 accounting record with aggregated information by End user ID every 10 otherwise normally created records. This setting will reduce the number of generated DB2 accounting SMF records from the same End used id by 10. In some few situations, however, a record may be written before reaching the 10th accounting interval.

Accumulation of accounting is done at the expense of aggregation of data, and this results in a loss of details. Information that may be useful for performance investigation is likely to be lost forever. Nevertheless, accounting roll-up can be enabled and disabled dynamically, allowing you to collect detailed information during a given period of time if needed. This can be useful if a problem can be reproduced, for example. Another limitation of accumulation of accounting is that it only applies to accounting records, and only for those generated by DDF and RRSAF threads.

Accumulation of accounting is available in DB2 10, but compression of DB2 SMF records is a better option.
Compression of DB2 SMF records exploits the z/OS compression service CSRCESRV to compress everything after the SMF header. Compression applies to all kind of DB2 SMF records. Because the SMF header is not impacted, the DB2 SMF records can be managed as usual by standard SMF manipulation tools like IFASMFDP. As far as I know, most of the commercial DB2 reporting tools will understand and decompress compressed SMF records without intervention. Nevertheless, the APAR PM27872: SMF DECOMPRESSION provides the sample application DSNTSMFD for decompressing compressed DB2 SMF records from SMF datasets as needed. This tool can be handy if you have your own DB2 SMF reporting infrastructure.
Compression of SMF records is controlled by the system parameter SMFCOMP. SMFCOMP is set to OFF by default, and it can be changed to ON/OFF online.
The performance impact is minimum with a reported less than 1% CPU impact for an OLTP workload. The disk savings for DB2 SMF data set can be significant with observed compression rates from 60% to 80%.

Example
Consider following scenario: to compare the effects of the default settings, accounting roll-up, and SMF compression I set a distributed OLTP benchmark workload designed to put stress on SMF. For illustration purposes, I resized the SMF datasets small enough to get a quick turnaround.
This is an extract of the SMF dump job showing the information related to the DB2 SMF records. Type 100 contains almost all statistics traces, type 101 contains almost all accounting traces, and type 102 is for almost all performance traces. Typically, most of the DB2 records will come from type 101 (accounting), unless your system is collecting some performance traces.
The difference between the START and END DATE-TIME values indicates the elapsed time required to fill a SMF dataset. When running at full speed and under default DB2 settings, a SMF dataset will fill in less than a minute.


A continuous execution of this benchmark exhausted the 3 defined SMF datasets quickly, and SMF records were lost.
As a countermeasure, I activated aggregation of accounting using ACCUMACC=10 and ACCUMUID=1. In this way, DB2 will write 1 SMF accounting record every each 10 for the same end user id. As a result, the stress on the SMF system will be alleviated at the expenses of loss of granularity in the accounting information.
These are the results:


The time to fill a SMF dataset increased from less-than-a-minute to about 4 minutes. The SMF system is not under stress, and there is no SMF data loss in this case. Note that the number of written records and the record size remains in essence the same.
Finally, I deactivated accumulation of accounting in favor of SMF compression by changing ACCUMACC to NO and SMFCOMP to ON.
These are the results:


The time to fill a SMF dataset drops to less than 2 minutes. Not as good as with ACCUMACC=10, but acceptable for this system. There is no SMF data loss and, more importantly, the DB2 accounting records keep all the detailed informations.
The effect of compression on the SMF datasets is made clear by the fact that the same dataset is able to contain about 4 times more DB2 accounting records (type 101) as a consequence of being each one substantially smaller. The average type 101 record length is now about 25% of the original size.

Conclusion:
DB2 10 for z/OS introduces the option of compressing DB2 SMF records.
This feature helps to alleviate the stress on the SMF infrastructure and enables users to keep detailed accounting information.
Accumulation of accounting is better than not collecting accounting records at all, but SMF compression in DB2 10 is a better option.