XM4DB2 continuously inspects each mission critical DB2 system. It proactively looks for indicators for current or potential future problems, so called “exceptions”. An exception is an unacceptable situation that DB2 or another z/OS component cannot automatically solve. XM4DB2 alerts DBA staff and optionally can take action to rectify the situation.  Working in the background it continually checks for availability of DB2 objects and the operational readiness of utilities, plans and packages.

Here are some examples of where XM4DB2 detects and signals severe problems. A load utility puts a tablespace into a “RECP” state and abends leaving the tablespace in a very undesired restricted state. The consequence is a plan or a package (an application) will fail. XM4DB2 immediately alerts the responsible DBA and can take corrective actions. It links the required information and presents the 'whole story', the utility that failed, the affected objects and the afflicted application.

XM4DB2 not only detects problems but first and foremost it anticipates any upcoming problems. XM4DB2 reports timely an impending space shortage for table or indexspaces. Another example is in the area of recoverability. XM checks image-copies (the underlying datasets) and calculates the time to recover to ensure that service levels are satisfied. Database administrators will receive a message if XM4DB2 calculates that the expected recovery time is longer than allowed under service levels agreements. A decrease in IO performance can become an ugly problem in peak load times. XM4DB2 continuously monitors the IO behavior and bufferpool performance. It detects problems and tuning opportunities and signals any critical developments. XM4DB2 interfaces with the BPA4DB2 graphical workstation giving in-depth analysis and tuning guidance.

XM4DB2 maintains and displays a table of read more