Intel 7xx Servers, 170 Servers, AS/400 RISC Server DB2 Multisystem for i5/OS, Commitment Control

There are 3 sets of tasks which do the SMAPP work. These tasks work in the background at low priority to minimize the impact of SMAPP on system performance. The tasks are as follows:

yJO_EVALUATE-TASK - Evaluates indexes, estimates rebuild time for an index, and may start or stop implicit journaling of an index.

yJO-TUNING-TASK - Periodically wakes up to consider where the user recovery threshold is set and manages which indexes should be implicitly journaled.

yJORECRA-DEF-XXX and JORECRA-USR-XXX tasks are the worker tasks which sweep aged journal pages from main memory to minimize the amount of recovery needed during IPL.

Here are guidelines for lowering the amount of work for each of these tasks:

yIf the JO-TUNING-TASK seems busy, you may want to increase SMAPP recovery target time.

yIf the JO-EVALUATE task seems busy, explicitly journaling the largest access paths may help or looks for jobs that are opening/closing files repeatedly.

yIf the JORECRA tasks seem busy, you may want to increase journal recovery ratio.

yAlso, if the target recovery time is not being met there may be SMAPP ineligible access paths. These should be modified so as to become SMAPP eligible.

To monitor the performance impacts of SMAPP there are Performance Explorer trace points and a substantial set of Collection Services counters which provide information on the SMAPP work.

SMAPP makes a decision of where to place the implicit access path journal entries. If the underlying physical file is not journaled, SMAPP will place the entries in a default (hidden) system journal. If the underlying physical file is journaled, SMAPP will place the implicit journal entries in the same place. SMAPP automatically manages the system journal. For the user journal receivers used by SMAPP, RCVSIZOPT(*RMVINTENT), as specified on the CHGJRN command, is a recommended option. The disk space used by SMAPP may be displayed with the EDTRCYAP and DSPRCYAP commands. It rarely exceeds 1% of the ASP size.

For more information on SMAPP see the Systems management -> Journal management -> System-managed access path protection section in the System i information center.

Commitment Control

Commitment control is an extension to the journal function that allows users to ensure that all changes to a transaction are either all complete or, if not complete, can be easily backed out. The use of commitment control adds two more journal entries, one at the beginning of the committed transaction and one at the end, resulting in additional CPU and I/O overhead. In addition, the time that record level locks are held increases with the use of commitment control. Because of this additional overhead and possible additional record lock contention, adding commitment control will in many cases result in a noticeable degradation in performance for an application that is currently doing journaling.

4.9 DB2 Multisystem for i5/OS

DB2 Multisystem for i5/OS offers customers the ability to distribute large databases across multiple System i servers in order to gain nearly unlimited scalability and improved performance for many large query operations. Multiple System i servers are coupled together in a shared-nothing cluster where each system uses its own main memory and disk storage. Once a database is properly partitioned among the

IBM i 6.1 Performance Capabilities Reference - January/April/October 2008

© Copyright IBM Corp. 2008	Chapter 4 - DB2 Performance
	56