IDUG EMEA 2026

This session is a deep dive into 3 new Db2 12.1 security features, Reduce file permissions, RCAC mask at read enhancements, and defining a Trusted Context using the new trust procedure and client callbacks. This will be a face paced session offering practical details on how to make use of these new features in more depth than a what's new session can cover. Reduced file permissions address the common concern of everyone having access to the db2diag.log (and others). Mask at read offers an alternative masking behaviour with fundamental changes to SQL behaviour. And Trust Procedures allow custom definitions of trust for determining a trusted connection.

When using Q-replication in evironments with different Db2 HA configuraions like HADR and pureScale and even single server Db2 installations or Db2 z/Os all together, configuration of Q-replication can become quite complex, especially on pureScale when trying to integrate the capture and apply programs into the resource model.
In this presentraion we will go through a different approach and build a seperate HA cluster for the Q-replication environment. This approach simplifies the setup of Q-replicatation and makes the target and source Db2 environment trasnparent to the replication environment, and it works with all possible Db2 setups.
And the best part, if you use Q-replication and Db2 LUW, you already have all the needed parts for this setup.

Since Db2 12.1, the Db2 AI Query Optimizer has been improving the quality of your query access plans through improved cardinality estimates. This was super-charged in 12.1 mod3 when it was enhanced to support pair-wise join cardinality estimates. Participants will learn how this technology reduces tuning efforts so you can confidently use it in production. You may also get a glimpse into what's in store for the future.

It is the classic DBA dilemma: the statistics are current, the access plan looks "clean" at first glance, yet the application is dragging. When the low-hanging fruit has been picked, how do you move from intuition to evidence-based troubleshooting?
This session follows a real-world "detective story" of a slow-running SQL statement originating from a Java (JDBC) application. We will move beyond basic EXPLAIN facility outputs to uncover the hidden bottlenecks that standard tools often miss. Using a step-by-step methodology, we will demonstrate how to:
- Capture the invisible: Isolate specific statements from the Package Cache and extract elusive parameter marker values.
- Leverage MON_GET: Use light-weight monitoring interfaces to identify where time is actually being spent (CPU vs. Wait times).
- Analyze the "Why": Utilize Activity Event Monitors and Section Actuals to compare estimated vs. actual cardinalities within a live execution.
- Apply Surgical Fixes: Explore advanced remediatio

Universal Tablespaces (UTS) have been the strategic tablespace types for Db2 for z/OS since Version 9, effectively rendering legacy tablespaces obsolete. But what truly lies beneath the surface? Why has IBM designated UTS as the future of data storage?
In this session, we will place the Universal Tablespace on the operating table for a surgical comparison against legacy objects. We will examine the internal anatomy of Partition-by-Growth (PBG) and Partition-by-Range (PBR) tablespaces. By dissecting the underlying page structures, space map management, and segmentation logic, we will reveal exactly what makes UTS special.
Join us for a deep dive into the bits and bytes of Db2 storage to understand why the transition to UTS is not just a recommendation, but a necessity for modern database performance and management.

If multiple statements can be combined into a single one it will be more efficient.
In this session we will explore multiple options to combine different SQL statements. Have you ever used the FINAL TABLE clause or selected the data you just deleted? Besides this the main focus is on the MERGE stamement which is probably the most powerful SQL operation which offers a lot of processing options and can even be used in ETL architectures and with temporal tables. Practical use case will be shown and explained.

A critical Db2 for z/OS purge batch is repeatedly abending after hitting CPU limits—without deleting a single row. What followed was a six-month troubleshooting marathon. With the batch spending over 80% of its time in I/O wait and racking up 500 million GETPAGEs on a 2-million-row table, standard tuning simply wasn't enough.This session dives into the gritty reality of complex performance tuning: the dead ends, the false starts, and the eventual breakthroughs. We will walk through the entire investigation—from utilizing monitoring tools to experimenting with UTS conversions and dedicated buffer pools. Finally, we’ll reveal how rethinking our DELETE index strategy, host variables, and leveraging ON DELETE CASCADE NOT ENFORCED transformed a CPU-crushing failure into a consistent, 20-minute purge process. Attendees will leave with a practical, battle-tested methodology for rescuing failing batch processes.

Are you, and all of your sub-systems, ready for Db2 vNext that is coming to an enterprise near you soon? Are you aware that you cannot even get to Db2 13 FL511 if you have any of the specially announced “deprecated” items that we all have hanging around? Do you have a plan to get you out of this mess?
This session explains how you can find all the migration blockers that exist in your system and how to fix nearly all of them as well. It will also delve into VTAM/SNA and workfile usage to round off everything that can bite you!

Db2 utilities are fundamental to database availability, performance, and recoverability—yet many sites treat them as black boxes.
This session explores the internal behaviour of key Db2 z/OS utilities such as REORG, RUNSTATS, COPY, and LOAD. We examine how these utilities interact with data, logging, locking, and system resources, and how understanding their internals helps DBAs run them more efficiently and safely.

Description:
How Db2 utilities really run
How Db2 utilities use buffer pools, logging, IRLM, and the catalogWhy utilities should be treated like normal Db2 work, not background jobs
REORG utility explained
What happens during each REORG phase: unload, sort, reload, rebuild, and switchHow REORG affects locking and loggingWhen REORG improves performance and when it provides little or no benefit
RUNSTATS and the optimizer
Difference between table statistics and index statisticsHow histograms and sampling influence query plansWhy the timing of RUNSTATS matters for access pa

The presentation is based on real life BPool tuning process for one of the Ensono clients. The "reverse application analysis" reveals the opportunities the IFCID(199) usage gives to every Db2 SYSPROG.
The standard Ensono BPool tuning process presented with a multiple charts.It also was enhanced with IFCID(199) implementation, giving amaizing results.
How to use IFCID(199), different characteristics SYNC I/O, ASYNCH I/O, GetPages can be involved into the the analysis uncovering the hidden performance bugs.