Migration of batch applications

When migrating a batch application to a data sharing environment, ensure that you account for any changes in processor speed.

Be aware of contention that can occur when there are hot spots in the data as it is updated from multiple members of the group.

Parallel scheduling

If a significant portion of the elapsed time of a long-running batch application is due to processor resource consumption and you are currently having scheduling problems, consider running more than one copy of the same program in parallel. You can run each copy on a different key range, typically the partitioning key of the main table.

If your batch application cannot be redesigned to run on separate partitions, consider running batch jobs on the CPC in the group that has the fastest single-central processor speed. This approach is recommended only if the application does not access the coupling facility at a high intensity.

To avoid disk contention, make sure the data partitions are placed on disk devices with separate I/O paths. Consider using the PIECESIZE option of the CREATE or ALTER INDEX SQL statements to give you more control over the data set size of nonpartitioning indexes.

Designing table spaces for heavy insert and update activity

MEMBER CLUSTER option: If your application does heavy sequential insert processing from multiple members of the group, consider putting the data in a table space that is defined with the MEMBER CLUSTER option. The MEMBER CLUSTER option causes Db2 to insert the data, based on available space rather then respecting the clustering index or the first index. For sequential insert applications, specifying MEMBER CLUSTER can reduce P-lock contention and give better insert performance at the cost of possibly higher query times.
TRACKMOD option: When an application is rapidly updating a single table space, contention can exist on the space map pages as Db2 tracks changes. Db2 tracks these changes to help improve the speed of incremental image copies. With TRACKMOD NO, Db2 does not track changes and thus avoids contention on the space map. This option is not recommended if you depend on fast incremental image copies for your backup strategy. If your application does heavy sequential inserts, consider also using the MEMBER CLUSTER option.