Guest post by Jim Kurtz, Advisory Software Consultant

Db2 10 for z/OS yields out-of-the-box Db2 CPU savings of up to 10 percent for traditional workloads when compared to running the same workloads on Db2 9. That’s attention-getting, and it’s possible without a REBIND.  But to obtain the best performance and memory improvements, it will be necessary to REBIND all PACKAGEs containing static SQL – an idea that may cause fear and angst to most DBAs.

To understand why, let’s review. For static SQL, it’s during the BIND/REBIND process that the Db2 optimizer determines the optimal access path to the data for each SQL statement using various inputs such as the SQL statement text, the schema definition, and the current object statistics from the Db2 catalog. The run-time performance of an SQL statement is directly related to the path the optimizer chooses at BIND/REBIND time. As long as a statement is performing well, especially in production, DBAs hesitate to REBIND unless they absolutely must (for example, the PACKAGE is marked as invalid or inoperative) for fear the Db2 optimizer will choose a less efficient, poorer performing access path.

Is REBIND Required for Migration?

REBIND isn’t required for migration to Db2 10, but it’s strongly recommended to achieve the significant performance improvements. However, all PLANs containing DBRMs and all PACKAGEs that were last bound on Db2 V5 or lower must be rebound. So, as Roger Miller said in a recent IDUG Solutions Journal article, “Please be kind and REBIND.”

Wouldn’t it be nice to know before you migrate to Db2 10 what access path changes to expect? This post discusses a process (homegrown or vendor-purchased) that can analyze and identify access path changes between two Db2 subsystems, one at Db2 9 and one at Db2 10, before migrating. Your actual “code” for this process will vary, but here are the basic steps.

Using the PLAN_TABLE and DSN_DETCOST_TABLE

This process relies on data that’s externalized to the userid.PLAN_TABLE and the userid.DSN_DETCOST_TABLE when executing a BIND/REBIND…EXPLAIN(YES) command. It presumes baseline information exists in those tables in the Db2 9 subsystem for the desired PACKAGE. In most shops, this is a byproduct of the standard for production migrations.

1. In the Db2 10 subsystem, create the Db2 objects associated with the PACKAGE exactly the same way as they’re created in the Db2 9 subsystem but with DEFINE NO on the CREATE TABLESPACE and CREATE INDEX statements.
2. In the Db2 10 subsystem, create a userid.PLAN_TABLE* and a userid.DSN_DETCOST_TABLE* if they don’t already exist.
3. In the Db2 9 subsystem, create a userid.PLAN_TABLE_V10* and a userid.DSN_DETCOST_TABLE_V10* (using the DB210 format).
4. For the objects created in step 1, copy all Db2 catalog statistics associated with access path selection from the Db2 9 subsystem to the Db2 10 subsystem. In Db2 9 and 10, there are 17 Db2 catalog tables containing user-updateable columns that the Db2 optimizer uses for access path determination. Be sure to get them all or it may skew what the optimizer chooses for an access path in the Db2 10 subsystem.
5. In the Db2 10 subsystem, BIND the PACKAGE with EXPLAIN(YES) and OWNER(userid) to externalize access path information to the userid.PLAN_TABLE and userid.DSN_DETCOST_TABLE.
6. In the Db2 10 subsystem, unload the data from the userid.PLAN_TABLE and userid.DSN_DETCOST_TABLE.
7. In the Db2 9 subsystem, load the data from step 6 into the userid.PLAN_TABLE_V10 and userid.DSN_DETCOST_TABLE_V10.
8. In the Db2 9 subsystem, run a query that will combine the data from the Db2 9 and Db2 10 tables in a way that visually “stacks” the Db2 9 results over the Db2 10 results while grouping it by QUERYNO, QBLOCKNO, and PLANNO.

* For steps 2 and 3, the Db2 10 format for these tables is slightly different from the Db2 9 format:

• userid.PLAN_TABLE: 59 columns in Db2 9, 64 columns in Db2 10
• userid.DSN_DETCOST_TABLE: 118 columns in Db2 9, 129 columns in Db2 10

Next week, we’ll look at the results of the query and an easier way to compare access paths.

The postings in this blog are my own and don’t necessarily represent BMC’s opinion or position.

