EZ-DB2 910 Enhancements Summary (V2)

EZ-DB2 910 Enhancements Summary

1 | P a g e

EZ-DB2 910 Enhancements Summary (V2)

Table of Contents Introduction ..................................................................................... 2 General ........................................................................................... 3

Reset command shortcuts ............................................................... 3 Select Plan Table information .......................................................... 4

EZ-Tracer ........................................................................................ 5 SET PROFILE command .................................................................. 5 Copy Workload Parameters ............................................................. 5 Automatically Delete Old Traces from Workload ................................. 5 Select IFCIDS to be traced .............................................................. 6 Capture Host Variable and Dynamic Literal Values ............................. 6 Extended XPRINT command ............................................................ 8 Display SQL Error Codes ................................................................. 8 Specify AUTHID and QUALIFIER Conversion ...................................... 9 Data sharing groups ..................................................................... 10 Access Path display enhancements ................................................ 11 Display Trace parameters ............................................................. 12 Trace filter wildcard changes ......................................................... 12 Reports Filter Command ............................................................... 12 Additional Trace Filters ................................................................. 13 SQL Statistics display ................................................................... 14 Index Utilization reports ............................................................... 16

EZ-Stats ........................................................................................ 18 Enhanced DB2 V9 Statistics Captured ............................................. 18 Select all databases ..................................................................... 19

EZ-SQL Warehouse ......................................................................... 21 EZ-Impact Analyzer ........................................................................ 22

No Bind-AP so Explain .................................................................. 22 Set Impact Analyzer Return code ................................................... 22

EZ-Index Analyzer .......................................................................... 25 Enhanced Predicate Set Analysis .................................................... 25 DB2 Virtual Index Support ............................................................ 27

EZ-XOP ......................................................................................... 31 Add TOTAL-COST processing for DB2 V9......................................... 31

EZ-Alerts ....................................................................................... 31 Alert Filtering in Reports ............................................................... 31 New Alert Types .......................................................................... 31


2 | P a g e

Introduction This document describes the many functional enhancements that have been introduced in EZ-DB2 through the APARS that have been released since the initial release of EZ-DB2 version 9.10. The enhancements described in this document include features implemented in APARs up to and including CX910112. The EZ-DB2 APARs are all cumulative. If you are still on the base release, or a lower APAR level, you only need to install the latest APAR to experience all of the new features described in this document. Note the APARs also include bug fixes not described. Only functional enhancements are described in this document. NOTE that changes compared to the previous version of this document are noted by a bar (|) in the left margin.


3 | P a g e

General

Reset command shortcuts Option 9.9 allows changes to the commands used to switch SQL drill displays. E.g. you may change AP for Access Path display to an alternate command of your choice. Hit ENTER repeatedly in Option 9.9 to move through the panel displays until the following panel is displayed.

Figure 1 Reset Command shortcuts Enter a new command abbreviation to be used in place of the default command.


4 | P a g e

Select Plan Table information When selecting a PLAN table for Explains, the panel now shows whether associated PLAN tables exist. DSN STMT Shows whether DSN_STATEMNT_TABLE exists for this plan

table. DSN DETCOST Shows whether DSN_DETCOST_TABLE exists for this plan

table. DSN STRUCT Shows whether DSN-STRUTURE_TABLE exists for this plan

table. Virtual Indexes Shows whether DSN_VIRTUAL_INDEX_TABLE exists for this

plan table. All Hidden Shows whether the various other hidden tables exist for this

plan table.

Figure 2 Select Plan Table


5 | P a g e

EZ-Tracer

SET PROFILE command If you usually use settings which differ from the defaults as standard for most new workloads you may wish to set these as the default initial settings for your new workloads. You can do this by issuing the command SET PROFILE when in the command line. This will save the current settings shown on the panel as the default initial settings for your userid and these will be used as the initial settings whenever you create a new workload. See also Copy Workload Parameters below.

Copy Workload Parameters To create a new workload with the same parameters as an existing workload you can now type CREATE workload-name in the command line, where workload-name is the name of the new workload name to be created.

Automatically Delete Old Traces from Workload If desired, Tracer will now automatically delete old traces from a workload to free up DASD space.

Figure 3 Trace filter parameters Refer to Maximum Kept Traces in Figure 3. The default value 0 means that all traces are kept for the workload. If you specify a value (1-99) for


6 | P a g e

maximum kept traces, the oldest trace will be deleted such that the number of traces retained for this workload does not exceed the maximum. Note that the data for the old deleted traces is still retained within the consolidated data for the workload. However, you will lose the ability to DRILL down on the data related to the old deleted traces.

