Effects of management classes on transactions

Each copy of a file or directory that is backed up by IBM Spectrum Protect is bound to (associated with) a management class.

A management class includes a backup copy group. A backup copy group defines how IBM Spectrum Protect manages objects that were backed up. Management class attributes include such things as the storage pool where the object is stored, how many versions of each object are created, and how long the versions are retained.

During backup operations, IBM Spectrum Protect bundles file and directory backup copies into transactions. That is, the client opens a transaction with the server database, backs up one or more objects, and then closes the transaction. If the IBM Spectrum Protect server database successfully commits the transaction, the client repeats the process until all eligible objects are backed up.

Transaction-based processing provides for reliable backups, but each commit operation also increases processing time. In general, the best performance is achieved by grouping as many objects as possible into a single transaction.

The maximum size of a transaction is governed by the following two parameters:

TXNGROUPMAX: This option is set on the server. It specifies the maximum number of objects that can comprise a transaction
txnbytelimit: This option is set on each client. It specifies the maximum size of a transaction, in KB.

The size of any transaction is based on which of these parameter values is reached first. For example, if the TXNGROUPMAX option is set to 4096 and the txnbytelimit option is set to 25600 KB (25 MB), then up to 4096 small files can be included in a transaction if the sum of their sizes does not exceed 25600 KB. If objects are 25 MB in size, or larger, they are sent as one file in one transaction.

Another factor that can influence the transaction size is the destination storage pool for the backed up objects. The objects within a transaction must all be directed to the same storage pool. As the transaction is processed, if one of the objects is directed to a different storage pool, then the current transaction is committed, and a new transaction is opened for the object that is destined for another storage pool.

If the destination storage pool is frequently changed during a backup operation, performance is reduced because new transactions must be created. For example, assume that you have a directory structure that contains many media files of different media file formats, such as the following files:

/media/vid001.jpg
/media/vid001.wmv
/media/vid002.jpg
/media/vid002.wmv.
.
.
.
/media/vid9999.wmv

Assume also that you have include statements that bind these files types to different management classes, such as the following examples:

include /media/*.jpg diskclass
include /media/*.wmv tapeclass

The management classes named DISKCLASS and TAPECLASS each specify a different storage pool: one writes to disk and the other writes to tape. When the media files are backed up, the /media/vid001.jpg file is backed up in one transaction and is directed to the disk storage pool. The next object, /media/vid001.wmv, is backed up in another transaction that is directed to the tape storage pool. Then, the /media/vid002.jpg file is backed up in yet another new transaction and is directed to the disk storage pool. This behavior adversely affects the performance of backup operations. In addition to the additional processing time from the inefficient transactions, more delays can occur if you must wait for tapes to be mounted.

Consider revising your management classes, or management class bindings, to reduce or eliminate the number of different storage pools that the client uses for backed up objects.

A similar situation can occur when directory objects are backed up. By default, directory objects are bound to the management class with the longest RETONLY (retain only version) value. If multiple management classes in the active policy set have the same value for RETONLY, then the management class that is last, when sorted alphabetically, is used. For example, if the management classes named DISKCLASS and TAPECLASS both have the same RETONLY setting, and they are both in the active policy set, then the default management class for directory objects is TAPECLASS.

If file objects are directed to a disk storage pool and directory objects are directed to a different storage pool, such as tape, that also reduces transaction efficiency and slows performance. One way to avoid the inefficiencies of using a different management class for directory objects is to use the dirmc option and specify the same management class that you use to back up files. Using the example management classes named DISKCLASS and TAPECLASS, set DIRMC DISKCLASS to bind directory objects to the management class, and storage pool, that you use for file objects.