IDUG EMEA 2024

Cloud Pak for Data, we've all heard of it before, but what can it do? Which components are inside of this offering and why would we combine this with Db2? This presentation present some key takeaways on the IBM Data Fabric solution and zooms in on its functional and technical architecture.
First, the presentation will explain how the Cloud Pak sits within a typical data architecture, with special attention to the uses cases of Db2 Warehouse en Watsonx.data. Next, we will discuss the main components and how they differ from their non-Cloud Pak counterparts. Finally, we discuss the deployment and licensing on different platforms.

Join us for an insightful session at IDUG EMEA 2024, where we delve into real-world user experiences with Db2 Analytics Accelerator. In this session, we'll provide an in-depth exploration of Garanti BBVA's implementation of Db2 Analytics Accelerator & Integrated Synchronization, highlighting the challenges encountered, strategies employed, and the outcomes achieved. Learn how we seamlessly integrated IDAA with our existing Db2 for z/OS environment, unlocking unprecedented performance improvements and accelerating our analytical processes.
Speakers, Tugce from Garanti BBVA & Cuneyt from IBM Germany R&D Lab, will guide you through a comprehensive exploration of the following objectives.
By attending this break-out session, participants will gain technical experiences of IDAA and Integrated Synchronization operation from the user perspective.

In today's modern applications, workload is increasingly shifting from traditional CICS or IMS transactions to Java workload. As a result, analyzing dynamic queries has become more important than ever before. 
In this presentation, I will demonstrate how to systematically analyze dynamic queries using the Global Dynamic Statement Cache, and how to identify queries that require immediate attention. We will develop a tool that allows SQL developers to analyze dynamic queries in their shop from day one after the conference. This tool is designed to be easily accessible and user-friendly, without requiring access to the mainframe. With it, developers can answer typical questions such as "Which queries performed better or worse within the last 30 days?", "Which of my queries were running at a given time and how did they perform?", and "Which of my queries are getting slower over time?" in a self-service mode. Additionally, we will explore how to translate query tuning results to cash savings, demonstrating the financial benefits of query optimization. By the end of this presentation, you will have a clear understanding of how to uncover and monetize hidden insights by analyzing the Global Dynamic Statement Cache.

Db2 13 for z/OS GA and CD offer many features useful for both application developers and database administrators. Some of the new functionalities include concurrency handling between application threads, controlling resource utilization duration to optimize for successful database object’s online schema change, and reducing the possibility of transaction failure after an online schema change. They are all useful enhancements which have been adopted by several Db2 users. Come and learn details of these features and why they are important to UBS during both the sponsor user process and after migration.

This presentation deals with the complicated migration of a decades-old COBOL application from an IBM mainframe with focus on migration journey from Db2 for z/OS to a distributed environment with Db2 LUW on Power Linux. With almost 12 million customers, the Polish banking institution faced the challenge of adapting to a new DBMS while transitioning to the distributed infrastructure. The focus lies on database layer monitoring, encompassing high-level performance monitoring and hardware capacity planning for the distributed architecture. Extensive testing and benchmarking, crucial for mitigating the inherent risks of migrating a 30TB+ database, are highlighted. Through this migration story, participants gain insights into complex, multi-level database monitoring and benchmarking, comparing DB2 Z/OS with DB2 LUW to assess needs for the new distributed environment. The second part shifts focus to theoretical aspects of complex DB2 monitoring, exploring the architecture behind state-of-the-art monitoring systems and strategies for implementation at scale to derive valuable insights. This presentation offers a blend of practical experiences and theoretical concepts, providing attendees with actionable knowledge for navigating similar database migration and monitoring challenges.

We’ll explore the journey from the inception of Partition by Growth (PBG) tablespaces, through converting to them from deprecated tablespace types and the exciting enhancements made in Db2 12 to fan out multi-table tablespaces to PBG. Db2 13 now provides a robust online mechanism to convert PBG tablespaces to Partition by Range (PBR) tablespaces which is useful for PBGs which have grown to an unmanageable dimension. We’ll have a sneak peek at the future enhancements which will make management of PBGs and PBRs more straightforward still.

