Journaling And Commitment Control - IBM 170 Servers Manual

limit the amount of data it brings into and keeps in memory to a job's share of memory. The amount of
memory available to each job is inversely proportional to the number of active jobs in a memory pool.
The memory-sharing algorithms discussed above provide balanced performance for all the jobs running in
a memory pool. Running short transactional queries in the same memory pool as long running, data
intensive queries is acceptable. However, if it is desirable to get maximum performance for long-running,
data-intensive queries it may be beneficial to run these types of queries in a memory pool dedicated to
this type of workload. Executing long-running, data-intensive queries in the same memory pool with a
large volume of short transactional queries will limit the amount of memory available for execution of the
long-running query. The plan choice and engine execution of the long-running query will be tuned to run
in the amount of memory comparable to that available to the jobs running the short transactional queries.
In many cases, data-intensive, long-running queries will get improved performance with larger amounts
of memory. With more memory available the optimizer is able to consider access plans which may use
more memory, but will minimize runtime. The query engine will also be able to take advantage of
additional memory by keeping more data in memory potentially eliminating a large number of DASD
I/Os. Also, for a job executing long-running performance critical queries in a separate pool, it may be
beneficial to set QQRYDEGREE=*MAX. This will allow all memory in the pool to be used by the job to
process a query. Thus running the longer-running, data intensive queries in a separate pool may
dramatically reduce query runtime.

4.8 Journaling and Commitment Control

Journaling
The primary purpose of journal management is to provide a method to recover database files. Additional
uses related to performance include the use of journaling to decrease the time required to back up
database files and the use of access path journaling for a potentially large reduction in the length of
abnormal IPLs. For more information on the uses and management of journals, refer to the Sytem i
Backup and Recovery Guide. For more detailed information on the performance impact of journaling see
the redbook
Striving for Optimal Journal Performance on DB2 Universal Database for System i.
The addition of journaling to an application will impact performance in terms of both CPU and I/O as the
application changes to the journaled file(s) are entered into the journal. Also, the job that is making the
changes to the file must wait for the journal I/O to be written to disk, so response time will in many cases
be affected as well.
Journaling impacts the performance of each job differently, depending largely on the amount of database
writes being done. Applications doing a large number of writes to a journaled file will most likely show a
significant degradation both in CPU and response time while an application doing only a limited number
of writes to the file may show only a small impact.
Remote Journal Function
The remote journal function allows replication of journal entries from a local (source) System i to a
remote (target) System i by establishing journals and journal receivers on the target system that are
associated with specific journals and journal receivers on the source system. Some of the benefits of
using remote journal include:
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 4 - DB2 Performance
54