Name: IBM® Db2® & Tools + Utilities: Powered by Legends, Built for the Future Virtual Summit
Uploaded: 2025-11-19T17:32:19.559Z
Duration: 2 h 52 min 40 s
Description: IBM® Db2® & Tools + Utilities: Powered by Legends, Built for the Future Virtual Summit

Transcript for "IBM® Db2® & Tools + Utilities: Powered by Legends, Built for the Future Virtual Summit": Thank you. My name is John Thruessen, and I'm a d b two tool specialist at Rocket Software. In this short fifteen minute segment, I'll cover two items around modern capabilities in the d b two tool, observability and metrics, and then, afterwards, integration of query monitoring software with SQL tuning services, which is was a must afterthought feature. So let's start with observability metrics. The IBM Db2 tools, including Omega One Db2, offers two different technologies for making data available for observability platform. The OmegaOne data provider, which has been around for a couple of years, allows streaming of these metrics to modern analytics platforms like IBM Instana, Splunk, Grafana, Elastic, etcetera. We also have REST APIs for OmegaMon d v two and CurryMonitor. This is allows the same observability observability platforms to pull real time or near real time data and display that in, dashboards. Specifically, for OmegaMon Diva two, we recently announced the OmegaMon data requester, which, has a Grafana plug in and a large set of dashboards across all of the OmegaMon. This is the strategic direction for the web UI for OmegaMon, and should eventually become your monitoring UI of choice. Now this architecture provides, many advantages, but let me, highlight a couple. First, we can seamlessly integrate data from multiple different, sources into a single dashboard, and we will see that in a demo. So So for instance, you can combine data from Omega one d v two with Query Monitor, Log Analysis tool, Automation Expert, and so on. You can also integrate data across the two different methods, So you can have a single dashboard that shows currently executing SQL statements, which is real time data along with the historical execution of SQL statements in the same dashboard. Also, the the flexibility of these, dashboarding platforms allows you to build, dashboards that are tailored to specific personas. So you might create a dashboard for application developers and owners, a dashboard for DBAs, a dashboard for DB2 Sysprocs, etcetera. And in a demo, I'll show some examples of of how that could be done. So let's first look at at an application dashboard where multiple data sources are being combined. At the top of the dashboard here, I have the negative SQL codes for the application, both over time and in a in a summarized fashion. Below that, we have the deadlock and timeouts. They are often important for the elapsed time and availability of an application. And this kind of dashboard solution allows drill down. So let me zoom in on one specific time out here. We can see the detail of the victim that got the time out, and we can also see a list of the blockers. And for the blocker, we can zoom in on the details and see this looks like a a spoofing execution, that was holding a resource, maybe not committing. Let's go back to the dashboard here. Let's scroll a bit down. Below that, I have, manage changes from a d v two administration tool, allows you to track, DDL changes to your application. We have this over time, but also in the summarized view by user. Scroll further down to the left, you know, let's assume this is a distributed application. So, here we can see the drivers that are being used by that application. It looks like four different driver versions are being used to cover them, back level, although they are still in service, but maybe something you wanna follow-up on. On the right, there's number of utilities run by utility type here, reorg, run, set, load, etcetera. And then at the bottom of this dashboard, we have exceptional SQL statements coming out of Query Monitor. So these are statements that use a lot of resources and are run for a long time, etcetera. So in this example, we can see how many different sources are being combined into a single dashboards that show, bytes and metrics for that application. Here's another example. This is all the way down to a tablespace level. So at the top of the dashboard, I have some basic information about the tablespace level. This is a p b p b p b r, four partitions. It has a single table inside. And then the first two graphs show key real time stats. These are being streamed by d v two automation expert. On left, the number of inserts since the last reorg. On the right, the number of changed pages since the last copy. We can see how, that data evolves. Below that, we have the object activity coming out of Query Monitor. So the green curve is the number of get pages over time, and the yellow curve is the total elapsed time against that object. Below that, we have which utilities will run. So it again, utility running a utility might impact, for instance, the the elapsed time from the curve above. So seeing them sort of on the same page allows you to see how, let's say, a reorg impacts the elapsed time. On the right below that, we have the individual utility executions as well. On the left, we have audit records coming out of OmegaMon DB2. In this case, this specific object is considered sensitive, and it's included in a d v two audit policy. And here we have the number of, access to this sensitive object. And then at the bottom of the dashboard, we have the d v two administration tool that manage changes for this object. So these are the, DDL changes, either upcoming or historical. As the third and final example, I have this application dashboard. Now on the left hand side, we have data coming from Query Monitor. At the top, we have data coming from the Query Monitor REST APIs. In this case, it's the currently executing SQL activity for specific user ID. Below that, we have the aggregated total CPU and total lapse time over time for that same user. This data has been streamed to Prometheus through OmegaOne data provider and is made available here in the dashboard. On the right hand side, we have a similar setup. At the top, we have the active threats currently executing in my data sharing group. This is data coming out of the OmegaOne, REST APIs, and in this case, I used the new OmegaOne data request to execute that REST API. It helped me build the REST API and and, and the dashboard here. At the bottom right, I have historical d v two accounting records. These have been streamed using a new feature in Omega one six point one, that allows you to stream accounting records to these dashboarding platforms, in this case, Prometheus. And then I built this dashboard based on the historical information. Again, this shows how you can combine, the REST API data sources with the long term history coming out of, let's in this case, Prometheus database, and then combine different products in the same dashboard to make the data easily available. So if you're interested in this new technology, either OmegaMode data provider or OmegaMode data requester, you can always reach out to us at ccon shares at rocket software dot com. We can set up a technical briefing, or you can also request our help on installation deployment to get you up and running as fast as possible. Again, that's cconcierz@rocketsoftware.com. So in the second part here, I'll cover a recent enhancement for the DB2 Query Monitor web UI, also known as the CAE server. So this enhancement was shipped as APAR P867186 back in September 2025, so a couple of months ago. So it provides integration with, admin foundation, SQL tuning services, including Visual Explained, and Db2 query workload tuner for workload tuning or more advanced tuning. Do note that Query Monitor uses the APIs from the two administration foundation. So, so that's a prereq. And then in addition, you need the SQL tuning services for visual explained or, Query Workload Tuner for the the workload tuning. So let's see a demo here. So you'll notice that, when you navigate down to a SQL statement, you will see a couple of new buttons here, The, visual explains. So let's, click on that one. So you're presented with a pop up, to select your tuning profile. You click next, next, and then the d v two administration foundation APIs are being called to generate the visual explain. You can click on that, and we can see the visual explain for that specific query right here in the web UI. There's also a new run button. You get this pop up. Click run SQL, and it will take you, directly to admin foundation run SQL dialogue, within admin foundation. Let me format the query. And from here, you could tune the query. So let's say you have Query Workload Tuner, so you have the advanced tuning capabilities, index advisor, access path advisor, etcetera. You can also click run to run the SQL statement here as well. Let me go back to the, Query Monitor web UI. So the last feature is the create workload feature. It allows you to create a workload based on the current selection and then launch into admin foundation. So you can select, which which, SQL statements to create a workload from, either selected rows, the current page, or all, the entire selection. In this case, I'll just take the the current page. Again, prompt for tuning profile. Let's create a workload. Now the workload has been created. In order to tune it, you would have to launch, admin foundation. Select the profile. We can see the the workload has been captured. From here, you could do a tune workload. You can select the, advisers. I'll disable the analytics accelerator in this case, and then run the tuning. And once the tuning is completed, you will be able to see the the result of the tuning, all of the advices coming out of the query workload tuner, such as the new indexes, query rewrites, etcetera. And with that, I'll hand it over to the legends. Thank you. John and Terry, thank you for being in here again. It's a privilege for all of us to hear you and I'm sure the DB2 community loves to have you back. So let's get started. I've been part of the DB2 journey for quite a while. I prefer to measure my years of service, by releases, and I came around DB2 around the release of DB2 version five. And I like releases because it makes me feel young. If I do years any other way, it would make me feel old, and I don't wanna do that. So, John, what drew you first to d v two, and how did your journey begin? Yeah, so I need to explain a little bit before and after my DB2 journey started. I mean, I started in IT as a cobalt IMS programmer with Rolls Royce and then moved on to IBM Central Manufacturing Systems, where I was an IMS DBA and a systems programmer. But by the time I moved to become a technical systems engineer, that was exactly the time that DV2 was coming out for version one release one, And I remember getting hold of this systems journal, which is a, I don't know whether IBM still does that journal, but the whole journal was dedicated to DB2. And I was actually mesmerized by this. I thought I'm passionate about it, And so, I specialized as a technical assistant engineer in DB2 and got involved in those first few years rolling out DB2 to about 20 customers, getting a starter with some pilot applications. And then as things went along, I became the country technical support professional for DB2 and then moved on to the DB2 lab where I was in the performance team, obviously specializing in performance on version three and version four. And then later on, as the end of the nineties there, I specialized in continuous availability and set up the, DV2 SWAT team. And then in 2003, I became a distinguished engineer. Well, speaking of performance and the optimizer, we've got so do you remember your first impression of Terry, John? Oh, I certainly do, but it was positive. I mean, Brian Smith, who was a good friend of both of us, told me you had this red hot query tuner working for Richard Jevich Consulting, and he was going to recruit him. I didn't know Terry particularly well at the time, but, Brian introduced Terry to me, and one thing that was obvious straight away with Terry, he was passionate about query optimisation, and he was a really good communicator, which is not surprising given the work he was doing for Jevich Consulting. But one thing you learn very quickly about Terry, he challenges, he asks questions, and that's a good thing. He's always so polite about doing it. And, another and then Brian said, could you mentor Terry? And, actually, it was pretty easy really because we always got on really well and we always cooperated, but I do remember one little story about Terry. He was in DB2 for about twelve months and there was the Academy of Technology meeting and Nick DiNapio was a senior IBM vice president at the time. Nick liked talking to newbies in the IBM company. So, Terry came along to this Academy of Technology meeting, and he participated in this round table with Nick, And Terry never wasted an opportunity, not then or later, and he sort of told Nick what he thought about the company and that we needed further investment in query optimization. And I thought it was excellent. So, anyway, after I left the Academy of Technology meeting, I came back to the DB2 Lab, and very quickly, Kurt Coppner was waiting for me and said, what did you let him off the leash for? You didn't have to let him say all of those things. And I defended you, Terry, by saying he's passionate about his subject, and he thinks we should invest more to make this area better, and he's probably quite right. So there you are, Terry. That was my first impression of you. I do remember Kurt coming to me and telling me, that I was not permitted to speak to IBM executives ever again. But Thank you. Did you ever think that Brian Smith would call you red hot? That would be my other description of you that was, Yeah. He he was the one with red hair. No. I didn't, you know, obviously, I don't know that that part of the part of the story, but but thank you, John. I I was wondering if you were talking about the right person when you said very polite. I'm like, is he talking about me? Okay. I'll I'll take it though, John. Thank you. You've always been that you've always been very polite, Terry. Even though you might constructively argue with me, you're always very polite about it. Thank you, Joe. Which is very good advice for the next generation. Right? This is part of what they're supposed to learn is to be able to speak up and learn, and your voice matters when you're saying stuff. Right? Well, when you look back on the early days of DB two, what made you lit leave the beach and the sun of Australia to move to Springfield, Illinois, Terry? Oh, so, you know, in Australia, they would have the IDUG conference in Melbourne or Sydney every year. You know, and Australia, as you know, is very isolated. Right? So, you know, you don't have immediate access to, to the expertise and, people like Richard, Richard Yevich, Willie Ferrero, Bonnie Baker would come to the IDAC conferences. And, you know, yeah, I was young. I was like a sponge trying to soak up as much, information as I could on the query optimizer understanding. And I was a DBA in in Melbourne, Australia. And then just by chance, Richard Yevich and and Susan Lawson, who I got to know through through the conference, they, they had a need for a quick optimizer person in their consulting, business. So they offered me a job. And and of course at that point, I had never seen Springfield, Illinois. I'd only seen America in the movies. And so, so, yeah, I took the leap because of it was such a significant significant opportunity to work with with the likes of Richard Jevic. So so, yeah, I I left the the the sun, the surf, without actually seeing. It was sort of like going on a blind date, I guess. So Well, don't worry. Not many Americans have seen Springfield, Illinois either, so I don't know if that's really, you know, but at least you have made the most out of it. Right? And look where I got you. Right? So it made you taking chances. Yeah. Now I'm in Seattle area, so, so, yeah, I did actually get out of, Springfield, Illinois. Right. Right. So let's shift gears a little bit and talk about big stuff and breakthroughs, battle scars, maybe moments. John, do you have any pivotal breakthroughs over the decades that you wanna talk about that evolutionized d b two, that was game changing that you witnessed or contributed to? Yeah, there was really three significant events, but one in particular I want to talk about. I mean, if you look back on version two and version 10 of DB2, those were pivotal moments because they delivered performance and scalability improvements. And, as Bruce Williamson used to say in IBM Research, performance sales and those had a big impact on customer take up and deployment of applications on DV2. But, I think the big pinnacle moment for me was DV2 version four and specifically data sharing. I'm not sure at the time I really understood how pivotal that period of time was. I can remember in the performance team, we were discussing assignments for version four and I was desperately hoping I could get data sharing, and I had no competition. Nobody wanted to do it at all, and I thought this was really strange, but I thought this was really exciting. This is a way of coupling multiple systems together so you could scale capacity out horizontally and also provide true continuous availability by masking outages. But if you look at the backdrop to this, it was a pivotal moment for me as an individual in my career, but also for DBT Development and the IBM Corporation. What most people on the outside may not have realized that IBM had some business problems in that period because they stopped producing more bipolar processors and the H5 processor was the last one they planned to deliver. And, at the time, there wasn't data sharing, so it was all about who had the largest single image for these large worldwide customers. And, of course, Hitachi had this processor called the Skyline, which was far had far greater capacity than the IBM H5, and IBM was switching over to these CMOS machines, these air cooled CMOS machines, which I often refer to as a pack of Bud Light. The code the code name was Squadron and literally they only they had about 10 MIPS an engine. They were very small. So, anyway, IBM desperately needed data sharing and the whole parallel Sysplex concept as a way of being able to scale this capacity out horizontally and move away from that single image constraint. And reflecting back on it, it was special times and probably the most enjoyable part of my career because I was actively working with research both in Almaden and at Yorktown and with the developers in DW2 development like Jeff Josten and the chief architects in Poughkeepsie as well. So, it was a special time for collaboration, driving changes. It wasn't an easy project because it wasn't like you change one component in DV2. You had to change so many components over DV2 and you had to do a tremendous amount of testing to prove the reliability of the components afterwards. And there were an awful lot of changes generated to achieve the performance goals. A lot of patents were filed by IBM on this particular subject. But when I now go back and reflect on it, this has probably been the most successful thing IBM have done in my lifetime. And I don't think they've done anything quite as big as Parallel Sysplex and Db2 data sharing since that time frame. What a great start of resilience and collaboration because you had to collaborate with all the different course. What a difficult thing to do in IBM as well. So, Terry, any pivotal breakthroughs that you you wanna talk about? Yeah. I think, as as you both know, not a lot of people really understand query optimization. And that was always one of my biggest challenges in DB two was you don't get customers with requirements to say, hey. Your list prefetch cost formula is off. Right? Or, you know, nothing related to the internals of the query optimizer because they just didn't understand it. And, you know, when I joined in the early two thousands, you know, we were literally the butt of, you know, everybody's jokes, the query optimizer. It's instability. And, you know, I actually, I I have to give so much credit to John, because even in d v two development, there was the query optimizer team who understand understood the query optimizer, and everybody else had no idea what we were doing. Right? And where John and I meshed so well was that the optimizer, you know, it's what you have to do is you have to model the execution behavior. Right? And you need to understand the optimizer behavior. Sorry. The the execution behavior to model it. Now John was the only person that I could find that knew basically everything about everything in d v two. So kind of the the pivotal moment for me was leveraging John to help, you know, drive the necessary improvements into the query optimizer to stabilize it. And that even included the focus on plan stability or plan management. And that was game changing because anytime you make a change to a query optimizer, you might improve nine things and break one. Right? And all you hear about is the one that you broke. Right? So but you you can't stand still because customers need improvements. So that focus working with John on on moving the optimizer forward, but creating a stability a platform of stability was really the game changer for us to deliver and, you know, to stabilize the query optimizer. And basically, you know, it it literally the reverse stopped becoming the butt of people's jokes at at conferences. You know? And I would always joke, because John and I would would make fun of our peers as well. And I'd, be at customer advisory boards and I'd, you know, I'd be, doing my presentation, talking about the optimizer. And I'd always tell the customers, my my goal is that next year, you're not complaining about the query optimizer. And John actually helped me stabilize the query optimizer. Again, so many internal changes that were bold decisions that I had to make that I wouldn't have been able to do without John's backing. So that kind of, you know, that's the pivotal stuff for me, how we're able to reshape the, the career optimizer to, to address the instability, of it. So thank you, John. Probably didn't even know how much he influenced you. He probably does. I don't think he does. I don't think he does know how much. So Well, and I mean, when looking back on learning experiences, when I was thinking about, this panel, I could probably make a list of everything that you two taught me. I am one of, like, many people in the DB2 community that could say lessons learned from Terry and John, and a lot of the lessons we learned were just by watching you. But I think the best thing, to tell us and to kinda learn from is, Terry, you've already mentioned one, but what is your next, favorite learning experience from John? It really has to be the customer focus. You know, again, in career optimization, it's a very academic and research focus. And John really helped me connect that, that customers care about reliability. I know John, you used to, you used to talk about that customers would, would prefer that if everything was 1% or 2% slower, but it was stable and reliable rather than sometimes really great and other times really bad. So that, that mindset of, you know, in the research and academic side of career optimization, you're always searching for the best plan, but at what risk. And that's something that John taught me that that really went back to that stabilization focus and something that, you know, that I continue, in the way I think about career optimization today is that stability, reliability in an OLTP system is far more important than than searching for the optimal plan if the risk is the risk of searching for those optimal plans could result in regression, nobody wants unreliability. People just want stability. So that's the, that's the one, you know, it, it sort of goes also to that pivotal moment in how we reshaped, the query optimizer in DV2. Well, I mean, and John, I think you also told me when it comes to customers, I think my biggest lesson that I've told everybody over and over again, you told me is never lie. If you don't know the answer, find someone that does, but never lie in front of them. And I think that's helped me in my career and helped me in life when we were making decisions for customers and giving them advice is to kind of listen and learn and then figure out the right person to give the answer. So, John, is there some other learning experience that you had from Terry? Well, certainly, Terry opened my eyes completely about query optimization. If you look at the developers who've typically been in that area, they may be technically brilliant, but they're not great on communication, and they weren't out there in the real world understanding the impact of changes, understanding, in some cases, the risk they were taking. So Terry really opened my eyes about this area, and we had many debates over many years, not just about query optimisation, about other aspects in DV2 and things like, you know, pseudo deleted index entries and some of the other things in DV2. For example, in version 13, when it was under development, Terry got me involved in what was called the DDL break in thing. Now that's not a home subject for either me or Terry, but Terry actually pulled me into that because he didn't feel that it was going in the right direction. So, I've always enjoyed the collaboration with Terry, and we talk about things, you know, at breakfast, in a conference, in a taxi cab ride. We'd always have this constructive discussion about things, and we always ended up with an outcome, you know, and it was a good outcome to have these sort of debates because some of our peers weren't so open to being challenged, weren't so open to having these sort of discussions. But, if I think about one customer experience with Terry, I took him down to see the UK Land Registry in The UK, which has one of the world's biggest operational databases. When Richard Winter used to do his surveys, they were number one in the world. And, basically, what the UK Land Registry does is they maintain a register of all the properties and the details of those properties in The UK. So it was growing and growing as each property was bought and sold and new properties were there. Anyway, the problem was that they they one of the main things for their users when they when they take calls or they take correspondence from solicitors and lawyers is they want to do a name and address search. Anyway, this had gone on for six or seven years with IBM specialists, consultants, some of their own people basically trying to tune these queries and without success. And, in fact, what the next person on doing what somebody had done previously. So, I brought Terry with me down to the Land Registry in Plymouth and my learning experience out of there was less was more. That Terry actually got rid of so many of those indexes, stopped collecting some of the advanced statistics, started collecting some extra ones, and the end result was the most fantastic improvements in those name and address queries. And you should see how happy the customer was. They were absolutely delighted about it. And one of the gifts Terry's got, I talked about communication, but here you can dumb it down to somebody like me to explain what the intent is, how it's meant to work, and why it might not be working, and basically humanises the the d v two optimizer. I mean, he once told me that I was one of three people in the world who understood column frequency statistics now, And I was always so eager to learn about the optimizer as I was in other areas of d b two because I was very much a generalist. But if I I I took it as a badge of honor, Terry, when you told me I was number three in the world on understanding column frequency statistics. I'm very proud to this day of that. How many people in the world know it, John? Now that's my question. Out of how many? Oh, there's a lot of people who think they know column frequency statistics. There's an awful lot of people at conferences this week and conferences I've been through over the years, and I've discovered based on Terry's education that I can now see people blowing a lot of smoke in this area and a lot of people making a lot of mistakes, aggravating the cost to bind and prepare, and also running the risk of the optimizer making a bad decision by over collecting of advanced statistics. So thank you, Terry. Blown away. Thank you. Do you even remember that? The I definitely remember the land registry one, because that was that was funny to me how, I mean, I I I think it's just, obviously, I my mind works differently that I get query optimization, but I'm dumb in all the other areas. And that's why, you know, I'd have these discussions with John and, you know, I had to understand the execution behavior. And in the query optimizer, we often didn't. And so the reverse was also true with with John, is that he could dumb down the system side. Because I'm an application guy, not a system guy, and John's the system guy. You know? But the customer buys the whole thing. Right? The whole of d v two. And in d v two, before these collaborations, you know, there was there was really a brick wall between the query processing side and, you know, the system side or the engine of, of DB two. And if the query optimizer doesn't understand the execution behavior, then we won't model it correctly. So that's the part that I think, you know, it's sort of what what John's saying is we both needed to dumb down the other side of the brick wall so that we could, you know, you know, improve the whole DB2 because otherwise, we were do we were developing two pieces of DB two and shipping it to a customer. Right? And so that's that to me is the, you know, sort of we I had so many of those moments, yeah, sitting in in, you know, in a taxi in Helsinki, you know, discussing pseudo deleted index entries or or at breakfast at some conference. And it was really difficult to get John's time. So whenever we had that time, you know, he's always, oh, you know, I've I've got a customer meeting or my team meeting or I'm visiting this customer. But, yeah, I I truly value those those opportunities where we could discuss, you know, the, the odd behaviors that we were seeing in, in customer environments. And, I, I still, I'm still, you know, surprised and impressed how, John helped me to to, make so many bold changes in the query optimizer. Because like like you said, John, nobody else in in DB two leadership, understood the crew optimizer. People were fearful. And if you and I could could dumb it down, you know, we were able to then advocate for change. And that was that was critical. So, so, yeah, I'm glad that you feel that it was effective. So So, Terry, as you were saying about bold changes, we're finding that our customers and especially, customers in DB two now, we're trying to convince them to modernize, use AI, and they're actually scared of making these bold changes. Do you have any advice that you can give to them as they're making changes in their environment? So I think I think bold change is necessary. Right? If if incremental change, you know, you're going to be disrupted by somebody else, if you just, if you're afraid to make change, you know, and what I talked about with making bold change in the query optimizer, it was necessary. Otherwise we were just going to be as unstable as, as someone like Oracle or, or many of the other databases. But when you're making bold changes, what is your, what is your backup? What is your fail safe? And, you know, we built that foundation of plan stability in the crew optimizer, such that when we made bold changes, if something went, went bad, went wrong, you know, we could revert back. So I bold change is necessary. But also, you know, what is your what is your backup plan? What you know, you have to think about a backup plan, but that's that's sort of my advice. Yeah. Take the risks. But but you have to have an out. You have to have a fail safe. Thank you for that. Alright. So now defining moments, John. Is there, outside of what you mentioned with data sharing, is there a, is there a defining moment or a project that stands out to you that made such an impact on DB two or the outcomes of advancements? I'm actually spoiled for choice, actually. So let I'll I'll mention a few of them. I mean, most people probably don't realize in the outside world that I was a double agent or triple agent inside of DB2. And, Arvind Krishna, who's now the Chief Executive Officer, you know, of the IBM Corporation, Arvind was my boss at the time, and many of our customers were just struggling with virtual storage constraint in Db2, and also they were falling behind. They couldn't keep it with the pace of which releases were coming out from Db2, and this was about the time of version eight and version nine. There was a very slow take of version nine, and I know I never waste an opportunity. If I see one, I will take it, and I remember arranging for Arvind to have some lunches and dinners with some major customers in Europe, and I primed the pump about three things. One, finally solving this virtual storage issue. Secondly, delivering some performance improvements and delivering the skip release. And it was just amazing to see all of a sudden that Kurt Coppner had a complete attitude adjustment, was a true believer because Arvind had been convinced and Arvind convinced Kurt it was the right thing to do. And he did exactly, you know, it was one of those pivotal moments in the history of DB2 allowing customers to catch up. Performance always motivates customers to get performance savings and by solving that virtual storage issue, that also delivered further performance improvements and enabled these customers to scale up. So, I often acted as a double or triple agent to try and get things done by massaging a particular customer to talk to an IBM business executive or the DB2 product director to try and get things done. Outside of that, the things that I really remember was working with customers closely to achieve major objectives. And, you know, having that feedback afterwards that everybody collaborated on that project. And I had this role of basically not telling them what to do, but coaching them what to do. And I can remember the China Construction Bank being able to benchmark and actually achieve in production 30,000 transactions a second. And most people won't even know the significance of that, but in China every year, the November 11 is called lovers day, and it's the biggest prize, you know, present giving period of the year. And for a five minute period after midnight, Alibaba is processing all those orders. And what most people don't realize is anything that involves money involves DB2 for ZOS. And basically, that's processing all the transactions. I can think about the Royal Bank of Scotland merging with NatWest, the small provincial bank, taking over a bank that's four times bigger and therefore having to scale the workload five times in order to be able to do that. Or, getting the Department of Human Services in Australia to migrate 125 instances of the SAP database server from Oracle to Db2 for zOS and getting better performance and better throughput on the system. So, I always enjoyed those projects and trying to guide the customer to do the right thing. And if I go back to one moment that sticks with me, and it goes back to that merger of the Royal Bank of Scotland and NatWest, I was in a meeting room with about a dozen STSM's and Distinguished Engineers and IBM, and all they could talk about was risk there, risk there, risk everywhere. And then eventually, we had to go and see the CIO. And I wasn't a distinguished engineer then, but I put my hand up to go. And it was a very lonely war because none of those distinguished engineers came with me. I just came with the account systems engineer. So I talked to Big John White, who was the CIO, who's a very formidable figure, technically very good. Anyway, I told him that there was these risks and what he should do, and he really didn't like it. So, I was basically dismissed from his room and as I'm about to exit out through his office door, he says come back and sit down, laddie. We need to talk some more. And, as I say, he's a very big imposing figure, and we sat down again. We talked about it, and John did all the right things. I was just sad at the end that after he got his bonus for the migration working faultlessly, he couldn't put a hand in his pocket to buy me a drink. But it was a magic it was a magical personal moment for me to when he said come back, laddie, and sit down. We need to talk. You remember those moments that you had this influence on a project? What gave you that confidence to raise your hand, John? Like, when you're thinking about the younger generation, it takes a lot for someone to have is it because you knew all the answers, or what was it that gave you that confidence to be the one to raise your hand? It wasn't that I had all the answers, but there has to, you know, you have to have some pragmatic solutions. When you've got problems, design problems, or real world customer problems, you've got to have a method there or some, some pragmatic way of getting a way forward. You can't say there's risk here, there, everywhere, just give up on this project. You can't give up on a bank merger like that. You've got to have some way forward, pragmatic way, to work on something that will actually make a breakthrough and for it to work. And sometimes people I've worked with, both customers and IBMers, they tend to want the perfect solution. They spend a lot of time debating about corner issues and and waste their time on that and don't focus on the main thing they're trying to achieve. And here, it was all about squeezing risk out of this project because inevitably it was going to be a big risk project where it's going to be very visible to The UK marketplace, to the UK government, and the financial markets. So, yeah, I don't know what all the answers are, but sometimes you have to be brave. Can you call it a brave or a stupid moment? Yeah. I can remember when I put my hand up to do data sharing and nobody else wanted to do it, and I thought, what have I done now? And then, I looked over my shoulder and then I realized it's my job now. I've got nobody else going to tell me how to do that. And often, as a technical leader, you get in situations like that. Somebody has to go. Somebody has to do something. Somebody has to look for a breakthrough. You can't just talk about risk everywhere. Oh, this is too difficult. People, you know, you need some breakthrough thinking. I know that term is often overused, but somebody has to go for a breakthrough and focus on what the main thing is and don't get hidden down in what I call corner or side issues and lose track on what you're meant to achieve. Such great advice. And I think, in addition to defining moments, one of the things that holds tight for many people in the DB2 ZOS community is our conferences. I think some of the best moments I have that I tend to still laugh about are the conference moments, from caravans to, talking to Terry yesterday, about Bonnie Baker and her famous dishwasher story where her daughter, I think, was unloading a dishwasher, and she was trying to explain prefetch. So there's, like, so many ways and hilarious moments, which I value, and I know many of the team, and community value from those conferences. Is there any hilarious moments, from a conference, Terry, that makes you laugh or anything that you, would like to that you're allowed to share on a There's there's there's too many, there's too many moments that I'm not allowed to share that are just too, you know, the the the conversations belong more maybe in the pub and not so much on a on a on a webcast. But, there there are there are so many sort of funny ones with with customers where, you know, we had such a good community in in DB 2. And I I remember, you know, going to to, Fogo de Chao, you know, that Brazilian steak restaurant with with, other IBMers and some customers. And and they have this, you know, they have this concept where they're bringing around plates of meat. Right? And you you have, like, a a little, like, a a little, like, circular disc. Like, you you you turn it up red if you don't want it, and you turn it up green if you do do want it. And, you know, so jokingly, we were using that for other purposes that evening as as well. And then the next day, the conference, the customers were had them and they were holding them up in my presentation. And I was, you know, struggling to to to, compose myself. So just those funny interactions. And there there's another another one where, you know, this is this is gonna, blur the lines a little bit about, appropriateness, but, you know, we're in, Vegas for a conference, and I remember, you know, I I presented, and then on the, you know, the the feedback, you know, the people would would, fill in the feedback sheet. And there was there was one where a lady had said, you know, after attending my presentation, that she was struggling to to, keep her composure during the presentation because she'd actually gone to see the, the stage show, Thunder Down Under from the night before. And because I have an Australian accent, she was thinking about her previous night. And because of that, for months, my colleagues in in the Optimizer team, particularly Patrick Bosman, they nicknamed me Thunder because of that. So, so that's another funny there's there's too many of those funny little stories where, you know, just interactions with the customers turned turned humorous. So, yeah, they're they're they're my question, though. Well, did you get a good rating, or was your Thunder how was your I I I think it was incredibly positive, but it might have been because of her, her, memories from the night before and not necessarily from my presentation. Well, I mean, this leads to a a great portion of of legacy and tradition as well is that, you you honor the tradition of DB2, but there's many things that you guys have gifted, to our community. And, one thing I have to let, as we go into the next generation and young professionals is I remember that I was taught to, you know, people would pick mentors for me and tell me that they were the most ideal mentor for me. And I learned through the process that you should pick your own mentor. And I remember watching, Terry Purcell on stage, and I had no idea what he was talking about. But I knew that, he was like a god, and I was like, what is he talking about? It's like Elvis. Everybody wants to come to see him present. And I remember asking him to be my mentor, And it was one of the greatest gifts I've ever had and the legacy that he's created, which was that he taught me how to have confidence in myself. And we always joke about this. And I was at a I remember being at a customer site, not knowing the answer to my question, and I answered the question to a customer, and I thought I got it incorrect. So I ran into the bathroom, and I started crying, and I called Terry. And I was like, this is what I said about the optimizer and performance, and and I don't know if I'm correct. And he's like, calm down. You were right. Go back in there. And I wiped off my tears, and I went back into the customer. And I I had more confidence in myself. So as we honor the legacy of DB two, we also honor the legacy of both of you guys as mentoring the CB two community. So is there any last messages, first starting with Terry that you'd like to leave, for the next generation of DB two people? So, Sahi, I didn't know you're gonna talk about that because I was, you know, I was as you started to think about, or or started to talk about this, I was thinking about the whole mentoring aspect because I have been fortunate, you know, when I when I first, as you asked me earlier, when I first moved from Australia, you know, I had Richard Jevic, as a mentor. And, you know, unfortunately, he was a huge figure in in the DB2 community. And, unfortunately, in the early two thousands, he passed away. And then I was, you know, as I joined DB2, fortunate to have John as a mentor. And and, you know, surrounding yourself or connecting with with leaders in in your field, in your area, you know, you get to learn a significant amount, if if you have a mentor like that. But the challenge is too, you can't just like you say, you can't maybe you pick a mentor, but, you know, if you know, you have to also, contribute to, you know, a lot of people who are successful, like to mentor others. They, they like to share their knowledge. But sometimes, you know, mentees will just, you know, sort of, use or go sort of abuse that mentoring relationship. So definitely find, and connect with people that, that can inspire you, that can drive you, but also, you know, you know, contribute to their success as well. And that's something, you know, John's been my mentor for, for so many, for over twenty years. And, you know, there was a mutual benefit to it, though, as well. So and Sahi, you and I, you know, that there was a mutual benefit as well. You know, we we, you know, we each made, each other's contribution to DV2 stronger through the through the the the mentoring relationship. So so, yeah, definitely mentoring, having a mentor is incredibly value valuable. But you also have to look at, you know, what benefit you provide to that person as well. So so that think about that as well, not just pick a mentor. So that would be my my advice. Well, and I I would say and and I think as a mentor, you also, had us play against each other. Like, if we didn't get all a good high rating, you were like, hey. My mentees all got scored a rating of one. How are you doing in the scale? So you had us competing against each other. So that's a whole different mentee strategy I've never even heard of, but it worked clearly. So, John, what is your advice to the next generation? I think it's now very important looking back that the new generation preserve the skills and knowledge of the previous generation. And I think it's important for anybody new coming in here, whether it be from a customer or an IBM viewpoint or a vendor viewpoint, is have some ambition. Be prepared to look for opportunities. And if you get those opportunities, grasp them. And sometimes they won't work out well. So always learn from those opportunities, either the things that work or the things that failed. I've often learned most of my things from the things that actually failed. And from a DB2 viewpoint, I mean, everything I've already said applies to DB2 development as well. But for them, I think what I would say to them is you need to listen to what the customers actually want. You need to have an open mind about what customers' real problems are and don't just preach at them or just talk to a very small number of very big customers. You need to talk to a broad church and don't just and do it much earlier in the cycle and also have lots of one on one conversation with customers because sometimes when you're in a customer advisory council, people may be shy, they may be frightened that some of their comments might be controversial. And, I think by exposing the designs earlier, being more open about it, there'll be more honest feedback, which will improve their designs. And also, I think as well that will lead to further problems, fewer problems down the road. And also, I think learning to kill things off when they're not going well, they're not going to hit the target you want to achieve. Kill them off early as opposed to discovering it much later. There's nothing worse developing a new enhancement or feature in DB2 that where the customer take up is not significant. You know, it needs to be wholesome, it needs to do the basic function there, and it needs to be workable from a customer viewpoint. So, that would be my advice to customers, IBM, DB2 development, and the whole marketplace. Thank you, John. Thank you both for sharing your insights and your stories. I can't tell you how much this meant to me and everybody else that you've done this. Your legacy lives on, with the new chapter of d v two and and the end of life of version 12. So thank you very much, and and thank you again, for being with us. This segment of the demo will show the OmegaMon WebUI sample dashboards for OmegaMon DB2. We start with the enterprise overview dashboard that's part of the sample dashboards. You can jump to the landing page of, OmegaMon DB2 by clicking the DB2 link and it will show what available data sharing groups are being monitored by the respective data source, which essentially is the Haptams running on zOS. For each group, you will then also see the respective members of this group and in addition, standalone subsystems that are not part of the data sharing group. From these entries, you can then jump into more detail level views. For example, a data sharing group threat activity will open in a separate tab in your browser. And here you see all active threats and you can page through the threats, look at the details, and also take action. For example, if you want to cancel a specific threat, you take the respective action and you can cancel the threat. The sample dashboards have additional link to other information that Omegamom d v two can show. For example, subsystem statistics data. On this screen you see a mix of real time but also near term historical data that is collected for the respective subsystems using the PDS collection. On the top, you have threat utilization parameters, buffer pull, hit ratios, but you also see active threats in context. Another interesting aspect is to look at history data from this dashboard. So let's look at the, threat history data. The threat history data workspace that we deliver is based on the same information that you see in the enhanced thirty seventy threat history. So you have an overview of the data store, how many records are in it, what's oldest and newest as time stamp, what's the status of your history data sets, what accounting classes are turned on for collection. You can then select the threat that has terminated and drill down into the details. You You can filter by the thread type. So I filter by RSAF, in this case. I drill down into the details of the threat in history and can look at the class one two breakdown in more detail. I can look at class three wait times to see what's going on on the waiting side and jump back to the overview screen and also look at things like buffer pool details, for the specific, threat that has terminated. This concludes the demo of the sample Grafana dashboards for, OmegaMon d v two. If you consider this in context with the, ODP data streaming, you will see that you can use Grafana as a central platform to integrate both real time, near term historical, and historical information processed by the batch report. In this segment, I will show how to stream batch report to file and safe convert data into an Elasticsearch using data provider capabilities. The product comes with a sample job that helps you with the stream, and a sample job is shown on this screen. There it has a well defined description where you see which tables are eligible for for streaming. But at the core, it will be referencing the ODP libraries and our product libraries and then as an input the, dataset that you want to stream. In this case, it's an accounting file from October 28 to October 31. So I have submitted the respective streamer job and now we look at the sample dashboard that that we built that is based on accounting file general data and you see that with autofresh five seconds the data starts to flow in coming from the, from the streamer. As the data flows in, obviously, you can look at the respective metrics. We have class two, three breakdowns, suspension breakdowns, and an overview of the heavy hitter main packs here. And as the data updates, you will see that data changing, obviously, because, of the overall characteristics. Then you can use the usual Grafana ways to drill in to the data and analyze it in more detail. Before we start with the demo of our AI capabilities, I want to quickly mention what the use case is that we implemented. Our use case is based on aggregated accounting statistics, which provides us usage per per d v two connection type. So we want to detect anomalies in the in d v two CPU, times for a respective connection type so that we can protect our transactional workload and detect the workload shifts or resource constraints. On the top level, you have anomalies that are calculated at the fifteen minute interval and you get an overview of high, medium, and low, anomalies in the respective visualizations. All of this is hosted through Grafana, and you can see that it's the same visualization platform as we've seen in the previous two segments on the ODP streaming of data and also the real time dashboards. What this product also supports is you can integrate with the existing, Grafana capabilities. The main persona for this is the site reliability engineer that detects these anomalies and wants to inform, SMEs or other persons that there is a potential problem to be looked at. This can be done through alerting capability or webhooks that can be integrated in a product. So for example, I have high anomalies here and I want to create an alert ticket. In this case, I've set up the webhook to use Teams Teams integration and we see that the critical anomaly is detected here. And then Fabienne, who is the recipient of this, will look at the dashboard and will be taken to this exact dashboard and analyze the issue. So what are the primary and secondary KPIs of our model? The primary KPI is the in d b two CPU time for the respective workload type. What this what the product does, it also creates a summary table which lists the, so called overconsumption, meaning how much, extra consumption has this, workload cost compared to the regular, seasonality that it goes through. So we see that here. We see that there is an overconsumption of about 27,000, for the time period that we look at. The primary KPI, as I said, is the n d v two CPU time and this is factored into the model calculation. And you can see this this, gray tube here which is the confidence interval for that, primary KPI class two CPU total time. Okay. Let's talk about secondary KPI. Secondary KPI's are KPI's that, can support the problem investigation. For those familiar with the aggregated accounting statistics, there is a plethora of information in there that allows you to pinpoint issues of the workload type, in certain areas. For example, we have the transaction count. We have the class three suspension times and the class two not accounted times that can be displayed on the time series, way. The other secondary metrics when you drill down into more details is effectively detailing out on the class three suspension times going down to database IO, lock write IO, and other IO. And the the farther you drill down, the more, details you, you can you can get. So when we look at this anomaly now, we want to drill into into this into this problematic area to understand a little bit more what might have caused this this issue. In this case, it might just be an increased transaction account, amount, which was driving the, the anomaly. We also see that there were some significant spikes on the suspension times and not accounted times, so there might be even a problem external to to d b two. So in conclusion, I want to mention that the data that is shown here is based on real customer data and we could also confirm the anomalies. What the customer confirmed is that they had an application change that was introduced towards the August and it showed the bad impact at the September. With this anomaly detection in place, the customer would have gotten the notifications way earlier. And if you combine this capability with the, ability to stream, low level information, accounting level information into, the Elasticsearch stack of your choice, you can do pretty good in-depth analysis of of your of your issues. This concludes the demo for OmegaMon AI insights in the DB2 context, as well as the parts for performance database, streaming, and real time dashboards. Hello. I'm Roger Miller. Many of you don't know me because I've been retired for fourteen years. But for the thirty two years before that, I worked on DB2 and various names as it went along. If you check my shirt here, it says DB2 for OS three ninety, DB2 UDB. That was our version six name with an operating system that some of you haven't yet haven't ever seen, since but it was so much nicer than the operating system before that. I started on DB two about four years before we shipped anything because somebody had to code it, and then kept coding, changing to work on design for DB2, solving some customer problems, and, and often taking a problem and turning it into a better design. So but my last version was DB2 version 10, and I hope none of you are on all the way back there. Indeed, with version 12 going out of service, one of the pieces I emphasized with my customers again and again was the more current you are, the more current you are on your service, the better off you are and the better off we developers and even ex developers are. But just for a hint, let's tell one of those old stories that we do. And and I'll tell it really from the sense of this old book. This is, so this is Hamlet, act three scene one, the DB2 edition. To bind or not to bind? When and how are the questions? Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous access paths or to take arms against the sea of troubles and buy opposing in them? Database and SQL design for performance continue to evolve as do the optimization and management techniques. Some of the old processes are still important and some even more important than ever. And but is the design changing? Has the SQL changed? Are the data statistics accurate? Amazing numbers of challenges there. Can SQL use the most efficient access? How are you monitoring performance? Oh, my goodness. Amazing number of we know it's wrong, but we don't have a clue. So if the SQL is accessing only a few rows, does it specify? Optimize for one row. That solved many, many challenges for us. You can save the prior access path using the plan management bind option. If a performance regression occurs after you rebind the package, you can use the saved historical information to switch back to the older copy of the package and regain the old access pass. You can also use the historical information in conjunction with the AP reuse bind option to specify the DB2 tries to reuse the existing access paths for static SQL statements when you rebind packages. Yes, the old and new packages and the new techniques may not end all of the troubles, but they can certainly reduce the frequency and the disruption. So I hope you all have good experiences and stay current with DB two. Thanks