Triton Db2 Geek

Confessions of a DB2 geek

IBM Gold Consultant Program and IBM Premier business Partner

DB2 10 – Secrets of Scalability

December 16th, 2011 - by

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)

Download the full paper



  • Hugh Lapham says:

    The full paper link in “DB2 10 – Secrets of Scalability” returns a 404 — is it still available? We’re running 20+ DB2 subsystems on a single LPAR to support multiple environments for multiple projects (all SAP) and I’m trying to figure out if there’s a way to improve performance (other than simply throwing iron at it).

    Thanks, Hugh.

  • Julian Stuhler Julian Stuhler says:

    Hello Hugh. Apologies for the broken link, I’ll get someone to take a look at this and fix it ASAP so you can download the paper.

    In the meantime, there are likely to be plenty of things you can do in an SAP environment if CPU constraints are the primary issue. I’ve just seen your related posting on DB2-L, so I’ll post a reply there.

  • Laura Hood Laura Hood says:

    Apologies, the link is now functioning.

« »

Tag Archives