Download PDF (1.3 MB) - IBM Redbooks

Increasing the primary log file size has implications for database recovery. Assuming a
constant value for softmax, larger log files mean that recovery might take more time. Although
you can lower the softmax parameter to counter this effect, consider that more aggressive
page cleaning might also be less efficient. Increasing the softmax parameter offers additional
opportunities for write coalescing at the cost of longer recovery time.
The default value of softmax is 100, meaning that the database manager attempts to clean
pages such that a single log file needs to be processed during recovery. For best
performance, we suggest increasing this value to 300 as follows, meaning that three log files
might need processing during recovery:
db2 update db config for using softmax 300
4.14.5 Using System Managed Storage for table spaces that contains LOBs
When creating REGULAR or LARGE table spaces in DB2 9.5 and later that contain
performance critical LOB data, we suggest specifying MANAGED BY SYSTEM to gain the
advantages of cached LOB handling in system managed storage (SMS).
This consideration applies to the following Business Process Manager-related products:
► Business Process Choreographer database (BPEDB)
► BPMN databases (twproc and twperfdb)
► Databases backing service integration bus messaging engine data stores
For background on using SMS for table spaces with large objects, see 4.13.5, “Avoiding
double buffering” on page 81. A detailed explanation follows here.
DB2 table spaces can be configured with NO FILE SYSTEM CACHING, which in many cases
improves system performance. If a table space is specified as MANAGED BY SYSTEM, then
it uses SMS, which provides desirable special case handling for LOB data regarding caching.
Even if NO FILE SYSTEM CACHING is in effect (by default or as specified), access to LOB
data still uses the file system cache.
If a table space is MANAGED BY DATABASE, it uses Database Managed Storage (DMS),
which does not differentiate between LOB and non-LOB data regarding caching. In particular,
NO FILE SYSTEM CACHING means that LOB access reads and writes directly to disk.
Unconditionally reading LOBs from disk can cause high disk use and poor database
performance.
Since Version 9.1, DB2 has created, by default, databases that use automatic storage
(AUTOMATIC STORAGE YES). Creating databases by using automatic storage means that
the database that manages disk space allocates itself from one or more pools of available file
system space called storage paths. If automatic storage is enabled, CREATE TABLESPACE
uses it by default (MANAGED BY AUTOMATIC STORAGE). For non-temporary table spaces,
REGULAR and LARGE, automatic storage is implemented using DMS on files.
Before DB2 9.5, the default caching strategy for table spaces was FILE SYSTEM CACHING.
In version 9.5, this strategy was changed to NO FILE SYSTEM CACHING for platforms where
direct I/O or concurrent I/O is available. Taking defaults on version 9.5, we now have a
database with AUTOMATIC STORAGE YES, and a table space that is MANAGED BY
AUTOMATIC STORAGE, and in many cases, NO FILE SYSTEM CACHING. Such a table
space, which is implemented using DMS, does not cache LOBs in the buffer pool or the file
system.
84 IBM Business Process Manager V8.0 Performance Tuning and Best Practices