Select IFCIDS to be traced Previously, you were able to enable/disable the collection of IFCIDs relating to FETCHs. You may now include/exclude other IFCID classes from the trace. Refer to Figure 3 Trace Filter Parameters. Specifically, you can now enable and disable the following IFCID classes:-

• Fetches • Prepares • Selects • Cursors • Insert/Update/Delete • Parallelism

Capture Host Variable and Dynamic Literal Values A much asked for feature is now available, and that is the ability to capture the specific host variable and literal values associated with specific SQL. Some background Historically, a fundamental design tenet of EZ-DB2 has been the ability to consolidate “essentially the same” SQL. That means merging the execution statistics of SQL where only the literal values were different. Typically, the actual values are of little interest, and the advantages of consolidating the SQL are explained below:-

• Most performance monitors are able to identify the SQL “elephants”, that is the really bad SQL where a single execution may have a long elapsed time and/or high CPU cost.

• However, it may be that these elephants should not be your cause for concern. For example, a particular elephant may be executed only once or infrequently. Spending time identifying and tuning this SQL may not warrant the effort.

• However, most DB2 systems have low cost cheap SQL that we shall call “mosquitoes”. These mosquitoes are not so easily identified by typical performance monitors. The problem is that these mosquitoes may be executed millions of times per day, and when added together


7 | P a g e

it becomes apparent that it is the mosquitoes that are the problem and need fixing, rather than the elephants!

• The reason that these mosquitoes fly under the radar of other performance monitors is that, where they use literal values, they are all considered by DB2 (and other monitors) as different SQL. You have a million mosquitoes, so how do you know where to look?

• It’s only when you consolidate these SQL (ignoring the literal values) that you get a true picture and suddenly see the mosquitoes replacing the elephants at the top of typical high CPU consumer reports.

• Another benefit of SQL consolidation is to drastically reduce the DASD requirement when capturing large workloads.

So that’s why we consolidate SQL and the benefit is fully appreciated by EZ-DB2 users. However, there are situations where it is desirable to also see Host Variable and Literal values. For example, in the consolidated workload you will see the TOTAL and AVERAGE CPU for all consolidated SQL, and just one representative access path (that would be derived from the 1st occurrence of the consolidated SQL). As some users have pointed out, this does not allow them to see the “outliers”. That is, 99% of the SQL may share the same access path, but particular host variable or literal values may have an adverse effect leading to degraded performance. It would be desirable to capture the host variable or literal values associated with these “outliers”. So the implementation of Host variable or literal value collection in EZ-DB2 has been designed to capture these values for the “outliers only”, identified by high CPU or GETPAGE activity.

Figure 4 Capture Host Variables Refer to the Trace Filters parameters as shown in Figure 4. To enable the capture of values for Host Variables and/or Dynamic Literals set the respective parameter to Y (default value is N) and ALSO specify a value for Minimum CPU MS and/or Minimum Getpages. The actual values will be captured for SQL that exceed the specified threshold. Note that

• The SQL captured with their individual values are also included with their execution statistics in the original consolidated SQL reports

• These thresholds for Host Variable and Dynamic Literal capture should not be confused with the Tracer Thresholds Min SQL CPU and Min SQL Getpages, which apply at the trace level, and do not relate to Host Variable and Dynamic Literal capture.


8 | P a g e

• To see the SQL and associated values refer to the new report option 25.5 - SQL with Captured Host Variables as shown in the following figure:-

Figure 5 Program SQL with Host Variables Captured You can DRILL on the SQL No to see the SQL Detail including the captured Host variable or Dynamic Literal values. You can DRILL on SQL Execs to see all occurrences of a particular SQL No. Refer to the EZ-Tracer/Cache user Guide for further information.

Extended XPRINT command When displaying SQL detail (e.g. SQL Text, SQL Statistics or Access Path) displays and you use the XPRINT command, the function has been extended to print ALL of the associated detail displays for the current SQL. As before the report is written to the specified SYSOUT class or dataset (and optional member name). This saves the user from having to repeat the XPRINT command on each screen.

Display SQL Error Codes There is a new report (Report 25.4 – SQL with Errors) to display SQL with negative SQL codes.


9 | P a g e

Figure 6 SQL with Errors The report shows the negative SQL code(s) and number of occurrences for each SQL in the workload that had an error.