Db2 for z/OS and vendor products collect and report on several buffer pool characteristics. Db2 statistics (SMF 100 records) and accounting (SMF 101) records can provide buffer pool performance information at the subsystem and thread level. Db2 can externalize multiple IFCIDs (198, 199, 201, and 202) with detailed buffer pools and object information.

Focus on the following metrics when looking at buffer pool performance; they will give you a good idea of overall buffer pool health:

• GETPAGE rate – The average number of GETPAGE requests per second over time. You can instantly compare the relative amount of work supported by each buffer pool. This is a good indicator of overall workload through the buffer pool. It’s also a great metric to review at the Db2 subsystem level.
• Page arrival rate – The average number of pages read into the buffer pool per second. This quickly identifies the buffer pools and objects that are driving your I/O subsystem. This is also a great metric for the entire Db2 subsystem.
• Buffer pool hit ratio (ratio of GETPAGEs resolved without read I/Os / total GETPAGEs) – This value measures overall buffer pool efficiency. Your goal is to have as high a number as possible. Generally, a lower value indicates a need for a larger buffer pool. However, if you have very large objects in the pool that are accessed randomly, then you may always have a smaller hit ratio. In this case, consider lowering the size of the pool. If the pool is page fixed, expect to see a number approaching 100%.
• Page updates per write – The average number of synchronous page updates for each system page written over the length of the interval. This indicates how well the pool size and deferred write thresholds enable repeated updates to the same page to occur before the page is written.
• Pages written per write I/O – The average number of pages written per write I/O over the length of the interval. For the most efficient use of the Db2 asynchronous write engines, the average pages per write should be as high as possible, but must be balanced against the amount of the pool tied up with updated (dirty) pages and the possibility of an undesirable spike in activity when checkpoints occur. Consider page updates per write and the deferred write threshold when reviewing this metric. The goal is to set the deferred write threshold and the vertical deferred write threshold at a level that gets the best possible updates per page write and pages per write I/O ratio.

In addition to these watching these metrics, it’s important to monitor adverse events occurring in the Db2 subsystem, including

• GETPAGE failures due to no available buffers
• GETPAGE failures due to DBM1 virtual storage shortage
• Write I/Os delayed because all 300 write engines are busy
• Data Manager Critical Threshold reached
• Prefetch disabled due to buffer shortage
• Prefetch disabled due to prefetch limit
• Parallel prefetch requests denied due to buffer shortage
• Parallel groups not started due to buffer shortage
• Parallel prefetch requests halved due to buffer shortage
• Parallel prefetch requests quartered due to buffer shortage
• Sort work files exceeded the sequential buffer limit
• Sort-merge passes degraded due to wk file/sequential limit

Buffer Pool Performance Tuning Tools

Buffer pool performance management can be a challenge, but tools are available to help you. These tools fall into two groups: general purpose monitors and buffer pool tools. (BMC System Performance for Db2 provides both types of tools.)

Db2 performance monitors monitor buffer pools in real time and may provide near and long-term historical reporting capabilities. Monitors report Db2 accounting and statistics data about buffer pool performance. Monitors can capture many adverse events, and you can use automation capabilities to respond to these problems. Detailed analysis of buffer pool configurations is typically not provided. Depending on your environment, this may be the only type of Db2 buffer pool monitoring tool you need.

For other Db2 environments, “deep-dive” products provide extensive monitoring and analysis. These tools collect and report on real-time performance metrics and maintain detailed historical performance data that can provide long term analysis of buffer pool performance to help you identify and respond to negative trends. These tools also recommend buffer pool configuration changes including number and size of pools, thresholds, and Db2 object placement.

Guest post by Lynn Gros, Lead Quality Assurance Representative

Second in a series of posts.

Last week, we reviewed some buffer pool basics. This week, we’ll discuss how to configure buffer pools for optimal performance.

Most Db2 users revisit buffer pool sizing and thresholds over time to make sure they meet performance goals. The IBM Db2 on z/OS Installation Guide provides information on initial sizing for Db2 buffer pools, and it is often the best place to start for new applications or subsystems. Once applications are in test or production, you can collect metrics that may lead you to consider changes to the buffer pool configuration.
General considerations
Use the simplest approach that effectively meets performance requirements. Your major task is determining Db2 object placement in the various pools. This effort will lead to the physical characteristics of the buffer pool configuration for your Db2 subsystem.

