DB2 10 – Secrets of Scalability
Storage constraints remain the single biggest factor in limiting the scalability of a single DB2 system today. Each process that runs concurrently within that system requires some storage, so the more workload a given system is asked to handle, the higher the storage requirements. Other factors such as logging and internal latching also play a part in limiting the scalability of a single DB2 system, and as bottlenecks are removed elsewhere these become increasingly important.
DB2 10 for z/OS delivers significant new functionality in all of these areas, allowing customers to scale up the workload that can be handled in a given DB2 subsystem with the associated performance and productivity benefits.
Virtual Storage Enhancements
In DB2 Version 8, IBM embarked upon a major project to transform DB2 into a 64-bit RDBMS, laying the foundations that would allow it to remove many of the addressability issues inherent in the previous 31-bit memory model.
The move to a 64-bit memory model in DB2 V8 allowed IBM to move several key DBM1 storage areas above the 2GB “bar” into the newly-addressable memory space, relieving some of the storage constraints and allowing more workload per DB2 subsystem. This provided some benefits, but a large amount of the thread-related storage remained below the 2GB bar.
DB2 9 increased scalability by a further 10-15% by moving another set of storage areas above the bar, but even with those enhancements most customers have been limited to running a maximum of 300-500 concurrent active connections within each DB2 system.
In DB2 10, IBM has completed the bulk of the remaining work in the 64-bit migration effort, with 80-90% of the remaining DB2 storage structures moving above the bar in the DBM1 address space. This has enabled a spectacular increase in the number of threads that can be supported by a single subsystem – most customers will be able to achieve 5-10 times the number of concurrent connections compared to DB2 9.
Prior to DB2 10, it was not uncommon for DB2 data sharing customers to have to run multiple DB2 subsystems per LPAR in order to support the required workload. A typical example is shown in the diagram below, where a DB2 subsystem is needed to support each SAP application server due to DBM1 virtual storage constraints.
With the increased headroom available in DB2 10, this customer can consider removing the additional DB2 subsystems, and consolidating the workload so that just one DB2 system per LPAR is used.
This subsystem consolidation approach has a number of potential benefits, including:
• Lower data sharing overhead
• Less systems to manage/maintain (although a minimum of four members is still recommended for true continuous availability)
The removal of DBM1 virtual storage constraints also allows a number of other important configuration changes to be made, including:
• More space for performance critical storage objects such as dynamic statement cache
• Potential to reduce legacy OLTP CPU cost through:
– More use of CICS protected entry threads
– More use of RELEASE (DEALLOCATE) with persistent threads (with a trade-off on concurrency)