Can XM4DB2 repair exceptions automatically?
Yes XM4DB2 can. The user can specify skeletons that are tailored and submitted when an exception was found. The skeletons can contain a set of variables like the object names and DB2 parameters. With these skeletons it is possible to do all tasks needed to repair an exception automatically.
Can XM4DB2 send emails to notify about exceptions?
Yes, XM4DB2 sends out emails to notify the user about new exceptions. Therefor XM4DB2 collects a set of messages and sends them out in a specifiable interval and also each exception is reported only once to avoid a flood of emails. Very critical exceptions can be sent out immediately.
Does the DSC component of XM4DB2 have the capability to combine an identical statement captured at 10 a.m. and one at 3 p.m. when summarizing metrics?
Yes – Strings and numbers are removed from the statement text – the remaining text is converted to a unique long integer value (“Hashkey”). The calculation is done using these “hashkeys”.
Does the DSC component of this tool have the capability to identify the tables used by statement/program/package and the indexes used? This would aid in removal of unused indexes.
This can easily be analyzed by a sql query: our historic PLAN_TABLE_H, which includes index and table names, has a unique key. The same key is present in the table where the statements are kept. So it is a simple join between both tables, to find out which statements are using which table or index.
Does XM4DB2 run the whole day?
XM4DB2 runs in intervals to spare the system resources. The intervals can be specified individually for each type of exception, so it is possible to check for the most critical exceptions more often.
Does XM4DB2 sample the cache often enough to capture all dynamic SQL?
The capture frequency depends on parameters. Normally 4 capture runs per day are enough. Panels show the residency time of the SQL in the cache, so it is easy to adapt the parameter.
Does XM4DB2 use a tool specific PLAN_TABLE or the system PLAN_TABLE?
We use a specific plan table, but also the system plan table. The specific plan table is used for dynamic statements and the system plan table is used to analyze static statements.
Has XM4DB2 a single point of control?
Yes XM4DB2 has. There is one director task managing the parameters and settings of XM4DB2. With an ISPF user interface it is easy to specify what kind of problems should be observed, how they should be observed and how often XM4DB2 should run. From this single point it is also possible to display all the exceptions found from all DB2 systems in the environment.
How are non-parameter marked SQL calls combined?
By removing strings and values from the statement text and converting the remaining text to a long integer value, the so-called “hashkey”.
How is the HASHKEY created and will the same statement possibly have different HASHKEYs over time?
The hashkeys are built by reducing the SQL Text to the absolute minimum (removing space, removing coded constants like ‘SMITH’ and removing numbers like “WHERE CUSTOMER = 399399” . This technique avoids having different HASHKEYS over time. But: same statements with different table names get different HASHKEYs, because we believe these are to be considered as different statements. Different tables might have completely different numbers of rows, indexes etc. – so they would not be comparable from a technical point of view.
How long does an installation take?
XM4DB2 can be installed and deliver the first results in less than two hours. After receiving the program files, creating the database and specifying the environment with it’s DB2 systems XM4DB2 can do the first checks with the default settings. Then the user can specialize XM4DB2 step by step by customizing the parameters.
Is it possible to define different supervision parameters for each DB2?
Yes it is. The parameters as well as the definition what an exception is can be specified in several levels. That means the user can specify one parameter or exception definition for all DB2 systems in the environment. But he also can specify a special set of parameters of definitions for a certain DB2 system. Even for a couple of objects in a DB2 system an individual set of parameters and definitions can be specified.
What is an exception?
With the notion exception we describe any situation or state of objects in a DB2 system that is a problem, critical, or just undesired. An exception is an unwanted restricted state of a tablespace as well as a problem with DDF. XM4DB2 is able to detect a set of exceptions like restricted states of spaces, foreseeable lack of space problems, problems with DDF, plans, packages, utilities, and procedures, problems with the recovery for example missing imagecopies, etc.
Where has XM4DB2 to be installed?
XM4DB2 consists of an observer part collecting and processing exceptions, an ISPF user interface managing the parameters and displaying the exceptions and optionally a director part building the note where all observer parts can connect to the single point of control. The observer part has to be installed on each LPAR where a DB2 system should be checked on. The observer can check all DB2 system on a LPAR. The observer and the director communicate via TCP/IP.
Where is the DSC history stored?
All history and exception information is stored within DB2 tables.