A good starting point is to consider the various Db2 object types you deal with on a day-to-day basis, including:

• System – Db2 catalog and directory objects (DSNDB01 and DSNDB06)
• Work – Storage used for temporary files and tables required for a multiple Db2 functions, including global temporary tables, Db2 sort work files, and other functions. Because these pagesets tend have high I/O volumes, consider page fixing for these pools. Db2 9 merges the WORKFILE and TEMP databases from Db2 V8 into a single WORKFILE database. Work file enhancements in Db2 10 reduce the CPU time for workloads that execute queries that require the use of small work files, and improve scalability.  Db2 10 supports partition-by-growth table spaces in the WORKFILE database, and it provides more opportunity to use in-memory work files than Db2 9.
• Large objects – LOB/XML structures.

• LOBs should not share a buffer pool with other kinds of data. Set the DWQT (deferred write threshold) to 0 for these objects. This allows updates to happen continuously (trickle writes) in the background to avoid massive writes at Db2 checkpoints.
• XML table spaces use uses 16K buffer pools. Place these objects in dedicated pools. Use a buffer pool other than BP16K0.
• Application table spaces and index spaces

Place WORKFILE and TEMP database objects in dedicated buffer pools. Typically, workfile pagesets are accessed sequentially and are short-lived objects. Db2 9 will try to make greater use of 32K workfile table spaces, so increase the size of the 32K buffer pool used for the WORKFILE database and increase the number of 32K page workfile data sets.

It is important to understand Db2 application object characteristics when deciding on buffer pool placement. Grouping objects with similar characteristics into the same buffer pool can be a good approach to meet your performance objectives. Consider these characteristics:

• Business priority – Perhaps the most important information you need is how critical the application is to your business. Consider placing critical application objects that require maximum performance into dedicated buffer pools to avoid resource contention with less-important application objects.
• Random or sequential access – Is the predominant level of GETPAGE activity random or sequential? Place objects that are accessed sequentially most often in a pool with a higher VPSEQT value; place objects with mostly random access in a pool with a lower VPSEQT value. If the accesses are split evenly between random and sequential, use the default values as a starting point;
• Activity against this object – How busy is this object? Activity is measured in GETPAGEs per second against the object. A very busy object might cause buffer pool pages to be stolen from another object that is not as busy but more important to the business.
• Update frequency – What is the update rate for the object? Is this a heavily updated Db2 page set? In general, table spaces and index spaces that are frequently updated should be separated from infrequently updated objects to allow optimum buffer pool sizing and thresholds.
• Object size – How big is this Db2 object in pages? If the object is very large and the access is very random, the chances of reusing a page that’s already in the pool will be minimal, so having a very large pool for the very large object may provide no benefit to application performance.

It can be difficult to collect many of these characteristics, especially for a new application. Use an educated guess as a starting point. In test environments, use an isolated set of buffer pools as you begin testing a new application or one that is undergoing major changes. This will give you more complete control of the testing environment where you can monitor buffer pool performance more easily.

Db2 application objects are a much more complex consideration, but here are some general guidelines:

• Don’t place application objects in BP0, BP8K0, BP16K0 or BP32K. Db2 catalog and directory objects are placed these pools. Set default buffer pools by modifying these values on the DSNTIP1 installation panel. It’s a good idea to specify an explicit buffer pool assignment for your objects; however, if you are allowing implicit object creation, you can’t directly specify what pools to use. Changing the installation defaults for user data and indexes will help enforce your strategy for object placement.
• Assign indexes to different buffer pools than table spaces for concurrency and long residency times. Indexes are typically accessed differently from the tables they index – and with greater frequency. The number of buffers required for average working set size of an index space is usually smaller than its corresponding table space/tables, and you want to ensure buffer pages used by index pages remain resident and not get flushed during heavy table space scan activity. Like table spaces, separate frequently updated indexes from infrequently updated indexes to allow optimum buffer pool sizing and thresholds.

Next week, we’ll look at metrics.

The postings in this blog are my own and don’t necessarily represent BMC’s opinion or position.