Specify AUTHID and QUALIFIER Conversion Certain applications, typically SAP®, PeopleSoft and JDBC type applications make use of the SET CURRENT SCHEMA as a way of specifying the object qualifiers to be used by an application. This has the benefit of making the application code transportable. However, this presents a problem for EZ-Tracer/Cache as the SET CURRENT SCHEMA may have been issued before the trace started, and hence Tracer/cache has no way of knowing how to properly qualify the subsequent SQL. In the past, we have defaulted to using the current AUTHID as the qualifier; however this may not be correct. To resolve this issue, we now allow the user to specify the desired mapping of AUTHID to Object Qualifier.

Figure 7 ERP Controls On the Trace Filters panel the ERP controls option can now be used to specify the qualifier translation. In this field, the user enters “S” for SAP, “P” for PeopleSoft or “O” for other JDBC application. The user can then DRILL on this value to display the AUTHID/Qualifier translation panel as shown in the following figure:-


10 | P a g e

Figure 8 Authid/Qualifier translation In this panel the user is able to enter up to 12 values for AUTHID and the associated default QUALFIER to be used.

Data sharing groups

Figure 9 Trace data sharing group Support Trace at DB2 Group level. The DB2 Group Name must first be defined with DB2 Group = Y in the Activate Subsystem control panels. The panels will then allocate a member in ISPPROF for each member of the DB2 Group. In Tracer you may then opt to trace a single member of the Group or the entire Group.


11 | P a g e

Access Path display enhancements

Figure 10 Access Path Display Enhancements

• QBLOCK type added to access path display For each Query Block an indication of the type of SQL operation that is performed.

• Narrative A descriptive interpretation of the access path.

Additional Detailed access path costs are now displayed:-

• STEPCOST • OPENCOST • COMPCOST • COMPCARD • ONECOMP Rows • Stage 1 DM Rows • Stage 2 RDS Rows • Times • RowCount

Refer to the ONLINE HELP for a description of these fields. These values are only available if a DSN_DETCOST_TABLE and DSN_STRUCT_TABLE exist for the relevant plan table. These values show for example, the composite cardinality and Timeron cost estimate for each Query Block in the access path. Thus you can see the relative cost of the access to each step in the access path.


12 | P a g e

Display Trace parameters

Figure 11 Display Trace parameters A new option has been added to the Tracer reports menu to view the filter and consolidation parameters that applied to each trace. The data will only be present for traces generated after applying this APAR. Enter the trace number at the top of the reports menu to view the parameters for that trace.

Trace filter wildcard changes Trace filter wildcards aligned to DB2 V9 usage, so

• Instead of “%” use “*” as a prefix delimiter, e.g. ABC* for anything starting ABC.

• Instead of “*” use “_” for wildcard. e.g. A_C* for anything starting with A in position 1 and C in position 3.

Reports Filter Command

Figure 12 Report Filter Command


13 | P a g e

New FILTER commands have been implemented on most reports. To filter an existing report, enter the command FILT followed by the keyword Program, DBRM, Package, Plan, Collid, Authid, Table or Index as applicable. e.g. FILT PROG EC* to display only those report lines where program name start EC as shown above. The FILT command can only be applied to drillable fields ( i.e. highlighted in yellow).

Additional Trace Filters

Figure 13 New Trace Filters The filters that can be applied at START TRACE time have been extended to include the additional filters Connection ID, Workstation, User Id and Application Name. An Exclude option has also been added for all available filters. Note that DB2 V9 supports additional filter parameters on the START TRACE command, and where applicable these additional filters are now applied by DB2 at trace collection time. For earlier releases of DB2, the filtering is still applied by EZ-DB2 post-trace.


14 | P a g e

SQL Statistics display

Figure 14 SQL Statistics display The format of the SQL statistics display has been improved in the way that the CPU and elapsed times are displayed as shown in the previous figure. You can now DRILL down on the CPU and Timeron Cost fields to show the more detailed breakdown of CPU/Elapsed times and estimated costs as shown in the following figures:-

Figure 15 Detailed CPU costs


15 | P a g e

Figure 15 shows the breakdown of the CPU and elapsed time for the OPEN and associated fetches for a cursor statement as well as the Open/Fetch cost ratio. Notice that PREPARE time (total and average) is also broken out for dynamic SQL statements. When DRILLING on the Timeron cost, the following additional display is shown:-

Figure 16 SQL cost estimates When displaying the cost estimates, EZ-DB2 now displays the estimated CPU, estimated Service units, estimated Timerons and estimated Total-Cost (total and average). Note that Total-Cost is only shown for DB2 V9.