JavaScript Object Notation (JSON) is an open standard data interchange format that has been around since the early 2000s but is gaining more traction all the time. 
Data is available from a variety of sources and customers want to be able to consume and publish it without having to involve extra resources; software or staff.
As such, it behoves us in the database community to ensure that we can store, process  and display the data.
This presentation will demonstrate how to accomplish that requirement.

Did you know that you can control and manage an individual application or a class of applications without having to change the application source codes and without having to make changes that affect the whole subsystem? From having the targeted applications executing with specific special registers, global variables, with the characteristic to qualify for IDAA offload, to monitoring remote threads and connections, you can have such controls by using the profile tables. You can also customize certain subsystem parameters to model a production environment on the test system to observe your query workload before promoting. Come to hear all about what you can do for particular contexts using the Db2 for z/OS profile tables.

The concept of temporal tables is a precious rare gem provided by IBM Db2 which has gone unnoticed.The intent of this abtract would be to reinstate the essence of the temporal concepts and its purpose, by elaborating on the different types of temporal tables offered along with appropriate use cases.Tips and tricks about where the temporal concept can be applied and how to overcome the time sync issue will be discussed.

Monitors for Db2 for z/OS use the Db2 Instrumentation Interface Facility to collect metrics. The Instrumentation Facility Interface is available to users as well. In this presentation you'll see how you can write your own programs to use this interface to gather metrics about your Db2 subsystems and workloads in real-time, and how we used them to solve problems we faced.

Zagrebačka banka has been using Db2 Analytics Accelerator from 2017 and have recently migrated from V5 to V7. Prior to migration we did proof-of-concept with IBM support. This presentation will cover our experiences from PoC and production migration including our use cases, IDAA on Z configuration and installation, HA/DR considerations, workload migration and implementation of Integrated Synchronization.

Join me on a journey through our first year of deploying SQL Data Insights (SDI) into production. Discover how SDI impacted our business processes, changed stakeholder perceptions of the mainframe, and enhanced our approach to data analysis.
We will start with a review of our first use case and discuss the resources consumed for training and scoring, as well as the impact SDI had on our business processes. 
SDI's most evident benefit is its ability to analyze data where it sits without having to export, transfer and reload it, and with minimal data science dependency. But how does it compare to more traditional approaches? To answer that, we'll compare SDI with other machine learning algorithms by applying them to a frequently used dataset for predicting diamond prices. We'll delve into the accuracy of the algorithms and see how SDI stacks up against data scientists' most loved algorithms.
Following that, we'll explore a brand-new use case that applies the new commonality-function in Db2 FL504. We'll discuss its usefulness, resource requirements, and potential impact on business processes, providing more practical insights into the power of SDI.
And finally, I'll share a use case that demonstrates how to identify outliers using SDI with Db2 monitoring data, ready to be applied in your own shop. 
Don't miss this opportunity to gain practical insights into the power of SDI and how it can transform your data analysis!

IBM provides us number of solution to achieve multisite HA/DR for PureScale clusters. Those include technologies like HADR Replication for PureScale Clusters, Geographically Dispersed PureScale Clusters, GPFS replication for PureScale Clusters, Q Replication for PureScale Clusters.
In the presentation we will describe alternative approach, where replication across 2 sites is provided by Storage Array Layer, which allows us to achieve additional benefits like consistency groups going beyond single GPFS filesystem used by the PureScale, optimized network utilization where Storage Array replication happens on SAN Fiber, additional HA layer where filesystem can be cross mounted across sites which gives additional redundancy layer for storage availability.
 
