IDUG NA 2025

Running Db2 on z/OS without a monitor is like driving a car without a speedometer or gas gauge; it’s something you need.   While monitoring at the subsystem level is important, you may ask yourself, do I really need a method of monitoring SQL?  You can try to export the Dynamic Statement Cache, or start an expensive SQL trace within your subsystem monitoring tool, but when there’s a problem, you need a quick and easy way to monitor the SQL statements.  You don’t want to recreate the issue; you want to go back in time to find out what happened.  The key software vendors for Db2 have a tool that monitors SQL.  
If you're new to Db2, just purchased a monitoring tool or maybe you don't have a tool at all, come listen to this session.  As a Db2 DBA most of my life, I'll go over the key reasons why you need to monitor your SQL.  Without an SQL monitoring tool:

Can you quickly determine the most expensive SQL statement on your subsystem?
Are you able to list all SQL statements within a package, sorted by most expensive in terms of getpages, CPU or elapsed times?
Do you receive alerts and email notes telling you there’s a resource unavailable condition or that a package failed?
Can you see who stopped your tablespace in production?

Monitoring an SQL statement is different than monitoring a Db2 thread in your subsystem monitor.  In this presentation, I’ll show you key metrics I look for.  Should you look at total getpage activity per query or the average number of getpages?  What are the delays telling me?  Are there certain SQL codes we should be monitoring?
Would extracting the host variables help in resolving SQL Code 100 return codes where no records are found?  While I will be using the IBM Db2 Query Monitor tool for screen shots, I hope to cover SQL accounting data used by all vendor tools.