16 | P a g e

Index Utilization reports

Figure 17 Indexes used by workload Tracer reports now include an Index Utilization report for the workload as shown in Figure 17. For each table in the workload the report shows the following:- Table Name The name of the DB2 table. You can DRILL on the table name

to see a list of the SQL that reference the table. DRILL on the table name to see the TABLE statistics.

TBL SQL The number of SQL in the workload that reference this table. DRILL on this number to see ALL SQL in the workload referencing this table.

Total SQL CPU The total CPU cost of all of the SQL that reference this table. The tables are listed in descending order of CPU cost. Note that for SQL that reference multiple tables, the total cost of the SQL is accounted against each table referenced by the SQL.

CPU% The CPU total for this table represented as a percentage of the total cost of all tables in the workload.

Index name The name of each index that exists for the table. If the number of Index SQL is > 0 you can DRILL on the index name to see a list of the SQL that use a particular index. DRILL on the INDEX Name to see the INDEX statistics. You may also see the name TablScan as an index name. In this case, IX SQL indicates how many SQL are using table


17 | P a g e

scan against this table. IX SQL The number of SQL in the workload that uses a particular

index for this table, or table scan. DRILL on IX SQL to see ALL SQL in the workload using this index or table scan against this table.


18 | P a g e

EZ-Stats

Figure 18 Display table statistics The display table statistics has been improved as shown in the above figure. Previously, the user had to set a “toggle” to “C” or “I” and then drill on the table name to display the list of columns or indexes for the table. Now the fields NCols and NIxs have been made DRILLable. NCols The number of columns in the table. DRLL on this field to

switch to the table column statistics display.

NIxs The number of indexes defined for the table. DRILL on this field to switch to the table index statistics display.

Another “enhancement” to EZ-Stats, when using option 1 to copy statistics between subsystems; The EZ-DB2 statistics repository of the target subsystem is now updated with the statistics which have just been copied to that subsystem. This ensures that when using EZ-Stats to view the statistics on that system, the statistics viewed will be consistent with the statistics in the DB2 catalog.

Enhanced DB2 V9 Statistics Captured DB2 Version 9 introduced some additional statistics including DATAREPEATFACTORF in SYSINDEXES and HISTOGRAM statistics in SYSCOLDIST. These enhanced statistics are now captured when extracting statistics to the EZ-DB2 statistics repository, and are included when copying statistics between DB2 subsystems or updating a DB2 subsystem catalog from the statistics repository. The following figure shows an example of the SYSCOLDIST histogram statistics. Refer to the DB2 V9 Performance and Tuning Guide for further information about the HISTOGRAM statistics and DATAREPEATFACTF.


19 | P a g e

Note that another enhancement when displaying the SYSCOLDIST data is the SHOW option. Instead of displaying all of the SYSCOLDIST data types together in one display you can now select which SYSCOLDIST TYPE you wish to see, namely:-

• C – Cardinality • F – Frequent value • H – Histogram Statistics • N – Non-padded frequent value

The following figure shows TYPE H (Histogram statistics).

Figure 13 SYSCOLDIST Histograms Stats

Select all databases In order to make it easier to refresh ALL of the statistics in the EZ-DB2 statistics repository, a new option has been added to EZ-Stats option 5.5 to allow the user to select ALL of the databases. See Select All Databases in the following figure.


20 | P a g e

Figure 20 Add New database to Statistics Repository


21 | P a g e

EZ-SQL Warehouse

Figure 14 Adjust SQL Frequency of execution The Adjust SQL Frequency panel has been enhanced to include additional columns to the right, specifically - Total Clock, Total CPU, Total GetPages and Total Timerons. Page Right <PF11> to see the additional fields. This allows the user to sort by these additional columns when selecting which SQL to modify and / or exclude from further analysis. In addition, the user can now enter D or X in the delete column. For example, enter D To delete a particular SQL from the workload. As before.

X New! To delete all SQL to the end of the display. This makes it easier for a user to remove the lowest cost SQL from the analysis. Rather than having to enter D against each SQL that is no longer required the user can sort by Total CPU (for example) and then enter X to exclude all SQL from a particular SQL onwards.


22 | P a g e

EZ-Impact Analyzer

No Bind-AP so Explain

