IDUG EMEA 2026

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.

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

Db2 LUW provides the capability to create partitioned tables which have a number of useful benefits. However, a current downside to the implementation on LUW is that there is no automatic built-in functionality to add partitions when needed or manage the process of adding, detaching and deleting partitions. In particular, for Production environments that require stability and availability without interruption, robust and auditable management of partitions is a critical and invaluable requirement.
In this session I will provide an overview of the design and implementation of a bespoke Unix based solution used in a high volume 24/7 transactional and warehouse database application. The presentation will include an explanation of the requirements to manage table partitions in a Production environment and will include high level diagrams of the process flow to manage the partitions; the logic to identify required partitions/timestamps to manipulate, the required commands to make changes,

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.