Download PDF (1.3 MB) - IBM Redbooks

4.13.5 Avoiding double buffering
Because the database attempts to keep frequently accessed data in memory, in most cases,
using file system caching offers no benefit. However, performance typically improves by using
direct I/O, when files read by the database bypass the file system cache and only one copy of
the data is held in memory. By using direct I/O, the system can allocate more memory to the
database and avoid resource usage in the file system as it manages its cache.
A further advantage can be gained on some operating systems, such as AIX, by using
concurrent I/O. Using concurrent I/O bypasses per-file locking, shifting responsibility for
concurrency control to the database and, in some cases, offering the possibility of more
useful work to the adapter or the device.
An important exception to this guideline occurs for large objects (LOB, BLOB, CLOB, and
others) that are not buffered by the database itself. In this case, a possible advantage is to
arrange for file system caching, preferably only for files that back large objects.
4.13.6 Refining table indexes as required
Business Process Manager products typically provide a reasonable set of indexes for the
database tables they use. In general, creating indexes involves a tradeoff between the cost of
queries and the cost of statements which insert, update, or delete data. For query-intensive
workloads, providing a rich variety of indexes as required to allow rapid access to data makes
sense. For update-intensive workloads, a helpful approach is to minimize the number of
indexes defined, because each row modification might require changes to multiple indexes.
Indexes are kept current even when they are infrequently used.
Index design therefore involves compromises. The default set of indexes might not be optimal
for the database traffic generated by a Business Process Manager product in a specific
situation. If database processor or disk use is high or there are concerns with database
response time, it might be helpful to consider changes to the indexes.
DB2 and Oracle databases provide assistance in this area by analyzing indexes in the context
of a given workload. These databases offer suggestions to add, modify, or remove indexes.
One caveat is that if the workload does not capture all relevant database activity, a necessary
index might appear unused, leading to a suggestion that it be dropped. If the index is not
present, future database activity can suffer as a result.
4.13.7 Archiving completed process instances
Over time, completed process instances accumulate in the database of the servers. This
accumulation can alter the performance characteristics of the solution being measured. It is
helpful to archive completed process instances to ensure that the database size is controlled.
If you do not archive completed process instances and Performance Data Warehouse events,
they grow unbounded over time, which impacts overall system performance.
One symptom of this problem is long query times on Business Process Definition (BPD) and
TASK tables. Another symptom is that your process server database tables occupy too much
disk space. Both of these symptoms occur because completed BPD instances are not
deleted from the system automatically. After a BPD instance is completed, the instance is
typically no longer needed and therefore can be removed from the Process Server database.
Business Process Manager provides a stored procedure, LSW_BPD_INSTANCE_DELETE,
which you can use to delete old instances. Archiving procedures are in the following technote:
http://www.ibm.com/support/docview.wss?uid=swg21439859
Chapter 4. Performance tuning and configuration 81