We implement solution by deploying Synchronic Storage Replication across 2 sites, where SAN fabric provides us NSD multi path connections from each side. This way on each side we have collection of NSD disks that are local to given side, and also connection to remote NSD disks from DR side. On both sites we install standalone PureScale clusters, independent from each, therefore failure of any of those clusters does not impact other side counterpart. Having 2 clusters we designate one as primary by creating PureScale managed GPFS on top of Storage Array Layer, and on top of that create Database with its' associated paths. Next we use gpfssync capabilities to export primary GPFS filesystem , and next mount the same on DR site. This allows us to mimic primary cluster on DR site, and next attach those synchronized mount points to TSAMP cluster on secondary site. Later on, we just move application connection to DR site, which can handle further ongoing workloads.
 
Proposed solution is active-passive deployment, when at any given time only one cluster has connection to synchronized storage array. We achieve this by protections on each layer (NSD disks active on one site only, GPFS mounts online on one site only, database cataloging on one site only). This is crucial to ensure only one side has active writes to the cluster, so that we prevent any corruption of the data. In the presentation we provide procedures to setup such deployment, along with failover procedures where we move storage attachment from primary to secondary, and reverse. We also provide testing results where we verify solution, by forcing failover and more failure scenarios while processing application workload.

There are many migration scenarios in which common tools like Backup/Restore or LOAD cannot be used, whether because of compatibility issues, too much manual doing, or lack of downtime.
In this session, I will go into detail of a self-made tool, which on top of Q-Replication makes it possible to migrate almost any DB, regardless of size, complexity, endianness or encoding in an effortless manner with near-zero downtime

This presentation will provide the ongoing success story Db2 z/OS Version 13 and covers the latest experiences with Db2 13 at Commerzbank AG. It will talk about some key important areas which are essential for the success and how to prevent some known avoidable pitfalls. We share the important latest experiences of the last 12 months, explains the upcoming and validated best practices in several key areas. This session will also dive into Function Level details and dependencies up to the latest FL 504 (/505), maintenance aspects, some tooling dependencies and some performance aspects as well as base utilities and system functionalities.

In 2021, we initiated a PoC for Db2 for z/OS Data Gate with primary focus on functional and non-functional performance requirements, running on an x86 platform, which was successfully completed with good results. As we started to drill further into other non-functional requirements focusing on HA/DR we came to the conclusion that Data Gate on Z could be a better fit for what we wanted to achieve, which triggered our 2022 PoC, covering Data Gate on Z. This presentation will cover the whole journey of having done PoCs for both x86 and the Z platform, but with emphasis on what additional benefits the Z variant brings to the table. This session will be about positioning Db2 Data Gate on Z as the most efficient/effective way of supporting the fundamental need for unlocking Db2 for z/OS data to support UBS requirements related to a newly defined Digital Core Architecture, app modernization, and MIPS offload use cases.

We need to move our production database to a new “machine”, or upgrade it to a new version of Db2.   But, we cannot take an outage (longer than a very few minutes).  How can we do that?  What tools are available?   This presentation is a follow-up to last year’s “AIX to RHEL conversion” presentation.  In that case, we were moving small dev environments from AIX to RHEL.  Now it’s SHOW TIME!   It’s time to do Production environments.   What are the strengths and weaknesses of each available tool?   What should we use and what challenges will we encounter?

Analyzing Db2 for z/OS performance problems can be overwelming. There is a lot of information available in Db2 , z/OS, ... so it is important that you know where to look and what to look at.
This session will discuss a number of real customer problems, what info to collect, and how to analyze and interpret the data to find the heart of the problem.
While the focus will be on Db2, but as Db2 performance is closely related to how the overall z/OS system is doing, the session will also explore a number of z/OS key metrics to see whether the issue you experience in Db2 might be part of a larger system problem or not. 

Db2 exposes various latch monitoring interfaces: - MON_GET_LATCH - TOTAL_EXTENDED_LATCH_WAIT in MON interfaces- db2pd -latches
Those are primarily intended for the support and internal usage, hence not well documented, but it still might be very useful for DBAs system admins to know how to interpret them and explore tuning possibilities to achieve better throughput.The intention of the presentation is to explain how Db2 handles concurrency and what types of workloads might cause latch waits.Presentation will cover latches in: - bufferpool  (bpdLatch, groupLatch, clockLatch)- memory (SMemPool latch)- lock manager (xhsh and hsh latch)- OS locks (SQLO_LT_NO_IDENTITY latch) 
Bottleneck analysis and examples will be primarily based on the real scenarios from Inditex environments, with whom I've worked over many years on various performance problems.
Presentation will be done with the customer (Indiex, Luis Alberto López Maldonado)