Figure 22 No BIND A-P so EXPLAIN A new option has been added to the panel used to Predict Impact on Access Paths of DB2 Vnext (option 6). In some cases, users do not have the current Vnow access paths to be used as the basis of the impact analysis when migrating to Vnext. This may be that historically they have not used EXPLAIN(YES) when binding applications, or they have simply not kept the PLAN tables relating to older applications. In some cases, applications may not have been bound for several years! These users may find the new option No BIND A-P so EXPLAIN to be useful. This option will result in all of the SQL in the selected DBRM library being explained to generate the Vnow access path version. It should be noted that this access path may not be equivalent to the actual access path being used for the SQL in the Vnow environment, but it does provide a basis for comparison and is better than nothing.

Set Impact Analyzer Return code To facilitate the inclusion of Impact Analyzer into existing batch job streams, the user can now create a user exit that controls how the return code is set, and the creation of additional batch job output.


23 | P a g e

A skeleton user exit is supplied in ezdb2.ISPEXEC called EZDBBW. Do NOT update this REXX program. This is the template from which you may generate your own tailored version to produce the results you want to feed into your own procedures. To implement this feature create a member in the ISPEXEC dataset called EZDBUSR1 using the code following the comment: "Start of code to be copied into EZDBUSR1" then tailor EZDBUSR1 following the instructions embedded within. The following parameters may be specified:- output_ddname =”OUTDDN”

Output_ddname defines the DD name to use for the lists produced. If the DDNAME is defined in the step JCL then output_dsname and output_member are ignored. Defaults to OUTDDN

output_dsname = “ “

output_dsname defines the dataset to use for the lists produced. It must be fully qualified and pre-allocated and may be a PDS or PDS/E in which case the member name following will also be used.

e.g. output_dsname = "MY.OUTPUT.DATASET" If you want the Workload name as part of the DSN then code it as in this example:

output_dsname = "MY.OUTPUT."||workload||".DATASET" If the output_dsname is null then the program exits RC 0. Any detected inconsistencies result in a message and RC 16.

output_member output_member defines the member name to be used in the dsname defined above. The (recommended) default is the workload name.

output_member = workload - to use Workload name output_member = "MYNAME" - to use a hard coded member name output_member = "" - if NOT using a PDS

The following flags control the level of output produced. e.g. list_changed_packages = "Y" will output a list of packages that have changed preceded by a "header". If no packages have changed then a header followed by "None" will be output.

If all the requested output is "None" the program will


24 | P a g e

terminate with a RC of 0. Otherwise the program will terminate RC 4.

list_changed_packages = "N" list_unchanged_packages = "N" list_better_packages = "N" list_worse_packages = "N" list_changed_DBRMs = "N" list_unchanged_DBRMs = "N" list_better_DBRMs = "N" list_worse_DBRMs = "N"

The user may code conditional job steps in the JCL based upon the return code set by EZDBUSR1. For example, in a compile, link and bind procedure. The user may embed the Impact Analysis job in the JCL and suppress the bind if it would result in deteriorated access paths.


25 | P a g e

EZ-Index Analyzer The EZ-Index Analyzer product has gone through a major revamp. While the basic functionally is still centred on identifying the predicate sets that are matched, unmatched or partially matched in respect of existing indexes, the level of detail and reporting is significantly improved. The reporting structure makes it far easier to identify the predicate sets and their relative costs within the context of the workload. When looking at the predicate set, there is far more information about the column usage within the set. Another major enhancement is the fully integrated support for DB2 Virtual indexes. The user may now easily convert an unmatched predicate set into a Virtual index and then re-explain the associated SQL to see if the DB2 Optimizer will indeed select that index and improve the access path. Examples of screens from the new Index Analyzer are shown below. For full details, refer to the latest EZ-Index Analyzer User Guide.

Enhanced Predicate Set Analysis The Index Analyzer Summary report shows for each entity, the number of predicate sets that have been identified, the number that match, the number that have no match and the number that are partially matched when compared against pre-existing indexes. It is possible to DRILL down on any of these values for greater detail.


26 | P a g e

Figure 23 Index Analyzer Summary For example, the following figure shows a DRILL down on No Match Predicate sets, that is, all of the predicate sets which have no corresponding index.

Figure 24 No Match Predicate sets This display shows all of the predicate sets with no matching index, in descending cost sequence. Each Predicate set is identified by a unique predicate set number. The display shows the number of SQL using the


27 | P a g e

particular predicate set, and the cost is the total cost of all of the SQL in the workload that uses the set, and taking into account the execution frequency. You can DRILL on a particular Set NO to see the Predicate set detail as shown in the next figure:-

