The Role of Db2 DBAs in Promoting zIIP Usage

 As most z/OS practitioners know, zIIP processors can provide significant benefits in terms of cost savings and improved performance. And one of the most significant areas for taking advantage of the benefits that zIIPs can provide is within Db2 for z/OS. As such, the role of Db2 DBAs in promoting zIIP usage can be critical.

It is important to note that not all features of Db2 for z/OS can run on zIIP processors, and that the extent to which a particular workload can be offloaded to zIIP processors depends on several factors, including the workload characteristics, system configuration, and the Db2 for z/OS version and licensing.

Of course, the first thing you need to be sure of is that the system is configured to utilize zIIPs. This means you must procure a license from IBM to use zIIPs. But you also need to ensure that you have configured your system appropriately for zIIPs, which is usually done by the system programming team. Configuration issues include:

• Ensuring that sufficient zIIP weight is defined for LPARs where Db2 for z/OS workloads run, and
  
  
• Using simultaneous multi-threading in the z/OS LPAR on z13 or later processors to increase zIIP capacity (when only one zIIP engine can be dedicated to the LPAR)

Once the system is properly configured, Db2 DBAs need to immerse themselves in understanding what type of workloads are zIIP-eligible. IBM documents the authorized zIIP uses for Db2 processing for each version of Db2 for z/OS. DBAs should bookmark this page (for Db2 13 for z/OS) and return to it for clarification as needed.

As a high-level guide, the following Db2 processing can run on zIIPs:

• Up to 100% of Db2 system agents processing running under enclave SRBs that execute in the MSTR, DBM1, and DDF address spaces are zIIP-eligible (except for P-lock negotiation). This includes things like buffer pool processing, log reading and writing, index pseudo-deletes and so on. In other words, things that Db2 will be doing as part of its general operation. These are not generally things that DBAs can influence or encourage much one way or the other, but can deliver benefits by offloading work from the general purpose CP to zIIPs.
  
  
• Up to 60% of distributed SQL that uses DRDA to access Db2 over TCP/IP and native REST calls over HTTP are zIIP-eligible. This can be a significant source for offloading work to zIIPs. DBAs can work with development teams to encourage the use of distributed SQL to further their organization’s usage of zIIPs.
  
  
• Up to 100% of parallel query child processes can be run on zIIPs, after you have reached a preset CPU threshold (which is defined by IBM for each specific model of IBM Z). DBAs can help to encourage parallelism, where appropriate, to further zIIP usage. This can be done by binding packages using DEGREE(ANY) or by setting CURRENT DEGREE to ANY. Furthermore, since parallelism can only be used by read-only queries, encourage developers to identify appropriate cursors as FOR READ ONLY.
  
  
• Up to 100% of XML processing for XML schema validation and non-validation parsing, as well as for the deletion of unneeded versions of XML documents. So, if you are using XML in your Db2 databases and applications, certain processing-intensive XML operations can be run on zIIPs.
  
  
• Many IBM Db2 utility processes are also zIIP-eligible. Up to 100% of the index maintenance tasks for LOAD, REORG, and REBUILD INDEX are zIIP-eligible. And up to 100% of the statistics-gathering portion of RUNSTATS is also zIIP-eligible. Planning and executing IBM Db2 utilities is something else that DBAs can do to encourage zIIPs usage. For example, encourage developers to use the LOAD utility instead of writing programs to load or bulk insert a lot of data whenever possible.
  
  
• And up to 100% of the SQL AI functions (SQL Data Insights) in Db2 13 for z/OS that is eligible to be run as a parallel query child process are zIIP-eligible. It is a bit more complex than that, because a portion of SQL statements that reference AI functions but are ineligible to be run as a parallel query child process may still be eligible if the SQL request is made through DRDA. Therefore, utilizing, where appropriate, the SQL Data Insights AI functions (AI_ANALOGY, AI_COMMONALITY, AI_SEMANTIC_CLUSTER, and AI_SIMILARITY) can help bolster the usage of zIIP processors.

I would be remiss if I did not mention that other ISVs offer Db2 utilities with varying degrees of zIIP eligibility; for example, BMC Software, Broadcom, and InfoTel. So, if you have Db2 utilities from vendors other than IBM, be sure to consult their documentation for details on their zIIP exploitation and proceed accordingly.

Furthermore, components of other types of system software may be zIIP-eligible, so be sure to investigate and document which products that you regularly use may be able to utilize zIIPs. For example, if you have heavy sorting requirements Precisely’s Syncsort MFSort can offload a good percentage of sort workload to zIIPs.

And do not forget about Java! Applications written in Java can be redirected to run on zIIPs. So, instead of writing a new application in COBOL (or another language that is not zIIP-eligible) consider using Java to create more zIIP eligible workloads. You might even take a look at where and when it makes sense to convert some existing workloads to run on a JVM to expand you zIIP usage.

