The check of the Db2 systems is an iterative and fatiguing task, so why not automate it?

Here are some examples of where XM4DB2 detects and signals severe problems:

• Inefficient and badly arranged SQL statements waste resources and cause significant performance degradation of the overall system. XM4DB2 detects bad SQL and alerts responsible staff. It, for example, recognizes statements that provoke DSC trashing, it reports obsolete Runstats, and it indicates missing indexes. XM4DB2 monitors and examines access path stability for static and dynamic SQL.
• 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.
• Another example is in the area of recoverability. XM4DB2 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 current exceptions across the Db2 subsystems and enterprise wide. Each event is highlighted only once – the entry disappears when the problem is fixed. On urgent matters the system notifies the database and system administrators. There is a function with the option to automatically resolve ’standard‘ issues.

Some of the exceptions that are continuously checked include:

• SQL statements created without parameter markers
• Bad access path changes of SQL statements
• Most CPU consuming SQL statements
• Objects in an unexpected restricted state and all its affected plans/packages
• Foreseeable lack of space of objects whether attributable to z/OS, ICF or Db2
• Unrecoverable tablespaces due to missing image-copies
• Possible infringement of SLAs with regard to recovery time
• Missing Archived Logs; inconsistency with BSDS
• Stopped Procedures e.g. REJECT or QUEUE with queue length reached
• Stopped Utilities and affected objects
• In-doubt Threads and related system implications
• DDF status with regard to connections and threads
• Plans/packages that are invalid or inoperative or impacted by other failures
• Buffer pool related problems, e.g. avoidable re-reads, thresholds hit, etc.
• Unexpected load peaks in respect of getpage and CPU consumption

Cope with the Raw Data Overload
Db2 systems continuously change. Activities invoke Db2 messages with information on events, warnings about restrictions and error messages on probable pitfalls. A dedicated effort is necessary to view and extract from the flood of messages those which are relevant. Simply scanning for particular messages or analyzing the output of display commands is not enough. Early recognition of costly disruptions requires that the DBA evaluate different sources of information and reach timely conclusions. An automated and proactive supervision prevents emergecies and ensures continuous database availability.

Raw data or information – What serves you best?
Multiple monitoring programs for Db2 and z/OS deliver great raw statistics. Unfortunately, they all lack the ability to intelligently review the observations to determine when a true exception or error situation is about to happen. The primary purpose of these monitoring tools is to make data available to the experts analyzing Db2 system failures. The UBS approach is to keep avoidable problems from impacting the company in the first place by automatically tracking suspicious and potentially harmful   events in real time.

XM4DB2 is for Operations and Production DBA staff. It delivers a timely pro-active status update of the Db2 systems to improve and guarantee availability of all objects to their dependent applications.

XM4DB2 offers predefined best practices solutions and also supports customized exception definitions. An exception that repeatedly leads to a particular error, and seems in the short term to be unavoidable, should receive a standard treatment. XM4DB2 offers prepared jobs for repair and other functions. These jobs can be checked, edited and released by the staff or submitted to a scheduler for execution.

XM4DB2 is designed to easily accept new defined actions. Defined actions or a described set of events are treated as an exception. They are continuously tracked and generate alerts.

Why XM4DB2?
There are hundreds of messages and warnings on over 30+ possible restricted states. With just two Db2 systems using potentially thousands of tablespaces it is near impossible to manually observe and detect problems, with 10 or say 100 subsystems it’s definitely in the realm of the impossible.

It requires a dedicated program to unerringly find the events within Db2 and z/OS that are causing problems. With the naked eye it’s impossible to see what is going on and to gauge possible consequences. XM4DB2 tackles the non-stop supervision of the Db2 environment with its unique functionality and technology. Beyond saving time, effort and staff resources, it helps to keep mission critical applications running smoothly. How much does each minute of Db2 downtime cost your organization?