IDUG EMEA 2026

Switching on the AI Query Optimiser in Db2 v12 is straightforward, but what do you do after you have switched it on? How do you confirm that it is doing what you want? How do you limit its execution to focus on just the tables you need and want? How do you confirm that it is having a positive effect? How do you manage the resources that it uses?
This presentation recounts some of the tricks, pitfalls and gotchas encountered in actual customer implementations of the AI Query Optimiser.

Based on the VECTOR data type, that came with Db2 12.1, your data can easily be put in definnable context by using similarities. This can help identifying correlations where exact values would make it too complicated. As a relational model typically is based on direct comparability of values only, vector usage can provide some extra level of data linking. With an example shown in a live demo, this session will show step by step, how to implement vector usage in your data to provide additional analytical features.

In the world of Db2 for z/OS, SQL performance tuning is one of the most critical and often most complex of DBA tasks. While static SQL has long been the standing order for traditional mainframe applications, the growing use of dynamic SQL - driven by modern applications, APIs, and distributed workloads - has changed the tuning game.Dynamic SQL’s agility and flexibility introduces a new layer of complexity that can hinder performance if not well managed and cause inconsistent performance and even be unpredictable. Dynamic SQL is becoming more prevalent as agile development and hybrid workloads become the norm. But with the flexibility of dynamic SQL comes responsibility - DBAs must adapt and develop new ways of monitoring and tuning dynamic workloads in real-time and across the application lifecycle. Colin Oakhill will share a proven approach to bring order to chaos by giving DBAs the visibility, control, and insight they need to ensure that dynamic SQL performs efficiently and predic

OpenTelemetry is rapidly becoming the industry standard for application observability —offering a unified approach across distributed platforms. But did you know that even mainframe applications and subsystems can now be part of this modern observability ecosystem?
In this session, we’ll dive into what OpenTelemetry means from a Db2 for z/OS perspective. You’ll learn its core concepts, why they matter for mainframe environments, and how to take your first steps toward OpenTelemetry-based end-to-end monitoring of Db2 for z/OS applications with minimal effort. We’ll also highlight common pitfalls and explain why OpenTelemetry complements — rather than replaces — traditional Db2 monitoring.

Db2 for z/OS environments generate thousands of system messages and codes every day, only a small subset of which indicate truly critical conditions. This session focuses on how Db2 DBAs can effectively identify, interpret, and respond to critical events that threaten system availability, data integrity, resource consumption, and security. Starting from the structure and meaning of Db2 messages, reason codes, and return codes, the presentation walks through real-world scenarios such as log space exhaustion, storage shortages, dataset access failures, and recovery-related errors. Attendees will learn how to distinguish symptoms from root causes and how timely detection can prevent hangs, outages, and data loss. The session emphasizes a proactive monitoring and troubleshooting approach based on SYSLOG and Db2 address space analysis. It is aimed at Db2 DBAs who want to strengthen operational resilience, improve incident response, and consistently meet SLA and recovery objectives.

The Db2 family of products including Db2, Db2 Warehouse, and Db2 PureScale provide a number of important features for diagnosing and solving your SQL problems. Through a series of practical examples, this session will bring you up speed on the latest capabilities available for SQL diagnostics and show you how you can leverage them to solve query problems in your own environment. You will learn how to identify your most expensive SQL statements using the package cache table functions, and how to use Db2's "time spent" metrics to analyze where your problem queries are spending their time. You will also learn some new tips for monitoring sort memory metrics and query memory consumption in order to tune your analytic workloads. Finally you will learn how to use the runtime explain capabilities in conjunction with the activity event monitor to capture actual query plan cardinalities as well the per object metrics.

To the average application, a database is often treated as a "black box": SQL goes in, and data comes out. But for those tasked with maintaining high-performance systems, "it just works" isn't enough. When a query hangs or a system spikes in CPU, understanding the mechanics "under the hood" is the difference between a quick fix and hours of guesswork.

This presentation takes you on a chronological journey of a query’s lifecycle. We will trace the path of a single PreparedStatement from the moment it leaves a remote application, through the DRDA protocol, and deep into the Db2 engine layers. We will explore:
- The Handshake: How client-server interactions and the SQLDA manage data exchange.
- The Brain: Inside the Query Compiler and Optimizer—how your SQL is transformed into an executable "Plan."
- The Engine Room: How the Runtime components interact with the Buffer Pools, Prefetchers, and Logger to retrieve your data.
- The Return: The mechanics of the ResultSet and how data is effic

It often makes sense for analytical applications to store the data in column organized tables instead of row organized tables to get better performance. Especially scans on column organized tables are different from scans on row organized tables. This presentation investigates these differences. One major difference is the usage of Synopsis tables to speed up scans. Therefore, we will look in depth at how Synopsis tables work, how one can check Synopsis tables e.g., with SQL statements, and how one can ensure to get "good" Synopis tables, i.e., Synopsis tables which allow the elimination of unneccesary page accesses during the scans of important queries.

Db2 Distributed Data Facility (DDF) is the gateway to delivering business enterprise data in our modern world of cloud computing. DDF is widely exploited in the information technology space and this session aims to share best practices and success stories to optimize your business with DDF. Some of the topics includes, infrastructure, security, protecting data over the network, monitoring resources (threads/connections), sysplex workload balancing, and so forth. The objective of this session is provide you with practical, useful knowledge that you can take back to your work and manage DDF confidently.

With growing data volumes, mixed workloads, and strict SLAs, effective tuning demands a structured, end-to-end approach.
This session focuses on practical, real-world Db2 tuning techniques that deliver measurable performance improvements in production systems. Attendees will learn how to identify high-cost SQL using Db2 accounting and statistics data, analyse access paths with EXPLAIN, and apply targeted tuning at the SQL, object, and subsystem levels.
Topics include SQL and predicate optimization, index design best practices, EDM pool and sort tuning considerations, and understanding performance differences between static and dynamic SQL.
Participants will leave with actionable techniques they can immediately apply to improve response times and control Db2 CPU usage.

Index pages splitting is a normal DB2 process when inserting or updating rows into table. However, this process can consume CPU resources and generate latch contention especially in a Data Sharing environment. Index page splits in also the main cause of index disorganization. In this presentation we will see how to identify costly index page splits and reduce their frequency with the help of RTS history tables.