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.

AI agents are transforming enterprise applications, but they need access to trusted, business-critical mainframe data. This session shows how MCP servers enable agents to query up-to-date, replicated Db2 z/OS data from targets like Db2 LUW or watsonx.data. It covers the rationale for agent integration, architecture patterns, implementation steps, and a live demo of an agent working with z/OS data.

Data lakes have become a foundational component of modern data platforms, enabling organizations to store and process large volumes of structured, semi-structured, and unstructured data with high scalability and flexibility.
For data architects and database administrators, the challenge lies not only in designing a robust data lake architecture but also in ensuring consistent performance, governance, and operational reliability across diverse workloads.
A well-designed data lake architecture typically follows a layered approach, incorporating ingestion, storage, processing, metadata management, and access layers.
Data is ingested through batch processing and streaming pipelines into cost-effective, distributed storage systems, based on object storage.
Processing frameworks support transformation and enrichment, while metadata and catalog services provide schema management, lineage, and discoverability. Increasingly, modern architectures adopt lakehouse patterns to bridge the gap betwe

Enterprise database migrations are often slowed to a crawl by their reliance on flat files. Large volumes of data must be written to disk, moved across networks, and reloaded using traditional utilities—a process that is time‑consuming, storage‑intensive, and error-prone. In migrating a legacy Oracle environment on AWS RDS to a modern, containerized Db2 platform running on OpenShift, it became clear that a fundamentally different approach was needed—one that removes the disk from the equation altogether.
This session presents a high‑performance, zero‑disk migration approach that streams data directly from the Oracle source into Db2. It walks through how to set up Db2 Federation and automate nickname creation to establish a direct data pipeline. Rather than relying on conventional SQL processing, the approach feeds a federated cursor straight into the Db2 LOAD mechanism, allowing data to be written directly into target tables with maximum efficiency.
To make this solution practical at

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.