Let Db2 take care of the audit data automatically, w/o having to run external Jobs in order to archive and extract the audit logs.This is a presentation about the handling of audit data in a customer project at REWE digital in Germany. Since Db2 10.5 FP4 (Cancun), it's possible for the extract of audit logs, to write that data to SYSLOG on Unix (AIX & Linux) systems.
Customer wants to get rid of scheduled external jobs, which have to run in intervalls against every db2 instance (more than 150) in their environment in order to archive and extract the audit data for instances and databases.
The session will give insight into the realisation of the project using Db2's internal administrative task scheduler and procedures in oder to extract the audit data directly to SYSLOG files and let QRADAR take the data directly from that single source per system for further processing.
Monitoring of the audit processing will be another main aspekt of this session.

The session will concentrate on new SWAT team experiences. Various unexpected outcomes and behaviors will be discussed as well has hot technical items customers are exploiting as well as technologies that have been challenging for customers. The complete session will be focused on customer experiences and sharing real life outcomes.

The presentation will be divided into 3 parts:
1. DR recommendation for Mainframe environment focusing on DB2 z/OS
DR cosiderations: What technology? What data? What purpose?
- popular DR myths word thinking about
- is there any recommendation other than 'It depends'?
2. DR configuration in mixed environmentPresentation will cover real production configuration for core banking application from Disaster Recovery point of view. Applications runs on Mainframe and Linux/Windows environment, both parts of app are important and data consistency between them is crucial. 
Application consumes :
a.      few thousand of MSU on Mainframe
b.     about 100 TB of data on Mainframe
c.      more than 50 physical intel servers 
d.     about 150 TB of data on distributed
Presentation describes the approach for db2 z/os and files data consistency between two platform. The approach for building and testing disaster recovery procedures will be presented. 
3. Golden Copy verification in mixed environmentsPresentation will cover the idea of creating consistent backup before each batch processing, short description of configuration will explain the idea of approach for backup.
All aspects of configuration and testing (consistency) Golden copy backup will be described.

I already showed howto work on Db2-Databases with Ansible and Python in previous IDUG sessions. This time around I'm going to guide you through the process on how to use Db2 as a configuration repository for Ansible. Runtime configuration for Ansible playbooks is usually done by the ansible inventory (usually requires a pull request) and, for runtime configuration, "extra-vars". This can be cumbersome in large environments and does not bear much flexibility. The result is usually an increase of AWX/Ansible-Tower templates for different configurations and targets. Furthermore, the templates (and surveys) get increasingly complex and uncomfortable to handle. Keeping runtime configuration data in a centralized database gives ample oportunity to create and maintain arbitrarily complex runtime configurations in one or multiple Databases with SQL so that the user does not need to know anything about Ansible at all, minimizing operational overhead.I will show how to implement this with the help of a few lines of python code. Live-elements will be pre-recorded if needed. Code will be available on GitHub.

Native Cloud Object Storage support brings to Db2 Warehouse a significant reduction in cost when compared with Block Storage. But this is not the whole story, Cloud Object Storage also enables increased scalability and availability, and the multi-tier LSM storage layer enables performance and functional benefits.  In this session you will learn about our favorite use cases and features that get the best out of this new feature.

For work I try to stick to a rule: "Never do something three times!". I do it once, the second time I'm annoyed and for the third time I try to automate it.As I'm currently managing around 40 RHEL servers with nearly 700DBs on it, automation, conventions and rules are key.
In this session I want to show the audience general commands and constructs within shell programming. Givng a method at hand how to fast develop shell scripts and oneliners and some tricks to get around some possible pitfalls on the way.