Figure 15 Predicate set detail This figure shows the Predicate set detail report for Predicate set 1205. The display lists the columns that constitute the set, and describes how each column is used. For example, it may be indexable equal or range, join, non-indexable stage-1 or stage-2, order by etc. Detailed statistics are also available by scrolling right on this display. In the above example, you can see that this predicate set contains two columns used as EQUAL predicates, and another column TIME_STAMP that is used as the subject of an ORDER BY.

DB2 Virtual Index Support As the tool has identified that the above predicate set is associated with high-cost SQL, and there is no corresponding index serving this combination of predicates, the logical question is, how much benefit would an index matching this predicate set represent? EZ-Index Analyzer is able to answer this question by easily creating a DB2 Virtual Index, and allowing the user to re-explain the relevant SQL. For example, the user types VI 1205 in the command line to automatically create


28 | P a g e

a virtual index based on this predicate set definition. The following screen would be displayed:-

Figure 26 Create Virtual Index This display shows the EZ-DB2 Create Virtual Index panel which is automatically populated with the values to create a virtual index for the applicable unmatched predicate set. The Virtual Index name is generated according to a pre-set rule, namely EZ-DB2_IX-SET_suffix, where suffix is the Predicate set name. Most of the statistics are automatically populated with known values or values that can be deducted. Certain values, namely the Estimated Colgroup cardinality need to be entered by the user based upon local knowledge.

The EZ-DB2 Virtual Index function takes advantage of the new DB2 Virtual Index support. When a Virtual Index is created, the DB2 Optimizer “sees” that index as if it were a real index when making access path choices. Virtual Indexes may be created to simulate the creation of a new index or a drop of an existing index. Apart from automatically creating virtual indexes for unmatched predicate sets as shown above, EZ-Index Analyzer may also be used to explicitly build Virtual indexes for both CREATE and DROP. Refer to the DB2

9.1 Performance Monitoring and Tuning Guide for further information about Virtual Indexes. After Creating a Virtual Index, the user may re-explain the SQL associated with the predicate set to test whether the new index would be chosen by the optimizer. The following display shows the SQL text for one of the SQL associated with this predicate set:-


29 | P a g e

Figure 167 SQL Text for unmatched predicate set In this display you can see the EQUAL Predicates and the ORDER BY corresponding to this predicate set. The following figure shows the access path analysis for this SQL after performing the new explain:-

Figure 28 Access Path using Virtual Index The Version O access path is the original or “actual” access path. You can see the access path contains a table scan on the table USATVPRT as well as a SORT for ORDER BY. The Version T access path is the Test access path generated by the new Explain. You can see that the access path uses the newly created “virtual” index (matchcols=2) and there is no SORT. This suggests an improvement but we can verify that by looking at the CPU costs display for the SQL as shown in the following figure:-


30 | P a g e

Figure 29 Estimated costs with Virtual Index Here we can see the estimated TIMERON COST for the Version O and the Version T access paths respectively. The display shows a projected 48% improvement. Remember, these aren’t our cost estimates, they are the actual cost estimates generated by the DB2 Optimizer. Users familiar with EZ-DB2 will know that you can DRILL on the TIMERON estimated costs to see the estimated CPU and estimated Service Units for Version O and Version T respectively. These displays show just a small part of the new functionality of EZ-Index Analyzer. For further details, please refer to the EZ-Index Analyzer User Guide.


31 | P a g e

EZ-XOP

Add TOTAL-COST processing for DB2 V9. An option had been introduced in EZ-XOP to use DB2 estimated Total-Cost as an alternative to estimated TIMERON cost in evaluating access path alternatives. Total-Cost is a new metric introduced by IBM in DB2 V9 which takes into account both CPU and IO cost, and is professed by IBM to be a more accurate cost indicator than Timerons.

EZ-Alerts

Alert Filtering in Reports When displaying an access path for an SQL (AP command) it has always been possible to filter the displayed ALERTs using the ALERTs filter panel (AL). What has not been commonly known is that you can also use the AL panel to filter the reports when displaying the various Alert Reports in EZ-Alerts. The documentation suggests that you need to go into option 1 (enable/disable alerts) and regenerate the alerts report using option 2 before displaying the alert reports again. In fact that is not necessary. What is recommended is that you enable ALL of the alerts in option 1, then use the Alert filters command (AL) to filter the reports as required.

New Alert Types Various new Alert types have been added, including

• DB2 V9 reserved words • SQL uses DISTINCT with JOIN • SQL average fetches =1

EZ-DB2 910 Enhancements Summary (V2)

Documents

Transcript of EZ-DB2 910 Enhancements Summary (V2)