Download PDF - IBM Redbooks

The usage of some z196 features requires a minimum level of z/OS. For information about
using the zEnterprise features and required software levels, see IBM zEnterprise System
Technical Introduction, SG24-7832.
3.1.3 Virtual storage constraint relief for DB2 10: Larger number of threads
A critical issue especially for large SAP installations in the past was the constraint on DBM1
storage below the bar (2 GB). Because each DB2 thread had a certain memory footprint in
the DBM1 access space, this limit put a severe constraint on the number of acceptable SAP
work processes per DB2 subsystem. This memory footprint is not static, but varies depending
on the work done by the individual thread. In addition, in recent times, SAP applications tend
to do more work asynchronously to the main thread so that they do not interfere with the
application logical unit of work (LUW). As a consequence, SAP work processes open
potentially several database connections, not just one of them.
In effect, this issue required customers to closely monitor the actual DBM1 storage
consumption and carefully assess the effects of changes in the application workload. Often,
customers needed to go for n-way data sharing to map their SAP workload to enough
database threads.
DB2 10 places many data structures (such as the complete EDM POOL and thread working
memory) above the bar, allowing for a massive scale-out of a single DB2 10 subsystem with
SAP solutions. The result is less need to closely monitor DBM1 storage consumption. The
result is also a large potential for DB2 member or logical partition (LPAR) consolidation,
leading to less resource consumption and administration overhead.
This feature alone is a significant contribution to total cost of ownership (TCO) reduction,
especially for large SAP installations. It is already available in DB2 10 conversion mode.
When planning to optimize the data sharing topology with DB2 10, in addition to the general
TCO savings resulting from administering fewer DB2 members, fewer members can lead to
needing fewer z/OS LPARs. In addition, if the members run similar workloads, less real storage
for DB2 buffer pools is needed. Alternatively, with fewer DB2 members, the downtime of a single
member can have a larger impact. First, the remaining members must handle the additional
workload. Then, in a configuration with two DB2 members, if a member is stopped for
maintenance, the remaining member is a single point of failure (SPOF). Overall, ensure that the
performance of the remaining member does not degrade from effects, such as DB2 log and
latch contention issues. This section continues by explaining efforts to tackle these issues.
For a comparison of the virtual storage consumption of DB2 9 and DB2 10 for the same
workload, see the white paper DB2 10 for z/OS with SAP on IBM System z Performance
Report at:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101845
Savings of up to 93% in storage consumption can be achieved. Also, over 2,500 threads can
be open at the same time.
MAXKEEPD parameter: Due to this memory constraint relief, the SAP recommendation for
the MAXKEEPD parameter has changed from = 12000. The MAXKEEPD
parameter controls the number of statements in the thread local statement cache. Because
the number of statements has been moved above the bar, no heavy restriction is on the
storage that is used. Customers can now optimize the local cache hit ratio without
compromising the maximum number of DB2 threads. Increasing the local statement cache hit
ratio avoids implicit prepare statements, increasing throughput and minimizing response time.
Chapter 3. Features of DB2 10 and the zEnterprise System as applied to SAP 31