On-going DBA zIIP Responsibilities

The DBA’s involvement with zIIPs does not end after workload has been made eligible. On-going activity is required to ensure effective zIIP usage. Db2 DBA must: 

• Monitor performance: Db2 DBAs should monitor system performance to ensure that zIIP processors are being used effectively. This involves tracking zIIP processor utilization, general-purpose CPU utilization, and overall system performance.
  
  
• Optimize performance: Furthermore, Db2 DBAs can help optimize performance by making changes to the system configuration or adjusting workload placement to improve zIIP processor utilization and overall system performance.

And finally, Db2 DBAs should take it upon themselves to educate other team members about zIIPs, their benefits, and how Db2 workloads can take advantage of zIIPs to reduce cost.

The Bottom Line

In summary, the role of a Db2 DBA in promoting zIIP usage involves identifying eligible workloads, ensuring the system is configured appropriately, monitoring performance, optimizing performance, and educating other team members on the benefits of zIIP processors. It can also include encouraging zIIP usage by educating and training developers on what types of processes are zIIP eligible. By promoting zIIP usage, a Db2 DBA can help improve system performance, reduce costs, and improve overall efficiency on IBM Z mainframes.

 

Db2 13 for z/OS Brings Precision with Statement-Level Invalidation

In the ongoing evolution of Db2 for z/OS, each new release brings capabilities that aim to improve efficiency, reduce overhead, and increase system availability. Db2 13 for z/OS continues this trend with a subtle but powerful enhancement: statement-level invalidation. It’s a change that may not grab headlines, but for DBAs and performance tuners, it’s a game-changer.

The Problem with Broad-Stroke Invalidation

Traditionally, when an object such as a table or index was altered, Db2 would invalidate entire packages. This broad-brush approach meant that even if only a single SQL statement within a package was impacted by the change, the entire package would be invalidated and require a rebind. In systems with large, complex applications and tightly integrated SQL packages, this could lead to unnecessary overhead, longer recovery windows, and potential disruptions during rebind processing.

This was particularly problematic in high-availability environments or continuous delivery models, where minimizing disruption is paramount.

Enter Statement-Level Invalidation

Db2 13 introduces a more precise approach. Rather than invalidating an entire package, Db2 can now invalidate only the specific SQL statements within the package that are impacted by a DDL change. The rest of the package remains intact and executable.

This capability is part of a broader initiative within Db2 to support more granular control and management of SQL execution, ultimately enabling more resilient applications.

Here’s how it works:

• When a DDL operation is performed (say, altering a column’s data type or dropping an index), Db2 analyzes which SQL statements are affected.
• Only those specific statements are marked as invalid.
• When the package is next executed, only the invalidated statements will trigger automatic rebinds (or failures, depending on your setup).
• The unaffected statements remain executable without interruption.

This shift significantly reduces the scope and impact of invalidation events, particularly for applications with large packages that include a variety of different SQL access paths.

Why It Matters

From a DBA's perspective, this change brings several key advantages:

1. Reduced Outages: Applications are less likely to experience failures due to widespread invalidation. If only one statement is invalid, the rest of the application can continue running.
2. Improved Performance Management: It’s easier to isolate performance impacts and address only the affected statements.
3. Smarter Rebind Strategy: With only the necessary statements marked invalid, DBAs can delay or prioritize rebinds more strategically.
4. Support for Continuous Delivery: Statement-level invalidation supports the DevOps and agile models that many enterprises are moving toward, where small, frequent changes are the norm.

Important Considerations

While this enhancement is a welcome one, it’s important to note that it is only available in Db2 13, with Function Level 500 (V13R1M500). Make sure your system is properly configured to take advantage of this behavior.

Additionally, the ability to diagnose which statements have been invalidated requires careful monitoring. Dynamic tracing (e.g., IFCIDs) can help track and respond to invalidation events.

A good tracing setup to consider would include starting the following IFCIDs:

• IFCID 217 to detect the triggering DDL.
• IFCID 316 to see which package or specific statement was invalidated.
• IFCID 31 and 22 to trace follow-up activity (rebinds or PREPAREs).

Also, it is worthwhile to note that application developers and DBAs should continue to coordinate DDL changes carefully, even with this added capability.

Final Thoughts

Statement-level invalidation might sound like a small tweak under the hood, but in practice, it represents a significant leap toward more granular, less disruptive database management. For organizations running mission-critical workloads on Db2 for z/OS, this enhancement helps pave the way toward more agile operations without sacrificing stability.

As always, staying on top of these kinds of changes is part of the evolving role of the modern DBA. And in the world of Db2 for z/OS, precision matters—especially when it comes to maintaining performance and availability.