TurboTuneSQL for DB2 · 2020. 2. 28. · problems in DB2 z/OS applications. It is an integrated tool that covers the most important aspects related to the process of analyzing DB2

TurboTuneSQL for DB2

VERSION 12.0

USER GUIDE

User Guide Manual

TurboTuneSQL for DB2 V120- User Guide – 2019. All Rights Reserved.

Preface

This document “as is” without warranty of any kind, including without limitation, anyimplied warranties of merchantability, fitness for a particular purpose or non-infringement. In no event we will be liable to the end user or any third party for any lossor damage, direct or indirect, from the use of this document, including withoutlimitation, lost profits, business interruption, goodwill, or lost data.

This publication may be changed to describe product changes available via fixes orfuture releases or to correct inadvertent misrepresentations. This publication couldinclude technical or typographical errors and this may make changes in the productsdescribed in TurboTuneSQL document. Always consult your local softwarerepresentative for updates to this material.

If license period terminates for any reason, it’s the user’s responsibility to have thisdocument destroyed.

This document may not be copied, transferred, reproduced, disclosed or duplicated, inwhole or in part, without the prior written consent of RALPHJCASTALDI.

© Copyright RALPHJCASTALDI, 2007-2019

Trademark Acknowledgments

The following are trademarks or registered trademarks of IBM Corporation: CICS, DB2,DFSMSdfp, IMS, Language Environment, MQSeries, MVS, z/OS, OS/390.

Microsoft Windows and the Windows logo are trademarks of Microsoft Corporation inthe United States, other countries, or both.

Java is a trademark of Oracle in the United States, other countries, or both. BMC is atrademark of BMC Software, Inc. The CA brand is a trademark of Computer Associates.

Other product and company names mentioned herein may be the trademarks orregistered trademarks of their respective owners.

Related Documents

Related documentation: TurboTuneSQL-User Guide TurboTuneSQL-Installation Guide TurboTuneSQL-VIRT User Guide TurboTuneSQL-Messages Guide

Revision: 2019-OCT-31 (CHANGE X0560)

TurboTuneSQL for DB2 V120 – User Guide – 2019. All Rights Reserved.

2

Contents

Charpter 1. Introduction

Charpter 2. Using TurboTuneSQL

Charpter 3. Online Reports

Charpter 4. Batch Report Reference

Charpter 5. Utilities

Appendix A. TurboTuneSQL Tables Reference

Appendix B. Console Commands

Appendix C. Online Commands

Appendix D. Algorithms

Appendix E. Limits

Appendix F. Plan Table Description

Appendix G. JCL Description

Appendix H. TurboTuneSQL CHANGES

Appendix I. Numerical and Time formats

Appendix J. TIPs

Appendix K.How to apply fixes to TurboTuneSQL

Appendix L. TurboTuneSQL PASSWORD SETUP

Appendix M.TurboTuneSQL Common Online Commands


3

Chapter 1. Introduction

We know that every business needs to reduce cost and to launch new products in shorttime and to spans. The availability and quality of those application systems must alsobe constantly improved. But continual business changeovers alter the system usagewhich generates degradation in IT production. These constant changes are associatedto new failures.

There is constant pressure to reduce IT costs. TurboTuneSQL for DB2 helps companiesto address these issues, because it can easily identify problems in DB2 z/OSapplications with an unique Integrated Tool.

What is TurboTuneSQL

TurboTuneSQL offers a complete solution to monitor and discover performanceproblems in DB2 z/OS applications. It is an integrated tool that covers the mostimportant aspects related to the process of analyzing DB2 z/OS applications. Also,TurboTuneSQL has several unique features that actually innovate the methods toidentify problems in DB2 applications.

The main idea of TurboTuneSQL is to analyze your DB2 environment using all theinformation available from DB2: Traces started along with DB2 execution with aminimum overhead, SQL texts from all possible sources, table definitions and ExplainData. All this data is saved in a repository making it possible to do an integratedanalysis of your DB2.

Optimal performance gains can be reached because your entire DB2 workload can beused as a starting point in the process of analyzing DB2 performance, instead of justanalyzing a single Batch Address Space or a single CICS Transaction. This point of viewoffers the best way to save more DB2 CPU than any other process. Applying efforts toimprove performance for top consumers will guarantee the best overall results for theentire z/OS, saving more CPU cycles and I/Os.

Also, TurboTuneSQL can be used in a Workload Base approach. That’s is veryimportant. The analysis of performance problems are based on workload only(executed programs). Performance improvement for one statement withTurboTuneSQL in an application always takes in consideration other statements in thesame or other application.

The effort for tuning the whole application with good performance by evaluating everystatement is overwhelming. TurboTuneSQL speeds up the analysis.

TurboTuneSQL has monitoring capabilities and it gets information from several sources(DB2 traces is just one source) to process all them together to achieve best final resultsfor performance recommendations.

This product can be used by everyone responsible for the quality of DB2 performance.It may still be used for tasks related to capacity planning as well.

The next figure below is an overview of how TurboTuneSQL works.


4

Integrated Analysis

TurboTuneSQL basic points are:

Optimal performance gains: the entire DB2 workload can be analyzed, not only a single CICS transaction

Several performance indicators can be collected. Examples: SQL commands which consume more resources, like DB2 CPU, WAIT, LOG

Allows a Cross Reference and an Impact Analysis for DB2 Objects Non intrusiveness Creates a SQL Inventory DB2 applications performance analysis associated to index recommendations Index recommendations are performed on a global basis, and not just for an

individual table or application Integrated Analysis approach: DB2 workload data, SQL Source, DB2 Tables

Definition and DB2 Explain Data can be used together in the analysis process (automaticly or manually)

Several Online and Batch Reports help you to analyze your DB2 Virtualization and Copy of Statistics will give accurate measurements for statement

explain, specially for the automatic index recommendations.

TurboTuneSQL measures the whole DB2 Workload

TurboTuneSQL was designed to measure your entire DB2 Workload, and not only aspecific CICS transaction or job. This way it is easy to identify the total CPUconsumption used by the top SQLs consumers. On the other hand, TurboTuneSQL willalso help to identify those SQLs with little consumption of CPU in each execution butspread among all applications which will also result in high CPU consumption.

A workload is a means of identifying a group of applications so that performance datacan be collected.


5

All DB2 traces can be started using sampling mode feature of TurboTuneSQL. Thisreduces the total amount of data to be processed by the product and reduce the DB2overhead associated with DB2 traces. This feature and others mentioned in the nextsections, will prevent high overhead associated with DB2 traces for small or even largeDB2 environments.

TRACE OPERATES THROUGH SAMPLING

The following DB2 traces are used by TurboTuneSQL: DB2 Accounting Traces, DB2Performance Traces (also used to capture activities of dynamic SQLs) and Traces fromDB2 CACHE (dynamic and static SQLs). DB2 Accounting Traces and DB2 Performance Traces are stored in SMF types 101 and102 respectively and they must be active in your system. This version of TurboTuneSQLcan only work with SMF or GTF data, therefore all DB2 traces must be redirected to oneof these 2 options. Also, DB2 performance data from SQL Cache Area (dynamic and static SQLs stored inEDM Pool) may be used by TurboTuneSQL (the collect of static SQLs from SQL CacheArea will be available only if add-on feature TurboTuneSQL-REAL TIME CACHE wasacquired). Overhead to collect DB2 Cache data is maximum 1.5%.

TurboTuneSQL data is stored into DB2 (TurboTuneSQL Repository). All input informationprocessed is done in Batch processes and the result is stored in this Repository.Reports and Utilities make use of this database.

TurboTuneSQL makes extensive use of DB2 LOAD table utility. This allows to reduceCPU and Elapsed time consumptions during its Batch processing. Also, SORT programis used to reduce and group information processed by TurboTuneSQL.

TurboTuneSQL Repository (Accounting and Performance Tables) keeps a historical viewof all DB2 Workloads.


6

Non intrusiveness

Non intrusiveness means TurboTuneSQL does not create hooks into the DB2 system.Only normal DB2 APIs are used. This is a very important point to consider when runningtools on heavy production systems.

TurboTuneSQL SQL Extractor and SQL sources

One important feature is TurboTuneSQL SQL Extractor. This functionality reads SQLtexts and it breaks them down into small pieces of information like columns used,column functions, predicates, ORDER BY and GROUP BY clauses, etc. All informationare stored into TurboTuneSQL Repository (Source Tables).

This is a useful feature because users can quickly see how one DB2 table are beingaccessed in a single point of view. For instance, you can see and analyze how aparticular DB2 table is being accessed for more than 100 different SQL static ordynamic commands in a summary screen with all used SQL predicates. This facilitycan save hours or days of work for the DBA analyzing DB2 performance problems.Further more, sometimes it is virtually impossible to have this information compiledbecause of dynamic SQLs or large DB2 applications (like in ERP systems).

All information extracted from TurboTuneSQL SQL Extractor create the SQL Inventory,which is another facility.

With this inventory, it is possible to analyze SQLs from several sources. It can analyzeSQLs from:

DBRM data sets DB2 Catalog Sequential data sets Dynamic SQLs from DB2 Performance Traces or from DB2 SQL Cache Area

(EDM POOL). This facility will allow you to examine SQLs from applicationslike IBM QMF, Java, Client Server application using IBM DB2 Connect, etc.


7

SQL Inventory

DB2 DBAs know that, normally, dynamic SQLs are difficult to analyze because theydon’t have a SQL statement number, different from a static SQL which is alwaysassociated with a SQL statement number. Therefore, dynamic SQLs do not have aneasy means of being identified in performance analysis, specially in terms of ahistorical view.

On the other hand, SQL statement number used in static SQLs are totally dependent onprogram maintenance because the SQL statement number is derived from DB2precompile line number. In other words, if you modify your program code, the SQLStatement Numbers normally change even if the SQL commands are not changed. Inthis sense, you will lose all historical views in terms of performance analysis.

TurboTuneSQL SQL Inventory is a very powerful feature and addresses the previousissues. The SQL Inventory facility creates new identifiers for each SQL command. Four(4) new identifiers are created for each SQL command. This facility is used in the entireproduct. These new identifiers are:

o SQL Statement Unique: identify ‘same’ SQL textso SQL Statement Group Tables: identify SQLs with ‘same’ Group of

tableso SQL Statement Group Columns: identify SQLs using ‘same’ DB2

predicateso SQL Statement Group Sort: identify SQLs using ‘same’ columns in

group by and order by clauses.

This facility allows a global SQL command analysis between applications and programs,regardless of which application language was used for both dynamic and static SQLs.Therefore, it is possible to track down any SQL changes in application maintenance. Other benefits are: identification of inadequate standards, poor code standardization,identification of same chances of improvement in different applications. These benefitshelp redirect efforts to a more efficient form of codification to fit your performanceneeds.

The TurboTuneSQL SQL Inventory allows a historical view of all DB2 Workload.

These new identifiers are shortly described in the next sections. For more informationplease check Appendix Algorithms in this manual.

SQL Statement Unique

This is a 4 bytes identifier that allows you to identify and group ‘exactly’ the same SQLcommands. This number will always be displayed in hexadecimal format.

Example:

The SQL command below will be assigned with the number 0403AABC fromTurboTuneSQL Statement Unique Algorithm:

DECLARE CURSOR CSR1 SELECT A.COLA, A.COLB FROM TABLE_CUSTOMER AWHERE A.COLA = 1 AND A.COLB = ?

TurboTuneSQL will assign the same Statement Unique Identifier for the SQL command below, because they are ‘exactly’ the same

DECLARE CURSOR CSR3 SELECT A.COLA, A.COLB FROM TABLE_CUSTOMER AWHERE A.COLA = 1 AND A.COLB = ?


8

SQL Statement Group Tables

This is a 4 bytes identifier that allows you to identify and group SQL commandsaccessing ‘exactly’ the same group of tables. This number will always be displayed inhexadecimal format.

Example:

The SQL command below will be assigned with the identifier 03A1B1C3 from TurboTuneSQL Statement Group Tables Algorithm:

DECLARE CURSOR CSR1 SELECT A.COLA, A.COLB FROM TABLE_CUSTOMER A, TABLE_ORDER B

WHERE A.COLA = 1 AND A.COLB = ? AND A.COLA = B.COLA

TurboTuneSQL will assign the same Statement Group Table Identifier for thecommand below, because both use the same DB2 tables:

DECLARE CURSOR CSR3 SELECT Z.COLC FROM owner1.TABLE_ORDER X,TABLE_CUSTOMER Z

WHERE Z.COLA = ? AND Z.COLA = X.COLB

SQL Statement Group Columns

This is a 4 bytes identifier that allows you to identify and group SQL commands with‘exactly’ the same group of DB2 predicates. This number will always be displayed inhexadecimal format.

Example:

The SQL command below will be assigned with the identifier A5B1C001 from TurboTuneSQL Statement Group Columns Algorithm:

DECLARE CURSOR CSR1 SELECT A.COLA, A.COLB FROM TABLE_CUSTOMER A, CORPORATE_TABLE B

WHERE A.COLA = 1 AND A.COLB = ? AND A.COLA = B.COLA

TurboTuneSQL will assign the same Statement Group Column Identifier for thecommand below, because both have same DB2 predicates.

DECLARE CURSOR CSR3 SELECT B.COLC FROM CORPORATE_TABLE A,TABLE_CUSTOMER B

WHERE A.COLA = B.COLA AND A.COLA = 1500 AND A.COLB = 3


9

SQL Statement Group Sort Columns

This is a 4 bytes identifier that allows you to identify and group SQL commands with‘exactly’ the same group of columns in group by and order by. This number willalways be displayed in hexadecimal format.

Example:

The SQL command below will be assigned with the identifier A5B1C001 from TurboTuneSQL Statement Group Sort Columns Algorithm:

DECLARE CURSOR CSR1 SELECT cola, colb TABLE_CUSTOMER A WHERE A.COLA = 1 ORDER BY COLB

TurboTuneSQL will assign the same Statement Group Column Identifier for thecommand below, because both have same DB2 predicates.

DECLARE CURSOR CSR3 SELECT * TABLE_CUSTOMER A WHERE A.COLZ = ? ORDER BY COLB

Identicals and Similars SQLs

For TurboTuneSQL:Identicals SQL are SQLs that receive that same SQL Statement Unique number.

Similar SQLs are SQLs that receive that same SQL Statement Group Tables plus SQL Statement Group Columns number (from predicates).


10

TurboTuneSQL Reports and Index Recommendations

TurboTuneSQL is a complete solution to monitor and discover performance problems inDB2 z/OS applications. It has 2 main logical components: Reports and IndexRecommendation.

TurboTuneSQL Reports gives you a lot of information about vital DB2 performanceindicators, like DB2 CPU, DB2 Wait time, etc. Check Chapter 3 and Chapter 4 for moreinformation.

TurboTuneSQL Index Recommendation is a very important tool of this product. It helpsusers in 2 different ways in an indexes analysis process: Automatic and Manual IndexesRecommendation. Just to emphasize, here follows a brief explanation of why indexesanalysis is a very important component of DB2 performance analysis.

There are several ways to improve performance in DB2 applications: SQL optimization

Change SQL syntax to help DB2 be more efficient

DB2 Subsystem customizationChange DB2 ZPARM (or other DB2 facility, like DB2 Buffer Pools) to improve DB2overall performance

New HardwareBuy new and improve hardware (Disk, CPU, etc)

Table maintenance (REORG, RUNSTATS and REBIND)Procedures that must be executed with some frequency to help DB2 be moreefficient

Design or Redesign of ApplicationsCreate or Change your application code to be more efficient

Design or Redesign Database ModelCreate or Change your Database Application Model to help more efficientprograms be written or changed. De-normalization sometimes is required

Design or Redesign Database Physical Modelo TableSpace, Table name and Views Parameters

Check Lock Level, Compression, etc o Design or Redesign of table Indexes

Design or Redesign of DB2 Indexes is one of the most attractive ways to reduce use ofresources in DB2 and in any other Database System, because it provides exceptionalsavings in terms of CPU and I/O usage. And, it is the most objective way to improveperformance. This is because usually, new indexes do not demand intervention in theapplication code nor demand new application to be tested again to check if problemswould be introduced because of new or changed Indexes. The correct Index manipulation is a very difficult task to be done because they requirea global analysis. There are several issues to be addressed:

How many Indexes should be created? It’s known that too many indexes makeSQLs update, delete and insert slower.

Will other SQLs be negatively affected by new Indexes? Sometimes, Indexescreated to bring a better performance to a particular application have a negativeeffect on other DB2 applications causing an overall increase on DB2 resourceconsumption.

Which columns should be used in the Index Creation? The only way to discoverthis information is checking all SQLs from all source (QMF, static SQLs, Dynamic


11

SQLs, etc). Now you should test all possible column combinations to generateone or more indexes to attend all checked commands.

This is a mathematical problem: the combination of several columns distributedin several indexes. An Index with columns A, B, C is completely different fromanother Index with columns C, A, B. In mathematical terms, this is factorialproblem (N!) which means this is almost impossible to be done manually.

When we have dynamic SQLs, how do we determine Indexes to be created oreven dropped?

Production workload is dynamic. The access pattern changes over time.


12

Operational Scenarios

This topic describes some possible operational scenarios.

As stated previously, the main idea of TurboTuneSQL is to analyze your DB2environment using all information available from DB2: Traces started along with DB2execution, SQL text from all possible sources, and Explain Data with a minimum ofoverhead. All this data is saved in a repository making it possible to do an integratedanalysis of your DB2.

Below are some possible operational scenarios:

Collecting DB2 trace Data in your production LPAR. Execute all other TurboTuneSQL batch jobs in the same LPAR Pros

All results will be accurate. All TurboTuneSQL functions will work properly All real production data will be examined

Cons CPU consumption in Production

Collecting DB2 trace Data and run TurboTuneSQL batch jobs in a production LPAR. At the end, load TurboTuneSQL tables in the Development DB2 environments.Pros

Most of all results will be accurate. Most of all TurboTuneSQL functions will work properly All real production data will be examined Less CPU consumption in Production With Environment Virtualization and Copy of Statistics, explain and Index

recommendations results will match production. Cons

None.

Collecting DB2 trace Data in LPAR from production but running all other TurboTuneSQL batch process into LPAR DevelopmentPros

Less CPU consumption in Production Most of all production data will be examined With Environment Virtualization and Copy of Statistics, explain and Index

recommendations results will match production. Cons

Results will not be accurate. Some facilities will not work properly. Examples:

– Table qualifier inside dynamic SQLs could be different – Table layout could be different – Different level of correction (PTFs) or DB2 customizations


13

This figure below illustrates the above scenario:


14

Security Implementation

TurboTuneSQL always relies on DB2 security mechanisms.

Some examples of security implementation that can be done to protect yourenvironment:

Authorize TurboTuneSQL DB2 Plan only for people able to use TurboTuneSQL ISPF application.

Create 2 TurboTuneSQL Plan tables. One for batch use and anotherspecifically to use in TurboTuneSQL ISPF application. So batch operators willnot have access to ISPF application.

Use RACF or another facility to protect TurboTuneSQL libraries

TurboTuneSQL Automatic Index Recommendation is the only utility to make use ofRACF facility class.

Online commands related to security are explained in more details on Appendix M.


15

Maintain TurboTuneSQL

TurboTuneSQL is a DB2 application. So, like any other application, you must alwaysperform RUNSTATS and rebind your TurboTuneSQL tables and packages. There aresome sample jobs provided by the product to execute these tasks J000REBI, J000REOR,J000RNST. Consult TurboTuneSQL Installation Guide for more information.

Another point: you must ALWAYS backup TurboTuneSQL tables. This is very importantbecause TurboTuneSQL makes intensive use of DB2 Load Function with options: LOGNO , RESUME and NOCOPYPEND. For recovery purposes, you must execute DB2 COPYutility before any batch run.

Always check space increase. Sometimes, you need to run TurboTuneSQL Clear Tablesutility to delete unused data to save space and improve TurboTuneSQL productperformance.

Also, you must look for new fixes at least each 6 months to maintain you system up todate. Check How to apply fixes to TurboTuneSQL for more details.


16

Chapter 2. Using TurboTuneSQL

TurboTuneSQL is capable of analyzing your DB2 environment using all informationavailable from DB2: Traces started along with DB2 execution, SQL texts from allpossible sources, Table Definitions and Explain Data. TurboTuneSQL store allinformation in TurboTuneSQL Repository.

Note: After changing any parameter, you will only need to re-create the JCL if it is specified.


17

Start TurboTuneSQL

To use TurboTuneSQL start the main product CLIST using the following command:

TSO EX '<TurboTuneSQL.SADVCLST data set.SSID>(START)'

There are several Online Commands that you can use to speed up screen navigation.Check Appendix Online Command for more details.

The screen below is main menu of TurboTuneSQL.

Here you can see screen name (MAIN MENU), TurboTuneSQL Profile(IVP), Edit Mode(the above figure shows that current profile are in Edit Mode {E}) and connected SSID(DBBG). Customer name is taken from password file.

Note: To avoid terminal wrong input/output data, fields Term CCSID (terminal CCSID)and Profile CCSID number (obtainned from TurboTuneSQL Profile) should show samenumbers. If numbers does not match, message 'MAIN05' will be displayed.

When running TurboTuneSQL on Trial mode, the “Trial Mode” literal and number oflines will be displayed on the right side of the screen after Customer Name. The licensewill expire soon. For any questions contact your local representative.


18

TurboTuneSQL V120 --------------- MAIN MENU ----------------------------- 13:2Option ===> Profile : IVP {E} 0 - TurboTuneSQL Profile DB2 SSID : DBBG 1 - SQL REAL TIME MONITOR User ID : IBMUSER Time : 13:25 2 - MANAGING COPY OF CATALOG STATISTICS Language : English Tso Logon: DBSPROCB 3 - ENVIRONMENT VIRTUALIZATION System Id: S0W1 MVS Acct : ACCT# 4 - SQL INVENTORY AND WORKLOAD Appl Id : SADV 5 - MANAGING INDEX RECOMMENDATIONS Term CCSID: 00037 Prof CCSID: 00037 Customer Name: CRITICAL PATH SOFTWARE

F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left F11=Right F12=Quit

TurboTuneSQL PROFILE (option 0)

TurboTuneSQL products are configured using TurboTuneSQL Profiles. If you haveseveral TurboTuneSQL products, they can share the same TurboTuneSQL Profile.

It contains parameters used by TurboTuneSQL products in both batch and online mode.Almost of all data entered by the user are saved into TurboTuneSQL Profile.

An TurboTuneSQL Profile is a member of PDS data set. Any PDS data set withLRECL=80 and RECFM=FB can be used.

Tips: 1 – Every user must have its own TurboTuneSQL Profile. A TurboTuneSQL Profilecannot be used by 2 users at same time. If the Profile is being used already andanother user tries to use it, TurboTuneSQL will switch to browse mode. 2 – The data you have type into TurboTuneSQL screens are saved into current Profilealways when:

✔ You type online command SAVE (*).✔ You type online command JCL (*).✔ At 'Product profile' screen, you use command 'S-Select for Edit Mode', 'B-Select

for Browse Mode', 'C-Create a profile', 'D-Delete a Profile' or 'G-Edit/BrowseGeneral Parms'.

✔ You exit the product.✔ Your are in Profile Edit Mode {E}

3 – User should have authority to update the profile data set. See online commandSECON/SECOFF (*) for details on how to turn on/off security. If user only has authorityto read the profile, TurboTuneSQL products will switch to Browse Mode automatically.

You must always have an active TurboTuneSQL Profile to navigate in the product.

To setup a Profile on main screen, choose “TurboTune Profile” (or type SETUP onlinecommand). The following screen will be displayed:


19

TurboTuneSQL V120 ------------------- Product profile -------- Row 1 to 4 of 4 Option ===> Profile Data set : TTUNESQL.PROFILE.DBBG Active Profile : DBBG Edit Mode: {E} DB2 SSID/Plan Name: DBBG / PLANSADV Connection Status: OK Current Location : DALLASB Line Actions ------------------------------------------------------------------ (E)Edit Parms (B)Browse Parms (C)Create (D)Delete (R)Refresh (S)Set Profile ------------------------------------------------------------------------------- CMD Name Description User ID Creation Date - -------- --------------------------------------- -------- ------------- DBBG IVP TEST IBMUSER 1900-01-01 IVP IVP TEST N/A 1900-01-01 PROFCAC PROFILE DEFAULT FOR DB2 DBBG N/A 1900-01-01 PROFSMF IVP TEST N/A 1900-01-01 ******************************* Bottom of data ********************************

Profile data set: it is used to store TurboTuneSQL Profiles. It is a PDS data set withLRECL 80, RECFM=FB. Create your own data set or use the installation provided dataset <HLQSADV>.PROFILE. <HLQSADV> is the HLQ where TurboTuneSQL productlibraries were installed.

Profile mode: Valid values: – {E} (Profile in Edit Mode)– {B} (Profile in Browse mode).

In Edit mode users can change all parameters and generate JCL for submission.Parameters are only saved when running in Edit Mode {E}.

In Browse Mode users can only browse parameters and no JCL submission is allowed,but users can change online report filters to run online reports.

You can change the Profile mode using options S, E or B in LINE ACTIONS.

DB2 SSID: It is the DB2 where TurboTuneSQL products were installed. This DB2 mustcontains with all TurboTuneSQL products tables and packages. You can change it usingoption G in LINE ACTIONS. DB2 Plan Name: It is the TurboTuneSQL product Plan Name. You can change it usingoption G in LINE ACTIONS.

Connection Status: shows if you are currently connected to a SSID and ‘ok’ means youare connected. Every time you use action lines B/S/G TurboTuneSQL will try to connectto DB2 using customized DB2 SSID and DB2 Plan Name inside TurboTuneSQL Profile.

Current location: DB2 Location, automatically obtained from connected DB2

There are several available line actions: ◦ E: Edit and set a Profile for Edit Mode ◦ B: Browse and set a Profile for Browse Mode ◦ C: Create a new Profile ◦ D: Delete a Profile ◦ R: Screen refresh ◦ S: Set a profile for Edit Mode only.

• Use option E to customize the current Profile In Edit Mode this line action willlaunch a new screen:


20

TurboTuneSQL V120 ------------------- Edit General Parameters ----------- 07:00 Option ===> More: + Edit General Parameters Profile : DBBG DB2 SSID : DBBG Edit mode: {E} Description: IVP TEST User ID : IBMUSER DB2 Specifications DB2 SSID : DBBG SSID where TurboTuneSQL was installed DB2 PLAN NAME : PLANSADV TurboTuneSQL DB2 Plan Name BIND QUALIFIER : SADVQUAL TurboTuneSQL Bind Qualifier DB2 VERSION : ** **/VA/VB/VC DB2 CCSID UNICODE : 00367 UNICODE CCSID DB2 CCSID EBCDIC : 00037 EBCDIC CCSID

FIELD DESCRIPTIONS

Description Free text to describe your TurboTuneSQL Profile

SSID DB2 SSID where TurboTuneSQL Profiles were installed If you change this parameter, JCL needs to be re-created, but only ifGenerated JCL contains DB2 Load Utility execution (check generated JCL).

DB2 Plan Name DB2 Plan name where TurboTuneSQL Profiles were installed

Bind QualifierQualifier for TurboTuneSQL product tables.

DB2 VersionDB2 version where product was installed/will generate batch jobs.Version can have one of the following values: V8/V9/VA/VB

Notes: – Use VA for DB2 version 10 ENFM/NFM. – Use VB for DB2 version 11 ENFM/NFM.– Use VC for DB2 version 12 ENFM/NFM.

If you are in CM, after migrating to ENFM/NFM you will need to execute specificinstallation jobs for this version. You will also need to change DB2 field versionin your TurboTuneSQL Profiles. Check Running Installation JOBs on InstallationGuide.

DB2 CCSID UNICODEEnter here your DB2 CCSID Unicode value. This value can be found inDSNHDECP module, field USCCSID.Very important: IBM recommends to set the value to 00367. This field shouldnot be changed.This DB2 CCSID UNICODE is used in TurboTuneSQL products to convertUnicode to EBCDIC when needed. Further explanation is below.

DB2 CCSID EBCDIC Enter here your DB2 CCSID EBCDIC value. This value can be found inDSNHDECP module, field SCCSID.

DB2 CCSID EBCDIC is used convert Unicode to EBCDIC in the followingsituations:A) When reading DB2 Traces written with UNICODE (zparm UIFCIDS=YES)B) When reading SQL texts (packages/dbrm/views) from DB2 Catalog orfrom DBRM data sets, if TurboTuneSQL detects that this text are in Unicode,conversion will be done. Several warning messages may be issued whenCCSID EBCIDC field header, present in DBRM/PACKAGE, has zero value or itdoes not match DB2 CCSID EBCDIC from profile. Sample messages:SQLTDBRMNCEW, SQLTDBRMCEMW, SQLTSPKSNCEW, SQLTSPKSCEMW,UVIE01V8001W, UVIE01V8002W.


21

DB2 SDSNEXITDB2 SDSNEXIT data set If you change this parameter, JCL needs to be re-created.

DB2 SDSNLOADDB2 SDSNLOAD data setIf you change this parameter, JCL needs to be re-created.

DB2 RUNLIB LOADDB2 RUNLIB data setIf you change this parameter, JCL needs to be re-created.

DB2 DSNTIAUL PROGRAM Name of DSNTIAUL programIf you change this parameter, JCL needs to be re-created but only if generatedJCL has a STEP using DSNTIAUL.

DB2 DSNTIAUL PLAN Name of DSNTIAUL Plan NameIf you change this parameter, JCL needs to be re-created but only if generatedJCL has a STEP using DSNTIAUL.

DB2 DSNTEP2 PROGRAMName of DSNTEP2 programIf you change this parameter, JCL needs to be re-created but only if generatedJCL has a STEP using DSNTEP2.

DB2 DSNTEP2 PLAN Name of DSNTEP2 plan nameIf you change this parameter, JCL needs to be re-created but only if generatedJCL has a STEP using DSNTEP2.

DECP DYNRULES: Force DECP rules parameter. Describe the behavior for some SQL codificationrules used by internal TurboTuneSQL modules.Important: Values may be Y or N:N- Some TurboTuneSQL product analyses SQL syntax. If option 'N' was used,this products will respect period/comma/apost/quote obtained from DBRM,DB2 Package or DB2 traces. Normally, this is the best option.Y- TurboTuneSQL will be forced to use period/comma/apost/quote as definedin DECP COMMA and DECP QUOTE profile parameters.

When loading SQLs from the SQL Cache Area, parameters DECP COMMA andDECP QUOTE specified below will always be forced by TurboTuneSQL,regardless whether option 'N' was configured in the DECP DYNRULE.

Comments:

(1) You must inform which period/comma/apost/quote rules are being used inthis SSID because TurboTuneSQL products cannot check how DBRMs werebinded and it doesn’t know the DB2 DSNHDECP configuration. Therefore,you must setup TurboTuneSQL parameters according to your DB2 andBIND customizations.

(2) These are DB2 rules for period/comma/apost/quote:○ For programs with BIND option DYNAMICRULES: BIND, DEFINE, INVOKE:

■ If DECP DYNRULES (DYNRULS) = Y, comma/quote from DECP parms(DECIMAL/SQLDELI) will be used


22

■ If DECP DYNRULES (DYNRULS) = N, comma/quote option fromPrecompiler will be used

○ For programs with BIND OPTION DYNAMICRULES: RUN ■ COMMA/QUOTE from DB2 DECP parm will always be used

DECP COMMA Inform to TurboTuneSQL internal SQL Extractor modules the decimal point:period or comma. Valid only if DECP DYNRULS is Y or if want to load SQLs from SQL Cache Area.Valid values are Y or N:

N - Means PERIOD is being used Y - Means COMMA is being used

DECP QUOTE Inform to TurboTuneSQL internal SQL Extractor to use apost or comma. Valid only if DECP DYNRULES is Y or if you want to load SQLs from SQL CacheArea.Valid values are Y or N: N - Means APOST is being used Y - Means QUOTE is being used

CEERUN Language Environment CEERUN data setIf you change this parameter, JCL needs to be re-created.

UTILITY PROGRAMLOAD Utility Program Name (IBM and non-IBM)IBM default utility is DSNUTILB.BMC default utility is AMUUMAIN.CDB default utility is CDBUTIL.If you change this parameter, JCL needs to be re-created.

PARAMETERS (NON-IBM)Enter the needed parameters below only if the utility is different fromDSNUTILB (IBM).

UTILITY PARMParameter to be used in parm jcl keyword.If you change this parameter, JCL needs to be re-created.

LOAD LIBRARY 1Load Library to be used in STEPLIB.If you change this parameter, JCL needs to be re-created.

LOAD LIBRARY 2Load Library to be used in STEPLIB.If you change this parameter, JCL needs to be re-created.

TRACETurboTuneSQL Trace parameter for batch jobs. Turn trace on only if your localsupport has requested trace data. Valid values are Y,1,2,3 or N:

To turn trace ON use: Y, 1,2,3Y – minimum trace information3 – maximum trace information


23

To turn trace OFF use: N

All trace data will be written to ddname MESSAGES. In some cases, ddnameSYSOUT will also be used.

Be aware of total amount of data being generated to SPOOL, becausein few situations ddname MESSAGES are being redirected to sysout. In thiscase, this options can generate many messages. There are some TurboTuneSQL batch jobs using //MESSAGES DD SYSOUT=*syntax.Also, trace option will slow down TurboTuneSQL batch jobs.

-ESTAEIf this parameter is ON, TurboTuneSQL will intercept if a system abend occurs.Valid values are Y or N:Y - Turn ESTAE routine ON. Use this option only if your local supportrepresentative has instructed you to doso.N - Turn ESTAE routine OFF

-BATCH MESSAGES DESTINATION: Controls where batch job messages will be printed. This parameter minimizethe number of messages issued in joblog.Valid values:J - Print messages in joblog and/or in MESSAGES data set.S - Print messages in sysout and/or in MESSAGES data set (default). N - Do not print messages in joblog but print in MESSAGES data set.Note: Some error messages will be shown in joblog anyway regardless what wasinformed in this parameter.

-CONSOLE INTERFACEAllows console interface through modify and stop commands. Valid values are Y or N: Y - will turn on console interface. N - will turn off console interface.

-TOTAL MSGSLimits the maximum number of messages to be written in TurboTuneSQL Logdata set (ddname MESSAGES). Valid values are 00000 to 99999For instance, value 00019 means that TurboTuneSQL will stop to writemessages when there are 19 messages written to ddname MESSAGES.Value 99999 will set a no limit number of messages.

-NCOMMITS Commits frequency. At each nnnnn SQLs updates, delete or inserts issued,TurboTuneSQL products will send a SQL commit. Valid values are 00000 to 99999. This parameter will be used by some TurboTuneSQL batch jobs, because mostof the TurboTuneSQL products make intensive use of DB2 Load utility insteaddoing mass inserts.

MAX STMT LENGTHMaximum size in byte for a single SQL statement

#ENTRIES TB DBRM Maximum size of each SQL statement (or program) in 80 bytes length.


24

Example: Value 1000 will use 80.000 bytes of memory (1000 * 80).

This parameter has 2 meanings: When processing SQLs from DBRM data set: - Set this parm to a size enough to fit all SQL statements of a single PDS

member When processing SQLs from DB2 Catalog: - Set this parm big enough to fit a single SQL statement from a DB2

Package/DBRM

#ENTRIES TB WORDMaximum number of words in a SQL Statement Example: SELECT MAX(COL) means 5 entries #ENTRIES TB FUNCMaximum number of entries for each function for a single column. Example:SELECT FUNC1(FUNC2(FUNC3(COLUMNS))) means 3 entries

#ENTRIES TB HOST Maximum number of Host Variables #ENTRIES TB CRCWORDS Maximum number of entries for internal computation

#ENTRIES TB PARM Maximum number of program names to be stored in memory

#ENTRIES TB TEXT Maximum size of each SQL statement in Kbytes. Example: Value 1000 will use 1MB memory (1204 * 1000)

#ENTRIES TB EXTRACT Maximum number of internal records created each SQL extracted

#ENTRIES TB SQLDYNMaximum number of statement/prepare names to be recorded for eachprogram in the same work unit (LUWID)

#ENTRIES TB EXPLAINMaximum number of entries to save DB2 Explain function data

#ENTRIES TB PROGLOGMaximum number of entries to be stored from proglog data set (distinctsprograms) in memory.

#ENTRIES TB SYSOBJS Maximum number of tables/views to be loaded in memory.Example: Value 100 will use 120400 entries (100 * 1204).

#ENTRIES TB SYSCOLSMaximum number of table column names to be loaded in memory. Thisparameter can be: maximum number of columns in a single table or themaximum number of columns with exactly the same name in all tables. Usethe biggest value.

#ENTRIES TB VIEWMaximum number of DB2 catalog lines for the largest view definition.

#ENTRIES TB MSGERROR


25

Maximum number of error messages to be held in memory before printingexecuted SQLs in performance processing.

#ENTRIES TB SYSREFCMaximum number of records (ddname SYSREFC) to be loaded in memory fromSYSRELS and SYSFOREIGNKEYS information (ddname SYSREF).

#ENTRIES TB SYSINDXMaximum number of records to be loaded in memory from SYSINDEXESinformation (ddname SYSINDX).

#ENTRIES TB SYSREIXMaximum number of records to be loaded in memory from ddname SYSREIX(for a single table).

#ENTRIES TB SYSFOKC Maximum number of records to be loaded in memory from ddname SYSFOKC.

#ENTRIES TB SPACESMaximum number of records to be loaded in memory from TABLESPACE information (ddname GTBSP).

#ENTRIES GENVIEWSMaximum number of DB2 views to be loaded in memory by DDL Generationutility.

#ENTRIES SYSINGGEN Maximum number of sysin entries for DDL Generation utility

#ENTRIES TB SORT120Q Maximum number of records (from performance trace) to be stored in memory having sequence errors which will possibly be processed in the second phase. Example: Value 50 will use 450,000 bytes memory (50 * 9000). Default is 50.


26

SQL REAL TIME MONITOR (option 1)

The screen below is menu of SQL REAL TIME MONITOR.


27

TurboTuneSQL V120 ----------- SQL REAL TIME MONITOR -------------------- 14:07Option ===> MENU Profile : IVP {E} DB2 SSID : DBBG 1 - SQL Real Time Monitor User ID : IBMUSER Time : 14:07 2 - Start DB2 Traces for CACHE Language : English Tso Logon: DBSPROCB 3 - Online Reports - Near Real Time System Id: S0W1 MVS Acct : ACCT# Appl Id : SADV Term CCSID: 00037 Prof CCSID: 00037 Customer Name: CRITICAL PATH SOFTWARE

F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left F11=Right F12=Quit

SQL Real Time Monitor (option 1.1)

This screen shows information about executed SQL statements. The information is real-time and based on SQL Cache Area: - DSC (Dynamic Statement Cache) & - SSC (Static Statement Cache) Pool The collection of statement-level statistics for SQL statements is activated by TraceMonitor Class (29/30).

This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired.

Notes:

1 - Before using this option, start DB2 Traces for Cache in option 1.2 as explainedfurther in this charpter.

2 - Fields related to CPU, WAIT and ELAPSED time are displayed usinghhhhhh:mm:ss.tttttt time format. All other fields are displayed using TurboTuneSQLNumeric format. Please, refer to Appendix Numerical and Time formats foradditional information.

3 - When data comes from SQL Cache Area (dynamic SQLs stored in EDM Pool),program name, CPU and other information may not be accurate (DB2 may recordSQL activities under a wrong program name). To avoid a prepare execution, DB2searches for an 'identical' SQL in the cache regardless for a different program orstatement number. When this happens, all computed values will be stored for theprogram and statement number found in Cache and not for the original executor.


28

TurboTuneSQL V120 --------------- REAL TIME MONITOR ---------- Row 1 to 3 of 3Option ===> SQL Statements in DB2 Cache (real-time) Profile : IVP DB2 SSID : DBBG Trace Status for Static: ON Dynamic: ON WAIT: ON Curr Loc : DALLASB Filters -----------------------------------------------------------------------DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Static: Y Dynamic: NProgram: Parameters --------------------------------------------------------------------Target : CPU - DB2 CPU TIME Min Value: 0000.000000 Max Lines: 00050Line Actions ------------------------------------------------------------------(D)Details (B)ProgC (N)ProgN (R)ProgS (P)ProgW (G)IXModel (F)SQLCom (L)SQLXref (K)XrefN (Y)SQLS (S)SQLText (E)Explain (U)SUniqueW (X)SSimilW (Q)TableC (Z)Zoom ------------------------------------------------------------------------------>C Program T Uniq S Num Desc Gtab Gcol Gsrt DB2 CPU(ALL) %CPUA SQLs- -------- - ---- ----- ------ ---- ---- ---- --------------- ----- ----------- DSNA6DB2 S 468C 1088 UPDATE C7D0 B242 0000 0.002092 57.6 1 DSNA6DB2 S 89A1 513 OPEN C7D0 B242 0000 0.000929 25.6 1 SADVPREN S F7C0 3147 SELECT 5CF6 0843 0000 0.000609 16.8 1******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Program: Program Name. T: Trace Source: Valid Values: 'D' - This statement are Dynamic 'S' - This statement are Static Bind Unique: Unique Number that defines this SQL Text. For more information, please refer to SQL Statement Unique Algorithm.

S Num:SQL Statement Number from DB2 precompiler. When Type is 'D', this value represents the line number of a prepare command.

Desc:Short SQL Statement description. Examples: SELECT, INSERT, etc.

Gtab:Number which defines all groups of DB2 TABLES found in this SQL statement. For moreinformation, please refer to SQL Statement Group Tables Algorithm.

Gcol:Number which defines all groups of predicates found in this SQL statement.For more information, please refer to SQL Statement Group Columns Algorithm.

Gsrt:Unique number which defines all groups of columns in group by and order by clause.For more information, please refer to SQL Statement Group Sort Columns Algorithm.

DB2 CPU(ALL):Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP). %CPUA:Percentage between DB2 CPU spent in all processors (CPU ALL).Note: This field is computed using the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:

40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - it means, this object in fact represents less than 40% (maximum screen lines WAS exceeded)

SQLs:Total SQLs executed.

Stmt ID:Unique statement identifier. This information is only available from DB2 V10 and up.

DB2 Elapsed: Total DB2 Elapsed Time.

%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:

80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - it means, this object in fact represents less than 80% (maximum screen

lines WAS exceeded)


29

DB2 CPU AVG:Total DB2 CPU Average per SQL.

DB2 Wait:Total DB2 Wait Time.

Owner: Table Owner.

Table: Table name.

WsTrans/CorrWorkStation Transaction Name

WsUserIdWorkStation User Id

WsName /Cn:This field has 2 meanings:

– When this thread comes from a DB2 Remote location, this field will be theworkstation name– When this thread is a Stored Procedure/User Define Function/Trigger, this

field will be the corresponding object name like Stored Procedure Name,User Defined Function Name or Trigger Name.

SSID:DB2 SSID.

Time Update in CACHE: Date/time when statement statistics was update

Time Insert in CACHE: Date/time when statement was insert into cache

Time Trace was Started: Date/time when statistics collection began. Data collection begins when IFCID 318 isstarted.

Snapshot Time: Date/time when collected trace data was done.

Collid:Collection name.

Program Timestamp: DB2 Precompile Timestamp.Note:

- DB2 Precompile Timestamp or, in some cases, an expansion of field'contoken' using z/OS macros (the final computed value is very close to Precompile Timestamp).

- Please, do not consider this date for remote programs, Triggers and for programs extracted from SQL Cache Area.

Hold:Cursor Hold. Valid Values:

'Y' - Statement was prepared for a held cursor 'N' - Statement was not prepared for a held cursor ' ' - Static SQLs from SQL Cache Area


30

Repl:Cache literal replacement indicator

blank - no literal replacement 'R' - literals were replaced was done 'D' - Same as 'R' but cached statement is duplicate cache entry instance

Drop: This field indicates if the statement has been invalidated. Valid values:

1 - Statement has been invalidated: drop or alter was issued 2 - Statement has been invalidated: revoke was issued 3 - Statement has been invalidated: removed from cache (LRU) 4 - Statement has been invalidated: RUNSTATS

'' - Statement is valid (or is a STATIC statement)

Degree:Current Degree - special register value Valid Values:

'A' - Current Degree is 'ANY' '1' - Current Degree is '1' blank - Static SQL from SQL Cache Area

Err Msgs: When 'Flag Error' field contains Y or W, this 7 bytes field indicates the the specific errorcode flagged by TurboTuneSQL. Valid Values:

blank - No Extract Errors. COMP=nn - compaction error, followed by Return Code. ERRCONV - Error on Unicode conversion to Ebcdic. Check Profile EBCDIC

parameter.NOTFND1 - Statement not found (rc=01). NOTFND2 - Statement not found (rc=01). NOTFND3 - Statement not found (rc=01). PKST=nn - Error on routine @SPK. Refer to Messages manual. Search for message @SPK0nn. SQD>32K - Statement exceeds 32K. SQL>32K - Statement exceeds 32K. TBHOST - Profile parameter #ENTRIES TB_HOST must be increased.

C:Indicates if a SQL COMMENT was created for the statement Valid Values:

'*' - SQL COMMENT found '?' - SQL COMMENT may have been created by line command 'F' blank - SQL COMMENT was not found

Prog Orig:Program name original. For remote DRDA programs,TurboTuneSQL may replaceoriginal program name by WsTrans/Corr field.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when the SQL was last updated in Cache) TimeR (Start/End Time when the SQL was last updated in Cache) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source


31

Explain Code Source Max Objects Other Filters: DB2 Plan Name DB2 Connection Type DB2 Correlation Name Unique Name Database Name

Area Size: Amount of memory in Kbytes used to get cache area. When zero is informedTurboTuneSQL will calculate the amount of memory.

Static:

(Static Statement are list) Only for DB2 V10 and up Y - Cached Statement STATIC bind will be list N - NO list Statement STATIC bind

Dynamic: (Dynamic Statement are list)

Y - cached Statement DYNAMIC bind will be list N - No list Statement DYNAMIC

Calc Uniq: To calculate Unique value of statements and by the way, get columns GTAB, GCOL,GSRT,S num, Desc, Owner, Table.

Y - Yes, calcate the Unique N - No Calculate

Target Field: (Used with List for specified field) E EXEC - Number of executions of Statement B READ - Number of buffer reads G GETP - Number of Getpage requests I INDX - Number of Index scans requests L PARL - Number of Parallel Groups P ROWP - Number of rows processed R ROWE - Number of rows examined S SORT - Number of sorts performed T TABS - Number of table space scans W WRIT - Number of buffer writes X RIDL - Number of times of RID was no used (limit) Y RIDS - Number of times of RID was no used (storage) C CPU - Accumulated Cpu time A ELAP - Accumulated elapsed time 1 WAIT - The accumulated wait time for synchronous I/O 2 LOCK - The accumulated wait time for lock requests 3 SYNC - The accumulated wait time for sync execution 4 GLOC - The accumulated wait time for global locks 5 RDOT - The acc wait time for read activity by another thread 6 WTOT - The acc wait time for write activity by another thread 7 LATC - The accumulated wait time for lock requests 8 TIME - The update timestamp when statistics were last changed 9 TINS - The insert timestamp when stetements first cached or EDM

* Value lowest value to be show Program Name – use wildcard '*' for programs started with a given

name


32

Transaction Name (EUTX) - use wildcard '*' for transaction started with a given name

Table Name - use wildcard '*' for table started with a given name

User Ident.(EUID) - use wildcard '*' for User Ident. started with a given name

Workstation Name (EUWN) - use wildcard '*' for workstation started with a given name

Obs: These last filters doesn't work exactly like wildcards have see before. This accept partially match.

AVAILABLE SORT FIELDS Sort Field Field Header PROG Program T T (Trace Source) UNIQ Uniq SNUM S Num DESC Desc GTAB Gtab GCOL Gcol GSRT Gsrt CPU DB2 CPU(ALL) SQLS SQLs STMT Stmt Id ELAPSED DB2 Elapsed CPUAVG DB2 CPU Avg WAIT DB2 Wait OWN Owner TAB Table Name WSTRANS WsTrans (WorkStation Transaction Name)WSUSERID WsUserId (WorkStation User Id) WSNAME WsName / User Routi SSID SSID TIMEUPD Time Update in Cache TIMEINS Time Insert in Cache TIMETRA Time Trace was started SNAP Snapshot Time COLL Collid PT Program Timestamp HOLD Cursor Hold REPL Replace DROP Drop DEGREE Current Degree ERMG Err Msgs C Comment Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


33

AVAILABLE LINE ACTIONS

(D)Details Report MORD-More details(B)ProgCReport SRIC-Shows Packages in Catalog(N)ProgN Report NRPG-Program Summary (near real-time)(R)ProgS Report SRPG-Programs Summary Source (P)ProgW Report AC00-Programs Summary (G)IXModel Report IXMD-Index Modeling (analysis of a single SQL)(F)SQLCom Report SSCO-SQL Comment (L)SQLXrefReport STRF-SQL Cross Reference(K)XrefNReport NRXR-General Cross Reference (near real-time)(Y)SQLS Report SRPS-SQLs List(S)SQLTextReport SRTX-SQL Text (E)ExplainReport SREX-SQLs Explain Information (U)SUniqueWReport ST02 - Identical statements summary (X)SSimilWReport ST03-Similar Statements Summary(Q)TableCReport TB00-Table Definition from DB2 Catalog (Z)Zoom Report ZOOM-Show extended fields


34

Start DB2 Traces for CACHE (option 1.2)

When choosing option 1.2, the utility to start and stop DB2 Traces for CACHE screenbelow will be displayed.

For a complete explanation, refer to charpter Create Traces.


35

TurboTuneSQL V120 ---------------- Setup DB2 Trace (CACHE) -------------- 12:24Option ===> More: + Start DB2 Trace (CACHE) Profile : IVP {E} DB2 SSID : DBBG General Parameters: Trace times: Start/End date: 1900-01-01 2100-12-31 (yyyy-mm-dd or ********) Start/End time: 00.00.00 23.59.59 (hh.mm.ss) Sampling: Trace duration : 00.10.00 (hh.mm.ss) Trace delay: 99.99.99 (hh.mm.ss) General options for CACHE traces: Trace options: (type '/') / Collect Dynamic SQLs from DB2 CACHE / Collect Static SQLs from DB2 CACHE Store Mode : R L/R/B L:Local R:Remote B:Both Ip Address/Port : 192.168.1.12 / 09190 Sampling mode option : N Y/N Y:Turn on traces in sampling mode Request Code for Source : DBBG Request code to search repository

Online Reports – Near Real Time (option 1.3)

When choosing option 1.3, online reports menu for near real times below will bedisplayed.

For a complete explanation, refer to charpter Online Reports and go to the reportexplanation.


36

TurboTuneSQL V120 ------------------ Online Reports --------------------- 12:40Option ===> Profile : IVP {E} DB2 SSID : DBBG Report : Curr Loc : DALLASB Filters ----------------------------------------------------------------------DateR : 1900-01-01 2100-12-31 Plan Name : CnTy: TimeR : 00.00.00 23.59.59 Correlation Name : Program: SSID: Source/Explain Req Code DBBG / DBBGUnique : Table Creator: Table Name: NEAR REAL-TIME WORKLOAD (Cache History) -------------------------------------------------------------------------------NRPG: Programs Summary NRS1: SQLs Summary NRS2: Identicals SQLs Summary NRS3: Similar SQLs Summary NRDB: Database Summary NRTB: Table Summary (First Table) NRCO: DB2 Correlation Summary NRXR: General Cross Reference (Real Time Monitor History)

MANAGING COPY OF CATALOG STATISTICS (option 2)

The screen below is the utility for COPY OF CATALOG STATISTICS.

This utility allows you to copy statistics DB2 tables from DB2 Catalog used by DB2optimizer when selecting query access paths.

Table utility reference:

SYSIBM.SYSCOLDIST Contains table level frequency, histogram, and multi-column cardinality statistics usedby the optimizer to estimate filter factors. Fields:

Access path fields (copied by this utility):CARDF Number of distinct values for the column group.COLGROUPCOLNO Identifies the set of columns associated with the statistics. COLVALUE Contains the data of a frequently occurring value. FREQUENCYF Gives the percentage of rows in the table with the value

specified in COLVALUE when the number is multiplied by 100.

NUMCOLUMNS Identifies the number of columns associated with the statistics.

TYPE Valid values:C - CardinalityF - FrequencyN - Non-paddedH - Histogram

Access path fields not copied by this utility (according to DB2documentation, these fields can not be updated by users):HIGHVALUE For TYPE='H', the high bound for the interval indicated by

the value of the QUANTILENO column.LOWVALUE For TYPE='H', the high bound for the interval indicated by

the value of the QUANTILENO column.QUANTILENO For histogram statistics, the ordinary sequence number of

the quantile in the whole consecutive value range from low to high

Non-access path fields (*) - (copied by this utility):


37

TurboTuneSQL V120 --------------- COPY OF STATISTICS -------------------- 12:47Option ===> Profile : IVP {E} DB2 SSID : DBBG SETUP PARAMETERS TO UNLOAD DB2 STATISTICS Force Owner : Force table owner in DML dataset (optional) Logical Commit: Y (Y/N) or Number of commits: 01000 Filters: Database: DB01 Creator : Include Table: Exclude Table: SETUP PARAMETERS TO LOAD DB2 STATISTICS USING DSNTEP2 PROGRAM Load Target Environment Parameters DB2 SSID : DB2 Plan Name : PLANNAME SDSNEXIT : SDSNEXIT SDSNLOAD : SDSNLOAD RUNLIB : RUNLIB

STATSTIME Date when RUNSTATS was last executed.(*) It may be used in access path if duplicate values exists for same column.

SYSIBM.SYSCOLDISTSTATS: Not supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSCOLSTATS:Contains partition-level column statistics that are used by DB2 to determine the degreeof parallelism, and also sometimes used to bound filter factor estimates. Fields:

Access path fields (copied by this utility):COLDCARD Total number of distinct values in the partitionHIGHKEY First 2000 char of highest value of columns in the partition

LOWKEY First 2000 char of lowest value of columns in the partition PARTITION Partition number for the table that contains the table in

which the column is definedNon-access path fields (copied by this utility):COLCARDDATA Total number of rows in the tableHIGH2KEY First 2000 bytes of second highest value of columns in the

partitionLOW2KEY First 2000 bytes of second lowest value of columns in the

partitionSTATSTIME Date when RUNSTATS was last executed

SYSIBM.SYSCOLUMNS: Contains table-level column statistics that are used by optimizer for filter factorestimation. Fields:

Access path fields (copied by this utility):COLCARDF Number of distinct values for the columnHIGH2KEY Second highest value of the columnLOW2KEY Second lowest value of the column

SYSIBM.SYSINDEXES: Contains table-level index statistics, that are used by optimizer for index costing.Fields:

Access path fields (copied by this utility):CLUSTERRATIOF A number between 0 and 1 that when multiplied by 100 FIRSTKEYCARDF Number of distinct values of the first key columnFULLKEYCARDF This is the number of distinct values for this IndexNLEAF Number of leaf pages in the index NLEVELS Number of levels in the index treeDATAREPEATFACTORF The number of times that data pages are repeatedly

scanned after the index key is ordered Access path fields not copied by this utility (according to DB2documentation, these fields can not be updated by users):CLUSTERING Whether the index was created using CLUSTER.Non-access path fields (copied by this utility):CLUSTERED Whether the table is actually clustered by the indexSTATSTIME Date when RUNSTATS was last executedCLUSTERRATIO Percentage of rows that are in clustering order

SYSIBM.SYSINDEXPART: Not supported by this utility.


38

Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSINDEXSTATS: Not supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSKEYTARGETSContains table-level frequency, histogram, and multi-column cardinality statistics forcolumn-expression index keys. The values are used by DB2 in filter factor estimationalgorithms for matched expressions. Fields:

Access path fields (copied by this utility):HIGH2KEY Second highest key value

LOW2KEY Second lowest key value STATS_FORMAT Type of statistic gathered:

blank : No statistic have been collectedN : Varchar statistical values are not padded

Access path fields not copied by this utility (according to DB2documentation, these fields can not be updated by users):CARDF Total number of distinct for the key-targetNon-access path fields (copied by this utility):STATSTIME Date when RUNSTATS was last executed

SYSIBM.SYSKEYTARGETSTATS: Not supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSKEYTGTDIST Contains table-level frequency, histogram, and multi-column cardinality statistics for

column-expression index keys. The values are used by DB2 in filter factor estimation algorithms for matched expressions. Fields:

Access path fields (copied by this utility):CARDF For type C, number of distinct values gathered in key

group; For type F, number of distinct values gathered in key

group -1;For type H, number of distinct values in the columngroup of the interval indicated by the value in theQUANTILENO column.

KEYGROUPKEYNO The set of KEYS associated with the statisticsKEYVALUE Frequently ocurring values in distribution.FREQUENCYF A number wich multiplied by 100, gives the percentage of

rows that contains the value of KEYVALUE.HIGHVALUE For type H, the high bound for the interval indicated by

the value of QUANTILENO column.LOWVALUE For type H, the low bound for the interval indicated by the

value of QUANTILENO column.NUMKEYS The number of keys associated with the statistics. TYPE The type of statistics gathered. Valid values:

C - CardinalityF - Frequent valueN - Non-paddedH - Histogram statistics

LOWKEY First 2000 bytes of lowest value of columns in the partition


39

QUANTILENO For histogram statistics, the ordinary sequence number of quantile in the whole consecutive value range from low to high.

Non-access path fields (copied by this utility):STATSTIME Date when RUNSTATS was last executed

SYSIBM.SYSKEYTGTDISTSTATSNot supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSLOBSTATSNot supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSTABLEPARTNot supported by this utility. Reason: this table does not contain fields related to access path. Or, if this tablecontain fields related to access path, they can not by updated by users (according toDB2 documentation).

SYSIBM.SYSTABLES Contains table-level table statistics that are used by the optimizer throughout the querycosting process. Fields:

Access path fields (copied by this utility):CARDF Total number of rows in the tableNPAGES Total number of pagesNPAGESF Total number of pages used by the tablePCTROWCOMP Percentage of rows compressedAccess path fields not copied by this utility (according to DB2documentation, these fields can not be updated by users):EDPROC Non-blank value if an edit exit routine is used

Non-access path fields (copied by this utility):PCTPAGES Percentage of active table space pages that contain rows

of the tableSPACEF Kilobytes of DASD storage STATSTIME Date when RUNSTATS was last executed

SYSIBM.SYSTABLESPACE Contains table-space level statistics that are used by the optimizer for costing of non-segmented table spaces. Fields:

Access path fields (copied by this utility):NACTIVEF Number of active pages in the table spaceNon-access path fields (copied by this utility):NACTIVE Number of active pages in the table spaceSTATSTIME Date when RUNSTATS was last executed

SYSIBM.SYSTABSTAT Contains partition-level table statistics that are used by the optimizer when costinglimitedpartition scans, and are also used by RUNSTATS to aggregate table-level tablestatistics that are stored in SYSIBM.SYSTABLES. Fields:

Access path fields (copied by this utility):CARDF Total number of rows in the tableNPAGES Total number of pages


40

Non-access path fields (copied by this utility):CARD Total number of rows in the tablePCTPAGES Percentage of active table space pages that contain rows

of the tableNACTIVE Number of active pages in the table spacePCTROWCOMP Percentage of rows compressedSTATSTIME Date when RUNSTATS was last executed

After you have executed it, a sequential data set with DML command will be generatedto populate DB2 Catalog or any other DB2 Catalog.

Notes:(A) This utility fully supports new DB2 lengths (128 bytes length).

(B) The data set generated by this utility has LRECL equal 72 bytes. It must be usend as input for programs that support this LRECL. Program DSNTEP2 andDSNTIAUL are examples. DB2 SPUFI will not work because it reads 79 bytes as inputrecords and data may be truncated to 72 bytes.

(C) The results will be stored in the following ddname://DMLOBJS will contain DDL to create results. data set name will be:

hlq.GDMLGSTA.DMLOBJS The above hlq will have the same name as defined in “HLQ work files” field in JCLcommand.

(D) The number of commits issued into DMLOBJs is controlled by -NCOMMITS profile parameter.

FIELD DESCRIPTIONS

Force Owner Force this qualifier for all generated DMLs (tables, indexes, etc).

Warning: this parameter will not work very if a table has several owners: statistics will be copied but all DMLs commands will be forced to use same owner. In this case, just one table statistics will prevail.

Commit Control

Logical Commit: Valid values: Y - Commits will be generated at logical set of records for each table. N - SQL Commits will be generated using Number of Commits parameter.Number of Commits:Specify when SQL Commits will be issued. This parameter will only work if LogicalCommit is N. Valid value: nnnnnn: at each nnnnn commands, a SQL commit will be issued.

FiltersAll filters, whenever present, will work as AND condition among them:

DatabaseSpecify Database name when filtering by database. Wildcard '*' can be used. CreatorSpecify a table owner as a filter. Wildcard '*' can be used.


41

TableSpecify up to 20 table. You can use table name or creator.table name. Wildcard '*' can be used.

Exclude TableSpecify a table to be excluded or a set of tables using wildcard. You can use table name or creator.table name. Wildcard '*' can be used. For best performance, always use Creator as filter.

OVERRIDE ONLINE PARAMETERs IN JCL

After JCL has being generated, you can increase override online parameters using JCL ddname. This allow you to increase total number of tables to be included (or excluded).

Filters

The following DDNAMEs are available to override original parameters.

//DBNAME DD * database name up to 500 //Owner DD * creator name up to 500 //TABLES DD * table or creator.table name up to 5000 //EXCLTABS DD * table or creator.table to be excluded up to 16000 //SYSIN2 DD * STAT_LOGIC_COMMIT=Y or NSTAT_NRO_COMMITS=nnnnn(must be edited with 5 digits)STAT_OWNER=forceownername or NONE

Notes:- If you override default JCL, parameters will be taken as follows:

- Online parameters DATABASE, CREATOR, TABLE, EXCLUDE TABLE will be taken from PROFILE data set only if any of the following ddnames was not informed: DATABASE, Owner, TABLES or EXCLTABS. Otherwise, if at least one ddname was informed, they will prevail from PROFILE.

- Online parameters Force Owner, Logical Commit, Number of Commits willbe taken from PROFILE data set only if ddname SYSIN2 was not informed.Otherwise, if informed, ddname will prevail from PROFILE.

- Whenever you inform STAT_OWNER=NONE, this cancel the force owner name indata set profile in case of you are not sure if this parameter has been informed.

- The SYSIN2 override accepts only 3 (three) parameters. Wrong parameters will be ignored as if they were not typed.


42

FILTER EXAMPLES

1- //DBNAME DD *DB001→ List All tables belonging to database DB001;

2- //DBNAME DD *DB001//OWNER DD*CRTABC

→ List all tables CRTABC.* belonging to database DB001;

3- //DBNAME DD *DB002//OWNER DD*CRTAB* //TABLES DD * TAB003*→ List all tables TAB003* with creator CRTAB* belonging to database DB002;

4- //TABLES DD * TAB004→ List all tables *.TAB004

5- //TABLES DD * CRTABA.TAB004*→ List all tables CRTABA.TAB004*

6- //EXCLTABS DD *SYSIBM.* → List all tables, except tables SYSIBM.*;

7- //Owner DD *CRTAB//TABLES DD *TAB003TABA*TAB111

→ List tables CRTAB.TAB003, CRTAB.TAB111, and all tables CRTAB.TABA*;

8- //Owner DD *CRTACCRTAD//TABLES DD *TAB001*TABB*//EXCLTABS DD * TABB0*TAB001ACME

→ List all tables CRTAC.TAB001*, CRTAD.TAB001*, CRTAC.TABB* andCRTAD.TABB* ; Exclude tables CRTAC.TAB001ACME, CRTAD.TAB001ACME andCRTAC.TABB0 and CRTAD.TABB0*


43

9- //DBNAME DD *DB00*//TABLES DD * TAB001*TAB00A*//EXCLTABS DD * CRTAB.TAB001*CRTAA.TAB0*CRTAC.TAB002ACME

→ List all tables starting with *.TAB001* and *.TAB00A* that belongs to databaseDB00*. Exclude tables: CRTAB.TAB001*, CRTAA.TAB0* and CRTAC.TAB002ACME;

10- //OWNER DD *CRTA*// TABLES DD * CRTB.TAB001*TAB00A* - //EXCLTABS DD *CRTAB.TAB001*CRTAC.TAB002ACME

→ List all tables CRTA*.TAB00A* and CRTB.TAB001*. Exclude tables: CRTAB.TAB001*and CRTAC.TAB002ACME;

11- //OWNER DD **TA*// TABLES DD * TAB001*//EXCLTABS DD *TAB001A**AB001P

→ List all tables *TA*.TAB001*. Examples: CRTAB.TAB001, CRTAB.TAB0012, CRTAC.TAB001, CRTAC.TAB0011. Exclude tables *TA*.TAB001* and *TA*.*AB001P. Examples: CRTAB.TAB001AB, CRTAC.TXAB001P


44

ENVIRONMENT VIRTUALIZATION (option 3)

The screen below is the menu for ENVIRONMENT VIRTUALIZATION.

For a complete explanation of ENVIRONMENT VIRTUALIZATION, refer to the manualTurboTuneSQL- VIRT Installation Guide and TurboTuneSQL VIRT User Guide.


45

TurboTuneSQL V120 ------------ ENVIRONMENT VIRTUALIZATION --------------- 12:57Option ===> Profile : IVP {E} DB2 SSID : DBBG 1 - Jobs to copy profiles from other systems User ID : IBMUSER Time : 12:57 2 - Manage DB2 Profiles Language : English Tso Logon: DBSPROCB 3 - ZPARM edit System Id: S0W1 MVS Acct : ACCT# 4 - ZPARM reload Appl Id : SADV Term CCSID: 00037 Prof CCSID: 00037 Customer Name: CRITICAL PATH SOFTWARE

SQL INVENTORY AND WORKLOAD (option 4)

The screen below is the menu for SQL INVENTORY and WORKLOAD.

TurboTuneSQL can use several sources of information to analyze a DB2 environment:DB2Traces (from SMF/GTF and from DB2 CACHE), SQL texts, Tables definitions (DDL)and Explain Data. The basic steps to achieve this are:

Start, Stop and Collect DB2 traces using TurboTuneSQL utility Collect SQL text, Table Definition and Explain Data

And, before collecting new data, you must decide: Do I want to clear previous TurboTuneSQL Repository data before loading

this new data? Should I create a new Request Code for this run? Which is better: get SQLs from my DBRMLIB data set or from DB2

Catalog? Should I load only programs found in DB2 traces or all of them?

At the end of this chapter, you will be able to answer all previous questions.


46

TurboTuneSQL V120 ----------- SQL INVENTORY AND WORKLOAD ---------------- 14:23 Option ===> MENU Profile : IVP {E} DB2 SSID : DBBG 1 - Load Source & Workload into Repository User ID : IBMUSER Time : 14:23 2 - Online Reports Language : English Tso Logon: DBSPROCB 3 - Batch Reports System Id: S0W1 MVS Acct : ACCT# 4 - Utilities Appl Id : SADV Term CCSID: 00037 Prof CCSID: 00037 Customer Name: CRITICAL PATH SOFTWARE

Load Source & Workload into Repository (option 4.1)

The screen below is the menu for Load Source & Workload into Repository.

Header Fields:Profile : TurboTuneSQL Profile

{?} : Profile Edit Mode (E - Edit Mode , B - Browse Mode) DB2 SSID: Connected DB2 Curr Loc : DB2 Location, automatically obtained from connected DB2


47

TurboTuneSQL V120 ----------- Load Source & Workload -------------------- 15:02 Option ===> MENU Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB 1 - Request Codes 2 - Filters to load DB2 Traces 3 - Filters to load SQL Information 4 - Filters for Explain Utility 5 - Calculate DASD Spaces 6 - Create JCLs to Submit Batch JOBs

Request Codes (option 4.1.1)

The screen below is the option to maintain request codes.

To store SQL text, Table Definitions and Explain Data into the Repository,TurboTuneSQL uses Request Codes. Request Code is a five byte store key used toguarantee that previous information will not be replaced when working with SQL text,Explain Data and table definitions. In other words, the function of the Request Code is to allow you to keep a historicalview of the information and allows you to repeat and maintain several versions by justentering a different value in the Request Code field. You can create as many RequestCodes as you need. For an examples, Request Codes: RUN01, LAST, IDX01, TEST, DB2P,SANDB, etc.

There are 3 kinds of Request Codes: –Request Codes for Source (type 'S') will be used when storing SQL Text and Table Definition into TurboTuneSQL Repository –Request Codes for Explain (type 'E') will be used when storing DB2 Explain Data

– Request Codes for Index (type 'I') will be used to hold indexes recommendations madeby the Automatic index recommendation utility . – Type 'C' is special type of Request Code. This request code automatically created bysystem (Compare Plan Tables Utility) to show the results of Plan Table comparison.

Use the command line LSTREQ also is used to display the screenn above.

There are several available Line Actions:o U: Update an existing Request Codeo D: Delete an existing Request Code.

Attention: TurboTuneSQL will not check if you are deleting a RequestCode spread in all TurboTuneSQL tables. This delete action will onlyremove one line from the TurboTuneSQL Request Code table. If you wantto clear TurboTuneSQL tables, go to Clear Tables Utility.


48

TurboTuneSQL V120 ------------- Request Code Control --------- Row 1 to 2 of 2 Option ===> Profile : IVP {E} DB2 SSID : DBBG Command Line: NEWREQ Line Actions ------------------------------------------------------------------ (U)Update (D)Delete (R)Refresh (B)Browse (S)Set ------------------------------------------------------------------------------- C Code Type Date Records Short Description - ------ ---- ---------- ----------- ------------------------------------------ DBBG E 2019-11-13 23 REQ DEFL DBBG S 2019-11-13 87 REQ DEFL ******************************* Bottom of data ********************************

o R: Screen refresho B: BrowseResults. This action will show the corresponding loaded data

using this Request Code. For Request type: S: Report SRPG (program list) will be opened E: Report SREX (Plan Table data) will be opened C: Report SRMI (Plan Table Comparison) will be opened

o S: Set. This action will set this Request Code as a default filter for OnlineReports.

Use Online Command NEWREQ to create a new Request Code. For a description of allOnline Commands, check Appendix Online Commands.


49

Filters to load DB2 Traces (option 4.1.2)

The screen below is used to define filters to load Db2 traces into repository.

One of the most important tools to understand DB2 performance problems is the use ofDB2 traces. It is a very important mechanism to help administrators to understandwhat happens with DB2 applications.

TurboTuneSQL needs DB2 traces to analyze a DB2 environment. So, first its necessaryto start DB2 traces and after collect them into TurboTuneSQL Repository.

There are several kinds of DB2 Traces, like DB2 Accounting Traces, DB2 PerformanceTraces, DB2 Audit Traces, DB2 Statistic Traces and DB2 Global Traces (check IBMdocumentation for more details).

The screen above will help you customize TurboTuneSQL to input Db2 traces intorepository. In order to see more information press PF8.


50

TurboTuneSQL V120 ----------- Filters to load Db2 Traces ---------------- 15:08 Option ===> More: + Profile : IVP {E} DB2 SSID : DBBG Use traces generated from: / SMF GTF / CACHE Input DB2 trace data sets: For SMF data sets, especify: PUT.YOUR.SMF.DUMPS.HERE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE For GTF data sets, especify: PUT.YOUR.GTF.DUMPS.HERE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE NULLFILE General options for CACHE traces: Delete CACHE rows after execution : N (Y/N) Extract only SQLs from CACHE with activity: Y (Y/N) Timeout parameters Control BATCH job concurrency Interval minutes : 30 Maximum time to wait resource be released End job on timeout : N (Y/N) Y:End Job N:Skip all records

TurboTuneSQL works with DB2 Accounting Traces, DB2 Performance Traces and withSQLs extracted from DB2 SQL Cache Area (EDM pool). So, before loading DB2 tracesinto TurboTuneSQL, you must first create traces. TurboTuneSQL has its own utility tostart and stop DB2 traces. If you want to learn more about this utility, refer toTurboTuneSQL Start DB2 Trace Utility. Note: the collect of static SQLs from SQL CacheArea will be available only if add-on feature TurboTuneSQL-REAL TIME CACHE wasacquired.

DB2 Traces output can be basically redirected to SMF, GTF or memory (Opx).TurboTuneSQL can not work directly with SYSx.MAN data sets, so always use theunloaded sequential SMF data set created by IBM utility IFASMFDP. The main store keyused to save DB2 traces in the Repository is the date and time obtained from theworkload. This guarantees that previous information will not be replaced when loadingnew DB2 trace onto TurboTuneSQL.

DB2 Accounting Traces normally generate one record when a DB2 thread ends. Thistrace will have accounting details about the just finished DB2 thread. In other words,when a job step ends, DB2 will generate an accounting record trace with a summary ofsome valuable DB2 information about the job step. Therefore, Accounting Tracenormally does not generate many records, but in heavy DB2 Workload, specially whenthere is high CICS transaction volume, many records can be generated. This trace isstored in SMF type 101 and it can be redirected to SMF, GTF or memory. DB2 Performance Traces used by TurboTuneSQL generate one record for each SQLcommand. So it will have performance details about each executed SQL command inthe thread. Just to exemplify, if the trace is on, when the program in job step executesa SQL command, DB2 Performance trace will generate a few records to register thisspecific SQL command. This trace is stored in SMF type 102 and it can be redirectedto SMF, GTF or memory.

DB2 Performance Trace generates data at command level. Therefore it will generatemuch more records when you compare it to DB2 Accounting Trace. But, evengenerating more records, the record length of DB2 Performance Trace is shorter thanDB2 Accounting Trace.

DB2 SQL Cache Area is populated with CPU and other performance indicators only if theIFCID 318 is active (dynamic) or IFCID 400 is active (static). This can be done with aDB2 monitor trace. The overhead for these traces is about 2% for each dynamic/staticSQL command executed. Also, to activate Dynamic Statements Cache use:–The system parameters CACHEDYN and MAXKEEPD–Bind parameter KEEPDYNAMIC(YES).

In order to minimize the overhead of collecting DB2 traces, TurboTuneSQL has an utilitycalled TurboTuneSQL Start DB2 Trace Utility. This utility can start traces usingsampling. It can start and stop traces in intervals minimizing total overhead.

When collecting trace in sampling mode (turning on and off trace), the total overheadmeasured within 1 hour will less than 5%, specially when tracing Online Applicationwhich are executed many times. The total overhead will depend on the suggestedsampling values and the type of application being measured.

Therefore we recommend that you use TurboTuneSQL Start DB2 Trace Utility samplingfeature. Using this feature, traces will be started and stopped in intervals minimizingthe total overhead

Create distinct jobs to when you wish to start differents traces types.Example: create one job to start Accounting Traces and another to startPerformance Traces. Refer to TurboTuneSQL Start DB2 Trace Utility formore examples.

Create a filter in DB2 Start Trace command


51

DB2 start trace command allows you to start traces just for specifics DB2Plans, Location, Program.

DB2 Version 9 allow you to create filters by Plan, Authid, Location, Package, etc

Make use of GTF. Normally GTF consumes less CPU than SMF.

Check IBM DB2 documentation for more details.

The number of traces can vary according to the size of your installation. Examples oftotal records generated by Accounting Traces and Performance Traces:

Customer A, 20.000 MIPS, 30 minutes of DB2 traces collected:o Full DB2 Trace Accounting (no sampling), has generated 1.500.000 of

SMF 101 records o DB2 Performance Traces (delay: 7 minutes, duration: 30 seconds) has

generated 4.000.000 of SMF 102 records.

Customer B, 15.000 MIPS, 30 minutes of DB2 traces collected:o DB2 Trace Accounting (delay: 7 minutes, duration: 1 minute) has

generated 4.000.000 of SMF 101 records o DB2 Performance Traces (delay: 10 minutes, duration: 20 seconds) has

generated 9.000.000 of SMF 102 records.

Customer must decide when traces should be started. The total amount of records willvary depending on the time of day you start the traces and when your workload has apeak. Sometimes, it’s better to turn on DB2 Accounting Traces only to understand yourworkload peaks before starting DB2 Performance Traces.

There isn’t a specific rule to determine how you should setup TurboTuneSQL Start DB2Trace Utility sampling parameter. Like any other Monitor Tool, traces must be turnedon very carefully. We recommend that:

In a production environment, do not turn DB2 Performance Trace on for along period without use sampling process. This will slow down your system.

Normally, 30 seconds of DB2 Performance Traces for several periods canbring up a lot of information. This number normally can be enough to realizea good DB2 Performance Analysis.

Shorter traces can make you direct efforts to DB2 threads which are not on the top of the list of consumers.

Accounting Traces should be turned on much more frequently thanPerformance Traces.

To learn more about DB2 Traces, refer to TurboTuneSQL Start DB2 Trace Utility .

The screen above shows the first part of the panel. Type F8 to see more fields.

FIELD DESCRIPTIONS

Use traces generated from:Enter the type of trace you want to load:

– Specify SMF if input traces data sets are from SMF– Specify GTF if input traces data sets are from GTF– Specify CACHE if you want to load SQLs from CACHE

(the collect of static SQLs from SQL Cache Area will be available only if add-onfeature TurboTuneSQL-REAL TIME CACHE was acquired).


52

Details:– User may request both SMF and GTF at one single JOB.– If the same DB2 trace information is in SMF and GTF, the results may not be

accurate if user choses to process SMF and GTF at one JOB. – If GTF was selected, parameter TIME=YES must be informed in GTF exec started

task.– CACHE option:

– It can be informed alone or with SMF or GTF. – Data from CACHE must be collected using TurboTuneSQL Start DB2 Trace

Utility. This utility collect SQL text from DB2 SQL Cache Area (EDM Pool) andstore them into STMT_CACHE_MON TABLE table.

This requires a JCL modification if the field is changed: –YES, If you decide to collect SMF and GTF at same time (and previous generated JCLwere created using only SMF or GTF).

Input DB2 Trace data sets Enter the data set names for SMF or GTF (or both) to be processed. If there is only onedata set, leave blanks or enter "NULLFILE" for the remaining data sets. If the numberof SMF (or GTF) data sets is greater than the number of fields on the screen, you canmanually input all of them later after you generate the batch JOBS.Attention: You CANNOT select to have the DB2 traces extracted together if they weregenerated from different DB2 versions.If you change this parameter, JCL needs to be re-created.

Delete cache Rows After Execution Delete rows from STMT_CACHE_MON TABLE after processing. This parameter is only used when CACHE option is chosen.

Valid Values:● Y – Rows from STMT_CACHE_MON TABLE will be deleted after normal batch

processing. This is the recommended value.● N – Rows will not be deleted.

Extract only SQLs from cache with activity Only select dynamic SQLs from DB2 Cache with activity. Dynamic SQLs with no CPU or Elapsed time will not be processed by TurboTuneSQL. This parameter is only used when CACHE option is chosen.

Valid Values:● Y - Only select statements from STMT_CACHE_MON TABLE with activity.● N - Select all statements.

Timeout parameters: Specify the actions when table STMT_CACHE_MON TABLE is locked by another process. Interval minutes: When table STMT_CACHE_MON TABLE is held by another process, this parameter will be used to determine how long this batch process must wait until above table be released. Values: 00 to 99 minutes

End job on timeout: Specify the condition code for the step when Interval minutes expires: Valid values: Y: Processing will be terminated and condition code will be set to 12.


53

N: Processing will not be terminated. A warning message will be issued informing that the records were not processed. Condition code will be set to 04.

Note: User may restart the execution when the resource is released.

Reduce trace data You can use this option to reduce disk space occupied by TurboTuneSQL Repositoryand improve the product performance.

This parameter is informed in minutes. At n minutes, TurboTuneSQL will round all dateand time obtained from DB2 traces.

For example, if this parameter was setup to 30 minutes and a job batch found in traceswas executed at 15:35, TurboTuneSQL will record this event at 15:30 and not 15:35.

Valid values: 01 to 60 minutes

Other examples:A) Reduce trace data = 30 minutes.

– If job a batch JOB named JLOADTAB has ended at 15:43 hs, this value will be roundedto 15:30 hs.

– If a CICS transaction named CUST has ended at 14:20, this value will be rounded to 14:00 hs.

B) Reduce trace data = 60 minutes. – If job a batch JOB named JLOADTAB has ended at 15:43 hs, this value will be rounded

to 15:00 hs.– If a CICS transaction named CUST has ended at 14:20, this value will be rounded to

14:00 hs.

Very important note:For SQLs loaded from DB2 SQL Cache, date/time fields does not represent that timewhen SQL was executed. For SQL Cache, they represents the moment when the tracewas extracted from Cache.

Capture Dynamic SQL from Performance trace Specify Y to process and load dynamic SQL from DB2 Performance trace. Specify N to reject dynamic SQL from trace (IFCID 63 will not be processed).This parameter applies to Performance trace only (dynamic SQLs captured from cacheare still captured according to CACHE option).

Adjust time zone in Sometimes DB2 generates date and time traces using different time zones.TurboTuneSQL will use this field value to adjust to generate date and time to yourcurrent time zone. This field is specified in minutes. Example: if you setup this field to –03, all DB2 starttime will be reduced in 3 hours.Tip: Use the same value as specified in SYS1.PARMLIB(CLOCKnn)parameter.

CPU Max Limit is/ ELAP Max Limit is Use these fields to guarantee that DB2 trace records were processed within the periodwhen the DB2 performance traces were turned on. WhenCPU or ELAPSED times exceeded these limits, TurboTuneSQL reset all values to zeros.When CPU exceeded, maybe ELAPSED exceeded as well and in this case only themessage for CPU will be shown in messages.The default is 120 seconds for CPU Max and 240 seconds for ELAP Max.Inform both parameters in seconds.


54

FILTERS Start/End DATE Enter the start/end range date. Note: the date used as a filter will be the value registered by z/OS when trace wasrecord. This date is not exactly same date registered by DB2. Start/End TIME Define start/end range time.You must be aware that:- Correct time zone parameter field are not used. Therefore, you must enter here start/end time without computation informed on correct time zone parameter.– The time used as a filter will be the value registered by z/OS when trace was record (SMF / GTF header). This time is not exactly same time registered by DB2.

DB2 Group Name Enter the DB2 Data Sharing Group Name. Blank means all DB2 will be extracted fromSMF, without exceptions.

Plan NameEnter a list of plan names.

Program

Enter a list of program names.Attention: (1) PROG Name filter is not recommended for dynamic SQLs in this currentTurboTuneSQL release. When using PROG Name as filter for programs that issuedynamic SQLs, the programs will be collected but no association against the source willbe done. Therefore, no SQL text will be extracted and stored in TurboTuneSQL tables,unique number will be zeros and TurboTuneSQL will not be able to generate Explaindata.

(2)PROG Name filter is ignored for traces generated from CACHE.For Cache, even if PROG Name filter was informed, all programs found into CACHE trace will be collected.

Collection Name Enter a list of DB2 Package Collections This parameter is ignored for traces generated from CACHE.

Correlation NameEnter a list of Correlations (examples: CICS transaction, job name, etc)This parameter is ignored for traces generated from CACHE.

Connection Type Enter a list of Connection TypeValid Codes: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION


55

0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W UDF 0Y TRIGGER 0Z STORED PROCEDURE EA CACHE (FOR DYNAMIC SQLS)EB CACHE (FOR STATIC SQLS)

IFCIDs Enter a list of IFCIDs to be extracted. Example: 60 will extract only IFCID 60, all otherIFCIDs will not be extracted. Blank will extract all IFCIDs treated by TurboTuneSQL.

After you have defined the input traces, you should define all other input data toTurboTuneSQL: SQL texts, Tables definitions (DDL) and Explain Data.

Note:(1) TurboTuneSQL normally uses its own Repository data for almost all Report and

Utilities. It means that you must load SQL text and Table Definition intoTurboTuneSQL Repository. Also, these guarantee a static view of you application system at the time whenDB2 traces were taken.

(2) TurboTuneSQL can process DB2 Traces only, without processing the SQL text or anyother kind of input data. This can be a desirable option when only DB2 Accountingtraces can be loaded into Repository.

(3) TurboTuneSQL can process Source only, without processing DB2 Traces. This canbe a desirable option when customers want to create a complete SQL Inventory oftheir system and do not have DB2 traces to be used as input.

(4) TurboTuneSQL cannot automatically discover the DB2 version. Check Appendix Online Command, “SETUP” for more details.

(5) This parameter is ignored for traces generated from CACHE.


56

Filters to load DB2 SQL Information (option 4.1.3)

The screen below is used to define filters to load Db2 SQL information into repository.

TurboTuneSQL can analyze SQLs from: DBRM data sets DB2 Catalog Sequential data sets Dynamic SQLs from DB2 Performance Traces or from the DB2 Cache.

Using this facility will allow you to extract SQL executed from IBM QMF application, Java, Client Server application using IBM DB2 Connect and others to be examined concurrently.

Dynamic and Static SQLs from the DB2 Cache. TurboTuneSQL can read the DB2 EDM pool area to get all of the dynamic SQL text and store this information in its repository tables.

The screen above will help you customize TurboTuneSQL to select where it will inputthe SQL text from.


57

TurboTuneSQL V120 ----------- Filters to load SQL Information ----------- 15:21 Option ===> More: + Profile : IVP {E} DB2 SSID : DBBG Request Code for Source DBBG SQL Source Extract From: C C - From DB2 Catalog D - From a DBRM data set T - From a sequential file Program Filter: Automatic List: P S - All Programs P - From Last Trace (current trace) L - From Last Trace (current trace) PLUS Last Program version Manual List: Update History Table: Y Y/N (Valid only for Automatic List=L) Update Control: KEEP KEEP , FORCE or NEVER For option C (DB2 Catalog), specify : Default Qualifier for Packages : SYSIBM N:Skip all records

Attention: This functionality makes use of Dynamic SQL. Therefore, you may have tosetup DB2 RLF.

The screen above shows only the first part of the Panel. To see more data, Press F8.

FIELD DESCRIPTIONS

Request Code Request code for Source. This is a 5 character key used to identifier the SQL beingloaded into the TurboTuneSQL repository tables. Usage samples: RUN01, LAST, FIRST,PROD, DB2P, etc.

Type NEWREQ line command if you want to create a new Request Code. Type LSTREQ line command to list all available Request Codes.

SQL Source Extract From Choose where the SQL text will be taken from. Options are:

C - Extract statements from DB2 Catalog.This is the best option. Except for some situations which we do not recommend the use of this option:

o A very large DB2 Catalog with multiple package versions for the same program (like several collections binded in the same program, not using DB2 command free, etc).

o A very large DB2 Catalog and are not using cloned SYSDBRM/SYSSTM tables with indexes. This is because SYSIBM tables SYSDBRM and SYSSTMT does not have indexes). See more details in the parameter “Default Qualifier for the DBRM/PLAN” below.

D - Extract statements from a DBRMLIB data set. If you are using this option, please consider:

o Check if your DBRM data set is up to dateo This is not a good option when you have multiples versions DBRM data

sets (not just one for each environament, like production/development). TurboTuneSQL can work with just only one DBRM data set per run.

o This is not a good option when you have same DB2 table with multiples table owners.

o TurboTuneSQL Explain/Copy Plan Table Utility may not work properly.

T - Will extract statements from a TurboTuneSQL sequential file. To see an example to construct a TurboTuneSQL sequential file, go to SQL Sequential data set Utility.

If you change this parameter, JCL needs to be re-created.

Program FilterThere are 2 ways to specify which programs will be extracted and loaded intoTurboTuneSQL.These options are NOT mutually exclusive.Options:

Option 1: Automatic List Specify a list of programs to be included automatically.Valid values:


58

– P: Extracts static SQLs from programs found in current traces being processed. SQLs can be extracted from DB2 Catalog and DBRMLIB data sets. Dynamic SQLs will also be processed.

– S: Extracts all SQLs from DB2 Catalog/DBRMLIB/Sequential data sets. If a DB2trace is being processed together, Dynamic and Static SQLs will be also extracted.

– L: Extracts static SQLs from programs found in current traces as well as from new compiled programs. This option is valid only when extracting SQLs from DB2 Catalog. To verify if this is a new program (last version), precompile timeis checked and compared within 'collection/program'. If a DB2 trace is being processed together, Dynamic and Static SQLs will be extracted also. Option L is the best option because more data will be loaded into TurboTuneSQL.

Option 2: Manual ListSpecify, individually, programs to be included or excluded. Attention: If processing DB2 traces and Source at same time, the use of this optioncan generate statements with their unique identifiers shown as all zeros.

Special considerations:- Use ‘*’ to include all programs- Use ‘\’ to exclude a program.

Rules: 1. A program filter can be used only if the extracted SQLs are from the DB2 system

Catalog or from the DBRMLIB. 2. First line cannot be spaces if other lines are filled3. You can use DB2 LIKE function syntax to specify which programs must be or not be

processed. Valid only if extracting SQLs from the DB2 system Catalog4. If using Exclusions (\) and DBRMLIB are being used, Exclusions must be informed

before Inclusions.5. Do not use *PROGRAM6. If using PROGRAM*, do not use write a line with `*`7. Do not write blank lines between 2 specifications8. If using Exclusions, at line one line with `*` must exist9. Valid wildcard: * or %

Example 1: Including all programsblank or

'*'

Example 2: Including programs starting with PGM1PGM1* or PGM%

Example 3: Include only program PGM2PGM2

Example 4: Including programs PGM2 and PGM3PGM2PGM3

Example 5: Including program PGM2 and programs starting with PGM3PGM2PGM3*


59

Example 6: Excluding program PGM3\PGM3* (*) is mandatory when using exclusions

Example 7: Excluding programs starting with PGM3\PGM3** (*) is mandatory when using exclusions

Example 8: Excluding programs starting with PGM3 andIncluding program PGM4\PGM3*PGM4*

Example 9: Excluding programs starting with PGM3 andIncluding programs starting with PGM4\PGM3*PGM4*

Invalid examples:

Example 1: Excluding programs but not using * at end of string\*PGM\PGM*1

Example 2: Including programs starting with PGM3*

PGM3**(if you use '*' here, all programs will be include, not only

PGM3)

Example 3: Including all programs**

Example 4: Including programs starting with PGM*1PGM*1

Example 5: Excluding programs but not using * at end of string\*PGM\PGM*1

Sample examples:

Example 1: To process only programs found in previous DB2 traces use:Option 1 Automatic List = ‘P’Option 2 Manual List = ‘*’

Note:Once informed programs to be included/excluded on Manual List, if option for Automatic List = 'P', the load process will consider only programs which have been extracted from workload also.

Example 2: To process all programs, regardless if found in DB2 traces, use:Option 1 Automatic List = ‘S’Option 2 Manual List = ‘*’


60

Default Collid(s)Specify one or more DB2 Collection to attempt programs as PACKAGE which the currentTrace found as DBRM.

To speed up SQL extraction from the DB2 system Catalog, TurboTuneSQL will try toretrieve SQLs from SYSPACKSTMT table before trying to get it from SYSSTMT table (thistable does not have indexes).

Therefore, if a DBRM was found in current Trace ONLY, default collid informed here willbe used as key to retrieve SQL text as if this program was a PACKAGE and not a DBRM.Valid only for options P and L in parameter Automatic List .

Update Control Define how source programs will be processed if they already exist in TurboTuneSQLrepository under same Request Code.

● KEEP: If a program with same DB2 collection id, program name, program token and statement number already exist in TurboTuneSQL Tables, it willNOT be loaded again.Keep normally is the best option.

● NEVER: Never checks if a previous program exists. This option providesbest performance for the first run or if you process using a new RequestCode.

● FORCE: All previous Program with same name will be delete fromTurboTuneSQL Tables. So, even if a program name already exists, it willbe loaded again into TurboTuneSQL tables. Effects:o By the end of this processing, only new programs being processed on

this run will remain in TurboTuneSQL tables. All previous programswith same name will be deleted and programs with different nameswill remain in the base.

o Also, ALL old dynamic SQL statements issued by DB2 programs, like,java.exe, will be discarded from the repository.

For option C (DB2 Catalog) When extracting statements from DB2 Catalog (“SQL Source will be extracted” is C),specify: Unload type (inform what kind of programs will be unloaded)

● PACKAGE - Only packages (*) ● DBRM - Only DBRMs ● ALL - Packages and DBRMs● ALLPACK - Packages and some DBRMs

Type chosen as:package Extract SQL only from DB2 Packages.Attention: Provides best batch performance, but SQL statement with uniqueidentifier zeros can be generated if DBRMs (not Packages) are present in DB2traces.dbrmOnly SQLs from DBRMs will be extracted. Using this option SQLs fromCollections/Packages will not be extracted. Valid only when “Automatic List' is S.all Only SQLs from DBRMs will be extracted. Using this option SQLs fromCollections/Packages will not be extracted.


61

Option PACKAGE has better performance if compared this option because DB2Catalog table normally SYSSTMT does not have indexesThis is best option if you don't have a large DB2 Catalog or if you have DB2 indexesas indicates in option Default Qualifier for DBRM/PLAN.allpackSimilar to option ALL. For programs found in Workload, SQLs from Package and DBRMs will be retrieved.Differences:–This option is valid only for Automatic List 'L'–When looking for new compiled programs, only Packages will be retrieved. There is no check for new DBRMs programs.

Option ALLPACK has better performance if compared with option ALL. Option PACK has better performance if compared with option ALLPACK. Option ALL is always the best option because is more complete than the others, butshould be used with care if you have a large DB2 Catalog and don't have indexes inDBRM catalog portion. For more information, see option Default Qualifier forDBRM/PLAN.

Default Qualifier for PackagesWhen extracting statements from Packages specify SYSIBM or another qualifier tospecify a cloned/shadows for those tables: SYSPACKAGE/SYSPACKSTMT to be accessed.

Default Qualifier for DBRM/PLANWhen extracting statements from DBRMs specify SYSIBM or another qualifier to specifya cloned/shadows for those tables: SYSDBRM/SYSSTMT/SYSPLAN to beaccessed. This option can be usefull because normally, DB2 Catalog tables (SYSIBM) related toDBRM (like SYSSTMT and SYSDBRM) don't have Indexes and there are norestriction to create indexes on clone/shadow DB2 Catalog Tables.TurboTuneSQL suggests to created the following not unique indexes either for clonedtables or DB2 system catalog tables:

TABLE SYSSTMT: ("PLNAME ASC , "NAME" ASC )

TABLE SYSDBRM: ("NAME" ASC , "TIMESTAMP" ASC)

TABLE SYSPLAN: ("NAME" ASC)Note: In order to execute TurboTuneSQL Batch JOBs, you must have SELECT authorityin tables: SYSPACKAGE/SYSPACKSTMT/SYSDBRM/SYSSTMT/SYSPLAN.

For option D (DBRM data set) When extracting statements from the DBRMLIB data set (“SQL Source will be extracted”is D), specify:

DBRMLIB data set name data set with DBRMs to be processed


62

Default Qualifier for tables Specify qualifier to be forced when SQL statement with unqualified objects is used.

If you change these parameters, JCL needs to be re-created.

For option T (Sequential data set with SQL Text) When extracting SQLs from TurboTuneSQL Sequential File with SQL text (“SQL Sourcewill be extracted” is T), specify an input data set Name.

If you want to use this option, there are some rules that must be obeyed to describeyour SQLs in the sequential data set. Check SQL Sequential data set Utility tounderstant how SQLs must be coded in the sequential data set.

You can use this utility to test SQL changes in mass. Using SQL Sequential data setUtility and using above option 'T', you can ‘clone’ all of your SQLs syntax from yourapplication programs, make your SQL changes and re-input altered data to test yourchanges. Tip: use a new Request Code when re-inputing the data.


DB2 Location Name(s) DB2 DDF location names.

If you have DataSharing, code all DB2 locations for all DB2 Members.

If you don’t have DataSharing but have DDF, just code the location for the DB2 ownerof DB2 Catalog. If you did not setup DDF, enter any string.

TurboTuneSQL will use this information to discover whether DB2 tables coded in SQLtext belong to this DB2 catalog or not. It will check SQLs coded using a 3-part-nameformat to match all location name(s); if location matches or SQL was not coded using a3-part-name, the DB2 table definition must exist in this DB2 Catalog.

Log parameter Control the level of messages is shown in the TurboTuneSQL log data set (ddnamemessages) ● Y – shows programs and statements being processed● N - shows programs being processed ● E - shows programs being processed. Statements will only be shown if they are

marked with processing errors.To learn more about processing errors, please refer to Appendix E. Limits and checkthe field flag error in the STIF Report.

Space Reduction Parms This parameter controls if TurboTuneSQL should load some particular information aboutinput data. In this sense, you can save disk space and can speed up TurboTuneSQLReports.

Load Variables Load literal, special register and host variables into TurboTuneSQL tables? Valid values:

Y - Load (best option – more disk space, but more accurate data)N - Do not load


63

Load Real Columns Only Load DB2 Table column only or Table columns and View columns?

Y - Load Table ColumnsN - Load Table and View Columns (best option – more disk space, but more accurate data)

Load View Create Text Load DDL text ‘Create View’ for each SQL command accessing views?

Y - Load N - Do not load (best option – save disk space)

Load View Predicate Info Load Predicate information found in DB2 view definitions?

Y - Load (best option – more disk space, but more accurate data)N - Do not load

Load All SQL Columns Load all columns Cross Referenced in SQLs?

Y - All columns will be load, even columns not referenced in DB2 predicates and sort clauses (like order by). This option will load into TurboTuneSQL selected columns from SQL Select Clause, all columns from SQL Insert and all updated columns from SQL Update.N - Only columns referenced in DB2 predicates and sort clauses (like order by) will be loaded.

If you choose option ‘N’, TurboTuneSQL Reports LG01, NW01 and SRCO will not workproperly.


64

Filters for Explain Utility (option 4.1.4)

The screen below is used to define filters to execute the explain utility to loadinformation from Plan Tables into repository.

TurboTuneSQL has utility to execute DB2 EXPLAIN function against SQL commandsstored into TurboTuneSQL Repository (Source Tables). Also, instead of execute Explain,this utility can copy user Plan Tables into TurboTuneSQL Repository.

To define Explain Data, on main screen choose “Load Workload and Source Data intoTables”, “Explain”. This option is the same Explain Utility found in Chapter 5 Utilities.

All Explain Data are stored using Request Code for Explain. Like Request Code forSource, this key guarantees a historical view of your Explain Data.

This utility can be used for several proposals and it can be used any time you want.Even when you are processing Traces and SQLs into TurboTuneSQL.

But it is possible to skip this step. Check item “Generate Jobs” in this chapter.


65

TurboTuneSQL V120 ----------------- Explain Utility --------------------- 16:33 Option ===> More: + Profile : IVP {E} DB2 SSID : DBBG Execution Mode: 1 Values: 1 - Execute Explain Only 2 - Execute Plan Table Copy Only 3 - Execute both functions Back-up Plan Table : N Y/N Backup explain data before execute this process --------------------------------------------------- Execute Explain PARAMETERS (Execution Mode 1 and 3) --------------------------------------------------- General Parms: Explain Request Code: DBBG Store explains in this Req Code Source Request Code: DBBG Retrieve SQL from this Req Code Get SQLs from programs: S Values: W - Workload (only executed statements) P - Last Trace (current trace) S - Source (all precompile versions) L - Source (last precompile versions) Process all stmts: Y Values: Y - Process all statements N - Process only normal statements Process Static/Dynamic: B Values: D - Process only dynamic statements S - Process only static statements B - Process both static and dynamic stmts Process all collections: N Values: Y - Process SQLs found in all Collections N - Process SQLs found in first Collection

Calculate DASD Spaces (option 4.1.5)

The screen below is used to define values to calculate the necessary disk spaces for allTurboTuneSQL Work Files for batch jobs to load all the information into repository.

The above screen shows the first part of panel. Type F8 to see more fields.

FIELD DESCRIPTIONS

Input FieldsNumber of records from DB2 Accounting tracesNumber of account records. For SMF records, you can set this parm to the same values as shown in IBM Utility IFASMFDP.If you change this parameter, JCL needs to be re-created.

Number of records from DB2 Performance tracesNumber of account records. For SMF records, you can set this parm to the same values as shown in IBM Utility IFASMFDP.If you change this parameter, JCL needs to be re-created.

Number of dynamic SQLs from DB2 tracesNumber of dynamic SQL found in DB2 traces. DB2 normally generates one IFCID 63record for each Dynamic SQL. If you change this parameter, JCL needs to be re-created.


66

TurboTuneSQL V120 ------------------- Space Options --------------------- 08:14 Option ===> More: + Space Options Profile : IVP {E} DB2 SSID : DBBG Input for calculation: Number of records from DB2 Accounting traces : 000002000 Number of records from DB2 Performance traces: 000002000 Number of dynamic SQLs from DB2 perf traces : 000002000 Number of SQLs from DB2 SQL Cache : 000002000 Number of programs to be processed from DB2 Catalog: 000002000 Percentage of views Used: 50 Percentage of full select: 25 Percentage for primary allocation: 10 Percentage for secondary allocation: 10 Total Space for this run in CYLS: 0002571 (old,delete)

Number of dynamic SQLs from DB2 SQL CacheNumber of dynamic SQL found in DB2 SQL Cache Area.If you change this parameter, JCL needs to be re-created. Number of programs to be processed from the DBRMLIB (or from DB2 Catalog or from Text)Number of programs to be processed from the DBRMLIB or from DB2 Catalog or fromSQL Sequential data set.If you change this parameter, JCL needs to be re-created. Percentage of views used Percentage of Views used relative to number of Tables in Catalog. If you have one DB2view for each DB2 Table name, this number should be set to 100(%).If you change this parameter, JCL needs to be re-created.

Percentage of full select Percentage of SQL commands using SELECT ‘*’. You must also consider all DB2 Views using SELECT ‘*’. This parameter helps TurboTuneSQL to understand how many DB2columns will be found in each SQL command.If you change this parameter, JCL needs to be re-created.

Percentage for primary quantity in CYLS for all allocations After TurboTuneSQL calculates all data set sizes, this parameter will determine howmuch percentage should be set for each JCL primary allocation.If you change this parameter, JCL needs to be re-created.

Percentage for secondary quantity in CYLS for all allocations Same as above. This parameter will determine how much should be set for each JCLsecondary allocation. If you change this parameter, JCL needs to be re-created. Output Fields There are several internal TurboTuneSQL fields shown on this screen. Each field meansa work or sort data set allocation. Total Space for this run in CYLSThis is the total space necessary to run TurboTuneSQL batch process to load DB2 tracesand all other DB2 information.

Tip: To solve SORT space problems you could request DFSORT to use dynamic allocation for work data sets using the following ddname:

//DFSPARM DD * OPTION DYNSPC=1000,FILSZ=E5000123,DYNALLOC=(SYSDA,20)


67

Create JCLs to Submit Batch JOBS (option 4.1.6)

Use this option to create all batch JOBS to Load data into TurboTuneSQL Repository.The created jobs will use all previous information from the options 4.1.1 to 4.1.5.

FIELD DESCRIPTIONS

Process DB2 Trace Data or Process Source OnlyOptions:

‘Y’ - This will create JCL to load information from DB2 Traces and to load SourceSQLs (from DB2 Catalog, DBRMLIB, etc)

‘N’ - This will create JCL to load information only from Source SQLs

Tip: We recommend to load all SQLs (option N above) at least once a week. This willgive much more information for analysis purposes.


Execute ExplainOptions:

‘Y’ - This will create the JCL to execute TurboTuneSQL Explain Utility ‘N’ - Do not create this JCL


At end, type JCL to generate all jobs. Check JCL command for more information.

Always execute the generated jobs in the same order as displayed on the screen.Check Appendix JCL Description for a summary of all the JCL generated byTurboTuneSQL.


68

TurboTuneSQL V120 ------------------- Generate Jobs --------------------- 09:20 Option ===> TYPE "JCL" TO GENERATE JOBS Profile : IVP {E} DB2 SSID : DBBG Process DB2 trace Data or Process Source Only : Y Y/N Y - JCL will be created to process Workload and Source N - JCL will be created to process Source Stmts ONLY Execute Explain : Y Y/N

Online Reports (option 4.2)

The screen below is the menu for the online reports to inquiry information from Db2Catalog, TurboTuneSQL repository workload/source and results from TurboTuneSQLutilities.

Chose the report code (4 characters) and the report will be displayed.

Filters are available and will be explained in detail in each report description.

TurboTuneSQL Reports gives much more information about vital DB2 performanceindicators, like DB2 CPU, DB2 Wait time, etc. It provides a complete set of Reports tohelp you to understand what is happening in your DB2 applications. Examples offunctionalities provided by Online Reports:

Shows the heaviest DB2 program: CPU, Wait, Elapsed, etc Shows the heaviest SQL command: CPU, Wait, Elapsed, etc. And can be

grouped by:o ‘Identical’ SQL commandso Similar SQL commandsCheck Appendix Algorithms for more details

Shows the DB2 tables with more access in terms of CPU Provides a complete DB2 Cross Reference Activity. Can see a previous executed Explain or allow an online explain. Can discover SQL commands with SCAN, filtered by Connect type, like

discover all SQL within CICS transaction with Table or Index Scan. Etc

Check Chapter 3 for more information.


69

TurboTuneSQL V120 ------------------ Online Reports --------------------- 09:39 Option ===> Profile : IVP {E} DB2 SSID : DBBG Report : Curr Loc : DALLASB Filters ---------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 Plan Name : CnTy: TimeR : 00.00.00 23.59.59 Correlation Name : Program: SSID: Source/Explain Req Code: DBBG / DBBG Unique : Table Creator: Table Name: DB2 CATALOG SRIC: Programs TB00: Tables TD00: Database REPOSITORY/WORKLOAD AC00: Programs APLN: Plan Names ASSI: SSIDs CO00: Collections ACNT: Connection Types ACNI: Connection IDs CICS: CICS Transactions IMSM: IMS Attach ACOR: Correlation IDs ST00: Group of Tables ST01: SQLs ST02: SQLs-Identicals ST03: SQLs Similars ST04: SQLs using SCAN SNEG: SQLCODEs Summary RF00: General Xref DB10: First Table REPOSITORY/INVENTORY SRPG: Programs SRPS: SQLs SRMI: Plan Table Comp SSCO: SQL Comments

Batch Reports (option 4.3)

The screen below is the menu for the batch reports to print information from Db2Catalog, TurboTuneSQL repository workload/source and results from TurboTuneSQLutilities.

Chose the report with a “/” and type JCL to generate the JOBS.


As mentioned previously, TurboTuneSQL Reports gives much more information aboutvital DB2 performance indicators, like DB2 CPU, DB2 Wait time, etc. It provides acomplete set of Reports to help you to understand what is happening in your DB2applications. Examples of functionalities provided by Batch Reports:

Shows the heaviest DB2 program: CPU, Wait, Elapsed, etc Shows the heaviest SQL command: CPU, Wait, Elapsed, etc. And can be

grouped by:o ‘Identical’ SQL commandso Similar SQL commandsCheck Appendix Algorithms for more details



70

TurboTuneSQL V120 ------------------ Batch Reports ---------------------- 10:22 Option ===> TYPE "JCL" TO GENERATE JOBS Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Filters --------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 Plan Name : CnTy: TimeR : 00.00.00 23.59.59 Correlation Name : Program: SSID: Source/Explain Req Code DBBG / DBBG Unique : Table Creator: Table Name: Level : 3 Trace Origin: A Max Objects: 00250 Type / to select a report ---------------------------------------------------- WORKLOAD (REPOSITORY) WORKLOAD SHORT (REPOSITORY) / AW00: Accounting Cache Summary / SH01: Programs (all) / LG01: SQLs Log Impact / SH02: Program Batch / NW01: SQLs Network Impact / SH03: Program Online / PG00: Program Summary / SH04: Stor Procedure / ST02: SQLs Identicals / SH05: CICS/IMS / SH06: Programs Batch/Online / SH07: Tables Summary / SHFE: Fetch/Open Summary

Utilites (option 4.4)

The screen below is the menu for the TurboTuneSQL utilities.

Chose the utility code (4 characters) and the screen for the specific utility will bedisplayed.

Filters are available and will be explained in detail for each utility description.

TurboTuneSQL Utilities are able to help to compare information in different aspects andalso maintain TurboTuneSQL repository.



71

TurboTuneSQL V120 ------------------- Utilities ------------------------- 10:30 Option ===> Profile : IVP {E} DB2 SSID : DBBG Utility: Curr Loc : DALLASB BATCH UTILITIES ON-LINE UTILITIES CLEA: Clear Product Tables EXPL: DB2 Explain CPLA: Compare Plan Tables SQL : Execute SQL commands DDLG: DDL Generator DB2 : Execute DB2 commands EXPB: Explain Utility SQLG: SQL Sequential Data set STAR: Start DB2 Trace SUPPORT (LAB DIAGNOSIS) XREF: SQL Tables Cross Reference SEND: Send data to lab MRFC: Multi-Row Fetch Converter MEM : Storage Manager Summary

MANAGING INDEX RECOMMENDATIONS (option 5)

The screen below is the menu for MANAGING INDEX RECOMMENDATIONS.

Option 1 is used to actually set all parameters and generate the JOBs necessary toexecute the index recommendations.

Option 2 is another way to analyze indexes manually.

Option 3 is used to adminstrate Virtual Indexes. Instead of creating physical indexes toanalyze access path for your applications, here, the user is able to create VirtualIndexes.

Option 4 is used to run batch reports to print duplicated indexes, non-used indexes,etc.


72

TurboTuneSQL V120 ---------- MANAGING INDEX RECOMMENDATIONS ------------- 10:38 Option ===> MENU Profile : IVP {E} DB2 SSID : DBBG 1 - Automatic Index Recommendation User ID : IBMUSER Time : 10:38 2 - Manual Index Analysis Language : English Tso Logon: DBSPROCB 3 - Virtual Indexes Configuration System Id: S0W1 MVS Acct : ACCT# 4 - Batch Reports for Indexes Appl Id : SADV Term CCSID: 00037 Prof CCSID: 00037 Customer Name: CRITICAL PATH SOFTWARE

Automatic Index Recommendation (option 5.1)

The screen below is the Automatic Index Recommendation screen.

TurboTuneSQL Index Recommendation component generates all necessary informationto help DBAs to execute DB2 Index Analysis.

TurboTuneSQL have two methods to perform Indexes Analysis: Manual Method orAutomatic Method.

The screen above is for Automatic Method.

Automatic Method

TurboTuneSQL Automatic Index Recommendation Utility uses an Artificial Intelligencealgorithm that automatically chooses and combines columns to test several DB2Indexing possibilities. Also, it uses a “what-if” processing approach that that allows youto choose which columns to include in an index to test a specific DB2 index design.Consider how an index with the following order of columns (A, B, C) is a completelydifferent index with the columns ordered as (C, A, B). In mathematical terms, this is afactorial problem (N!) which means this tasks would be almost impossible to workmanually.

Concepts

Indexes recommendation is a very difficult task. Many things must be verified whendoing an index recommendation:

•Access table counts: total Insert/Update/Delete activities versus less Select activity •Check if existing indexes are being used•Look for redundant indexes•Columns unsuitable for usage in index, like no cardinality, length, etc•There are static packages dependencies on DB2 catalog?


73

TurboTuneSQL V120 ----------- Automatic Index Recommendation - Row 1 to 2 of 2 Option ===> List of Requests Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: Table Name: User ID : Line Actions ------------------------------------------------------------------ (C)Create Request (U)Update/Submit (B)Browse Parameters (R)Recommended Actions (P)PlanTable Comparison (D)Delete Request Code ------------------------------------------------------------------------------> C RCode Owner.Table Name Status User ID M VInd ETime - ----- -------------------------- ------------------ -------- - ---- ----- RCIX1 IVPQUAL.IVPTABLE_T001 ENDED SUCCESSFULLY IBMUSER I Y N RCIX2 IVPQUAL.IVPTABLE_T002 N/A IBMUSER I Y N ******************************* Bottom of data ********************************

•There are dynamic SQL using this indexes?•Utilities activities

Except for Utilities Activities, all above issues are addressed by TurboTuneSQLAutomatic Index Recommendation.

These are the principal features of this utility: •You can create indexes recommendations for one or more tables •Following indexes recommendation (or actions) can be issued by this utility:

Create New indexes to be createdDrop Drop old indexesKeep keep indexesAttention Attention are warning messages that can be issued to

provide user with useful information about current indexes recommendation.

•DB2 Virtual Index facility may be explored (no DDL command is issued).•Static and dynamic SQLs may be used as input.•Can automatically choose columns to test and combine new indexes (ArtificialIntelligence Method) or allows you to choose which columns should be used to test(“what-if” Method).•Workload may be used. Therefore, SQLs with more execution frequency will takeadvantage over SQLs less executed. •Analysis of Identical and similar indexes. Identical and similar indexes may have aDROP recommendation.•Identifies non unique indexes that may be turned unique.•AUTOMATIC WORKLOAD COMPARISON: Automatically shows programs differentaccess path by comparing access paths before and after recommendation takeeffect. •SAVINGS: Determine CPU/Service Units savings percentage after checking SQLexecution frequency (also total of Inserts / Updates / Deletes activities versusSelects).

Artificial Intelligence and What-if Method

Artificial Intelligence MethodIndex recommendation is a very difficult task because there are many problems to be addressed. For some tables, too many indexes candidates should be tested. In these cases, the time to test the whole solutions (method known as brutal-force) may take many days processing for just one table.

TurboTuneSQL Automatic Index Recommendation use an artificial intelligence algorithm that tries to bring good results but avoid testing all solutions. This algorithm will choose and combines several columns to test several DB2 Indexes possibilities.

What-if MethodThis method allows you to manually choose which columns should be used to test aspecific DB2 indexes.


74

Automatic Index Recommendation Overview

This figure gives an overview how TurboTuneSQL Automatic Index Recommendationworks:

TurboTuneSQL Automatic Index Recommendation Utility uses the following input/outputinformation.

INPUT: •SQLs: SQL text loaded into TurboTuneSQL repository will be used as input. Toimprove batch response time, not all SQLs will be used. Users can choose type ofSQLs that will be used as input:

1.Only identicals sqls2.Only similars sqls3.Dynamic option: if using this option, TurboTuneSQL will dynamically choosebetween identical or similar SQLs.To understand more about identical or similar SQLs, please refer to Algorithms

•WORKLOAD: To produce better results, top executed SQLs may have morechances to receive good indexes. The execution frequency may be obtained fromDB2 Performance traces or from SQL Cache Area stored into TurboTuneSQLrepository.•CATALOG: DDL definitions like table, indexes and columns definitions and db2statistics are obtained from DB2 Catalog.•EXPLAIN: TurboTuneSQL Automatic Index Recommendation makes use of DB2optimizer. Therefore, it will execute several time of DB2 explain command againstinput SQL to test if indexes are good or not.


75

OUTPUT:

•INDEX RECOMMENDATIONS: The following indexes recommendation (or actions)can be issued by this utility: Create, Drop, Keep, Attention

•SAVINGS: To check how good is an index, TurboTuneSQL will provide Savings field.Total Savings correspond to service unit DB2 explain field (PROCSU) and it iscomputed as total PROCSU after recommendation subtracted from beforerecommendation (PROCSU before less PROCSU after).

•AUTOMATIC WORKLOAD COMPARISON: Using explain output, utility willcompare all inputed SQLs in terms of access path and cost differences. Therefore,users are able to check all affected programs (positively or sometimes negatively). Inother words, the comparison shows programs access path differences by comparingaccess paths before (original format B) with access paths after (original format A)automatically. Click here for more information about original format field.

Short explannation of TurboTuneSQL Index Recommendation ACTIONS:

CREATE INDEX ACTION:New indexes will be recommended by TurboTuneSQL when total service units savingsare positive. Note: negatives savings are also possible in a specific situation (checkIXRM report).

DROP INDEX ACTION: Examples of reasons why TurboTuneSQL has recommended a drop action:–No rows found in PLAN TABLE and there is no catalog dependencies (no rows found inSYSIBM.SYSPLANDEP and SYSIBM.SYSPACKDEP)–Indexes is identical or similar to another index. Note: Click on How indexes are compared to identify similar and identical indexes tofind more about how indexes are compared to find identical and similar indexes andwhy this index has received DROP recommendation.

KEEP INDEX ACTION: Some examples of reasons why TurboTuneSQL has recommended a keep action:–Rows found in PLAN TABLE and there is a catalog dependencies (rows found inSYSIBM.SYSPLANDEP or SYSIBM.SYSPACKDEP)–Index is partitioned–Index is not identical or similar to another index

ATTENTION INDEX ACTION: Attention are warning messages that can be issued to provide user with usefulinformation about current indexes recommendation.Example: TurboTuneSQL can warn you that you can transform an index with duplicateatrribute to unique attribute.


76

Filter Descriptions

Table Owner:Table Owner to filter occurrences in this screen.

Table Name:Table Name to filter occurences in this screen.

User ID:User ID to filter occurrences in this screen.

Field Descriptions RCode Indicate the request code for Index associated with this index recommendation.

Owner.Table Name Owner and Table Name used for recommendation. A plus (+) sign, indicates there aremore objects for this recommendation.

StatusStatus for the recommendation.

N/A JOB NOT SUBMITTED, Canceled by user or issued Return-Code > 04.

ENDED SUCCESSFULLY JOB successfully executed with Return-Code 00 or 04.

PROCESS STOPPED STOPPED by user request.

INCOMPLETE JOB issued an Error Message and terminated with Return-Code > 04.

User ID User ID that created the request. Only this user id will be able to update and submitthis recommendation.

M Method used for this recommendation. I – Artificial Inteligence W – WhatIf VInd Virtual Indexes Y – Virtual Indexes were used in this recommendation. N – Physical Indexes were used in this recommendation.

Etime Estimate Time request. Y – User requested to estimate processing time only for this recommendation. Therecommendation will not be executed. N – Recommendation will be executed normally.

Submission Date Date and Time the user submitted this recommendation.

End Date Date and Time the recommendation was ended.


77

Available Line Actions

(C)Create Request CodeA pop up screen will be displayed to create a new request code.

(U)Update/SubmitIXRE Panel will be diplayed to configure your Automatic Index Recommendation. Also, use this option to submit the batch process that will processs the request for recommendations.

Note: Do not change the configuration while the recommendation is executing.Unpredictable results can be generated.

Only one recommendation can be executed at a time.

(B)Browse ParametersIXRE Panel will be diplayed to show all parameters for this recommendation.

(R)Recommended ActionsIXRT Panel will be diplayed to show all recommended actions.

(P)PlanTable ComparisonIXMI Panel will be diplayed to show all access path comparisons.

(D)Delete Request CodeA pop up screen will be displayed to confirm the deletion for this request code.


78

Create Request line action

When choosing line action (C)Create, the screen below will be displayed to add a new request code for recommendation (type = I).

Other types of request code can be added as well.

Enter the 5 characters request code and description.


79

TurboTuneSQL V120 ------------------- Request Code Control -------------- 06:50 Option ===> Create Request Code Description Profile : IVP {E} DB2 SSID : DBBG Request Code: This is a free 5 characters code to be used as a unique identifier into TurboTuneSQL Tables. Usage examples: RUN01, LAST, FIRST, PROD, TEST Type I Valid Values: S - Request Code to be used by Source SQLS in TurboTuneSQL E - Request Code to be used by Explain Utility I - Request Code to be used by Index Recommendation Description:

Update/Submit line action

When choosing line action (U)Update/Submit, the screen below will be displayed to configure all parameters necessary for the recommendation and after typing JCL a JOB will be created to submit the recommendation.

Please, read guidelines for important tips.

SPECIAL ONLINE COMMANDs DEFAULT: Some parameters have been set to default values. Click here for more

information. LSTTAB : List Tables by catalog. Wildcard can be used. Report TB00. JCL : Submit batch indexes recommendation processes. Click here for more

information.

FIELD DESCRIPTIONS

MAIN PARAMETERS

Index Recommendation Req.CodeThis is a free 5 characters code identifying the request for this recommendation. It wascreated via line action (C)Create. All stored recommendation will be associated with this request code.


80

TurboTuneSQL V120 ------------------- Automatic Analysis ---------------- 06:53 Option ===> Type "JCL" to generate jobs,"DEFAULT" to reset values,"LSTTAB" to list tables IXRE - Automatic Index Recommendation Parameters Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Index Recommendation for Request Code: RCIX1 --------------------------------- Recommendation Method : I I/W A.I/What-IF ( Type '/' for setup ) ONLY estimate processing time: N Y/N Y-Recommendation will not be performed Recommend Indexes for Tables: ------------------------------------------------- IVPQUAL . IVPTABLE_T001 Type '/' for more owner.tables Options ----------------------------------------------------------------------- Source Request Code : DBBG SQLs from Workload, Source or Mix : M W/S/M Use Virtual indexes (VT) : Y Y/N (For Y, consider the use of VOLATILE table attribute) Execute Runstats : N Y/N Default parameters for new indexes Creator : C1 Valid for Virt/Physical Indexes Storage Group : S1 Valid for Physical Indexes Alloc.Primary: 00004 Secondary: 00004 Valid for Physical Indexes More Options. Type '/' to choose an option ------------------------------------ Explain Options and Input SQLs Define processing time and accuracy Drop Options Define which indexes can be virt dropped

Recommendation Method Valid values:

I- Let TurboTuneSQL make indexes recommendations using Artificial Intelligencealgorithm.

Type '/' for Artificial Intelligence algorithm setup ARTIFICIAL INTELLIGENCE

W- “What-if”. Let users to test their own index set.

Option What-IF (mainly) and a table or a list of tables will be used as input toWhat-if method.In some cases of Table Filter option was specified and there is no what-if indexspecified for it, TurboTuneSQL will still make recommendations over the pre-existing indexes either, such as, duplicated or non-used indexes and otherrecommendations. For instance, you have chosen DATABASE as table filter and didnot specify some tables, TurboTuneSQL will analyse the pre-existing indexes either.WHAT IF option defines tables and indexes to be used as input.

Note: when using What-if method, consider set parameter Drop at end to 'F' (force)to be able to make a deep analysis of the suggested indexes.

Type '/' for What-IF suggested index setup WHAT IF

ONLY estimate processing time Use this option to estimate how long it will take to run this job using the currentparameters. Estimate time processing will not perform recommendation.Valid values: Y - Calculate estimated time processing. The basic computation used is Explain Time Average parameter multiplied by forecastnumber of explain for current table.Note:

–When using this option, parameter Clear Recommendation Results parameter willbe respected.–Depending on how many tables you are processing, batch job may take some timeto process. –Once any of the explain options have been checked, they will be ignored when youchoose to only estimate time process.

N - Run this job normally

If you have set option ONLY estimate processing time to YES, check messageSADBIXRE078I in MESSAGES data set to get the total amount of time required toprocess all selected tables. Note: the previous message will provide two numbers for "total amount of time": - the expected total amount of time to recommend indexes using Identical SQLs - the expected total amount of time to recommend indexes using Similar SQLsTo fit your batch processing time needs, you must set your preferred filter settingsusing option EXPLAIN SQLs (and others) in EXPLAIN OPTIONS AND INPUT SQLS.


81

The screen above will always be displayed to remind the user to estimate proccessingtime before executing an index recommendation.

Recommend indexes for Tables

It is available some options to filtering tables to perform index recommendations formore than one Program, or more Correlation or even more other Tables. Inform '/' toshow a windowed screen to expand more occurrences possibilities.Inside the expanded screen, you can issue commands:LSTTAB owner.tablename List tables by catalog (wildcard can be used).ERASE Erases all unprotected parameters.

Table Inform Table owner and Table name to perform index recommendations or a list ofup to 20 tables. A symbol '+' will be shown next to it to indicate that there are morethan one table informed. Wildcard CAN be used only if there is no other table informed. To check all availabletables you may use online command LSTTAB. Table owner SYSIBM can NOT be informed.

OPTIONS

This parameters are needed for both methods (Artificial Intelligence Method and “What-if” Method).

Source Request CodeThis is a 5 character code used as key identifier to read stored SQL commands fromTurboTuneSQL Repository.


82

------------------------------ Automatic Analysis--------------------- IXRE01- Tip: Always Use Time Estimating Processing before executing an index recommendation. If you have already used it, ignore this message. Also, in order to reduce total execution time, check parameters in option SQL Entry File and Explain NOTE: The table filtered has 15 UNIQUE SQLs CONFIRM ACTION Y- BATCH JOB WILL CLEAR PREVIOUS RESULTS N- RETURN TO PREVIOUS PANEL F1=Help

SQLs from Workload, Source or MixOption to reduce batch processing times but accuracy results may be affected.This is a filter to identify which SQLs will be used as input to Automatic IndexRecommendation to be analysed and explained.

Valid values:W: Explain only executed SQLs. SQL execution frequency will be obtained from DB2 traces. Identical and similar SQLswill have their execution frequency summarized. It may provides good results in termsof indexes recommendation accuracy. Batch processing may take less time if comparedwith options S and M.

S: Explain ALL SQLs found in source. SQL execution frequency will always have value 1. It may provides good results interms of indexes recommendation accuracy, but batch processing will take more timeto be completed.

M: Explain ALL SQLs found in source. For each SQL also found in DB2 traces, SQL execution frequency will be obtained fromDB2 traces. Provides the best results in terms of indexes recommendation accuracy,but batch processing will take more time to be completed.Identical and similar SQLs will have their execution frequency summarized.

Use Virtual Indexes (VT)It is important to observe that when choosing Virtual Index option, consider alter tableto use VOLATILE attribute in order to help DB2 optimizer to choose better indexes.Sample syntax for volatile:–alter table owner.table volatile (catalog field SPLIT_ROWS=Y)–alter table owner.table not volatile (catalog field SPLIT_ROWS=N)

If you want to create the indexes physically, you need to define a FACILITY classprotected by RACF. For further information, please check referred topic JOB INST50SEin TurboTuneSQL Installation Guide. Click here to have some tips about best practices of Index Recommendation: usingvirtual or physical indexes

Valid values:Y: The recommended indexes will be created (or dropped) virtually. TurboTuneSQL assumes some index default attributes when creating virtual indexes,this attributes are only valid for Artificial Intelligence recommendation method:

NLEVEL : -1NLEAF : -1FULLKEYCARDF: -1FIRSTKEYCARDF: -1CLUSTERRATIOF: 0CLUSTERING: NPADDED: NUNIQUERULE : It will contain: For AI method: D (allows duplicated)

For What-if method: It will be according to what user informedon panel

N: The recommended indexes will be created physically and dropped at end ofrecommendation. If Execute RUNSTATS was not set to yes, TurboTuneSQL will not change DB2 defaultvalues (-1 in most cases).For What-if method: It will be according to what user informed on panel Note: Existing physically indexes will never be dropped. Check Drop options for moreinformation.


83

Execute RUNSTATSControls the execution of RUNSTATS utility.

Valid values:Y: Execute RUNSTATS in the following phase: - Once per table or database before first Explain (OF – original format = B , before). - At each new internal suggested index (valid only if creating index physically).N: RUNSTATS will not be executed.

Default parameters for new indexes: Inform indexes parameters. They will be used when physical index creation has beenordered and on sample DDL indexes creation (available on ddname DDLS in batch job).Note: when automatically generated by TurboTuneSQL the indexes name will becomposed by Request Code for Index plus a sequential number. When Request Code isinformed under 5 (five) characters, it will automatically completed by '@'.

Creator Inform an index creator. Storage Group Inform DB2 Storage group. Maximum Primary allocation Inform index primary allocation Maximum Secondary allocation Inform index secondary allocation

MORE OPTIONS Type “/”

Choose an option:

EXPLAIN OPTIONS AND INPUT SQLSDROP OPTIONS


84

Explain Options and Input SQLs

Define processing time and accuracy

When typing “/” in Explain Options and Input SQLs in the previous screen, a pop upscreen below will be displayed.

Clear Recommendation Results

It controls if you want to clear previous results for this Request Code.

Valid values: Y - All previous results will be deleted.

N - If there are previous results, TurboTuneSQL will prevent you to clear them. If youwant to execute a new recommendation, change it to 'Y' or set a new request code forindex.Note: Once you typed 'JCL' to submit an index recommendation process, if there is anyprevious result for the current Request Code, the system will display a window toconfirm the action of submission. This window confirmation can follow a tip withmessage code IXRE01, please refer to TurboTuneSQL-Messages Guide for thecorrespondent code.


85

┌─────────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ ││ Explain Options and Input SQLs ││ More: ││ Clear Recommendation results : Y Y/N ││ Explain Options: ││ Explain with this Queryno : 05000 (starting number) ││ Plan Table and Virtual Indexes Qualifier: SADVQUAL ││ Average explain time : 0.30 (in seconds) ││ ││ Define INPUT SQLs and filters to reduce processing time ││ ││ Range limit for number of explains for each table: 00000000 to 00080000 ││ Using explain range, filter SQL by: D I/S/D(Identical/Similar/Dynamical ││ ││ Filter SQLs based on Plan Tables and Performance. ││ Type '/' to choose these filters: Logical conjunction: (AND) (OR) ││ ProcSU > 000000 Use of SORT ││ TS Scan Average CPU > 01.000000 ││ Index Scan Total Executions > 0000000001 ││ F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER ││ F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left │└─────────────────────────────────────────────────────────────────────────────┘

Explain Options:

Required authorities to execute DB2 Explain function:– SYSADM authority OR – Must have the authority to send SQL SET CURRENT SQLID (check option

Use this Plan Table Qualifier / Set Current SQLID) – It may be necessary to have the same authority as required by DB2 to

execute the command that will be explained, except if job INST33BE wasexecuted during TurboTuneSQL Installation Process.

– SELECT, DELETE, UPDATE on tables (or Alias are in DB2 version 8 or up):PLAN_TABLE, DSN_STATEMNT_TABLE, DSN_VIRTUAL_INDEX andDSN_VIRTUAL_INDEXES.

– EXPLAIN or SQLADM or System DBADM.(consult IBM DB2 documentation for more information.)

Explain with this Queryno

Query number to be used in Plan Tables after each explain.This is the starting number.

Plan Table and Virtual Indexes Qualifier

This is the qualifier for DB2 Plan Tables and for Virtual Indexes table. If you are notusing the default owner of TurboTuneSQL repository, you must create your own tables(PLAN_TABLE, DSN_STATEMNT_TABLE, DSN_VIRTUAL_INDEX andDSN_VIRTUAL_INDEXES). For sample DDL syntax, check TurboTuneSQL InstallationGuide manual.The recommendation here is to use PLAN TABLE created by TurboTuneSQL and not theUSER PLAN TABLE (specially when this USER PLAN TABLE is used in productionenvironment).

Note: A) All Virtual Indexes related to the tables requested by the user in theDSN_VIRTUAL_INDEXES used in this processing will be reset to disable mode. So, if theuser needs to set these Virtual Indexes to enable mode, it has to be done manually. B) During the Index Recommendation, any Virtual Index created by the user in theDSN_VIRTUAL_INDEXES used in this processing will be deleted.

Average explain timeInform the average explain time for a SQL according to the environment. Thisparameter is used only if ONLY estimate processing time parameter was set to Y.

Define INPUT SQLs and filters to reduce processing time:

Range limit for number of explains for each tableOption to reduce batch processing times but accuracy results may be affected. This parameter controls the maximum number of explain that can be performed foreach table being processed.When the total number of explains for each table is not within this range, the table willNOT be processed for the index recommendation. When only one table is informed, setvalue to zero (NO LIMIT). This limitation will reduce the batch processing time.TurboTuneSQL will check if the forecast number of explains for current table fits ininformed explain range.


86

If fits, Explain will be done and a table will be processed. If not, table will be skipped.

Also, if parameter Explain SQLs was set to 'D' (dynamic), TurboTuneSQL will check:– If the forecast number of explain to process identical fits, Explain SQLs will be setto 'I'. If it does not fit, the forecast number of explain to process similars will bechecked. If it fits, Explain SQLs will be set to S.– If both fails table will be skipped.

If you do not want to limit the explains, inform fields as zero (allowed only if just oneOwner and Table name is informed).

Using explain range, filter SQL by

Option to reduce batch processing times but accuracy results may be affected.This parameter let you choose which kind of SQLs will be explained.TurboTuneSQL Automatic Index Recommendation Utility has several internal explainphases:

- Initial or Before Explain phase:This is the first explain related to current table. Only identical SQLs are explained. Therefore, if same SQL is found in several programs, it will be explained once.In the example above, just one SQL will be explained (this will speed-up analysis). Example:

Program PGMA contain:SELECT * FROM TABLE WHERE COD=?SELECT * FROM TABLE WHERE NAME=?

Program PGMB contain:SELECT * FROM TABLE WHERE NAME=? (repeated)DELETE FROM TABLE1 WHERE STATE=?

Each SQL explained will be stored as 'B'- Before (original format). If you have ordered RUNSTATS, RUNSTATS will be executed before this initial explain.

- Testing Indexes Explain phase:SQLs are explained repeated times to test every new set of indexes candidates. Normally this is the longest internal phase of this utility.

- Ultimate or After Explain phase:This is the last explain related to current table after new indexes been created and old indexes being dropped. Like initial phase, only identical SQLs are explained. Each SQL explained will be stored as 'A' - After (original format).

Using explain range, filter SQL by parameter only controls Testing IndexesExplain phase. Because this is the longest phase, this parameter let you choosewhich kind of SQLs will be explained.

Valid Values: I – Only identical SQLs will be explained Provides the best results in terms of indexes recommendation accuracy, butbatch processing will take more time to be completed.S - Only similar SQLs will be explained.Only similar SQLs for TurboTuneSQL are SQLs with same GTAB, GCOL and GSRTwill be explained. SQL INSERT and SQLs with no Where Clause and will not beexplained Provides good results in terms of indexes recommendation accuracy and batchprocessing will take less time to be completed.


87

To understand more about identical or similar SQLs, please refer toAlgorithms.D - Dynamic option. TurboTuneSQL will dynamically choose either option I andS depending on parameter Explain range limits for each table.See a behavior example in SAMPLE USAGE

Note: It does matter which parameter was chosen, only non-repeated SQLs will beused as input. For instance: If SQL with unique number 00AB2A01 is repeated inprogram A and B, it will generated here just once.

If you set option ONLY estimate processing time to yes, message SADBIXRE078Iwill provide the total amount of time required to process all selected tables. Theprevious message will provide two numbers for "total amount of time: the expectedtotal amount of time to recommend indexes using Identical SQLs and using SimilarSQLs. Therefore, option ONLY estimate processing time will help you to configureout option EXPLAIN SQLs.

For better batch performance, it is provided some other explain options to filter SQLsbased on Plan_Tables and Performance which will exclude good commands accordingto parameters, therefore, only highly costly commands will be analysed.

Filter SQLs based on Plan Tables and Performance

Logical conjunction (AND) (OR) The clauses (AND) and (OR) are mutually exclusive. It is only required when the user has chosen more than one option below:

.ProcSU

Service Unit Cost requests a minimum value for filtering .TS Scan (AccessType = R)

Tables Space Scan .Index Scan (AccessType = MX, DX, N, NR, I, IN, I1 and Matchcols=0) .IndexAccess with Matchcols (AccessType = MX, DX, N, NR, I, IN, I1)

For Index Access with Matchcols, inform a minimum matchcols value .Use of SORT (SORTN and SORTC ) .Average CPU

Average CPU for commands executed in workload. The following commands are computed: Open, Delete, Insert, Update, Truncate, Merge, Refresh and Select

.Total ExecutionsTotal executions for the command

The logical conjunction AND works if the SQL has satisfied all of the chosen options

condition and the logical conjunction OR works if the SQL has satisfied at least one ofthe chosen options condition.

Notes:-These options will be ignored when you choose Y in option ONLY estimate the processing time in the main parameter.

-If DROP at End was selected a warning message will be issued.

See a behavior example in SAMPLE EXECUTION TIME


88

Process Static/Dynamic SQLs

Specify:

D: to process only dynamic statements S: to process only static statements B: to process both dynamic and static statements

Program NameInform a program or a list of up to 20 programs to be used as FILTER. To insert moreprogram names, type '/' in the next field. If there are more than one program from thelist, a symbol '+' will be shown and is editable.Wildcards are not available.Check the table of consistency below for further information.

Connection Type Inform Connection Type as a Filter. Valid only if Get SQL STMTS found in parameter isW or M.Valid Codes: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH

Start/End DATE Inform start/end range date. Valid only if Get SQL STMTS found in parameter is W or M.

Start/End TIME Define start/end range time. Valid only if Get SQL STMTS found in parameter is W orM.

DataSharing FiltersDB2 Group Name DB2 Data Sharing Group Name. Valid only if Get SQL STMTS found in parameter is W orM.

DB2 Member Name FROM/TODB2 Data Sharing Member Names. Valid only if Get SQL STMTS found in parameter isW or M.

SSID DB2 Subsystem ID. Valid only if Get SQL STMTS found in parameter is W or M.

Note: To verify all valid combinations, please check Cross Reference of Table Filterand Input SQLs


89

Drop Options

Define how indexes should be virtually dropped When typing “/” in Drop Options in the previous screen, a pop up screen below will bedisplayed.

Drop Indexes Control:

Drop at startDrop old (existing) table indexes before starting the processes of new indexesrecommendation.

– If Virtual Indexes parameter was set to N, this parameter will be ignored (value Nwill be used).

Valid values:Y – Existing indexes will be virtually dropped. When you set this value to 'Y' the pre-existing physical indexes are dropped virtuallyaccording to drop rules below and exception filled.N - Indexes will be left intactWhen you set this value to 'N' the pre-existing physical indexes will left intact.This parameter must be set to N if Virtual Indexes parameter was set to N.

Drop at end

Inform if TurboTuneSQL should recommend drop action for existing table indexes.Before drop an index, TurboTuneSQL will also check parameters Drop RestrictionsIf Virtual Indexes parameter was set to N, this parameter will be ignored and nophsycal drop will be issued.


90

┌─────────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ ││ DROP OPTIONS ││ More: ││ Drop Indexes Control: ││ Drop at start: N Drop old indexes before start recommendation ││ Valid values: (Only if using VT) ││ Yes - Indexes will be virtually dropped ││ No - Indexes will be left intact ││ Drop at end : Y Drop indexes at final recommendation ││ Valid values: (Only if using VT) ││ Yes - Drop will be recommended for duplicated ││ or non-used indexes. ││ No - Drop will be recommended for duplicated ││ indexes ONLY. ││ F - Drop will NEVER be recommended. ││ ││ Drop restrictions: ││ Check these itens before recommend a drop action: ││ Drop indexes with Unique attribute. ││ F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER ││ F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left │└─────────────────────────────────────────────────────────────────────────────┘

Valid values:

Y - Drop will be recommended for duplicated or non-used indexes. You may set this parameter to Y only if Virtual Indexes parameter was set to Y.

N - Drop will be recommended for duplicated indexes ONLY. You may set this parameter to N only if Virtual Indexes parameter was set to Y.

F - Drop will NEVER be recommended. Even for duplicated or non-used indexes or anyother condition. You must set this parameter to F if Virtual Indexes parameter was set to N.

Notes:(1)If you have chosen WHAT-IF method and the value for Drop at end is set to F,TurboTuneSQL will NOT do any index comparison (identical or similar indexes).

(2) When using WHAT-IF method, your suggested indexes will receive a CREATErecommendation action only when they have an overall good result (positive savings),otherwise, no action will be appear on IXRM panel. However, If you want to see allqueries impacted by your guessed indexes, set Drop at end to 'F' (force). This optionwill allow you to visualize all SQLs affected by guessed indexes.

(3) For value 'Y', a warning message will be issued whenever find any consideringrecommendation for explain options.

Drop Restrictions

Check these itens before recommending a drop action.Very important: TurboTuneSQL may recommend a drop ONLY if:Drop at end was not set to 'F' - forceDrop at start was set to 'Y'

Notes: -Indexes defined with UNIQUERULE 'G' or 'X' will be checked will never be dropped.-Partitioned indexes will never be dropped.

Drop indexes with Unique attribute

Valid values:Y – Allow drop Unique indexesN – Do not allow drop Unique indexes

Drop indexes with Cluster attribute

Valid values:Y – Allow drop CLUSTER indexesN – Do not allow drop CLUSTER indexes

Note: if TurboTuneSQL find 2 identical indexes, one of them will be dropped.Therefore, in this situation, paramaters above (Unique/Cluster) will not be followed.

Never drop these indexes (name)Inform indexes that must never be dropped, even if Drop at start/end is set to Y.Do not inform here the index creator.


91

Artificial Inteligence Method

Define parameters for A.I. Method.

When typing “/” for set up in Recommendation Method in the previous screen, a pop upscreen below will be displayed.

ARTIFICIAL INTELLIGENCE METHOD OPTIONS

Setup A.I Algorithm. Mutually exclusive with What-if. Attention: this parameter should not be changed. For use only under the direction ofyour local representative.

Parameters for Algorithm:Parameters used by artificial intelligence algorithm.

Columns Indexes candidates:Inform which columns must be discarded in automatic indexes recommendation. These columns will never be used in any new index.

Suggest index with cardf 1:

Valid Values: Y - Suggest indexes where the first column has cardinality 1 N – Do not suggest. This is the default value

Use VARCHAR columns:

Valid Values: Y - Discard VARCHAR columnsN - Do not discard


92

┌───────────────────────────────────────────────────────────────────────┐│ Option ===> ││ ││ Artificial Intelligence Method Options ││ More: + ││ Parameters for Algorithm: ││ Columns Indexes candidates: ││ Suggest index with cardf 1 : N Y/N ││ Use VARCHAR columns : N Y/N ││ Use UPDATED columns : Y Y/N ││ Discard columns without statistic: N Y/N ││ ││ Discard following column names: ││ ││ ││ ││ ││ ││ Other parameters: ││ F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER ││ F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left │└───────────────────────────────────────────────────────────────────────┘

Use UPDATED columns:

Valid Values: Y - Discard columns that were updated in UPDATE SQL commandN - Do not discard

Discard columns without statistic:

Valid Values: Y - Discard columns without statisticsN - Do not discard

Other parameters:See a behavior example in SAMPLE EXECUTION TIME

Max new indexes recommendation:Inform the maximum number of new indexes that TurboTuneSQL can recommend foreach table.

Generation quantity:Option to reduce batch processing times. Inform number of generations (internal A.I. algorithm parameter). High numbers mayprovides best results in terms of indexes recommendation accuracy, but batchprocessing will take more time to be completed.

Quantity of individual:Inform number of individual (internal A.I. algorithm parameter).

Elite (internal A.I. algorithm parameter). Computed by (100) less: Crossover

Inform percentage of individuals in crossoverNew random indiv generation Inform percentage of new individuals to be generated

Mutation:Mutation probability (internal A.I. algorithm parameter). Inform mutationprobabilityPercentage of node mutation:Inform nodes in mutation (internal A.I. algorithm parameter).

Crossover reference (0-1)Inform how crossover works (internal A.I. algorithm parameter). Use default 0.

Repeat individuals Inform if algorithm should try to do not repeat individuals (internal A.I. algorithmparameter). Use default 0 (try to do not repeat).

Max columns penaltyInform a number of columns that will be used as threshold by the algorithm to penalizenew indexes with many columns. A low-number will only encourage the creation ofindexes with few columns. This is not a limitation number.

Max columns per new indexInform the maximum number of columns for each new index recommended. Any othervalue from 2 to 98 is assumed as limitation number.TurboTuneSQL will fit the best number of columns for the new indexes automaticallybut you still have this option to limit new indexes.


93

Penalty coefficientInform penalty bad routes (internal A.I. algorithm parameter). Use default 5.

MetricInform how sub-tree will be combined (internal A.I. algorithm parameter). Use default 0 (indicates TurboTuneSQL Cost plus number of hops).

Max combination each sub-treeInform limit number to define combination efforts (internal A.I. algorithm parameter).


94

What-IF Method

Define parameters for What If method.

User index Guess. Mutually exclusive with Artificial Intelligence .

When typing “/” for set up in Recommendation Method in the previous screen, a pop upscreen below will be displayed.

WHAT-IF Method Options:

Create an index using these controls for

Index Creator: If you want to change this value, check option New Indexes/Creator on previous screen.

Table Owner.NameInform at least one table or up to 10 tables. Table name with wildcard is not allowed.

Inform Index NameCreate index with this Name. TurboTuneSQL always prefix the name informed with therequest code.

Unique Inform if this index will be UNIQUE or NON UNIQUE attribute for the index.

Valid values:U – Create index with unique attribute.N - Create a non unique


95

┌───────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ USE COMMAND "ERASE" OR "ERASEALL" TO ERASE PREVIOUS PARAMETERS ││ WHAT-IF Method Options ││ More: + ││ Create index(es) using these controls for: ││ Index Creator: C1 (it will be used by all indexes) ││ INFORM DATA FOR INDEX NUMBER 1 ││ Table Owner.Name: IVPQUAL . IVPTABLE_T001 ││ Index Name : ││ Attributes--------------------------------------------------------- ││ Unique: N (U/N) Clustering: N (Y/N) C Ratio: 0 ││ Fullkeycard: -1 Firstkeycard: -1 Nlevel: -1 ││ Nleaf: -1 Page Size: 4 Padded: IxType: 2 ││ Columns------------------------------------------------------------ ││ (S) Name A/D Type S to list columns ││ ││ ││ ││ ││ F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER ││ F6=REFRESH F7=Up F8=Down F9=Swap Nex F10=Left │└───────────────────────────────────────────────────────────────────────────┘

Clustering Whether CLUSTER option was specified when the index was created.

Valid values: N - No Y - Yes

C Ratio:Cluster Ratio.

Fullkeycard:Number of distinct values of this Index.

Firstkeycard: Number of distinct values of the first key column

Nlevel: Number of levels in the index tree

Nleaf: Number of active leaf pages

Page Size: Index page size.

Valid values: 4, 8, 16, 32.

Padded: Indicates whether keys within the index are padded for varying-length column data:

Valid values: Y - The index contains varying-length character or graphic data and is PADDED (the

varying-length columns are padded to their maximum length). N - The index contains varying-length character or graphic data and is NOT PADDED

(the varying-length columns are not padded to their maximum length). Index-only access to all column data is possible. blank - The index does not contain varying-length character or graphic data. The

value is blank for indexes that have been created or altered prior to Version 8.

IXType: Indicates whether this is a partitioned index:

Valid values: D - This is a partitioned secondary index on a table in a partitioned table space. This is a DPSI - Data-partitioned secondary index. 2 - This is a nonpartitioned index (primary or secondary) on a table in a table space

(partitioned or nonpartitioned). If table space is partitioned this is a NPSI - nonpartition secondary index.

Show Table Columns: List all table columns (report TC00)

Column namesInform column name.


96

Direction (A/D)Inform direction (A – ASCENDING, B – DESCENDING).Others attributes, like Creator Name, Storage Group will be obtained from New Indexesparameter.

Commands line:ERASE Erases all parameters except table Owner and Name ERASEALL Erases all filled parameters LSTTAB owner.tablename List tables by catalog (wildcard can be used).


97

Parameters set to DEFAULT values

User has option to set default values for some parameters which are:

Value 'M' for Get SQL STMTS found inTo provide the best results in terms of indexes recommendation accuracy, but batch processing will take more time to be completed.

Value 'B' for Process Static/DynamicTo process both dynamic and static statements.

Value 'I' for Use Virtual indexesTo use Virtual index facility

Value 'N' for Drop at startTo maintain pre-existing physical indexes

Value 'Y' for Drop at endDrop physical indexes virtually at the end of recommendation process

Value 'N' for Drop indexes with Unique attributeTo maintain intact UNIQUE indexes even asked to drop at start

Value 'N' for Drop indexes with cluster attribute To maintain intact Cluster indexes even asked to drop at start

Value 3 for Generation QuantityTo attempt generations for each new index

Value 30 for Quantity of individualTo create new indexes in each generation cycle

Value range 0 to 80000 for limit of explainsTo limit the number of explains for each table


98

Executing Batch Process

Executing the batch processes of indexes recommendation.

If you type JCL command, the screen below will be displayed.

FIELD DESCRIPTIONFor field description, go to JCL command.

Note: 1 - Once you have started batch process of TurboTuneSQL Automatic IndexRecommendation Utility, do not cancel it! If you cancel it, you may generateunpredictable results on all posterior explain commands against DB2 tables used as afilter in utility process. This may occurs because DSN_VIRTUAL_INDEXES table may bepopulated with non existing virtual indexes or it may contain several physical indextested in recommedantion processes.If you have cancel it, please run step SADBCLIX alone to identify which index werecreated, as well as get a DROP ddl command for those indexes (also, temporaryindexes will be deleted from DSN_VIRTUAL_INDEXES table). The best way to interrupt a processing is issuing console command STOP becauseTurboTuneSQL needs clear work tables and Virtual Index tables to avoid keep anyvirtual or physical recommended index. Check out in Appendix B. Console Commands2 – Before you decide to drop an index that has a drop recommended action issued byTurboTuneSQL, check drop tips here: dropping an index.


99

TurboTuneSQL V120 ------------------- Create Jobs ----------------------- 08:31 Option ===> HIT "ENTER" WHEN READY Create Jobs Profile : IVP DB2 SSID : DBBG Inform PDS to receive JCL: DEVQ.V900.JCL Inform PDS member for JCL: J970IXRE HLQ work files : TWORK10 Unit Names Work Datasets : UNIT=SYSDA Example: UNIT=SYSDA Sort Datasets : UNIT=SYSDA Volumes Work Datasets : Example: VOL=SER=(VVVVV1,VVVVV2), Sort Datasets : SMS DATACLAS WK: SMS STORCLAS WK: SMS DATACLAS ST: SMS STORCLAS ST: JOB Cards: (Recommended region size is 24M or 0M) //JLOADIVP JOB 'IVP-TEST',MSGCLASS=A,CLASS=D,NOTIFY=IBMUSER, // REGION=0M //*

Sample Execution Time

Here we will show sample execution times.

Object Tested: DATABASE TESTDBMaximum number of tables: 55 Maximum number of columns: 48Total number of identical SQLs: 4.008 Mixed Total number of identical SQLs: 357 Workload

Tables: A and B are the tables with largest number of SQLs

Virtual index option: YES (use virtual indexes)

A.I ParameterGeneration Quantity: 10 default is 3Quantity of individual: 30 default is 30

Customer real Explain time Average 0.55 sDefault value for parameter Explain time Average for estimation 0.30 s

Figure A: Comparing the overall explain with identical and similar SQLs Explain SQLs Identical Similar

Overall Explains 897923 289191

Table A explains 30,00% 28,90%

Table B explains 55,00% 53,00%

Time processing 74 hours 24 hours

Table A time 29,80% 29,00%

Table B time 55,40% 54,00%

Figure B: Testing several parametersGeneration Quantity 10 More accurately Average precision Quick processing

Get SQL STMTS found in Mixed Mixed Workload

Explain SQLs Dynamic Similar Identical

Explain range 0 to 30.000 0 to 80.000 0 to 30.000

Elapsed time 11 hours 5 hours 9 hours

The same processing using parameters of Average precision but Generation Quantity of 3 will reduce 60% of time. This is the default value.

To reduce processing times check parameters:1. Time Estimate Processing2. Generation Quantity3. Explain SQLs and options4. Explain RANGE5. GET SQL Found in 6. Process Static/Dynamic7. Virtual Index option. When using 'Virtual Index=N', indexes will be createdphysically and it may demand much more time.


100

Recommended Actions line action

Check recommended actions by table.

When choosing line action (R)Recommended Actions, the screen below will bedisplayed showing the report IXRT.

FIELD DESCRIPTIONS

OWNER / TABLENAMEOwner/Table filtered for index recommendation according to the parameters.

SAVINGS WITH EXECSavings for SU (PROCSU- Service Units) in percentage. The overall savings of PROCSU after the index recommendation results for the table.

YES:SQL execution frequency was considered in computation.

NO:SQL execution frequency was NOT considered in computation (value 1 is considered asthe execution frequency). Note:Other possible values:N/AIt means there is no valid PROCSU for the calculation. ERROR1It means in a comparison of results, the PROCSU before starting the recommendationwas not available, therefore, the percentage could not be calculated. ERROR2It means the total execution still remains as zero, therefore, the percentage couldnot be calculated.For any situation above, please re-execute the process. If problem persist, pleasecontact your local representative.


101

TurboTuneSQL V120 ------------------- Automatic Analysis ----- Row 1 to 1 of 1 Option ===> IXRT - Recommended Actions by Table Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Show savings : % Line Actions ------------------------------------------------------------------ (A)Actions (I)Indexes (T)TableH (Q)TableC (F)ForeignK (C)Columns (L)AllIxColumns (G)IXModel (D)CatlgDep (S)SQLs (X)PlanTable (H)PlanTableSum (M)FullPlanTBComp (Z)Zoom ------------------------------------------------------------------------------- C OWNER TABLENAME SAVINGS WITH EXEC % ACTIONS YES NO Drop Keep Crea Attn Fail - ---------- ------------------ --------- --------- ---- ---- ---- ---- ---- IVPQUAL IVPTABLE_T001 1.82 2.77 001 006 001 000 ******************************* Bottom of data ********************************

Drop Number of indexes with drop recommendation. Keep Number of indexes with keep recommendation. Crea Number of indexes with create recommendation. Attn Number of indexes with attention recommendation.

Fail Valid values: Y - Recommendation has failed. Blank - Recommendation has successful executed.

AVAILABLE SORT FIELDS

Sort Field Field Header TAB - TableNameOWN - Owner DROP - Drop KEEP - Keep CREA - Crea ATTN - Attn FAIL - Fail Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(A)ActionsReport IXRM-Indexes to drop,create,keep or attention(I)Indexes Report TI 00 -History Indexes(T)TableH Report HT00-Tables Definition from History(Q)TableCReport TB00-Table Definitions from DB2 Catalog(F)ForeignK Report HTFK-Foreign Key Reference(C)Columns Report HC00-History Columns (L)AllIxColumns Report HC01-History Index Columns (G)IXModel Report IXMD-Index Modeling (analysis by table - all SQLs)(D)CatlgDep Report SRIC-Shows Packages in Catalog (S)SQLs Report SRPS-SQLs List(X)PlanTable Report EX01-Cross Reference from PLAN TABLE(H)PlanTableSum Report EX02-Plan Table Summary (M)FullPlanTableComparison Report IXMI-Index Recommendation Full Comparison (Z)Zoom Report ZOOM will be started (shows extended fields)


102

PlanTable Comparison line action

Check recommended actions by table.

When choosing line action (P)PlanTable Comparison, the screen below will be displayedshowing the report IXMI.

This report show the results of Plan Table comparison in order to visualize explain costsafter and before recommendations, including savings and others useful information.

There are 3 kinds of comparison:

A) Compare the whole Request Code for Index. If you have used database (or tablerange) as filter, you must trigger report IXMI from report IXON to be able to see to totalsavings for all tables together.

B) Compare only one table. You must trigger report IXMI from report IXRT to be able tosee to total savings for this table.

C) Compare only one index. You must trigger report IXMI from report IXRM be able tosee to total savings for this index. The following SQLs statements shown: - SQLs having different Explain Costs - SQLs with different Access Path - SQLs with no mismatch differences at all


103

TurboTuneSQL V120 ------------------- Automatic Analysis --- Row 1 to 10 of 10 Option ===> IXMI - Index Recommendation Full Comparison Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table/Index: IVPTABLE_T001 / Total Explain Cost WITH SQL executions | Total Explain Cost WITHOUT execution Before SUs: 6,256 CPUms: 0.188000 | SUs: 4,101 CPUms: 0.118000 After SUs: 6,142 CPUms: 0.185000 | SUs: 3,987 CPUms: 0.115000 Savings SUs: % 1.82 | Savings SUs % 2.77 Line Actions ------------------------------------------------------------------ (E)ExplainAll (S)SQLText (P)ProgW (R)ProgS (K)SUniqueS (Z)Zoom (F)SQLComm (X)PlanTable (L)SQLXref ------------------------------------------------------------------------------> C Uniq Desc SQLs Program COMPARISON COSTS ACCESS PATH Cost Example Cost-MS Cost-SU AMIP IX SR TN Categ - ---- --------- ----------- --------- --------- --------- ------------- ----- 90BB INSERT 1 ZIVPBT01 *stm with no mism* - - - - - AAFA SELECT 2 ZIVPBT01 *stm with no mism* - - - - - 35B4 SELECT 2 ZIVPBT02 *stm with no mism* - - - - - 4173 INSERT 2 ZIVPBT02 *stm with no mism* - - - - - 85E2 SELECT 2 ZIVPBT03 *stm with no mism* - - - - - 16B2 DELETE 2 ZIVPBT04 *stm with no mism* - - - - - DFE7 SELECT 1 ZIVPBT06 *stm with no mism* - - - - - 5A37 UPDATE 10 ZIVPBT06 *stm with no mism* - - - - - 0190 SELECT 1 ZIVPBT07 *stm with no mism* - - - - - 89BA SELECT 1 ZIVPBT08 better-ms better-su Y Y - - - ******************************* Bottom of data ********************************

Field Descriptions

Total Explain Cost WITH SQL executions

Before: The sum of all Costs by the DB2 Explain Function executed by TurboTuneSQLAutomatic Index Recommendation before you started recommendations multipliedby the total number of executioned SQL frequency.Field SUS (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format.Field CPUms ((PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format.

After: Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL AutomaticIndexes Recommendation after recommendations has applied multiplied by SQLexecutions frequency. Field Sus (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format.

SAVINGs SU %: Savings for Service Units (PROCSU before less PROCSU and after) is shown as apercentage. The total PROCSU after a recommendation is compared with the beforepercentage. The SQL execution frequency was used in this computation. Note: This field should show same values as in report IXRM. But, when Report IXMI wastriggered from report IXRM and current index does not appear last explain (originalformat B), the SAVING values may be different.

Total Explain Cost WITHOUT SQL executions

Before /After/SAVINGs SU %: Exactly same meaning as in Total Explain Cost WITH SQL executions butSQL executions frequency were not used.

Uniq: Unique Number that defines this SQL Text.

Desc: Short SQL Statement description. Examples: Select, Insert. Attention: when this command is a dynamic SQL, open, fetch and close will sometimesappear as a select command.

SQLs: Sum of all SQL executions frequency for this same Unique Number extracted whenTurboTuneSQL utility was ran. If workload not informed, value 1 will be shown. Formore information, check parameter Get SQL STMTS found in.

Program Example: This is just a sample program name that contains this unique number.

Cost Comparison:

CostMS

Valid values:worse-ms: This field will show worse-ms if CPU cost for new explain is worse thanold explain for this statement.better-ms: This field will show better-ms if CPU cost for new explain is better thanold explain for this statement.


104

CostSU

Valid values: worse-su: This field will show worse-su if Service Unit for new explain is worse thanold explain for this statement. worse-su: This field will show better-su if Service Unit for new explain is better thanold explain for this statement.

Other possible values for CostMS or CostSU: only old: This SQL statement was only found in the Old Explain Request.

This reason should not appear. only new: This SQL statement was only found in the New Explain Request.

This reason should not appear.stmt with no mism: When no mismatch was found for the statement.pgm with no mism: When no mismatch was found for all statements for thecurrent program. No extra information will be displayed (Unique, S Num andDescription).

Access Path: AMI

This field will show "Y" if ACCESSTYPE, MATCHCOLS or INDEXONLY are differentcomparing old explain and new explain for this statement.

IX This field will show "Y" if ACCESSCREATOR or ACCESSNAME are different comparing the old explain and the new explain for this statement. Normally, this field will contain the DB2 Index Name. SRT This field will show "Y" if any SORT is different for this statement. TN This field will show "Y" if CREATOR or TNAME are different for this statement.

Cost Categ:This field will show "Y" if the cost category is different for this statement.

S This field will indicate with "N" the commands not selected for the currentrecommendation. Valid Values: 'N' - SQL command not selected for the recommendation. ' ' - SQL command was selected for the recommendation.

EXPLAIN COSTS --WITHOUT-- SQL EXECUTIONS CPU before

Total CPU Costs by DB2 Explain Function before indexes recommendation for this sqlSU before

Total SU Costs by DB2 Explain Function before indexes recommendation for this sqlCPU after

Total CPU Costs by DB2 Explain Function after indexes recommendation for this sqlSU after

Total SU Costs by DB2 Explain Function after indexes recommendation for this sqlSAVINGs SU %: Savings for Service Units (PROCSU before less PROCSU after) in percentage. Thetotal SU after recommendation is compared with before recommendation. SQLexecution frequency was used in computation.

EXPLAIN COSTS --WITH-- SQL EXECUTIONS Exactly same meaning as in EXPLAIN COSTS --WITHOUT-- SQL EXECUTIONS butSQL executions frequency were used to multiply CPU/SU before and afterrecommendation.


105

DB2 CPU:Total DB2 CPU time for this SQL retrieved from DB2 traces loaded into productrepository. If parameter Get SQL STMTs found in was set to 'S', value 0 will be shown.

DB2 Elapsed:Total DB2 Elapsed time for this SQL retrieved from DB2 traces loaded into productrepository. If parameter Get SQL STMTs found in was set to 'S', value 0 will be shown.

QUERYNO:This field shows the QUERYNO field used in the last explain phase. Only used fordiagnosis purpose.


Sort Field Field Header UNIQ Uniq DESC DESC SQLS SQLs PROG Program COST-MS Cost Comparison Cost-MS COST-SU Cost Comparison Cost-SU ACCESSPATH Access Path (AMI IX SRT TN) CATEG Cost Category SELC Selected Command

Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(E)ExplainAllReport SREX-Statement Explain Information before recommendation (S)SQLText Report SRTX-SQL Text (P)ProgW Report AC00-Programs Summary (R)ProgS Report SRPG-Program Source Information (K)SUniqueS Report SRPS-SQLs List - Only Identical Statements(Z)Zoom Report ZOOM will be started (shows extended fields)(F)SQLCom Report SSCO-SQL Comment(X)PlanTableReport EX01-Cross Reference from PLAN TABLE (L)SQLXref Report STRF-SQL Cross Reference


106

Actions Line action

Show recommended actions by table in details with indexes, savings, etc.

When choosing line action (A)Actions from IXRT report, the screen below will bedisplayed showing the report IXRM.

FIELD DESCRIPTIONS

ACTION Action recommended for this index.

Valid values: Create:You will see Create action if field SAVINGS% is positive. SAVINGS% might be negative in certain situations:A) TurboTuneSQL executes EXPLAIN function many times. These EXPLAINs are split intoseveral internal phases. If DB2 changes Explain costs at last explain in the last internalphase, we cannot drop it because this would demand a new Explain. To avoid executingExplain infinitely, the process stops and negative value will be shown.B) When What-if method was chosen and parameter DROP at end was set to 'F'.

DROP INDEX ACTION: Reasons why TurboTuneSQL has recommended a drop action:–No rows found in PLAN TABLE and there is no catalog dependencies (no rows found inSYSIBM.SYSPLANDEP and SYSIBM.SYSPACKDEP)–Indexes is identical or similar to another index. –This index is NOT a Data-partitioned secondary index–This index is NOT a partitioned/partitioning index –Parameter Drop at End is not 'F' (force) and it does not adhere to restrictions DropOption/Drop restrictions.Check field Reason for the Action for more information.


107

TurboTuneSQL V120 ------------------- Automatic Analysis ----- Row 1 to 8 of 8 Option ===> IXRM - Indexes to drop,create,keep Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table Owner : IVPQUAL Table Name: IVPTABLE_T001 Database: Line Actions ------------------------------------------------------------------ (C)Columns (M)FullPlanTableCom (X)PlanTable (I)Index (D)CatlgDep (Z)Zoom ------------------------------------------------------------------------------> C Action Creator IxName U Savings Savings Done Phase ( % ) PROCSU - ------ -------- ------------------ - ------- ------------ ---- ----- CREATE C1 RCIX10001000000003 - 98.28 114 Y 0 DROP IBMUSER IXSUB - 0.00 0 Y 2 KEEP IVPQUAL IXTB101 - 0.00 0 Y 3 KEEP IVPQUAL IXTB102 - 0.00 0 Y 3 KEEP IVPQUAL IXTB103 - 0.00 0 Y 3 KEEP IVPQUAL IXTB104 - 0.00 0 Y 3 KEEP IVPQUAL IXTB105 - 0.00 0 Y 3 KEEP IVPQUAL IXTB106 - 0.00 0 Y 3 ******************************* Bottom of data ********************************

KEEP INDEX ACTION: Some examples of reasons why TurboTuneSQL has recommended a keep action:–Rows found in PLAN TABLE or there is a catalog dependencies (rows found inSYSIBM.SYSPLANDEP or SYSIBM.SYSPACKDEP)–Index is not identical or similar to another index or Drop at End was set to 'F' (force).–This index is a Data-partitioned secondary index–This index is a partitioned/partitioning index –Drop at End was set to 'F' (force) and it does adhere to restrictions in parameter DropOption/Drop restrictions.Check field Reason for the Action for more information.

ATTENTION INDEX ACTION: Attention are warning messages that can be issued to provide user with usefulinformation about current indexes recommendation.Example: TurboTuneSQL can warn you that you can transform an index with duplicateatrribute to unique attribute.Check field Reason for the Action for more information.

CREATOR Index creator. IXname Index name.

U:Describe Index Type. Valid values:

D - Duplicates are allowed U - Unique P - Unique and primary indexC - Unique, used to enforce UNIQUE constraint or hash key N - Unique, defined with UNIQUE WHERE NOT NULL R - Unique, enforce the uniqueness of a non-primary parent keyG - Unique, enforce the uniqueness of ROWIDX - Unique, enforce the uniqueness value of XML column

Savings ( % ) Savings for Service Unit (PROCSU before less PROCSU after) in percentage. The totalPROCSU after recommendation is compared with before recommendation. SQLexecution frequency was used in computation. Value '-' will be shown for action 'ATTN'. Note: Negatives savings are possible. Check field ACTION for more explainnation.

Savings PROCSUTotal Savings for SU (PROCSU before less PROCSU after). Note: A false value may be generated here.When PROCSU before and PROCSU after are equal, a value bigger than zero may begenerated purposely.The reason is to help this new index to be created if DB2 access plan *AFTER* wasenhanced in terms of prefetch, scan and sort when compared to DB2 access plan*BEFORE*.

DoneInternal use only.It means that this action was virtually (or physically) done.Valid values:

blank - Action not done or does not apply'-' - Action not done or does not apply (action ATTN)'Y' - Action done.


108

PhaseInternal use only.This field shows from which phase this recommendation was issued.

Related Indexes (creator / Name)If TurboTuneSQL has found identical or similar indexes, this field shows the indexesname used in this comparison.

Reason for the ActionReason explainning why this ACTION was issued. For more information consultTurboTuneSQL-Messages Guide.


Sort Field Field Header ACTN Action CREATOR Creator IXNM IXname SAVSU Savings PROCSUDONE DONE PHASE PHASE



(C)Columns Report HC01-History Index Columns (M)FullPlanTableComparison Report IXMI-Index Recommendation Full Comparison (X)PlanTable Report EX01-Cross Reference from PLAN TABLE (I)Index Report HI00-History Indexes (D)CatlgDep Report SRIC-Shows Packages in Catalog(Z)Zoom Report ZOOM will be started (shows extended fields)


109

Index Recommendation Guidelines

Guidelines to better usage of TurboTuneSQL's Automatic Index Recommendation:

(1) The wrong DB2 statistics can cause DB2 to choose an incorrect DB2 access path. Soalways execute DB2 RUNSTATS before executing this utility or set it to executeRUNSTATS in run-time. Also, you should REORGanize your tablespaces often.Withoutcorrect tables and indexes statistics the results of the automatic indexesrecommendation can vary widely.

(2) Consider using the of VOLATILE table attribute when using Virtual Indexes.

(3) If you don’t have enough data to execute DB2 RUNSTATS in your developmentenvironment, you can also copy DB2 statistics from another DB2 using TurboTuneSQL.Please see (Copy Catalog Statistics Utility) for more information on this function.

(4) Be sure all tables related to the table (or tables) you are recommending indexes areup-to-date in terms of the DDL definitions and DB2 statistics. Related tables are tablesthat are used in the same SQL text (joins, subselects, etc). This precaution will help youavoid bad indexes recommendation and SQLCODE -204. Some important indexrecommendations may not be created. To have a list of related tables, you may use theSQL Tables Cross Reference Utility

(5) Different results may be produced for related tables (tables used in the same SQLtext -joins, subselects, etc) if specified separetely. For instance, let's suppose you havethe following SQL command:

select * from TABLE-A, TABLE-BDifferent index recommendation results may be generated if you:– Create an index recommendation only for table TABLE-A– Create an index recommendation only for table TABLE-B– Create an index recommendation only for table TABLE-A and TABLE-B

(6) This utility makes the recommendation comparing the results of the Explain Beforethe recommendation, with results of the Explain Results After Recommendation havebeen made. Therefore be aware of recommendations that are NOT made using the currentprograms access path created at BIND or REBIND time. You may need to rebind yourprograms before or after the execution of this utility to have same behavior.

(7) In order to avoid performance problems, always execute REORG, RUNSTATS andRebind against the TurboTuneSQL tables and packages. More information onMaintain TurboTuneSQL.

Also, we recommend the following indexes:INDEX 1: NON UNIQUE INDEX ON PLAN_TABLE (PROGNAME ASC, QUERYNO ASC, QBLOCKNO ASC, PLANNO ASC,


110

MIXOPSEQ ASC) INDEX 2: NON UNIQUE INDEX ON PLAN_TABLE (ACCESSCREATOR ASC, ACCESSNAME ASC)

INDEX 3: NON UNIQUE INDEX ON DSN_STATEMNT_TABLE (PROGNAME ASC, QUERYNO ASC)

INDEX 4: NON UNIQUE INDEX ON DSN_VIRTUAL_INDEXES (TBCREATOR ASC, TBNAME ASC)

(8) You cannot execute several batch indexes recommendation at the same time toavoid unpredictable results, like abends, concurrency problems, wrong results (mixed).If you submit several jobs they will be enqueued.

(9) TurboTuneSQL Automatic Index Recommendation makes use of DB2 optimizer. Itdoes not try to guess how DB2 works.

(10) To produce better results, set parameter Get SQL STMTs found in to 'M' or 'W'.Top executed SQLs will receive more chances to have better index recommendations.


111

Index Recommendation: using virtual or physical indexes

The choise of using physical or virtual index method in not an easy choice. To help youin this decision, you can use the following guidelines:

1.Use physical indexes and RUNSTATS whenever possible but be very careful:Do NOT use in production environment;Do NOT use when disk space is an issueDo NOT use when CPU time can be an issueDo NOT use when may create conflict of unavailability for the table being recommended

2. If for some reason, the use of a physical index is not feasible, use the virtual indexoption 'Virtual Index=Y'.

3. Once TurboTuneSQL has executed the automatic recommendations, you should testthem physically. Use TurboTuneSQL as a tool to make tests with the utilities Explainand Plan_Table Comparison or using the method WHAT-IF.

4.If you have chosen to create a physical index as an option for the process ofrecommendations, beware of the existence of this index might affect a Bind programprocess, and this is NOT affected when using a virtual indexes.

5.Make sure the table chosen for a recommendation has the VOLATILE attribute. Thisattribute helps DB2 to make better choices of indexes even the catalog statistic doesnot have the most current information since Virtual Indexs work independently with theDB2 catalog.

6.PROS and CONS of Using Virtual or physical indexes:Advantages of using Virtual Indexesa) Allows user and system tools test several configured indexes more rapidly thanphysical indexes;

b) Useful when several indexes/tables are being tested;

c) Allows you to test new concurrent indexes with parallel running applications,therefore virtual indexs do not affect dynamic SQL access path and BIND, consequentlyit does not affect the developers;

d) Allows to simulate drop indexes;

e) Requires less disk space because the indexes do not need to be created

Disadvantages of using Virtual Indexesa) Since the index is created virtually, the DB2 catalog statistics are not populated

b) There is no tool to predict possible statistical key fields for the DB2 access path, suchas FULLKEYCARD, NLEVEL, NLEAF, CLUSTERRATIO and etc


112

c) Requires re-testing. Since the statistics are not reliable for virtual indexes, theyshould be tested with the physically index (with RUNSTATS) after the user has beenprovided a set of recommended indexes;

d) Virtual index it is relatively a 'new' feature in DB2, therefore excess or lack of PTFsmay cause different behaviors within different DB2 installation and sometimes in thesame environment;

Advantages of using Physical Indexesa) Allows to check the validity of new indexes with up to 100% of certainty if all conditions are true: they must be created in same DB2, the same database (content), with DEFER NO and with RUNSTATS process;

Disadvantages of using Physical Indexesa) Higher consumption of processing time as long as several indexes will be testedconcurrently;

b) Higher consumption of disk space. Since DB2 V8, DEFER YES option is no more feasible when you are testing new indexes.Indexes created with DEFER YES and in Rebuild pending status are not used by dynamicSQLs (cached or dynamic prepared).Therefore, TurboTuneSQL Automatic Index Recommendation can not use this optionbecause our dynamic explains will fail;

c) Does not allow users and tools able to test several configurations of indexes quickly,compared to virtual indexes;

d) Does not allow test concurrent indexes with paralel running applications;

e) Does not allow to simulate any drop or create index;


113

Manual Index Analysis (option 5.2)

The screen below shows the most important reports when performing a manual indexanalysis.

OPTION Related Online Report

1 - List Current Indexes (Catlg) TI002 - List Current Indexes Columns (Catlg) TC013 - List Table Columns (Catlg) TC004 - Table Workload Summary DB105 - SQL Type Workload Summary SW016 - Index Modeling (analysis by table - all SQLs) IXMD7 - Table Package Catalog Dependency SRIC8 - Table Explain Summary EX029 - Table Explain Detail EX0110 - Visualize Explain Differences SRMI11 - List Current Foreign Key T B FK

BATCH UTILITIES:

OPTION Related Report/Utility12 - Execute Batch Explain Explain Utility 13 - Execute Plan Table Compare Compare Plan Table Utility14 - Batch Report Menu Menu for Batch Reports


114

TurboTuneSQL V120 ------------------- Manual Analysis ------------------- 13:35 Option ===> XMNZ - Index Manual Analysis Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Filters ----------------------------------------------------------------------- Table Owner: Table Name: ------------------------------------------------------------------------------- --- ONLINE REPORTS 1 - List Current Indexes (Catlg) 2 - List Current Indexes Columns (Catlg) 3 - List Table Columns (Catlg) 4 - Table Workload Summary 5 - SQL Type Workload Summary 6 - Index Modeling 7 - Table Catalog Dependency 8 - Table Explain Summary 9 - Table Explain Detail 10 - Visualize Explain Differences 11 - List Current Foreign Key --- BATCH UTILITIES RE-DIRECTION (manually set filters and other parms) 12 - Execute Batch Explain 13 - Execute Plan Table Compare 14 - Batch Report Menu

Virtual Index Configuration (option 5.3)

The screen below is the Virtual Index Configuration.

This utility will assit you to edit and list Db2 Virtual Index Tables.

Field Description

Index Owner:Specify an index owner or a set of indexes using wildcard (*)

Index Name:Specify an index name or a set of indexes using wildcard (*)

Virtual Index Table Owner:Owner of table DSN_VIRTUAL_INDEXES.

Table Owner:Specify an owner or a set of owners using wildcard (*)

Table Name:Specify a table name or a set of tables using wildcard (*)

Max Lines: Maximum number of lines to be displayed.

Create New Virtual Index: Valid values: Y - Create a new virtual Index. N - Do not create a new virtual Index.

List catalog indexes:Valid values: N - Do not list DB2 catalog indexes. Y - List DB2 Catalog Indexes. Owner and Table Name found in DSN_VIRTUAL_INDEXES

will be used as filter. F - List DB2 Catalog Indexes. Owner and Table Name found in field Table

Owner/Name will be used as filter.


115

TurboTuneSQL V120 ------- Virtual Indexes Configuration ------ Row 1 to 1 of 1 Option ===> Profile : IVP {E} DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index Owner/Name: * / * Virt Index Tab Owner: * Table Owner/Name: * / * Max Lines: 0200 Create New Virtual Index: N (Y/N) List Catalog Indexes: N (N/Y/F) Line Actions ------------------------------------------------------------------ (C)Create (D)Delete (P)Drop (T)TableC (V)View (I)TableIdxC (S)SQLs (G)IXModel (U)Update (Z)Zoom ------------------------------------------------------------------------------> C IXName TBName Type Enabl Mode U C CRtio FullKeyCard - ------------------ ------------------ ---- ----- ------ - - ----- ----------- VIRTUAL_INDEX1 IVPTABLE_T003 VIRT Y CREATE N N 0 -1 ******************************* Bottom of data ********************************

IXNAME:Index Name

TBNAME:Table Name

Type:Index Source.

Valid values: CTLG - Physical index. Data taken from SYSIBM DB2 Catalog. VIRT - Virtual Index (or virtual drop). Data was taken from

<VIT owner>.DSN_VIRTUAL_INDEXES.

Enable: Virtual Index status. Valid values: Y -Virtual Index (or virtual drop) is ENABLE. N - Virtual Index (or virtual drop) is DISABLE. '-' - Not applied for physical indexes.

Mode:Virtual Index action. Valid values: CREATE - New Virtual Index. To be valid, DROP - This index Virtually drop this index. '-' - Not applied for physical indexes.

U:Describe Index Type. Valid values:– D Duplicates are allowed– U Unique – P Unique and primary key– C Unique, used to enforce UNIQUE constraint or hash key – N Unique, defined with UNIQUE WHERE NOT NULL – R Unique, enforce the uniqueness of a non-primary parent key– G Unique, enforce the uniqueness of ROWID– X Unique, enforce the uniqueness value of XML column

C: Clustering – Whether CLUSTER option was specified when the index was created. Valid values: N - No Y - Yes

CRatio:Cluster Ratio.

FullkeyCard:Number of distinct values of this Index.

IXCreat:Index Creator

TBCreat:Table CreatorNlevl: Number of levels in the index tree


116


Statstime:Date and Time from last DB2 RUNSTATS Utility.

–IXType:Indicates whether this is a partitioned index: Valid values: – D: This is a partitioned secondary index on a table in a partitioned table space. This is a DPSI - Data-partitioned secondary index. – N: This is a non-partitioned index (primary or secondary) on a table in a table space

(partitioned or non-partitioned). If table space is partitioned this is a NPSI - non-partition secondary index.– 2: Same as N. – P: This index is both partitioned and partitioning index on a table in a partitioned

table space that uses table-controlled partitioning.– I: This index is both partitioned and partitioning index on a table in a partitioned

table space that uses index-controlled partitioning. – blank: Type 1 Index

VIT Owner: Show current Virtual Index owner ( <VIT owner>.DSN_VIRTUAL_INDEXES).Not applicable for physical indexes.

Available Sort Fields

Sort Field Field Header IXNM IXName TAB TBName TYPE Type ENAB Enable MODE Mode U U (Index Type) C C (Clustering) CRTIO CRtio (Cluster Ratio) FKEY FullKeyCardf IXCR IXCreator TBCR TBCreator NLEVL Nlevl (Number of levels) NLEAF Nleaf (Number of active leaf) STAT Statstime IXTP IXType VITOW VIT Owner Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


117

Available Line Actions

(C)Create Report IXCR-Create Virtual Index. Current index attributes and defined columns will be copied to IXCR report to allow users to create a new index based on current index. If you don't want to copy current index definition, use “Create New Virtual Index:” instead

(D)Delete Report IXCR-Delete Virtual Index

(P)Drop A confirmation screen will appear for the drop command

(U)Update Report IXCR-Update Virtual IndexFor DROP mode, a screen will appear to update enable column (Y/N)

(V)View Report IXCR-View Virtual Index (for Virtual Index) Report TC01-Index Columns (for Catalog Index) For DROP mode, a screen will appear.

(T)TableCReport TB00-Table List from DB2 Catalog

(I)TableIdxC Report TI00-Table Indexes from DB2 Catalog

(Z)Zoom Report ZOOM will be started (shows extended fields)

(S)SQLs Report SRPS-SQLs List

(G)IXModelReport IXMD-Index Modeling (analysis by table - all SQLs)


118

Create line action

When Create line action is chosen, the screen below will be displayed to create a virtual index from the one in the current line.

If you wish to create a new virtual index from scratch, just chose “Y” on field Create New Virtual Index from the previous screen.

FIELD DESCRIPTIONS

Index Owner:Index Owner.

Index Name:Index Name.

Virtual Index Table Owner:Owner of table DSN_VIRTUAL_INDEXES.

Table Owner:Table Owner.

Table Name:Table Name.

Enable: Virtual Index status. Valid values: Y - Virtual Index (or virtual drop) is ENABLE. N - Virtual Index (or virtual drop) is DISABLE. '-' - Not applied for physical indexes.


119

TurboTuneSQL V120 ------------------- Virtual Indexes ------------------- 14:16 Option ===> More: + IXCR - Create New Virtual Index Profile : IVP DB2 SSID : DBBG Index identification ---------------------------------------------------------- Index Owner/Name: / Virt Index Tab Owner: Table Owner/Name: / Attributes -------------------------------------------------------------------- Enable : Y (Y/N) Unique: N (U/N) Clustering: N (Y/N) C Ratio : 0 FullKeyCard: -1 Nlevel: -1 Nleaf : -1 Page Size: 4 FirsKeyCard: -1 Padded: N Index Type: 2 Line Actions for columns------------------------------------------------------- (S)SetCol (I)Ins (D)Del (M)Move (A)After (B)Before C Name A/D ColType Null Length Cardf - ------------------------------ --- -------- ---- ------ -----------

Unique: Describe Index Type. Valid values: D - Duplicates are allowed U - Unique index

Clustering: Indicates if this index was defined with CLUSTER YES attribute.Valid values: Y - It was defined using CLUSTER YES N - It was not defined using CLUSTER YES

CRatio: Cluster Ratio. Valid values: >=-1 and <=100

FullKeyCard:Number of distinct values of this Index. Valid values: >=-1.

Nlevl:Number of levels in the index tree. Valid values: >=-1.

Nleaf: Number of active leaf pages. Valid values: >=-1.

Page Size: Index page size. Valid values: 4, 8, 16, 32.

FirstKeyCardf: Number of distinct values of the first key column. Valid values: >=-1.

Padded: Indicates whether keys within the index are padded for varying-length column data: Valid values: Y - The index contains varying-length character or graphic data and is PADDED (the varying-length columns are padded to their maximum length). N - The index contains varying-length character or graphic data and is NOT PADDED (the varying-length columns are not padded to their maximum length). Index-only access to all column data is possible. blank - The index does not contain varying-length character or graphic data. The value is blank for indexes that have been created or altered prior to Version 8.


120

Index Type: Indicates whether this is a partitioned index: Valid values: D: This is a partitioned secondary index on a table in a partitioned table space. This is a DPSI - Data-partitioned secondary index. 2: This is a non-partitioned index (primary or secondary) on a table in a table space (partitioned or non-partitioned). If table space is partitioned this is a NPSI - non-partition secondary index.

Available Line Actions (for columns) (S)SetColumn Shows TC00 panel to select a columns for the index (I)Insert Insert a column before this line (D)Delete Delete a column (M)Move Move a column. When no A or B line action is informed, M is ignored (A)After When using M line action, the column will be moved after this line (B)Before When using M line action, the column will be moved before this line

C:Edit command lines.

Name:Column Name

Asc/Desc:Column Direction

Table Cardf: Total Table Rows (cardf column).

COLTYPE: Column Data Type. Example: Decimal, Char, etc

NULL: Null indicates. Y - accept null values N - do not accept null values

Length: Column Length in bytes.

Cardf: Rows Cardinality for this column.


121

Update line action

When Update line action is chosen, the screen below will be displayed to update the virtual index from the current line.

Field description and line actions are the same when creating the virtual index.


122

TurboTuneSQL V120 ------------------- Virtual Indexes ------------------- 14:25 Option ===> More: + IXCR - Update Virtual Index Profile : IVP DB2 SSID : DBBG Index identification ---------------------------------------------------------- Index Owner/Name: IVPQUAL / VIRTUAL_INDEX1 Virt Index Tab Owner: SADVQUAL Table Owner/Name: IVPQUAL / IVPTABLE_T003 Attributes -------------------------------------------------------------------- Enable : Y (Y/N) Unique: N (U/N) Clustering: N (Y/N) C Ratio : 0 FullKeyCard: -1 Nlevel: -1 Nleaf : -1 Page Size: 4 FirsKeyCard: -1 Padded: N Index Type: 2 Line Actions for columns------------------------------------------------------- (S)SetCol (I)Ins (D)Del (M)Move (A)After (B)Before Table Cardf: -1 C Name A/D ColType Null Length Cardf - ------------------------------ --- -------- ---- ------ ----------- COL1 A INTEGER N 4 -1

Batch Reports for lndexes (option 5.4)

The screen below is the menu for the batch reports to print indexes information fromDb2 Catalog.

Chose the report with a “/” and type JCL to generate the JOBS.




123

TurboTuneSQL V120 -------------- Index Batch Reports ---------------- 13:45 Option ===> Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Filters --------------------------------------------------------------------- Program Name : Table Creator : Source/Explain Req Code: DBBG / DBBG Table Name : Index LastUsed: months Level: 3 Max Objects: 00250 Type / to select a report ---------------------------------------------------- / TI00: Index Usage / TI01: Duplicated Indexes

Chapter 3. Online Reports

This chapter has a reference of all TurboTuneSQL Online Reports. All TurboTuneSQLOnline Reports have a report code and corresponding name.

Online reports main menu are located main screen, “Online Reports”:


{?} : Profile Edit Mode (E - Edit Mode , B - Browse Mode) DB2 SSID: Connected DB2 Curr Loc : DB2 Location automatically obtained from connected DB2

Filters

TurboTuneSQL has some basic filters to help you select what you want to inquiry.

Online TurboTuneSQL FILTER command is used to setup filters.

Tips:1 - FILTER is an Online command used to filter both Batch and Online Reports.TurboTuneSQL Report Program always uses information stored in TurboTuneSQLProfiles to select which filters will be used. It means if you use FILTER Online commandwhile report batches are running, unexpected results may occur. So, the best option isto create new TurboTuneSQL Profiles just to create and run Batch Reports. In a futurerelease, this will no longer be necessary. 2 - Type LSTREQ line command to list all available Request Codes.


124

TurboTuneSQL V120 ------------------ Online Reports --------------------- 03:22 Option ===> Profile : IVP {E} DB2 SSID : DBBG Report : Curr Loc : DALLASB Filters ---------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 Plan Name : CnTy: TimeR : 00.00.00 23.59.59 Correlation Name : Program: SSID: Source/Explain Req Code: DBBG / DBBG Unique : Table Creator: Table Name: DB2 CATALOG SRIC: Programs TB00: Tables TD00: Database REPOSITORY/WORKLOAD AC00: Programs APLN: Plan Names ASSI: SSIDs CO00: Collections ACNT: Connection Types ACNI: Connection IDs CICS: CICS Transactions IMSM: IMS Attach ACOR: Correlation IDs ST00: Group of Tables ST01: SQLs ST02: SQLs-Identicals ST03: SQLs Similars ST04: SQLs using SCAN SNEG: SQLCODEs Summary RF00: General Xref DB10: First Table REPOSITORY/INVENTORY SRPG: Programs SRPS: SQLs SRMI: Plan Table Comp SSCO: SQL Comments

Online Reports Summary

Summary of TurboTuneSQL Reports. Note that not all reports are available on mainreport screen. Some of them are available using Line Actions.

Reports from Workload: the information presented by these reports were basicallyobtained from DB2 Traces. Note that DB2 CPU and DB2 Wait time have parallel childtask rollup time included. Reports from Sources: the information presented by these reports were basicallyobtained from DB2 Packages, DBRMs, DB2 Catalog and Dynamic SQLs.

When running TurboTuneSQL on Trial mode, a number of lines selected to “Trial Mode”will not be shown in online reports. For any questions contact your local representative.

DB2 Catalog:The information presented by these reports are obtained from DB2 Catalog.

SRIC Program List (from DB2 Catalog) TB00 Table List (from DB2 Catalog) TD00 Database List (from DB2 Catalog)

REPOSITORY/WORKLOAD The information presented by these reports were basically obtained from DB2 Traces (SMF and Cache) and stored into the product repository via batch jobs. AC00 Program Summary (from product repository) APLN DB2 PLAN Summary (from product repository) ASSI DB2 SSID Summary (from product repository) CO00 DB2 Package Collection Summary (from product repository) ACNT DB2 CONNECT TYPE Summary (from product repository) ACNI DB2 CONNECT ID Summary (from product repository) CICS CICS Transactions (from product repository) IMSM IMS Transacations (MPP) (from product repository)ACOR DB2 CORRELATION Summary (from product repository) ST00 Group Tables Summary (from product repository)ST01 Statements Summary (from product repository)ST02 Identical Statements Summary (from product repository)ST03 Similar Statements Summary (from product repository)ST04 Statements with TABLE or INDEX SCAN (from product repository)SNEG SQLCODEs Summary (from product repository)RF00 Programs Cross Reference (from product repository)DB10 First Table Summary (from product repository)

REPOSITORY/INVENTORY The information presented by these reports were basically obtainedfrom DB2 Catalog and DB2 Traces stored into the product repository via batch jobs. Other informations like Plan Tables comparison created by product Utilities are also presented.

SRPG Program Summary (from product repository) SRPS SQLs Summary (from product repository) SRMI Plan Table Comparison (from product repository)

SSCO SQLs Comments (from product repository)


125

REPORTS – COMPLETE LIST:

Code Description

ACNI DB2 Connection ID Summary This report shows DB2 Connection ID activities.

ACNT DB2 Connection Type SummaryThis report shows DB2 Connection Type activities.

ACOR DB2 Correlation SummaryThis report shows an overview of all DB2 Correlation activities.The following are examples of DB2 Correlation names: CICS Transaction,JOBNAME, TSO Userid, etc.

ACTO More DetailsThis report shows detailed information about current object listed from APLN, ASSI, CICS and other reports.

AC00 Programs Summary This report shows an overview of all programs loaded into TurboTuneSQL database from DB2 traces.

AC01 This report shows the activity of the selected program grouped by date and time.

APLN Plan Name Summary This report shows DB2 PLAN activities.

AP01 This report shows information about current object listed from ACNI, ACNT, ACOR, APLN, ASSI, CICS and IMSM grouped by date and time.

ASSI SSID Summary This report shows all SSID activities.

CICS CICS TransactionsThis report shows CICS Transactions activities.

CO00 Collection Overview This report shows an overview of all DB2 activities by DB2 Package Collections.

DB10 Table Summary (first table appears in SQL) This report shows summary information about objects accessed by executedSQL found in DB2 Performance Traces and SQL Cache Area.

Object can be tables, views, alias, synonym. Only the first object and Ownerreferenced in the SQL statement will appear.

EX01 Cross Reference from PLAN TABLEThis report shows a cross reference of programs found in PLAN TABLE for an object.

EX02 DB2 Plan Table SummaryThis report shows DB2 Explain Plan Table Summary an object.

HC00 Column DefinitionHistory DB2 Column definition from TurboTuneSQL Repository.


126

HC01 Index ColumnsHistory DB2 Index Column definitions from TurboTuneSQL Repository.

HI00 Index Definitions History DB2 Index definitions from TurboTuneSQL Repository.

HT00 Table Definitions

History table definition from TurboTuneSQL Repository.

IMSM IMS Transactions (MPP)This report shows IMS Transactions activities.

IXMD Index Modeling This report shows important metrics to help users model new indexes.This report are presented in 2 formats: Index Modeling (analysis by table - all SQLs) Index Modeling (analysis of a single SQL)

MORD More DetailsThis report shows detailed information about previous object found in SQLCache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRCO DB2 CORRELATION Summary (near real time)

This report will show an overview of all DB2 Correlation Activities foundin SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRDB Database Summary (near real-time)This report shows summary information about databases accessed byexecuted SQL found in SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRDT Shows Details Grouped by Date and Time (near real-time)This report will show details for the selected object grouped by date andtime. The information is based on SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRPG Programs Summary (near real-time)This report will show an overview of all DB2 programs found in SQL CacheArea. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRS1 SQLs Summary (near real time)

This report shows information about executed SQL statements grouped byprogram name, statement number and Unique number.The information is based on SQL Cache Area.This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.


127

NRS2 Identicals SQLs Summary (near real time)This report shows information about executed SQL statements grouped byIdentical SQLs. The information is based on SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRS3 SQLs by Similars (near real time)

This report shows information about executed SQL statements grouped bySimilar SQLs. The information is based on SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

NRTB Table Summary (near real-time)This report shows summary information about objects accessed by executedSQL found in SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHEwas acquired.

NRXR General Cross Reference (near real-time) This report shows information about executed SQL statements. No groupingis done to allow general cross reference. The information is based on SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REALTIME CACHE was acquired.

PGDT Program Execution DetailsThis report shows program information obtainned from DB2 Accounting, DB2Performance Traces and DB2 Performance data from SQL Cache Area (EDMPOOL) for the current program.

PGSD SQL DetailsThis report shows detail SQL information from DB2 Performance Traces andperformance data available from SQL Cache Area.

RF00 Programs Cross Reference This report shows cross reference of all DB2 Objects captured by

TurboTuneSQL.

SNEG SQLCODEs Summary This report shows a summary of all negative SQLCODEs or SQLCODEs withzero but SQLCA Warning flags were turned on.

SNGD SQLs with SQLCODE negativeThis shows all statements from workload with same SQLCODE.

SRCO DB2 Columns Cross ReferenceThis report shows a complete cross reference of DB2 columns and programs.

SRER Statements Explained – Log ResultsThis report shows SQL statements explained for “DO Explain” option in reportSREX.

SREX SQLs Explain Information

This report shows SQL statements costs from Explain output. It may alsoexecute DB2 explain command.


128

SRIC Programs List Catalog This report will show all DB2 Programs found into DB2 Catalog (Packages /DBRMs).

SRMI Show Plan Table Comparison ResultsThis report shows the result of DB2 Plan Tables comparison results made byTurboTuneSQL Plan table Comparison batch utility.

SROJ Object ListThis report shows summary information about objects accessed by this SQL.

SRPC SQLs List from CatalogThis report will show all SQLs found into DB2 Catalog (Packages only).

SRPG Programs List This report shows all programs loaded into TurboTuneSQL Repository.

SRPS SQLs List This report shows all SQL statements loaded into TurboTuneSQL RepositorySource Tables.

SRPT Plan Table InformationThis report shows DB2 Explain information from TurboTuneSQL Repository(Plan Tables).

SRTX SQL TextThis report shows SQL text stored in TurboTuneSQL Repository (Dynamic and Static SQLs).

SSCO SQL CommentThis report is used to show and update SQL Comments made by users.

STIF SQL Source Detail InformationThis report shows detail information about current SQL statement (Source).

ST00 Group Tables Summary This report shows an overview of all DB2 Activities summarized by Group oftables in all SQLs.

ST01 SQLs Summary This report shows information about executed SQL statements grouped byprogram name, statement number and Unique number.

ST02 Identicals SQLs Summary This report shows information about executed SQL statements grouped byIdentical SQLs.

ST03 Similar SQLs Summary This report shows information about executed SQL statements grouped bySimilar SQLs.

ST04 SQLs with Table or Index ScanThis report shows information about executed SQL statements where an DB2index or a DB2 Table Scans may have happened.

ST1N Shows SQL Details Grouped by Date and TimeThis report shows the activity of the selected SQL grouped by date and time.


129

STCX Show SQL text from DB2 Catalog (package only)

STRF SQLs Cross ReferenceThis report shows an overview of all DB2 Activities by SQL command found in TurboTuneSQL Plan Tables which may have doing a DB2 Table or Index Scan.

SW01 SQLs by Statement type and TableThis report shows an overview of all SQL activities by command type for atable.

TB00 Table Definitions from DB2 Catalog

This report shows all DB2 Tables.

TC00 Columns Definition from DB2 CatalogDB2 Table Columns from DB2 Catalog.

TC01 Index Columns from DB2 CatalogThis report shows DB Index Columns from DB2 Catalog.

TD00 Database List from DB2 CatalogThis report will show all Databases found in DB2 Catalog Table.

TI00 Index Definitions from DB2 Catalog This report shows DB2 indexes from DB2 Catalog.

UPDC This utility will assist you to update access path statistics for columns.

UPDI This utility will assist you to update access path statistics for indexes.

UPDT This utility will assist you to update access path statistics for tables.

ZOOM ZOOM PanelThis report will show all previous fields in extended format which do not fiton the screen (like new DB2 V8 fields with 128 bytes) will be shown here.

A complete reference will be shown on the next pages.


130

ACNI - DB2 Connection ID Summary

This report shows DB2 Connection ID activities.

This information is based only on DB2 Accounting Traces.

Notes: 1 - Fields related to CPU, WAIT and ELAPSED time are shown usinghhhhhh:mm:ss.tttttt time format. All other fields are shown using TurboTuneSQLNumeric format. Please, refer to Appendix Numerical and Time formats foradditional information.

2 - When data comes from SQL Cache Area (dynamic SQLs stored in EDM Pool),program name, CPU and other informations may not be accurate (DB2 may recordSQL activities under a wrong program name). To avoid a prepare execution, DB2searches for an 'identical' SQL in the cache regardless for a different program orstatement number. When this happens, all computed values will be stored for theprogram and statement number found in Cache and not for the original executor.

SAMPLE REPORT


131

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 3 of 3 Option ===> ACNI - DB2 CONNECTION ID Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Plan Name : Correlation Name : Group Name : SSIDs : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (N)Expand (Z)Zoom ------------------------------------------------------------------------------> C CNID T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ----------- - ---------------- ---------------- ---------------- ----------- BATCH A 1.494 0.009 1.617 11 *CACHE/S C 1.464 0.005 1.573 N/A BATCH C 0.000 0.000 0.001 N/A ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

CNID:Connection name. Sample of valid values:

BATCH - TSO BACKGROUND TSO - TSO FOREGROUND SERVER - DRDAUTILITY - DB2 UTILITIESRRSAF - RRSAF ATTACH *CACHE/D* - CONNECTION IS UNKNOWN. A DYNAMIC SQL WAS EXECUTED

BUT IN THIS CASE DB2 SQL CACHE AREA HAS NOT INFORMED THE ORIGIN CONNECTION TYPE.

*CACHE/S* - CONNECTION IS UNKNOWN. A STATIC SQL WAS EXECUTED BUT IN THIS CASE DB2 SQL CACHE AREA HAS NOT INFORMED

THE ORIGIN CONNECTION TYPE.Other values - CICS address space name, etc

T: Trace Source: Valid Values: 'A' - This SQL comes from Accounting Traces 'C' - This SQL comes from SQL Cache Area

DB2 CPU:Total DB2 CPU time spent on a normal CP processor.

DB2 Wait:Total DB2 Wait Time. Use option D for more information.

DB2 Elapsed:Total DB2 ELAPSED Time.

Occurrence:Total traces found.

Application Elapsed: Total application elapsed time.

%InDB2: Percentage between DB2 Elapsed and Application Elapsed.

Application CPU: Total application CPU time spent on a normal CP processor.

DB2 Not Accounted: Result of DB2 Elapsed time minus the sum of DB2 CPU time and DB2 wait time.

%NAct: Percentage between DB2 not Accounted and DB2 Elapsed.

RD: This field indicates if a RidPool access has failed and a table scan has occurred. Valid values are:

' ' - RIDPOOL List not used or RIDPOOL List access was OK. 'S' - Access using RID List has failed because of size of RIDPOOL. If you can,

increase RIDPOOL size.'L' - Access using RID List has failed because of internal DB2 limits. So, even


132

if you change RIDPOOL size, nothing will change. In the past, some internal limits were: Data Manager limit (16 million) or RDS reach 25 percent of table size.

DB2 CPU(SE/ZIIP):Total DB2 CPU time running on a SE/ZIIP.

DB2 CPU(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP)

%CPUA:Percentage between DB2 CPU spent in all processors (CPU ALL).Note: This field is computed using the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:




lines WAS exceeded)

Application CPU(SE/ZIIP):Total application CPU time running on a SE/ZIIP.

Application CPU(ALL):Total application CPU spent in all processors (CP plus SE/ZIIP)

CommitFreq:This field is the SQL Commit Frequency.It is composed by the rules below: (1) Computation of: The sum of SQLs Insert , Delete and Update / Total number of executed Commits. (2) A zero value will be shown if the number of executed Commits is zero. (3) A value -1 will be shown if the number of executed Commits is not zero and the sum of SQLs Insert, Delete and Update is zero. (4) The final number will be rounded up according to the examples: - Value 0,3 will be rounded to 1 (This example is an exception: instead of zero, value 1 will be generated). - Value 0,8 will be rounded to 1 - Value 1,2 will be rounded to 1 - Value 1,8 will be rounded to 2 A high number value in this field can indicate a DB2 application problem. In order to avoid DB2 problems, programs must frequently execute SQL commits to release locks and relief other resources, like DB2 LOG. A small number might indicates a program with too many Commits (this can slow

down program execution.

SQLs: Total executed SQLs.


133

CPU per Occurre: Total DB2 CPU Average per Occurrence.

CPU per SQL: Total DB2 CPU Average per SQL.

Log Written:Total log records written.

Fetch/Open:Total Fetches divided by Opens. Value will be rounded. Note:N/A means both fetch and open contains zeros. N/O means open contains zeros and fetch have contents.

%SSID: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) and the sum ofCPU (all processors) spent in all SSIDs (currently filtered). This percentage is related to current Trace Source. Therefore:– If Trace Source is 'A', the percentage is computed using CPU spent by SSIDs found inAccounting Traces.– If Trace Source is 'C', the percentage is computed using CPU spent by SSIDs foundin SQL Cache Area.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects


Sort Field Field Header CNID Name (Connection Id) T T (Trace Source) CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed AELAPSED Application Elapsed INDB2 InDB2 (Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) SQLS SQLs RD RD (RidPool) CPUSE DB2 CPU(SE/ZIIP) CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP)ACPUALL Aplication CPU(ALL) COMMITF CommitFreq OCCU Occurrence


134

LOG Log Written FET Fetch/Open



(X)ProgXrefReport RF00-Programs Cross Reference

(P)ProgWReport AC00-Programs Summary

(D)DetailsReport ACTO-More Details

(N)Expand Report AP01-Details Grouped By Date and Time (ACNI)

(Z)ZoomReport ZOOM-Show extended fields


135

ACNT - DB2 Connection Type Summary

This report shows DB2 CONNECTION TYPE activities.




SAMPLE REPORT


136

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 3 of 3 Option ===> ACNT - DB2 CONNECTION TYPE Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Plan Name : Correlation Name : Group Name : SSIDs : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (N)Expand (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C CNTY T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ----------- - ---------------- ---------------- ---------------- ----------- TSO F/B A 1.494 0.009 1.617 11 *CACHE/S C 1.464 0.005 1.573 N/A TSO F/B C 0.000 0.000 0.001 N/A ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

CNTY:Connection type. Valid Values:

TSO F/B - TSO FOREGROUND AND BACKGROUND CALL ATTACH - DB2 CALL ATTACH CICS ATTACH - CICS ATTACH DB2 PRIVATE - DB2 PRIVATE PROTOCOL DL/I BATCH - DL/I BATCH DRDA - DRDA PROTOCOL IMS ATT BMP - IMS ATTACH BMP IMS ATT MPP - IMS ATTACH MPP IMS CTL REG - IMS CONTROL REGION IMS TRN BMP - IMS TRANSACTION BMP UTILITY - DB2 UTILITIES RRSAF - RRSAF ATTACH *CACHE/D* - CONNECTION IS UNKNOWN. A DYNAMIC SQL WAS EXECUTED



THE ORIGIN CONNECTION TYPE. UNKNOWN - CONNECTION IS UNKNOWN.



DB2 Wait:Total DB2 Wait Time. Use option D for more information.

DB2 Elapsed:Total DB2 ELAPSED Time.Occurrence:Total traces found.







137

RD: This field indicates if a RidPool access has failed and a table scan has occurred. Valid values are: ' ' - RIDPOOL List not used or RIDPOOL List access was OK. 'S' - Access using RID List has failed because of size of RIDPOOL. If you can,

increase RIDPOOL size. 'L' - Access using RID List has failed because of internal DB2 limits. So, even




%CPUA:Percentage between DB2 CPU spent in all processors (CPU ALL).Note: This field is computed using the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:

40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - it means, this object in fact represents less than 40% (maximum

screen lines WAS exceeded)



lines WAS exceeded)

Application CPU(SE/ZIIP):Total application CPU time running on a SE/ZIIP.Application CPU(ALL):Total application CPU spent in all processors (CP plus SE/ZIIP)

CommitFreq:This field is the SQL Commit Frequency. It is composed by the rules below: (1) Computation of: The sum of SQLs Insert , Delete and Update / Total number of executed Commits. (2) A zero value will be shown if the number of executed Commits is zero. (3) A value -1 will be shown if the number of executed Commits is not zero and the sum of SQLs Insert, Delete and Update is zero. (4) The final number will be rounded up according to the examples: - Value 0,3 will be rounded to 1 (This example is an exception: instead of zero, value 1 will be generated). - Value 0,8 will be rounded to 1 - Value 1,2 will be rounded to 1 - Value 1,8 will be rounded to 2 A high number value in this field can indicate a DB2 application problem. In order to avoid DB2 problems, programs must frequently execute SQL commits to release locks and relief other resources, like DB2 LOG.


138

A small number might indicates a program with too many Commits (this can slow down program execution.

SQLs:Total executed SQLs.



Log Written: Total log records written.



AVAILABLE FILTERS


AVAILABLE SORT FIELDS Sort Field Field Header CNTY Name (Object Name) T T (Trace Source)CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed AELAPSED Application Elapsed INDB2 InDB2 (Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) SQLS SQLs RD RD (RidPool)


139

CPUSE DB2 CPU(SE/ZIIP)CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP)ACPUALL Aplication CPU(ALL) COMMITF CommitFreq OCCU OccurrenceLOG Log WrittenFET Fetch/Open






(N)Expand Report AP01-Details Grouped By Date and Time (ACNT)



140

ACOR - DB2 Correlation Summary

This report shows an overview of all Correlation Name activities loaded intoTurboTuneSQL repository.

The information shown here is obtained from DB2 Accounting traces or from SQLCache Area.

When working with SQL Cache Area, an object named *CACHE* will be generatedand option (D) will not be available.

Some examples of Correlation names are: CICS Transaction Name, JOBNAME, TSOUserid, etc.



SAMPLE REPORT


141

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 13 of 13 Option ===> ACOR - DB2 CORRELATION Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Program Name: Correlation Name : Cnty: Group Name : SSIDs : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (N)Expand (U)StatOverv (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C Correlation T Connection DB2 CPU (ALL) DB2 Wait DB2 Elapsed - ----------- - ----------- ---------------- ---------------- ---------------- *CACHE/S C *CACHE/S 1.464 0.005 1.573 ZIVPJ01 A TSO F/B 1.459 0.009 1.570 ZIVPJ02 A TSO F/B 0.005 0.000 0.008 ZIVPBD01 A TSO F/B 0.005 0.000 0.006 ZIVPJ03 A TSO F/B 0.004 0.000 0.005 ZIVPJ10 A TSO F/B 0.003 0.000 0.004 ZIVPJ06 A TSO F/B 0.003 0.000 0.003 ZIVPJ07 A TSO F/B 0.002 0.000 0.002 ZIVPJ08 A TSO F/B 0.002 0.000 0.003 ZIVPJ09 A TSO F/B 0.002 0.000 0.002 ZIVPJ04 A TSO F/B 0.002 0.000 0.006 ZIVPJ05 A TSO F/B 0.002 0.000 0.002 ZIVPBD01 C TSO F/B 0.000 0.000 0.001 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Correlation:Correlation name. Examples: JOBNAME, CICS Transaction, etc


Connection:Connection type. Valid Values:





DB2 CPU :Total DB2 CPU time spent on a normal CP processor. When trace comes from *CACHE*, this is the DB2 CPU spent in in all processors (CP plus SE/ZIIP).

DB2 Wait:Total DB2 Wait Time. Use option D for more information. When this trace comes from SQL Cache Area, use option P first.

DB2 Elapsed:Total DB2 ELAPSED Time.Application Elapsed: Total application elapsed time.Information not available when trace comes from *CACHE*.


Application CPU: Total application CPU time spent on a normal CP processor.Information not available when trace comes from *CACHE*.



142






DB2 CPU(SE/ZIIP):Total DB2 CPU time running on a SE/ZIIP. When trace comes from *CACHE*, this is the DB2 CPU spent in in all processors (CP plus SE/ZIIP).


%CPUA:Percentage between DB2 CPU spent in all processors (CPU ALL). Note: This field is computed using the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:





lines WAS exceeded)

Application CPU(SE/ZIIP):Total application CPU time running on a SE/ZIIP.Information not available when trace comes from *CACHE*.


CommitFreq:This field is the SQL Commit Frequency. It is composed by the rules below: (1) Computation of: The sum of SQLs Insert , Delete and Update / Total number of executed Commits. (2) A zero value will be shown if the number of executed Commits is zero.


143

(3) A value -1 will be shown if the number of executed Commits is not zero and the sum of SQLs Insert, Delete and Update is zero. (4) The final number will be rounded up according to the examples: - Value 0,3 will be rounded to 1 (This example is an exception: instead of zero, value 1 will be generated). - Value 0,8 will be rounded to 1 - Value 1,2 will be rounded to 1 - Value 1,8 will be rounded to 2 A high number value in this field can indicate a DB2 application problem. In order to avoid DB2 problems, programs must frequently execute SQL commits to release locks and relief other resources, like DB2 LOG. A small number might indicates a program with too many Commits (this can slow


Occurrence:Total traces found.A value 'N/A' will be always generated when this information comes from DB2 SQLCache Area.For CICS transactions, this value can not be equal to total of CICS transactionsexecuted as shown in CICS monitors because of DB2/CICS Thread Reuse mechanism. If you really want to have compatible values, you can set option ACCOUNTREC to UOWor to TASK in the DBENTRY RDO definition. Check IBM DB2 documentation for allimplications of doing this change.






AVAILABLE FILTERS



144

Other Filters: Program Name Correlation Name - use wildcard '*' for correlations started with a given name Correlation Name and Connection Type Correlation Name and Program Name

AVAILABLE SORT FIELDS Sort Field Field Header CORR Correlation T T (Trace Source)CONN ConnectionCPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed AELAPSED Application ElapsedINDB2 InDB2 (Percentage Elapsed) ACPU Application CPU SQLS SQLs RD RD (RidPool) ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) CPUSE DB2 CPU(SE/ZIIP) CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP)ACPUALL Aplication CPU(ALL) COMMITF CommitFreqOCCU Occurrence LOG Log Written FET Fetch/Open Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)





(N)ExpandReport AP01-Details Grouped By Date and Time (ACOR)



145

ACTO - More Details

This report shows more Accounting details from current listed object.



SAMPLE REPORT


146

TurboTuneSQL V120 ------------------- Online Report ------- Row 1 to 31 of 107 Option ===> ACTO - More Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Object : ZIVPJ01 ----------------------------- ACCOUNTING DETAILS ------------------------------ TOTAL OCCURRENCE: 1 DB2 CPU TIME (AVG PER OCCURRENCE): 1.459371 TOTAL SQLs EXECUTED: 3 DB2 CPU TIME (AVG PER SQL): 0.486457 APPLICATION ELAPSED TIME TOTAL: 1.601537 __APPLICATION ELAPSED TIME: 1.601537 __STORED PROCEDURE TOTAL ELAPSED TIME: 0.000000 __TRIGGER TOTAL ELAPSED TIME: 0.000000 __UDF TOTAL ELAPSED TIME: 0.000000 APPLICATION CPU TIME TOTAL (CP): 1.486236 __APPLICATION CPU TIME: 1.486236 __STORED PROCEDURE CPU TIME: 0.000000 __TRIGGER CPU TIME: 0.000000 __UDF CPU TIME: 0.000000 APPLICATION CPU TIME TOTAL (SE/ZIIP): 0.000000 __APPLICATION CPU TIME: 0.000000 __STORED PROCEDURE CPU TIME: 0.000000 __UDF CPU TIME: 0.000000 __TRIGGER CPU TIME: 0.000000

FIELD DESCRIPTIONS - ACCOUNTING DETAILS

TOTAL OCCURRENCE:Total Traces found for this object

DB2 CPU TIME (AVG PER OCCURRENCE):Average CPU time per occurrence.

TOTAL SQL EXECUTED:Total SQL Executed. (*)

DB2 CPU TIME (AVG PER SQL): Average CPU time per SQL executed.

APPLICATION ELAPSED TIME TOTAL: Sum of all application elapsed Time as below:

_APPLICATION ELAPSED TIME: Total application elapsed time without spending time in Stored Procedure, Triggers andUDF.

_STORED PROCEDURE ELAPSED TIME:Total elapsed time spent by Stored Procedure

_TRIGGER ELAPSED TIME: Total elapsed time spent by Trigger while under and not under an Enclave.

_UDF ELAPSED TIME: Total elapsed time spent by UDF.

APPLICATION CPU TIME TOTAL (CP): Sum of all application CPU time as below:

_APPLICATION CPU TIME: Total application CPU time without spending time in Stored Procedure, Triggers and UDF.

_STORED PROCEDURE CPU TIME: Total CPU time spent by Stored Procedure in DB2 Stored Procedure Address Space or inWLM Address Space to process SQL call statement

_TRIGGER CPU TIME: Total CPU time used by Triggers under and not under an Enclave.

_UDF CPU TIME: Total CPU time spent by udf

APPLICATION CPU TIME TOTAL (SE/ZIIP) Sum of all application CPU time running on a SE/ZIIP as per below:

_APPLICATION CPU TIME Total application CPU time spent on SE/ZIIP without computing the time spent by Stored Procedures, udf and Triggers.

_STORED PROCEDURE CPU TIME Total CPU time spent by Stored Procedured in DB2 Stored Procedure Address Space or in WLM Adress Space to process SQL CALL statement


147

_TRIGGER CPU TIME Total CPU time used by Triggers under and not under an Enclave.

_UDF CPU TIME Total CPU time spent by UDF.

DB2 ELAPSED TIME TOTAL: Sum of all DB2 elapsed Time as below:

_DB2 ELAPSED TIME: Total DB2 elapsed time without spending time in Stored Procedure, Triggers and UDF

_STORED PROCEDURE DB2 ELAPSED TIME: Total DB2 elapsed time by Stored Procedure executing SQLs

_TRIGGER ELAPSED TIME:Total elapsed time spent by Trigger while under and not under an Enclave.

_UDF DB2 ELAPSED TIME: Total DB2 elapsed time by User Defined Function in executing SQLs

DB2 NOT ACCOUNTED: Result of DB2 Elapsed time minus the sum of DB2 CPU time and DB2 wait time.Usually the DB2 Class 2 Not Accounted time is very small or negligible. It representstime that DB2 is unable to account for. If you see significant DB2 Class 2 Not Accountedtime, it could be a problem. Check IBM DB2 documentation for more information.

DB2 CPU TIME TOTAL (CP) Sum of all DB2 CPU time spent on a normal CP processor as per below: (when trace comes from *CACHE*,this is the DB2 CPU spent in CP plus SE/ZIIP)

_DB2 CPU TIME: Total DB2 CPU time without spending time in Stored Procedure and udf

_STORED PROCEDURE DB2 CPU TIME:Total DB2 CPU time by Stored Procedure executing SQLs.

_TRIGGER CPU TIME: Total CPU time used by Triggers under and not under an Enclave.

_UDF DB2 CPU TIME: Total DB2 CPU time by User Defined Function in executing SQLs.

DB2 CPU TIME TOTAL (SE/ZIIP) Sum of all DB2 CPU time running on a SE/ZIIP as per below:

_APPLICATION CPU TIME Total DB2 CPU time spent on SE/ZIIP without computing the time spent by Stored Procedures, Triggers and UDF.

_STORED PROCEDURE CPU TIME Total CPU time spent by Stored Procedured in DB2 Stored Procedure Address Space or in WLM Adress Space to process SQL CALL statement

_TRIGGER CPU TIME Total CPU time used by Triggers under and not under an Enclave.

_UDF CPU TIME Total CPU time spent by UDF.


148

CPU CONSUMED ON CP FOR SE/ZIIP-ELIGIBLE WORK DB2 version 9 field (not supported by DB2 V10).Total CPU time consumed on a normal CP processor that would be eligible to run on SE/ZIIP.To have this information in DB2 V10, you will need to use RMF reports. See IBMdocumentation for more information.

DB2 WAIT TIME TOTAL:

_DB2 WAIT TIME LOCK/LATCH:Total DB2 WAIT Time Spent in Lock/Latch.

_DB2 WAIT SYNC I/O DATABASE:Total DB2 WAIT Time in synchronous I/O to read/write DB2 application tables.

_DB2 WAIT I/O LOG: Total wait time for LOG write I/O

_DB2 WAIT TIME OTHER READS: Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

_DB2 WAIT TIME OTHER WRITES: Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported

_DB2 WAIT TIME COMMIT/ABORT:DB2 WAIT time spent in commit, abort or deallocation process.

_DB2 WAIT TIME OPEN-CLOSE:DB2 WAIT time spent in: open and close of a Data Set ; HSM recall Data Set

_DB2 WAIT TIME SYSLGRN UPDATE: DB2 WAIT time spent in update of SYSLGRNG

_DB2 WAIT TIME data set SERVICES:DB2 WAIT time spent in data set services:

Dataspace Manager ServicesDefine Data SetExtend Data Set Delete Data Set

_DB2 WAIT TIME OTHER SERVICES:DB2 WAIT time due to other DB2 service tasks

_DB2 WAIT TIME DRAIN LOCK: DB2 WAIT time to acquire drain lock

_DB2 WAIT TIME ARCHIVE LOG: DB2 WAIT time to process archive log command

_DB2 WAIT TIME ARCHIVE READ: DB2 WAIT time for archieve reads, active reads, active log prefetch reads


149

_DB2 WAIT TIME DRAIN WAIT FOR CLAIM TO BE RELEASED: DB2 WAIT time for a Drain when waiting for a Claim to be released.

_DB2 WAIT TIME PAGE LATCH CONTENTION: DB2 WAIT time because of a page latch contention. Some DB2 utilities use page latch instead of lock table to collect statistics.

_DB2 WAIT TIME AVAILABLE TCB STPROC:Total waiting time for available TCB before Stored Procedure could be scheduled

_DB2 WAIT TIME AVAILABLE TCB UDF:Total waiting time for available TCB before User Define Function could be scheduled

_DB2 WAIT TIME FOR COMMIT PHASE 1 WRITE I/O:Total accumulated wait time for commit phase 1 database write I/O completion.

_DB2 WAIT TIME DATASHARING SENDING MESSAGES: Total waiting time caused by suspension for sending messages to other DB2 Members

_DB2 WAIT TIME GLOBAL CONT. PARENT L-LOCKS:Total waiting time caused by global contention for parent l-locks.

_DB2 WAIT TIME GLOBAL CONT. CHILD L-LOCKS: Total waiting time caused by global contention for child l-locks.

_DB2 WAIT TIME GLOBAL CONT. OTHER L-LOCKS: Total waiting time caused by global contention for other l-locks.

_DB2 WAIT TIME GLOBAL CONT. PAGESET P-LOCKS: Total waiting time caused by global contention for pagetset/partition p-locks.

_DB2 WAIT TIME GLOBAL CONT. PAGE P-LOCKS: Total waiting time caused by global contention for page p-locks.

_DB2 WAIT TIME GLOBAL CONT. OTHER P-LOCKS: Total waiting time caused by global contention for other p-locks.

_DB2 WAIT ASYNCH CF REQUESTS:Accumulated wait time for IXLCACHE and IXLFCOMP asynch request.

_DB2 WAIT TIME TCP/IP LOB AND XML MATERIALIZ:Total waiting time for TCP/IP LOB and XML materialization.

DB2 TOTAL I/O EVENTS: Total wait trace events.

I/O RESPONSE TIME:Average Disk I/O time. This number is obtained dividing Sync I/O database by TotalI/O Events.

TOTAL PARALLEL TASKS:Total parallel tasks.

TOTAL LOG WRITTEN:Total log records written.

TOTAL COMMIT:Total COMMIT executed.


150

TOTAL MERGETotal MERGE executed.

TOTAL TRUNCATETotal TRUNCATE executed.

TOTAL ROLLBACK:Total ROLLBACK executed.

TOTAL SELECT:Total SELECTs executed

TOTAL INSERT:Total INSERTs executed

TOTAL UPDATE:Total UPDATEs executed

TOTAL DELETE:Total DELETEs executed

TOTAL DESCRIBE:Total DESCRIBEs executed

TOTAL DESCRIBE TABLE:Total DESCRIBE TABLEs executed

TOTAL PREPARE:Total PREPAREs executed

TOTAL OPEN:Total OPENs executed

TOTAL FETCH:Total FETCHes executed

TOTAL CLOSE:Total CLOSEs executed

TOTAL LOCK TABLE:Total LOCK TABLEs executed

TOTAL GRANT:Total GRANTs executed

TOTAL REVOKE:Total REVOKE executed

TOTAL SET CURRENT SQLID:Total SET CURRENT SQLIDs executed

TOTAL SET HOSTVARS:Total SET HOSTVARS executed

TOTAL SET CONNECT:Total SET CONNECTs executed

TOTAL SET CURRENT DEGREE:Total SET CURRENT DEGREEs executed


151

TOTAL SET CURRENT PATH:Total SET CURRENT PATHs executed

TOTAL SET CURRENT PRECISION: Total SET CURRENT PRECISIONs executed

TOTAL DECLARE GLOBAL TABLE: Total DECLARE GLOBAL TABLEs executed

TOTAL CREATE TEMP TABLE:Total CREATE TEMP TABLEs executed

TOTAL TIME-OUTS:Total TIME-OUTs

TOTAL RID LIST WAS USED:Total RID LIST WAS USEDs

TOTAL RIDPOOL NO STORAGE:Total access using RID List has failed because of size of RIDPOOL. If you can, increaseRIDPOOL size. A DB2 Table Scan will be done.

TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limits were:

● Data Manager limit (16 million table lines) ● When RDS reaches 25 percent of table size ● A DB2 Table Scan will be done.

TOTAL PREPARE STMT FOUND IN CACHE:Total dynamic statements found in cache

TOTAL PREPARE STMT NOT FOUND IN CACHE:Total dynamic statements not found in cache

TOTAL IMPLICIT PREPARE: Total prepare done because keepdynamic (yes) but a copy of SQL was not found

TOTAL PREPARE AVOIDED KEEPDYNAMIC:Total prepare avoided because keepdynamic is yes and a copy of SQL was found

TOTAL STMT DISCARDED BECAUSE MAXKEEPD: The number of times that an application process' executable copy of a prepared statement was discarded due to the maxkeepd system limit being exceeded

TOTAL STMT DISCARDED BECAUSE TABLE ALTER: The number of times that a prepared statement was purged from the cache statement was purged from the cache because a drop, alter, or revoke statement was issued on a dependent object.

TOTAL TIME DIRECT ACCESS WAS USED: The number of times that direct row access was successful

TOTAL DIRECT ACCESS REVERTED IX SCAN: The number of times an attempt to use direct row access was reverted to using an index to locate a record

TOTAL DIRECT ACCESS REVERTED TB SCAN:


152

The number of times an attempt to use direct row access was reverted to using a table space scan to locate a record

(*) This field is a sum of all executed SQLs shown here.Some SQLs statements, like SQL VALUE, SQL Call and some others will not be shown inthis version of TurboTuneSQL

FIELD DESCRIPTIONS - CACHE DETAILS

SQL TOTAL EXECUTION: Total SQLs executed. For SQLs with cursor, this is the number of OPENs.

DB2 ELAPSED TIME: Total DB2 Elapsed Time.

DB2 CPU TIME: Total DB2 CPU spent in all processors (CP plus SE/ZIIP).

DB2 CPU TIME (AVG PER SQL):Average DB2 CPU Time per SQL Execution.

ROWS PROCESSED:Number of Rows of all record types processed.For example, number of rows returned for a SELECT, or number of rows affected by an INSERT, UPDATE or DELETE TABLESPACES with only 1 table:

– This number counts rows for the related DB2 TABLE only Segmented TABLESPACES:

– This number counts rows for the related DB2 TABLE only Index Spaces: same as above.

– This number counts rows for the related DB2 TABLE only Single TABLESPACES with multiple tables:

– This number counts all rows for all tables,not only for the related table.

ROWS EXAMINED:Number of Rows of all record types processed.This number counts rows for the related table only.So, in some situations, this number will be the same value as ROWS PROCESSED

NUMBER OF SORTS: Total Number of sort performed.

INDEX SCAN: Total Number of index scan performed.

TABLESPACE SCAN:Total Number of index scan performed.

TOTAL GETPAGES:Getpages issued.

SYNCHRONOUS BUFFER READ: The number of synchronous buffer reads.

SYNCHRONOUS BUFFER WRITE: The number of buffer writes.


153

TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done.

TOTAL RIDPOOL NO STORAGE: Total access using RID List has failed because of size of RIDPOOL. If its possible,increase RIDPOOL size. A DB2 Table Scan will be done.

DB2 WAIT TIME TOTAL:Total DB2 Wait Time

_DB2 WAIT SYNC I/O DATABASE:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables.

_DB2 WAIT TIME SERVICE TASK: Total DB2 Wait Time for Service Task (wait time due to synchronous execution unit switch to other DB2 service tasks). Service that may be included here:

– Open and close of a Data Set – Update of SYSLGRNG – HSM recall Data Set – Dataspace Manager Services – Define Data Set – Extend Data Set – Delete Data Set

– Wait time spent in commit, abort or deallocation process.

_DB2 WAIT TIME DATASHARING GLOBAL CONTENTIONTotal waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks. _DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

_DB2 WAIT TIME OTHER WRITES:

Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported

_DB2 WAIT TIME LOCK: Total DB2 Wait Time Spent in Lock.

_DB2 WAIT TIME LATCH: Total DB2 Wait Time Spent in Latch.





154


NRO PARALLLEL GROUPS CREATED: Total Number of parallel groups created by the statement.

TOTAL COMMIT:Total COMMIT executed.

TOTAL MERGETotal MERGE executed.

TOTAL TRUNCATETotal TRUNCATE executed.

TOTAL ROLLBACK:Total ROLLBACK executed.

TOTAL SELECT:Total SELECTs executed

TOTAL INSERT:Total INSERTs executed

TOTAL UPDATE:Total UPDATEs executed

TOTAL DELETE:Total DELETEs executed

TOTAL DESCRIBE:Total DESCRIBEs executed

TOTAL DESCRIBE TABLE:Total DESCRIBE TABLEs executed

TOTAL PREPARE:Total PREPAREs executed

TOTAL OPEN:Total OPENs executed

TOTAL FETCH:Total FETCHes executed

TOTAL CLOSE:Total CLOSEs executed

TOTAL LOCK TABLE:Total LOCK TABLEs executed

TOTAL GRANT:Total GRANTs executed

TOTAL REVOKE:Total REVOKE executed


155

TOTAL SET CURRENT SQLID:Total SET CURRENT SQLIDs executed

TOTAL SET HOSTVARS:Total SET HOSTVARS executed

TOTAL SET CONNECT:Total SET CONNECTs executed

TOTAL SET CURRENT DEGREE:Total SET CURRENT DEGREEs executed

TOTAL SET CURRENT PATH:Total SET CURRENT PATHs executed

TOTAL SET CURRENT PRECISION: Total SET CURRENT PRECISIONs executed

TOTAL DECLARE GLOBAL TABLE: Total DECLARE GLOBAL TABLEs executed

TOTAL CREATE TEMP TABLE:Total CREATE TEMP TABLEs executed

TOTAL WORK RIDPOOL OVERFLOW BY NO STORAGE:

TOTAL WORK RIDPOOL OVERFLOW BY LIMIT :

TOTAL JOIN RIDPOOL OVERFLOW BY STORAGE:

TOTAL JOIN RIDPOOL OVERFLOW BY LIMIT:

TOTAL MIAP RIDPOOL OVERFLOW LIMIT:

NO AVAILABLE LINE ACTIONS


156

AC00 - Programs Summary

This report shows an overview of all DB2 programs loaded into TurboTuneSQLrepository obtained from DB2 Accounting and Performance Traces, and SQL CacheArea.



SAMPLE REPORT


157

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 24 of 33 Option ===> AC00 - Programs Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: Correlation: Connection Type: Table Owner : Table Name : Stmt Uniq: Group Tab : Group Col : SSID : Plan Name : Collection : Database: Line Actions ------------------------------------------------------------------ (X)ProgXref (S)SQLs (L)SQLXref (D)Details (N)Expand (P)ProgW (R)ProgS (B)ProgC (E)Explain (M)PlanTableComp (C)CorrelationW (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C Program T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ------------ - ---------------- ---------------- ---------------- ----------- ZIVPBT01 A 1.458 0.009 1.570 1 ZIVPBT01 C 1.454 0.005 1.561 N/A ZIVPBT02 A 0.005 0.000 0.008 1 DSN@EP2L A 0.004 0.000 0.005 1 ZIVPBT03 A 0.003 0.000 0.005 1 ZIVPBT10 A 0.003 0.000 0.003 1 ZIVPBT02 P 0.003 0.000 0.003 N/A ZIVPBT06 A 0.002 0.000 0.002 1 DSN@EP2L P 0.002 0.000 0.002 N/A ZIVPBT08 A 0.002 0.000 0.003 1 ZIVPBT07 A 0.002 0.000 0.002 1

FIELD DESCRIPTIONS

Program:Program Name.

T: Trace Source: Valid Values: 'A' - Program found in Accounting Traces 'P' - Program found in Performance Traces 'C' - Program found in SQL Cache Area (Static or Dynamic)

DB2 CPU(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP).When field Trace Source is P (performance trace), a value N/A will appear depending oncurrent filters. For example: N/A will appear if filtering by Correlation (report ACOR) orby Plan (report APLN).

DB2 Wait:Total DB2 Wait Time. When Trace Source is P this field will be computed as DB2 Elapsed less DB2 CPU time.A value N/A will appear depending on current filters. For example: N/A will appear iffiltering by Correlation (report ACOR) or by Plan (report APLN).For Trace Source P, if DB2 elapsed and CPU time is available, Wait time will be computed as DB2 Elapsed minus DB2 CPU time. When Trace Source is A or C, use option D for more information.

DB2 Elapsed: Total DB2 ELAPSED Time spent by this Program.When field Trace Source is P (performance trace), a value N/A will appear depending oncurrent filters. For example: N/A will appear if filtering by Correlation (report ACOR) or by Plan (report APLN).

Occurrence: This field has 3 meanings:

- When Trace Source is 'P' or 'C', this version of TurboTuneSQL does not know how many time this program was found in traces. So, value 'N/A' will be always generated.- When Trace Source is 'A', this number registers the total number of accounting traces where this program was found. But attention: if this program was executed under CICS, this value does not match the total executed programs as shown in CICS monitors because of DB2/CICS Thread Reuse mechanism.

DB2 CPU(SE/ZIIP) :Total DB2 CPU time running on a SE/ZIIP.Information not available when trace comes from *CACHE*. When field Trace Source is P (performance trace), a value N/A will appear depending oncurrent filters. For example: N/A will appear if filtering by Correlation (report ACOR) orby Plan (report APLN).

DB2 CPU:Total DB2 CPU spent by this Program. If trace type is: 'A' - CPU time spent on a normal CP processor. 'P' - CPU time spent on all processors (CP plus SE/ZIIP). 'C' - CPU time spent on all processors (CP plus SE/ZIIP). When field Trace Source is P (performance trace), a value N/A will appear depending oncurrent filters. For example: N/A will appear if filtering by Correlation (report ACOR) orby Plan (report APLN).


158



screen lines WAS exceeded)%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines.If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage valuewill be approximate and will be prefixed with character <.Examples:

80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - it means, this object in fact represents less than 80% (maximum screenlines WAS exceeded)

SQLs: Total SQLs executed.




AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: DB2 Plan Name DB2 Connection Type DB2 Correlation Name Program Name Program Range – use wildcard '*' for programs started with a given name Unique Name Database Name Table Name(s) Table Name(s) and Owner


159

AVAILABLE SORT FIELDS Sort Field Field Header PROG Program T T (trace source) CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed OCCU Occurrence CPUSE DB2 CPU(SE/ZIIP)CPUALL DB2 CPU(ALL) Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)



(S)SQLsReport ST01-SQLs Summary

(L)SQLXrefReport STRF-SQL Cross Reference

(D)DetailsReport PGDT- Program Execution Details

(N)Expand Report AC01 with Program Detail Grouped By Date and Time


(R)ProgSReport SRPG-Programs List

(B)ProgC Report SRIC-Shows Packages in Catalog

(E)ExplainReport SREX-SQLs Explain Information

(M)PlanTableCompReport SRMI-Plan Table Comparison

(C)Correlation Report ACOR-Correlation Summary

(Z)Zoom Report ZOOM-Show extended fields


160

AC01 - Show Details Grouped by Date and Time

This report shows the activity of the selected program grouped by date andtime.



SAMPLE REPORT


161

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> AC01 - Show Details Grouped by Date and Time Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: ZIVPBT06 Plan Name: Collection: Correlation : Tupe: C Connection Type: SSIDs : Summarize by: (M/D/Y) Line Actions ------------------------------------------------------------------ (X)ProgXref (S)SQLs (L)SQLXref (D)Details (R)ProgS (M)PlanTableComp (C)Correlation (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C DateR TimeR I T DB2 CPU (ALL) DB2 WAIT DB2 Elapsed - ---------- -------- -- -- ---------------- ---------------- ---------------- 2019-11-13 06.00.00 60 CS 0.001 0.000 0.001 2019-11-13 07.00.00 60 CS 0.001 0.000 0.001 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Summarize by (option to summarize DB2 time values based on the original display):M - Overall DB2 CPU and Elapsed Time by YEAR/MONTH D - Overall DB2 CPU and Elapsed Time by YEAR/MONTH/DAY Y - Overall DB2 CPU and Elapsed Time by YEAR ' ' - To switch back to the original display for this report which is ordered by Date

and Time as default Note: On every option, the fields Time, Interval and Program Timestamp are not

applicable

DateR:Date when the program was ended

TimeR:Time when the program was ended (rounded by parameter “Reduce Trace Data”)

Interval:Same value as used in parameter “Reduce Trace Data”




DB2 CPU:Total DB2 CPU spent by this Program. If trace type is: 'A' - CPU time spent on a normal CP processor. 'P' - CPU time spent on all processors (CP plus SE/ZIIP). 'C' - CPU time spent on all processors (CP plus SE/ZIIP).

DB2 Elapsed: Total DB2 ELAPSED Time spent by this Program.

T:Trace Source: Valid Values: 'A' - Program found in Accounting Traces 'P' - Program found in Performance Traces 'CS' - Program found in SQL Cache Area (Static) 'CD' - Program found in SQL Cache Area (Dynamic)

DB2 CPU(SE/ZIIP) :Total DB2 CPU time running on a SE/ZIIP.Information not available when trace comes from *CACHE*.

DB2 CPU(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP).




162

NO AVAILABLE FILTERS


Sort Field Field Header DATE DateRTIME TimeR I I (Trace Interval)PT Program Timestamp CPU DB2 CPU ELAPSED DB2 Elapsed CPUSE DB2 CPU(SE/ZIIP)CPUALL DB2 CPU(ALL) Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)









(C)Correlation Report ACOR-Correlation Summary


163

APLN - Plan Name Summary

This report shows DB2 PLAN activities.

The information shown here is obtained from DB2 Accounting traces or from SQLCache Area. When data comes from SQL Cache Area, an object named *CACHE* willbe generated.



SAMPLE REPORT


164

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 4 of 4 Option ===> APLN - DB2 PLAN Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Plan Name : Correlation Name : Group Name : SSIDs : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (N)Expand (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C Plan T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ----------- - ---------------- ---------------- ---------------- ----------- PLANSADV A 1.488 0.009 1.611 10 *CACHE/S C 1.464 0.005 1.573 N/A DSNTEP11 A 0.005 0.000 0.006 1 *CACHE/D C 0.000 0.000 0.001 N/A ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Plan:DB2 Plan name

T:Trace Source: Valid Values: 'A' - This SQL comes from Accounting Traces 'C' - This SQL comes from SQL Cache Area

DB2 CPU:Total DB2 CPU time spent on a normal CP processor. When trace comes from *CACHE*, this is the DB2 CPU spent in in all processors (CP plus SE/ZIIP).

DB2 Wait:Total DB2 Wait Time. Use option D for more information. When this trace comes from SQL Cache Area, use option P first.


Occurrence:Total traces found. A value 'N/A' will be always generated when this information comes from DB2 SQLCache Area.

Application Elapsed: Total application elapsed time.Information not available when trace comes from *CACHE*.









165










CommitFreq:This field is the SQL Commit Frequency. It is composed by the rules below: (1) Computation of: The sum of SQLs Insert , Delete and Update / Total number of executed Commits. (2) A zero value will be shown if the number of executed Commits is zero. (3) A value -1 will be shown if the number of executed Commits is not zero and the sum of SQLs Insert, Delete and Update is zero. (4) The final number will be rounded up according to the examples: - Value 0,3 will be rounded to 1 (This example is an exception: instead of zero, value 1 will be generated). - Value 0,8 will be rounded to 1 - Value 1,2 will be rounded to 1 - Value 1,8 will be rounded to 2 A high number value in this field can indicate a DB2 application problem. In order to avoid DB2 problems, programs must frequently execute SQL commits to release locks and relief other resources, like DB2 LOG. A small number might indicates a program with too many Commits (this can slow




166






AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Plan Name - use wildcard '*' for plans started with a given name

AVAILABLE SORT FIELDS Sort Field Field Header PLAN PlanT T (Trace Source) CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed AELAPSED Application Elapsed INDB2 InDB2 (Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) SQLS SQLs RD RD (RidPool) CPUSE DB2 CPU(SE/ZIIP)


167

CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP)ACPUALL Aplication CPU(ALL) COMMITF CommitFreq OCCU OccurrenceLOG Log WrittenFET Fetch/Open Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)



(P)ProgW Report AC00-Programs Summary

(D)Details Report ACTO-More Details

(N)Expand Report AP01-Details Grouped By Date and Time (APLN)



168

AP01 - Show Details Grouped by Date and Time

For reports: ACNI, ACNT, APLN, CICS and IMSM This report will show execution information, grouped by date and time, for thefollowing objects: Connection Id, Connection Type, Plan or CICS/IMS Transactions.

For report: ACOR

This report will show an overview of DB2 Correlation Activities, grouped by dateand time. The following are examples of DB2 Correlation names: CICS Transaction, Jobname, TSO User, etc.

For report: ASSI

This report will show activities of DB2 SSIDs, grouped by date and time.



SAMPLE REPORT


169

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> AP01 - Report (APLN) Grouped by Date Time Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Type: A Plan Name : DSNTEP11 Correlation Name : Group Name : SSID: Summarize by : (M/D/Y) Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C DateR TimeR I DB2 CPU (ALL) DB2 Elapsed DB2 Not Accounted - ---------- -------- -- ---------------- ---------------- ------------------- 2019-11-13 09.00.00 60 0.005 0.006 0.000785 2019-11-13 10.00.00 60 0.005 0.006 0.000785 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Summarize by (option to summarize DB2 time values based on the original display): M - Overall DB2 CPU and Elapsed Time by YEAR/MONTH D - Overall DB2 CPU and Elapsed Time by YEAR/MONTH/DAY Y - Overall DB2 CPU and Elapsed Time by YEAR ' ' - To switch back to the original display for this report which is ordered by Date

and Time as default Note: On every option, the fields Time and Interval are not applicable

Date:Date when the program was ended

Time:Time when the program was ended (rounded by parameter “Reduce Trace Data”)


DB2 CPU:Total DB2 CPU time spent on a normal CP processor. When trace comes from *CACHE*, this is the DB2 CPU spent in in all processors (CP plus SE/ZIIP).DB2 Elapsed:Total DB2 ELAPSED Time.DB2 Not Accounted: Result of DB2 Elapsed time minus the sum of DB2 CPU time and DB2 wait time.Application Elapsed: Total application elapsed time.Information not available when trace comes from *CACHE*.


Occurrence:

Total traces found.A value 'N/A' will be always generated when this information comes from DB2 SQLCache Area.For CICS transactions, this value can not be equal to total of CICS transactionsexecuted as shown in CICS monitors because of DB2/CICS Thread Reuse mechanism. If you really want to have compatible values, you can set option ACCOUNTREC to UOWor to TASK in the DBENTRY RDO definition. Check IBM DB2 documentation for allimplications of doing this change.






170




AVAILABLE SORT FIELDS Sort Field Field Header DATE DateR TIME TimeR I I (Trace Interval)CPU DB2 CPU ELAPSED DB2 Elapsed ACCOUNTED DB2 Not Accounted AELAPSED Application Elapsed ACPU Application CPU OCCU Occurrence Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)







171

ASSI - SSID Summary

This report shows all SSIDs activities loaded into TurboTuneSQL repository.

The information shown here is obtained from DB2 Accounting traces or from SQLCache Area. When data comes from SQL Cache Area, an object named *CACHE* willbe generated.



SAMPLE REPORT


172

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> ASSI - DB2 SSID Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR: 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Group Name: SSIDs: Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (L)Plan (C)Correlation (N)Expand (Z)Zoom ------------------------------------------------------------------------------> C SSID T GroupName DB2 CPU (ALL) DB2 Wait DB2 Elapsed RD - ---- - --------- ---------------- ---------------- ---------------- -- DBBG A 1.494 0.009 1.61 DBBG C 1.465 0.005 1.57 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

SSID:DB2 SSID.


Group Name:DB2 Data Sharing Group Name.

DB2 CPU:Total DB2 CPU time spent on a normal CP processor. When trace comes from *CACHE*, this is the DB2 CPU spent in in all processors (CP plus SE/ZIIP).

DB2 Wait:Total DB2 Wait Time. Use option D for more information. When this trace comes from SQL Cache Area, use option P first.DB2 Elapsed:Total DB2 ELAPSED Time.RD: This field indicates if a RidPool access has failed and a table scan has occurred. Valid values are: ' ' - RIDPOOL List not used or RIDPOOL List access was OK. 'S' - Access using RID List has failed because of size of RIDPOOL. If you can,



Application Elapsed: Total application elapsed time.Information not available when trace comes from *CACHE*.








173







Application CPU(SE/ZIIP):Total application CPU time running on a SE/ZIIP.Information not available when trace comes from *CACHE*.Application CPU(ALL):Total application CPU spent in all processors (CP plus SE/ZIIP)





174

Occurrence:Total traces found.A value 'N/A' will be always generated when this information comes from DB2 SQLCache Area.For CICS transactions, this value can not be equal to total of CICS transactionsexecuted as shown in CICS monitors because of DB2/CICS Thread Reuse mechanism. If you really want to have compatible values, you can set option ACCOUNTREC to UOWor to TASK in the DBENTRY RDO definition. Check IBM DB2 documentation for allimplications of doing this change.

Log Written: Total log records written.




AVAILABLE FILTERS


AVAILABLE SORT FIELDS Sort Field Field Header SSID SSIDT T (Trace Source) GROUP Group Name CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed RD RD (RidPool) AELAPSED Application Elapsed INDB2 InDB2 (Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) SQLS SQLs


175

CPUSE DB2 CPU(SE/ZIIP) CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP) ACPUALL Aplication CPU(ALL) COMMITF CommitFreqFET Fetch/OpenOCCU Occurrence LOG Log WrittenExamples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)




(L)Plan Report APLN-Plan Summary

(C)CorrelationReport ACOR-Correlation Summary

(D)Details Report ACTO-More Details

(N)Expand Report AP01-Details Grouped By Date and Time(ASSI)

(Z)Zoom

Report ZOOM-Show extended fields


176

CICS - CICS Transactions

This report shows CICS Transactions activities.

The information shown here is obtained from DB2 Accounting traces or from SQL Cache Area.



SAMPLE REPORT


177

TurboTuneSQL V120 ------------------- Online Report --------------------- 13:51 Option ===> CICS - TRANSACTION SUMMARY Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Plan Name : Correlation Name : Group Name : SSIDs : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (D)Details (N)Expand (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C Trans T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ----------- - ---------------- ---------------- ---------------- ----------- TRN1 A 1.494 0.009 1.61 2 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Trans:CICS Transaction name.



DB2 Wait:Total DB2 Wait Time. Use option D for more information.DB2 Elapsed:Total DB2 ELAPSED Time.Occurrence:Total traces found.For CICS transactions, this value can not be equal to total of CICS transactionsexecuted as shown in CICS monitors because of DB2/CICS Thread Reuse mechanism. If you really want to have compatible values, you can set option ACCOUNTREC to UOWor to TASK in the DBENTRY RDO definition. Check IBM DB2 documentation for allimplications of doing this change.












178







CommitFreq:This field is the SQL Commit Frequency. It is composed by the rules below: (1) Computation of: The sum of SQLs Insert , Delete and Update / Total number of executed Commits. (2) A zero value will be shown if the number of executed Commits is zero. (3) A value -1 will be shown if the number of executed Commits is not zero and the sum of SQLs Insert, Delete and Update is zero. (4) The final number will be rounded up according to the examples: - Value 0.3 will be rounded to 1 (This example is an exception: instead of zero, value 1 will be generated). - Value 0.8 will be rounded to 1 - Value 1.2 will be rounded to 1 - Value 1.8 will be rounded to 2 A high number value in this field can indicate a DB2 application problem. In order to avoid DB2 problems, programs must frequently execute SQL commits to release locks and relief other resources, like DB2 LOG. A small number might indicates a program with too many Commits (this can slow







179



AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Correlation Name - use wildcard '*' for correlations started with a given name Extended filters for CICS Report:

Database Name / Source Request Code Table Qualifier / Source Request Code Table Name(s) / Source Request Code

AVAILABLE SORT FIELDS Sort Field Field Header TRANS Name (Object Name) T T (Trace Source) CPU DB2 CPUWAIT DB2 Wait ELAPSED DB2 Elapsed AELAPSED Application Elapsed INDB2 InDB2 (Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) SQLS SQLs RD RD (RidPool) CPUSE DB2 CPU(SE/ZIIP) CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP) ACPUALL Aplication CPU(ALL) COMMITF CommitFreq OCCU OccurrenceLOG Log WrittenFET Fetch


180






(N)Expand Report AP01-Details Grouped By Date and Time (CICS)



181

CO00 - Collection Overview

This report will show an overview of all DB2 Activities by Collection.

This information is based on DB2 Accounting Traces , Performance Tracesand from SQL Cache area.



SAMPLE REPORT


182

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 7 of 7 Option ===> CO00 - DB2 Package Collection Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Collection : Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (Z)Zoom ------------------------------------------------------------------------------- C Collid T DB2 CPU(ALL) DB2 Wait DB2 Elapsed Occurrence - ------------ - ---------------- ---------------- ---------------- ----------- SADVCOL A 1.485 0.009 1.607 10 SADVCOL C 1.464 0.005 1.573 N/A SADVCOL P 0.016 *N/A* 0.022 N/A DSNTEP2 A 0.004 0.000 0.005 1 DSNTEP2 P 0.002 *N/A* 0.002 N/A DSNDYNAMICSQ C 0.000 0.000 0.001 N/A DSNTEP2 C 0.000 0.000 0.000 N/A ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Collid:Collection name.

T: Trace Source: Valid Values: 'A' - Program found in Accounting Traces 'P' - Program found in Performance Traces 'C' - Program found in SQL Cache Area DB2 CPU(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP)


Use option X to navegate to RF00 report. After that, use option P and D for more information.For Trace Source P, if DB2 elapsed and CPU time is available, Wait time will be computed as DB2 Elapsed minus DB2 CPU time.


Occurrences:Total traces found.For Trace Source P, TurboTuneSQL does not summarize the total record found in traces.Therefore, N/A value will always be generated.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Collection Name

AVAILABLE SORT FIELDS Sort Field Field Header COLL Collection T T (Trace Source) CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed OCCU Occurrence Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


183






184

DB10 - Table Summary (first table appears in SQL)

This report shows summary information about objects accessed by executed SQLfound in DB2 Performance Traces and SQL Cache Area. Object can be tables, views, alias, synonym. Only the first object and Ownerreferenced in the SQL statement will appear.



SAMPLE REPORT


185

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 5 of 5 Option ===> DB10 - Table Summary (first table appears in SQL) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Plan : Table Name: Table Owner: Database: Line Actions ------------------------------------------------------------------ (X)ProgXref (G)IXModel (S)SQLs (D)Details (U)StatOverv (P)ProgW (M)PlanTableComp (Q)TableC (Z)Zoom ----------------------------------------------------------------------------- C Name Owner DB2 CPU(ALL) DB2 Elapsed SQLs - ------------------ -------- ---------------- ---------------- ----------- IVPTABLE_MQT IVPQUAL 1.455 1.563 5 IVPTABLE_T001 IVPQUAL 0.023 0.031 22 VIEW2 IVPQUAL 0.002 0.002 4 IVPTABLE_T002 IVPQUAL 0.001 0.002 2 TAB1 IVPQUAL 0.000 0.001 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name:This field normally represents a Table Name. Also, this field can be:

– A DB2 DDL Object, normally a DB2 Table name (check field T (Object type)– A Dynamic SQL command when no DB2 table was accessed. Example: SQL SET

CURRENT DATE. SQL commands will be always presented between ‘()’.

Sometimes you will see an object called UNKNOWN. This can happen if the SQL sourcewas not found. You should check:

- If informed Request Code is the right Request Code.- This is a non-Extractable SQL command. Check Appendix E. Limits to get more information.

Owner: Table Owner.

DB2 CPU(ALL):Total DB2 CPU spent by this table in all processors (CP plus SE/ZIIP).Note: The total CPU time consumption by DB2 are not broken by each table involved ina SQL Join. Therefore, DB2 total time shown here could be related to other tables too,not only the table exposed here.

DB2 Elapsed:Total DB2 ELAPSED Time spent by this object. Note: The total Elapsed time consumption by DB2 are not broken by each tableinvolved in a SQL Join. Therefore, DB2 total time shown here could be related to othertables too, not only the table exposed here.


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Plan Name Database Name Table Name(s) - use wildcard '*' for tables started with a given name Table Name(s) and Owner


186

AVAILABLE SORT FIELDS Sort Field Field Header NAME Name OWN Owner CPU DB2 CPU ELAPSED DB2 Elapsed SQLS SQLs Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)



(G)IXModel Report IXMD-Index Modeling (analysis by table - all SQLs)





(U)StatOvervReport SW01-SQLs by Statement type and Table

(Q)TableCReport TB00-Table Definitions from DB2 Catalog



187

EX01 - Cross Reference from PLAN TABLE

This report shows a cross reference of programs found in PLAN TABLE for a DB2tableor for a MQT. DB2 views are not supported by this report.

Note:Fields related to CPU, WAIT and ELAPSED time are shown using hhhhhh:mm:ss.tttttttime format. All other fields are shown using TurboTuneSQL Numeric format. Please,refer to Appendix Numerical and Time formats for additional information.

SAMPLE REPORT


188

TurboTuneSQL V120 ------------------- Online Report --------------------- 13:57 Option ===> EX01 - Cross Reference from PLAN TABLE Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Stmt Uniq : Ix Creator : Ix Name : EXPLAIN (OF=N) - total costs = SUs: 0 CPUms: 0.000000 EXPLAIN (OF=C) - total costs = SUs: 0 CPUms: 0.000000 Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (S)SQLText (C)IndexColH (B)IndexColC (U)SUniqueW (G)IXModel (P)ProgW (R)ProgS (E)Explain (F)SQLCom (Z)Zoom ------------------------------------------------------------------------------> C Program Uniq S Num OF AC MT I P SRTN SRTC Accessname CostSU ty co o f UJOG UJOG - ------------ ---- ----- -- -- -- - - ---- ---- ------------------ ----------- ZIVPBT01 FABC 455 N R 0 N S NNNN NNNN IXT001 1,844 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

EXPLAIN (OF=N) - Explain made by TurboTuneSQL Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL Batch ExplainUtility (options 1 and 3). Field Sus (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN (OF=C) - User plan table copied into TurboTuneSQL Sum of all Costs from User Plan Table. When TurboTuneSQL Batch ExplainUtility executes options 2 or 3, user plan table will be copied into TurboTuneSQL Plan Table and Flag OF will be stored as 'C'. Field Sus (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN Before - total costs (Flag OF is B ): Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL AutomaticIndexes Recommendation BEFORE starting recommendations. Field Sus (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN After - total costs (Flag OF is A ): Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL AutomaticIndexes Recommendation AFTER recommendations are completed. Field Sus (PROCSU - Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS - CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.


Uniq:Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.

S Num:SQL Statement Number from DB2 precompiler.

OF (Original Format):Y - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) WEREpreserved. Check utility parameter Explain Parameter Mark option.N - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) were NOTpreserved. Check utility parameter Explain Parameter Mark option.C - TurboTuneSQL Explain Utility has executed Plan Table Copy Function for this SQL.Original program work variables format has been preserved. Only most recent BIND-TIME has been copied from User Plan Table to TurboTuneSQL Plan Table. Originalprogram work variables format has been preserved. Check utility parameter ExecutionMode.


189

B/A - Explain created by TurboTuneSQL Automatic Index Recommendation B - Show Explains made BEFORE Index Recommendation A - Show Explains made AFTER Index RecommendationFor more information about SQL formats, go to program original format and non-original format.

ACty:Access TypeValues:I - Index Access. I1 – Index Scan, one-fetch. N - Index Scan, predicate contains IN Keyword. R - Tablespace Scan. M - Multiple Index Scan(Check Access types: MX, MI or MU). MX - Index Scan. MI - Intersection - multiple indexes. MU - Union - multiple indexes. T - Space Index (star join works file).DI - Intersection of DOCID DU - Union of DOCID DX - XML Index Scan E - Direct row access P - Dynamic pair-wise ix scan RW - Work file scan MQT V - By Buffer INSERT within SELECT blank - Not applicable.

MTco:Match Cols - This represents the number of index keys in an INDEX SCAN for thefollowing ACCESSTYPEs: I, I1, N, MX or DX.

IO:Index Only - When access to an index alone is enough to satisfy the request.Values: Y=YES N=NO

Pf:Will DB2 use prefetch (read pages in advance) S – Yes. Sequential method will be used L – Yes. Page list method will be used D – Yes. Dynamic prefetch may occur blank – Not. Prefetch will be used. But this can be changed at run-time. Dynamicprefetch)

SRTN (Sort N fields)U: UNIQ - Sort to remove duplicated rows (new table)J: JOIN - Table is sorted for Join method 2 or 4 (new table)O: ORDERBY - Sort by Order by Clause (or predicate) (new table)G: GROUPBY - Sort by Group by Clause (new table)

SRTC (Sort C fields)U: UNIQ - Sort to remove duplicated rows (composite table)J: JOIN - Table is sorted for Join method 1,2 or 4 (composite table)O: ORDERBY - Sort by Order by Clause (or predicate) (composite table)G: GROUPBY - Sort by Group by Clause (composite table)

Accessname:DB2 Index Name used for accesstypes: I, I1, N, DX, or MX.


190

CostSU:Total Service Units provided DB2 Explain Function.

Program Timestamp: DB2 Precompile Timestamp. Notes: (3) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken'using z/OS macros (the final computed value is very close to Precompile Timestamp).(2) Please, do not consider this date for remote programs, Triggers and forprograms extracted from SQL Cache Area

Explain Date: Shows date and time when this statement was explained by TurboTuneSQL batch utility.

Collection:DB2 Package Collection.Others valid values:– It can be #NODBRM plus DB2 PLAN if this programs is a DBRM (not package).– It can be blank for some Dynamic SQLs capture from DB2 traces– It will be DSNDYNAMICSQLCACHE if program was loaded from DB2 SQL Cache Area.


Gcol:Number which defines all groups of predicates found in this SQL statement. For moreinformation, please refer to SQL Statement Group Columns Algorithm.

For more information about Plan Table, please go to Appendix F- Plan tables description .

AVAILABLE SORT FIELDS Sort Field Field Header PROG Program UNIQ Uniq SNUM S Num OF OF (Original Format) ACTY ACTY (Access Type) MATCH MTCO (MacthCols) IO IO (Index Only) PF PF (Prefetch) SRTN SRTN / UJOG SRTC SRTC / UJOG ACCES Access name COSTSU CostSU PT Program Timestamp EXPD Explain Date COLL Collection GTAB Gtab GCOL Gcol Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


191


(S)SQL TextReport SRTX-SQL Text


(C)IndexColhReport HC01-History Index Columns

(B)IndexColCReport TC01-Table Index Columns

(F)SQLComReport SSCO-SQL Comment



(G)IXModelReport IXMD-Index Modeling (analysis of a single SQL)

(U)SUniqueWReport ST02 - Identical statements summary



192

EX02 - DB2 Plan Table Summary

This report shows DB2 Plan Table Summary a DB2 table, index or MQT. Views are not supported by this report.

A summary of all DB2 explain information about the current Table as well all othertables related to this table in SQL commands (joins, subselects).

Note:Fields related to CPU, WAIT and ELAPSED time are shown using hhhhhh:mm:ss.tttttttime format. All other fields are shown using TurboTuneSQL Numeric format. Please,refer to Appendix Numerical and Time formats for additional information.

SAMPLE REPORT


193

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 8 of 8 Option ===> EX02 - Plan Table Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Ix Creator : Ix Name : Explain Before - Total costs = SUs: 5,743 CPUms: 0.162000 Explain After - Total costs = SUs: 5,629 CPUms: 0.159000 Source/Explain Request Code:( DBBG / RCIX1 ) Line Actions ------------------------------------------------------------------ (Z)Zoom ----------------------------------------------------------------------------- C OF Access Type Match Cols Index Only SRTN SRTC SQLs - -- ----------- ---------- ---------- ---- ---- ----------- A N NNNN NNNN 2 A I 01 N NNNN NNNN 4 A I 01 Y NNNN NNNN 2 A R N NNNN NNNN 2 B N NNNN NNNN 2 B I 01 N NNNN NNNN 3 B I 01 Y NNNN NNNN 2 B R N NNNN NNNN 3 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

HEADER

EXPLAIN (OF=N) - Explain made by TurboTuneSQL Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL BatchExplain Utility (options 1 and 3). Field SUs (PROCSU – Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS – CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN (OF=C) - User plan table copied into TurboTuneSQL Sum of all Costs from User Plan Table. When TurboTuneSQL Batch ExplainUtility execute options 2 or 3, user plan table will be copied into TurboTuneSQL Plan Table and Flag OF will be stored as 'C'. Field Sus (PROCSU – Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS – CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN Before - total costs (Flag OF is B ): Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL AutomaticIndexes Recommendation BEFORE start recommendations. Field SUs (PROCSU – Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS – CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

EXPLAIN After - total costs (Flag OF is A ): Sum of all Costs by DB2 Explain Function executed by TurboTuneSQL AutomaticIndexes Recommendation AFTER recommendations done. Field SUs (PROCSU – Service Units) is shown using TurboTuneSQL Numerical format. Field CPUms (PROCMS – CPU) is shown using hhhhhh:mm:ss.ttt time format. For more information about SQL formats, go to program original format and non-original format.

ACty: Access Type. Access TypeValues:I - Index Access. I1 – Index Scan, one-fetch. N - Index Scan, predicate contains IN Keyword. R - Tablespace Scan. M - Multiple Index Scan(Check Access types: MX, MI or MU). MX - Index Scan. MI - Intersection - multiple indexes. MU - Union - multiple indexes. T - Space Index (star join works file).DI - Intersection of DOCID DU - Union of DOCID DX - XML Index Scan E - Direct row access P - Dynamic pair-wise ix scan RW - Work file scan MQT V - By Buffer INSERT within SELECT blank- Not applicable.


194

MTco:Match Cols - This represents the number of index keys in an INDEX SCAN for thefollowing ACCESSTYPEs: I, I1, N, MX or DX.




Total SQLs:Total different SQLs (based on TurboTuneSQL Statement Unique feature.

For more information, please go to Appendix F- Plan tables description .


AVAILABLE SORT FIELDS Sort Field Field Header OF OF (Original Format) ACES Accessname MATCH MTco (MacthCols) IO IO (Index Only) SRTN SRTN / UJOG SRTC SRTC / UJOG SQLS SQLs Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)




195

HC00 - Column Definition – Recommendation Log

DB2 Column definitions from TurboTuneSQL Index Recommendation results.

Note: Numeric fields are shown using TurboTuneSQL Numeric format. Please, refer toAppendix Numerical and Time formats for additional information.

SAMPLE REPORT


196

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 10 of 10 Option ===> HC00 - Column Definition - Recommendation Log Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table Owner : IVPQUAL Table Name: IVPTABLE_T001 Line Actions ------------------------------------------------------------------ (I)ColBelongIxH (J)ColBelongIxC (S)SQLs (Z)Zoom ------------------------------------------------------------------------- C ColName Data Type Null Length Precision Scale ColCardf - ------------------ ----------- ---- ------ --------- ----- ------------ COD_CLIENT1 DECIMAL N 4 6 0 9,999 COD_AREACLI DECIMAL N 4 6 0 9,999 COD_CLIENT1_T1 DECIMAL N 4 7 0 9,999 COD_CLIENT_NUL_T1 DECIMAL Y 4 6 0 9,999 NAME_CLIENT1 CHAR N 30 30 0 9,999 NAME_CLIENT_NULT1 CHAR Y 30 30 0 3,714 ADDRESS_CLIENT1 CHAR Y 30 30 0 3,714 SSN_CLIENT1 INTEGER N 4 10 0 9,999 SSN_CLIENT_SMALLT1 SMALLINT N 2 5 0 9,999 TOT_ROWS SMALLINT N 2 5 0 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Colname:Column Name.

Data Type:Column Data Type. Examples:INTEGER Large integerSMALLINT Small integerFLOAT Floating-pointCHAR Fixed-length character stringVARCHAR Varying-length character stringLONGVAR Varying-length character stringDECIMAL DecimalGRAPHIC Fixed-length graphic stringVARG Varying-length graphic stringLONGVARG Varying-length graphic stringDATE DateTIME TimeTIMESTMP TimestampBLOB Binary large objectCLOB Character large objectDBCLOB Double-byte character large objectROWIDRow ID data typeDISTINCT Distinct type XML XML data typeBIGINT Big integerBINARY Fixed-length binary stringVARBIN Varying-length binary stringDECFLOAT Decimal floating point

N:Null indicator.Y - null values can be acceptedN - null values can NOT be accepted

Length:Column Length in bytes.

Prec:Precision. Number of digits for this column.

Scale:Scale of decimal data.

ColCardf:Rows Cardinality for this column.

AVAILABLE FILTERS

Table Qualifier / Source Request Code Table Name(s) / Source Request Code


197

AVAILABLE SORT FIELDS Sort Field Field Header COLN ColName TYPE Data Type N N (Null indicater)LEN Length PREC Precision SCALE Scale COLC ColCardf Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(I)ColBelongIxHReport HI00-History Indexes

(J)ColBelongIxCReport TI00-Table Indexes



198

HC01 - Index Columns – Recommendation Log

DB2 Index Column definitions from TurboTuneSQL Index Recommendation results. Note: Numeric fields are shown using TurboTuneSQL Numeric format. Please, refer toAppendix Numerical and Time formats for additional information.

SAMPLE REPORT


199

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> HC01 - Index Columns - Recommendation Log Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table Owner : IVPQUAL Table Name: IVPTABLE_T001 Ix Creator : IVPQUAL Ix Name : IXTB101 Line Actions ------------------------------------------------------------------ (Z)Zoom ------------------------------------------------------------------------------> C ColName ColSeq O Data Type N Length Prec Scale ColCardf - ------------------ ------ - --------- - ------ ----- ----- --------------- COD_CLIENT1 1 A DECIMAL N 4 6 0 9,999 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Colname:Column Name

Colseq:Index column sequence definition number

O:Order. Valid values: A - Ascending D - DescendingBlank – Included columns

Data Type:Column Data Type. Examples: Decimal, Char, etc.

N:Null indicator. Valid values: Y – null values are acceptedN - null values are NOT accepted

Length:Column Length in bytes

Prec:Precision. Number of digits for this column.



Creator:Index Creator

IXName:Index Name.

AVAILABLE SORT FIELDS Sort Field Field Header COLN ColName COLS ColSeq O O (Column order) TYPE Data Type N N (Null indicater) LEN Length PREC Prec SCALE Scale COLC ColCardf Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


200




201

HI00 - Index Definition – Recommendation Log

DB2 Index definitions from TurboTuneSQL Index Recommendation results.


SAMPLE REPORT


202

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> HI00 - Index Definition - Recommendation Log Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table Owner : IVPQUAL Table Name: IVPTABLE_T001 Line Actions ------------------------------------------------------------------ (C)Columns (X)PlanTable (D)CatlgDep (H)PlanTableSum (Z)Zoom ------------------------------------------------------------------------------> C Creator IXName U C CRtio FullKeyCard Type Statstime - -------- ------------------ - - ----- ----------- ------- ------------------- IVPQUAL IXTB101 P N 100 9,999 REAL 2019-11-14-14.37.39 IVPQUAL IXTB105 U N 100 9,999 REAL 2019-11-14-14.37.39 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Creator:Index Creator

Name:Index Name. For VIRTUAL indexes (check column Type), the first 5 characters in the Index Namecorrespond to the Request Code for Index setup in the Automatic IndexRecommendation Utility.


D - Duplicates are allowed U - Unique P – Unique and primary indexC - Unique, used to enforce UNIQUE constraint or hash key

N - Unique, defined with UNIQUE WHERE NOT NULL R - Unique, enforce the uniqueness of a non-primary parent keyG - Unique, enforce the uniqueness of ROWIDX - Unique, enforce the uniqueness value of XML column

C:Indicate if this is a CLUSTER index. Values: N-NO / Y-YES

CRatio:Cluster Ratio

FullkeyCard:This is the number of distinct values for this Index

Type:Indicates if this index is:REAL – This index was copied from DB2 catalog SYSIBM.SYSINDEXES table toTurboTuneSQL Repository (History Tables)VIRTUAL - This index is a not REAL index. It is just a suggested index made byAutomatic Index Recommendation Utility

Statstime:Date and Time from last DB2 RUNSTATS Utility

FirstKeyCardf: Number of distinct values of the first key column.

IndexSpc: Name of the index space

Bpool: Name of the buffer pool used for the index

Nlevl: Number of levels in the index tree



203

Partitioned: Indicates whether this is a partitioned index: Valid values:

D - Data-partitioned secondary indexP - An index that is both partitioned and is a partitioning index

(index that is on a table that uses table-controlled partitioning) blank - This indexes is not partitioned

Compress: Indicates whether index compression is active:

N - Index compression is not activeY - Index compression is active.

Last Updated: This TimeStamp column indicates when this object was stored into TurboTuneSQL history tables.

AVAILABLE SORT FIELDS Sort Field Field Header CREATOR Creator IXNM Name (Index Name) U U (Index Type) C C (Clustering) CRTIO CRtio (Cluster Ratio) FKEY FullKeyCard TYPE Type (TurboTuneSQL Index Type) STAT Statstime CARDF FirKeyCardf INDEX IndexSpc BPOOL Bpool NLEVL Nlevl (Number of levels) NLEAF Nleaf (Number of active leaf) PART Partitioned COMP Compress UPD Last Updated Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(C)ColumnsReport HC01-History Index Columns (X) PlanTableReport EX01-Cross Reference from PLAN TABLE (D) CatlgDepReport SRIC-Shows Packages in Catalog (H)PlanTableSumReport EX02-Plan Table Summary (Z)Zoom Report ZOOM-Show extended fields

Note: To visualize reports through options (X) and (H), for virtual indexes with prefix name different as the explain Request Code in the filter, use by . Automatic index recommendations utility


204

HT00 - Table Definitions – Recommendation Log

This report shows all DB2 Tables which were found in all application programsaccessing DB2.

This information is based only on TurboTuneSQL Index Recommendation resultswhich contains all table definitions used in the recommendation..


SAMPLE REPORT


205

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> HT00 - Table Definitions - Recommendation Log Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Index ReqCode: RCIX1 Table Owner : IVPQUAL Table Name: IVPTABLE_T001 Database: Line Actions ------------------------------------------------------------------ (C)Columns (O)CoXref (I)Indexes (W)TableW (Q)TableC (F)ForeignK (H)PlanTableSum (X)PlanTable (M)FullPlanTBComp (S)SQLs (L)AllIxColum (D)CatlgDep (R)ProgS (Z)Zoom ------------------------------------------------------------------------------> C Name Owner T Rows Npages Statstime - ------------------ -------- - ----------- ----------- ---------------------- IVPTABLE_T001 IVPQUAL T 9,999 313 2019-10-02-09.37.01.749 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name:Table name.

Owner:Table Owner.

T: Object type: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY H History TableM Materialized query table P Implicit table created for XML columns T TABLE V VIEW X AUXILIARY TABLE Y SYNONYM

Rows:Total Table Rows from DB2 Cardf Columns.

NPages:Total Number of Active Pages.


Database: Database Name.

Tablespace: Tablespace Name.

Parents: Number of relationships in which the table is a dependent. It will be 0 in some cases:

–View–Alias–Created temporary table–Materialized query table

Child: Number of relationships in which the table is a parent. It will be 0 in some cases:



206

Audit: Value of the audit option: Value of the audit option:

A - All C - Change

blank- None or the row describes a view, an alias, or a created temporary table.

DataCap: Records the value of the DATA CAPTURE option for a table:

blank - No Y - Yes

For a created temporary table, DATACAPTURE is always blank.

Scheme: Encoding scheme for tables, views, and local aliases:

E - EBCDIC A - ASCII M - Multiple CCSID set or multiple encoding schemes M - Multiple CCSID set or multiple encoding schemes U - UNICODE blank- For remote aliases;

EDPROC: Name of the edit procedure. It will be blank in some cases:

–View–Alias–Table without an edit procedure

Last Updated: This TimeStamp column indicates when this object was stored into TurboTuneSQL history tables.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Table Name(s) - use wildcard '*' for tables started with a given name Table Name(s) and Owner Owner Database Name Database Name Range


207

AVAILABLE SORT FIELDS Sort Field Field Header NAME Name (Table Name) OWN Owner ROWS Rows NPAGES Npages STAT StatstimeDBASE Database Name TSPACE Tablespace Name PARENTS Parents CHILD Children AUDIT Auditing DTCAP Data capture SCHEME Encoding Scheme EDPROC EDPROC UPD Last update Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(C)ColumnsReport HC00-History Columns – Recommendation Log

(O)CoXrefReport SRCO-DB2 Columns Cross Reference

(I)IndexesReport HI00-History Indexes Recommendation Log

(W)TableWReport DB10-Table Summary

(Q)TableCReport TB00-Table Definition from DB2 Catalog

(S)SQLsReport SRPS-SQLs List

(F)ForeignKReport HTFK-Foreign Key Reference

(H)PlanTableSumReport EX02-Plan Table Summary

(X)Plan TableReport EX01-Cross Reference from PLAN TABLE




208

(B)IXRecomTurboTuneSQL Index Recommendation (manual and automatic) will be launched(report XMNU).

(L)AllIxColumnsReport HC01-History Index Columns - Recommendation Log

(D)CatlgDepReport SRIC-Shows Packages in Catalog

(R)ProgSReport SRPG-Program Source Information



209

IMSM - IMS Attach MPP

This report shows IMS transaction (Attach MPP) activies.


Note: Fields related to CPU, WAIT and ELAPSED time are shown using hhhhhh:mm:ss.tttttttime format. All other fields are shown using TurboTuneSQL Numeric format. Please,refer to Appendix Numerical and Time formats for additional information.

SAMPLE REPORT


210

TurboTuneSQL V120 ------------------- Online Report --------------------- 14:15Option ===> IMSM - IMS MPP SUMMARY Profile : IVP DB2 SSID : DBBG Filters -----------------------------------------------------------------------DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Plan Name : Correlation Name : Group Name : SSIDs : Line Actions ------------------------------------------------------------------(X)ProgXref (P)ProgW (D)Details (N)Expand (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------>C Trans T DB2 CPU (ALL) DB2 Wait DB2 Elapsed Occurrence - ----------- - ---------------- ---------------- ---------------- ----------- IMS1 A 1.458 0.009 1.570 1******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Trans:IMS Correlation.



DB2 Wait:Total DB2 Wait Time. Use option D for more information.DB2 Elapsed:Total DB2 ELAPSED Time.Occurrence:Total traces found.













211














212


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Correlation Name - use wildcard '*' for correlations started with a given name

AVAILABLE SORT FIELDS Sort Field Field Header TRANS Name (IMS transaction name)T T (Trace Source) CPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed OCCU Occurrence AELAPSED Application ElapsedINDB2 InDB2(Percentage Elapsed) ACPU Application CPU ACCOUNTED DB2 Not Accounted NACT NAct (Percentage DB2 Not Accounted) RD RD (RidPool) CPUSE DB2 CPU(SE/ZIIP) CPUALL DB2 CPU(ALL) ACPUSE Application CPU(SE/ZIIP) ACPUALL Aplication CPU(ALL) COMMITF CommitFreq SQLS SQLs LOG Log Written FET Fetch Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


213





(N)Expand Report AP01-Details Grouped By Date and Time (IMSM)



214

IXMD - Index Modeling (analysis by table - all SQLs)

This report will show several important metrics to help users to model new indexes. It can also help users to analyse just a single SQL.

This report are presented in 2 formats: Index Modeling (analysis by table - all SQLs – this report) Information is generate from all SQLs related for a given DB2 table. Because of ALL SQLs are being analysed together, a more detailed information can be provide by this report when compared to previous report. To open this report execute action line (G) in front a table. Index Modeling (analysis of a single SQL)

Information is generate from a single identical SQL for the current program being analysed. This report can help users to analyse the performance of a single SQL.To open this report execute action line (G) in front a program/unique.

SAMPLE REPORT


215

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 4 of 4 Option ===> IXMD - Index Modeling (analysis by table - all SQLs) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner/Name: IVPQUAL /Name: IVPTABLE_T001 Colname: Source Request Code:( DBBG ) Summarize: Y (Y/N) Show all columns N (Y/N) Total SQLs found in Source ---------------------------------------------------- Ins: 2 Upd: 5 Del: 1 Sel: 9 Total REAL-TIME Insert/Update/Delete Activity:--------------------------------- Ins: 0 Upd: 0 Del: 0 Reorg: 2019-09-24-13.59.29 Line Actions ------------------------------------------------------------------ (J)ColBelongIxC (R)ProgS (S)SQLs (Q)TableC (N)Expand (Z)Zoom ------------------------------------------------------------------------------> C Gcol Colname Score Index Match Select Update ColCardf Qtd Column List Column - ---- ------------------ ----------- ----- --------- ------ ------ ----------- ---- COD_CLIENT1 20,000 2 Full Matc 6 1 9,999 ---- NAME_CLIENT1 60,000 2 Full Matc 6 - 9,999 ---- ADDRESS_CLIENT1 29,716 - No Match - - 3,714 ---- SSN_CLIENT1 42,000 2 Parc Matc - - 9,999 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Total SQLs found in Source: Number of identicals SQLs splitted by SQL type.Ins (Insert) : Number of identicals INSERTsUpd (Update) : Number of identicals UPDATEsDel (Delete) : Number of identicals DELETEsSel (Select) : Number of identicals SELECTs

Total REAL-TIME Insert/Update/Delete Activity: Real time statistics for table space (SYSTABLESPACESTATS). The above number represent the number of records that have been inserted / updated / deleted into / from table space.

Ins (Inserted):The number of records inserted into the table space using the LOAD utility specified without the REPLACE option since the last time that the RUNSTATS utility was run, or since the object was created.

Upd (Updated):The number of rows that have been updated in the table space since the last time that the RUNSTATS utility was run, or since the object was created.

Del (Deleted):The number of records that have been deleted from the table space since the last time that the RUNSTATS utility was run, or since the object was created.

Reorg:The timestamp the REORG Utility was last run or the time when the table space /partition was created.

GCOL:Number which defines all groups of predicates found in this SQL statement. For moreinformation, please refer to SQL Statement Group Columns Algorithm.

Colname:Table Column Name.

Score: The total number of points that determines if this column is a good candidate to be an index.

Index Qtd: Number of DB2 indexes (from catalog) where this column was found.

Match Column: Compare sequential position where the column was coded with indexes. Full Match - All sequential position where this column was coded correspond to the

sequence of indexes. Parcial Match - Some sequential position where this column was coded correspond to

the sequence of indexes. No Match - No sequential position correspond to the sequence of indexes.

Select List: Number of identical SQLs where this column was selected by SELECT command.


216

Update Column: Number of identical SQLs where this column was updated by UPDATE command.

ColCardf: Rows Cardinality for this column.

Predicates Number of identicals SQLs where the following set of operator was found.If more than 999 SQLs is found, value 999 will be moved. The operators were grouped as follows:

Type Set of operators

EQ = , IN, IS, IS NOT

Range < , >, >=, <=, BETWEEN, LIKE, EXISTS

NEG <>, ^, ^=, ^>, ^<, !, !=, !>, !<, NOT BETWEEN, NOT LIKE, NOT EXISTS, NOT IN

SUB ANY, SOME, ALL, <=, BETWEEN or LIKE

Other Other operators

Sort Number of identicals SQLs where functions DIST/MIN/MAX/SUM/AVG or order by or group by clause was found. If more than 999 SQLs is found, value 999 will be moved.

Distribution of Where/On/Having (**) Show the sequential position and number of identicals SQLs found using where/on/having clause in that postion. Limitations: only the 6 first postions will be record and if more than 999 SQLs is found inthe position, value 999 will be moved.

Distribution of Order By/Group By (**) Show the sequential position and number of identicals SQLs found using order by/group by clause in that postion. Limitations: only the 6 first postions will be record and if more than 999 SQLs is found inthe position, value 999 will be moved. (**) Note: An '*' will appear if there is at leat one index that this column at this same position. Example: Index IX1 COLA ASC COLB ASC COLC ASC - If COLC appear in position 3, an '*' will appear - If COLC appear in position 2, an '*' will not appear


217

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters:

Summarize:Summarize by column or by gcol/column. Valid values: Y - Show just one line by column (synthetic view). N - Show all group of columns associate with this column.

Pred/Sort Only:

Decide if report must show all columns, even if they not appear in a predicate or sort condition (DIST/MIN/MAX/SUM/AVG/ORDERBY/GROUPBY). Valid values: Y - Show all columns, all situations. N - Only show columns that appear in a predicate/sort condition. Also show columns

that were udated by UPDATE SQL command.

AVAILABLE SORT FIELDS Sort Field Field Header GCOL Gcol COLN Colname SCORE Score IDXQT Index Qtd MATCH Match Column SELL Select List UPDC Update ColumnCOLC Colcardf EQ EQ RANGE Range NEG NEG SUB SUB OTHER Other DIST Dist MIN MIN MAX MAX SUM SUM AVG AVG ORD ORD GRP GRP Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


218


(I)ColumnIndexHReport HI00-History Indexes – Recommendation Log

(J)ColumnIndexCReport TI00-Table Indexes – Recommendation Log



(Q)TableCReport TB00-Table Definition by DB2 Catalog

(N)Expand Report IXMD-Index Modeling (analysis by table - all SQLs)



219

IXMD - Index Modeling (analysis of a single SQL)

This report will show several important metrics to help users to model new indexes. It can also help users to analyse just a single SQL.

This report are presented in 2 formats: Index Modeling (analysis of a single SQL – this report)

Information is generate from a single identical SQL for the current program being analysed. This report can help users to analyse the performance of a single SQL.To open this report execute action line (G) in front a SQL statement. Index Modeling (analysis by table - all SQLs) Information is generate from all SQLs related for a given DB2 table. Because of ALL SQLs are being analysed together, a more detailed information can be provide by this report when compared to previous report. To open this report execute action line (G) in front a table.

SAMPLE REPORT


220

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> IXMD - Index Modeling (analysis of a single SQL) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: ZIVPBT07 Uniq: 019003B6 Group Col: AE7DC478 Colname: Source Request Code:( DBBG ) Summarize: Y (Y/N) Show all columns N (Y/N) Line Actions ------------------------------------------------------------------ (J)ColBelongIxC (R)ProgS (S)SQLs (Q)TableC (N)Expand (Z)Zoom ------------------------------------------------------------------------------> C Gcol Colname Name Score Index Summary Qtd Where Sort Match - ---- ------------------ ------------------ ----------- ----- ----- ---- ----- ---- ADDRESS_CLIENT1 IVPTABLE_T001 14,113 - Y N N ---- SSN_CLIENT1 IVPTABLE_T001 20,000 2 Y N F ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

GCOL:Number which defines all groups of predicates found in this SQL statement. For moreinformation, please refer to SQL Statement Group Columns Algorithm.


Name:Table Name.

Score: The total number of points that determines if this column is a good candidate to be an index.

Index Qtd: Number of DB2 indexes (from catalog) where this column was found.

Summary:Show a short summary of some important indicators. Where - Indicate if column was found in where/on/having clause. Y - Column was found. N - Column was not found. Sort - Indicate if column was found under functions DIST/MIN/MAX/SUM/AVG or order by or group by clause was found. Y - Column was found N - Column was not found. Match - Compare sequential position where the column was coded with indexes. Valid values: F - All sequential position where this column was coded correspond to the sequence of indexes. P - Some sequential position where this column was coded correspond to the sequence of indexes. N - No sequential position correspond to the sequence of indexes. Predicates Number of identicals SQLs where the following set of operator was found.If more than 999 SQLs is found, value 999 will be moved. The operators were grouped as follows:

Type Set of operators

EQ = , IN, IS, IS NOT

Range < , >, >=, <=, BETWEEN, LIKE, EXISTS

NEG <>, ^, ^=, ^>, ^<, !, !=, !>, !<, NOT BETWEEN, NOT LIKE, NOT EXISTS, NOT IN

SUB ANY, SOME, ALL, <=, BETWEEN or LIKE

Other Other operators

Sort Number of identicals SQLs where functions DIST/MIN/MAX/SUM/AVG or order by or group by clause was found. If more than 999 SQLs is found, value 999 will be moved.


221

Distribution of Where/On/Having (**) Show the sequential position and number of identicals SQLs found using where/on/having clause in that postion. Limitations: only the 6 first postions will be record and if more than 999 SQLs is found inthe position, value 999 will be moved.

Distribution of Order By/Group By (**) Show the sequential position and number of identicals SQLs found using order by/group by clause in that postion. Limitations: only the 6 first postions will be record and if more than 999 SQLs is found inthe position, value 999 will be moved. (**) Note: An '*' will appear if there is at leat one index that this column at this same position. Example: Index IX1 COLA ASC COLB ASC COLC ASC - If COLC appear in position 3, an '*' will appear – If COLC appear in position 2, an '*' will not appear

ColCardf: Rows Cardinality for this column.

Owner:Table Owner.

Select List: Number of identical SQLs where this column was selected by SELECT command.

Update Column: Number of identical SQLs where this column was updated by UPDATE command.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters:

Summarize:Summarize by column or by gcol/column. Valid values: Y - Show just one line by column (synthetic view). N - Show all group of columns associate with this column.

Pred/Sort Only:

Decide if report must show all columns, even if they not appear in a predicate or sort condition (DIST/MIN/MAX/SUM/AVG/ORDERBY/GROUPBY). Valid values: Y - Show all columns, all situations. N - Only show columns that appear in a predicate/sort condition. Also show columns

that were udated by UPDATE SQL command.


222

AVAILABLE SORT FIELDS Sort Field Field Header GCOL Gcol COLN Colname NAME Table Name SCORE Score IDXQT Index Qtd WHERE Summary Where Indicator SORT Summary Sort Indicator MATCH Summary Match Indicator SELL Select List UPDC Update Column COLC Colcardf EQ EQ RANGE Range NEG NEG SUB SUB OTHER Other DIST Dist MIN MIN MAX MAX SUM SUM AVG AVG ORD ORD GRP GRP



(I)ColumnIndexHReport HI00-History Indexes – Recommendation Log

(J)ColumnIndexCReport TI00-Table Indexes



(Q)TableCReport TB00-Table Definition by DB2 Catalog

(G)IXModelTBReport IXMD-Index Modeling (analysis by table - all SQLs)



223

MORD - SQL Details

This report will show more details about previous object.

The information shown here is obtained from other monitors. Also, this report will beavailable only if add-on feature TurboTuneSQL-MONITOR ACCESS was acquired.



SAMPLE REPORT


224

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 29 of 34 Option ===> MORD - More Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Program : DSNA6DB2 Stmt Uniq: Database: Group Tab : Group Col : WsTrans/Corr: Table Owner: First Tabl: Stmt Num : Stmt id: 0000000000000008411 ------------------------------------------------------------------------------- ---------------------------SQL CACHE AREA--------------------------- TOTAL SQLs EXECUTED: 7,343 DB2 ELAPSED TIME: 16.572279 DB2 CPU TIME: 13.744877 DB2 CPU TIME (AVG PER SQL): 0.001871 ROWS_PROCESSED: 7,343 ROWS_EXAMINED: 7,343 NUMBER OF SORTS: 0 INDEX SCAN: 7,343 TABLESPACE SCAN: 0 TOTAL GETPAGES: 22,029

FIELD DESCRIPTIONS – SQL CACHE AREA

















TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done. TOTAL RIDPOOL NO STORAGE: Total access using RID List has failed because of size of RIDPOOL. If its possible,increase RIDPOOL size. A DB2 Table Scan will be done.


225


_DB2 WAIT SYNC I/O DATABASE:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables.




_DB2 WAIT TIME DATASHARING GLOBAL CONTENTIONTotal waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks.

_DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

_DB2 WAIT TIME OTHER WRITES:

Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported








TOTAL WORK RIDPOOL OVERFLOW BY NO STORAGE:


226

TOTAL WORK RIDPOOL OVERFLOW BY LIMIT :

TOTAL JOIN RIDPOOL OVERFLOW BY STORAGE:

TOTAL JOIN RIDPOOL OVERFLOW BY LIMIT:

TOTAL MIAP RIDPOOL OVERFLOW LIMIT:



227

NRCO - DB2 CORRELATION Summary (near real-time)

This report will show an overview of all DB2 Correlation Activities found in SQL CacheArea.

This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired. The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository). The following are examples of DB2 Correlation names: CICS Transaction, Jobname, TSO User, etc.



SAMPLE REPORT


228

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> NRCO - DB2 CORRELATION Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: WsTrans/Corr: Program Name: Line Actions ------------------------------------------------------------------ (S)SQLs (D)Detail (N)Expand (P)ProgN (X)XrefN (Z)Zoom ------------------------------------------------------------------------------> C WsTrans/Corr Connection DB2 CPU(ALL) %CPUA DB2 Elapsed %ELAP - -------------- ----------- ---------------- ----- ---------------- ----- N/A CACHE STATI 1.464 99.9 1.573 99.9 ZIVPBD01 TSO F/B 0.000 0.1 0.001 0.1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


DB2 CPU:Total DB2 CPU time spent in all processors (CP plus SE/ZIIP).




AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID(s) WsTrans/Corr

AVAILABLE SORT FIELDS Sort Field Field Header WSTRANS WsTrans/CorrCONN ConnectionCPU DB2 CPU ELAPSED DB2 Elapsed



229


(S)SQLsReport NRS1-Statements Summary (near real-time)

(D)Details Report MORD-More details

(N)Expand Report NRDT-Show details grouped by date and time

(P)ProgN Report NRPG-Program Summary (near real-time)

(X)XrefN Report NRXR-General Cross Reference (near real-time)

(Z)Zoom



230

NRDB - Database Summary (near real-time)

This report shows summary information about databases accessed by executed SQLfound in SQL Cache Area.

This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired. The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository).



SAMPLE REPORT


231

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> NRDB - Database Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Database Name: Line Actions ------------------------------------------------------------------ (S)SQLs (X)TableN (Q)TableC (P)ProgN (D)Detail (N)Expand (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C Name DB2 CPU(ALL) %CPUA DB2 Elapsed %ELAP DB2 Wait - -------- ---------------- ----- ---------------- ----- ---------------- IVPDB 1.465 100 1.574 100 0.005 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name:Database name.


%CPUA: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) andthe sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - this object in fact represents less than 40% (maximum screen lines

WAS exceeded)



%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <.

Examples: 80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - this object in fact represents less than 80%

(maximum screen lines WAS exceeded)


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID(s) Name


232

AVAILABLE SORT FIELDS Sort Field Field Header Name Database nameCPU DB2 CPU ELAPSED DB2 Elapsed WAIT DB2 WaitSQLS SQLs





(T)TableHReport HT00-Table Definition from History




(Z)Zoom



233

NRDT - Shows Details Grouped by Date and Time (near real-time)

This report will show details for the selected object grouped by date and time.

This report will be available only if add-on feature TurboTuneSQL-REAL TIME CACHEwas acquired.

The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository). Summarize by (option to summarize DB2 time values based on the original display): M - Overall DB2 CPU and Elapsed Time by YEAR/MONTH D - Overall DB2 CPU and Elapsed Time by YEAR/MONTH/DAY Y - Overall DB2 CPU and Elapsed Time by YEAR ' ' - Blank to switch back to the original objects displayed for this report. Default isordered by Date and TimeR.

Notes: 1 - For summarize by option M,D,Y, field TimeR are not applicable.

2 - Fields related to CPU, WAIT and ELAPSED time are shown using hhhhhh:mm:ss.tttttttime format. All other fields are shown using TurboTuneSQL Numeric format. Please,refer to Appendix Numerical and Time formats for additional information.

3 - When data comes from SQL Cache Area (dynamic SQLs stored in EDM Pool),program name, CPU and other informations may not be accurate (DB2 may record SQLactivities under a wrong program name). To avoid a prepare execution, DB2 searchesfor an 'identical' SQL in the cache regardless for a different program or statementnumber. When this happens, all computed values will be stored for the program andstatement number found in Cache and not for the original executor.

SAMPLE REPORT


234

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> NRDT - Show Details Grouped by Date and Time Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Program : ZIVPBT01 Stmt Uniq: Database: Group Tab : Group Col : WsTrans/Corr: Table Owner: Table Name: Summarize by: (M/D/Y) Line Actions ------------------------------------------------------------------ (S)SQLs (D)Details (L)XrefN (U)StatOverv (Z)Zoom ------------------------------------------------------------------------------> C DateR TimeR DB2 CPU DB2 Elapsed CPU avg SQL SQLs - ---------- -------- ---------------- ---------------- ----------- ----------- 2019-11-13 06.30.00 1.454355 1.561457 0.727177 2 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

DateR: Start/End Date when this object was updated in cache - rounded

TimeR: Start/End Time when this object was updated in cache - rounded

DB2 CPU: Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP).





AVAILABLE SORT FIELDS Sort Field Field Header ---------- ------------- DATE - Date TIME - Time CPU - DB2 CPU ELAPSED - DB2 Elapsed CPUAVG - DB2 CPU Avg SQLS - SQLs WAIT - DB2 Wait




(D)Details Report ACTO-Deep Accounting Details

(L)XrefN Report NRXR-General Cross Reference (near real-time)

(Z)Zoom



235

NRPG - Programs Summary (near real-time)

This report will show an overview of all DB2 programs found in SQL Cache Area. This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired.

The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository).



SAMPLE REPORT


236

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 12 of 12 Option ===> NRPG - Programs Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Program : Stmt Uniq: Database: Group Tab : Group Col : WsTrans/Corr: Table Owner: First Table: Line Actions ------------------------------------------------------------------ (S)SQLs (D)Details (B)ProgC (R)ProgS (P)ProgW (C)CorrelationN (X)XrefN (N)Expand (E)Explain (U)StatOverv (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C Program DB2 CPU(ALL) %CPUA DB2 Elapsed %ELAP DB2 Wait - -------- ---------------- ----- ---------------- ----- ---------------- ZIVPBT01 1.454 99.2 1.561 99.1 0.005 ZIVPBT02 0.002 0.1 0.002 0.1 0.000 ZIVPBT10 0.001 0.1 0.001 0.1 0.000 ZIVPBT06 0.001 0.1 0.001 0.1 0.000 ZIVPBT03 0.001 0.1 0.001 0.1 0.000 DSN@EP2L 0.000 0.1 0.001 0.1 0.000 ZIVPBT08 0.000 0.1 0.001 0.1 0.000 ZIVPBT09 0.000 0.1 0.001 0.1 0.000 ZIVPBT07 0.000 0.1 0.000 0.1 0.000 ZIVPBT04 0.000 0.1 0.000 0.1 0.000 ZIVPBT05 0.000 0.1 0.000 0.1 0.000 DSN@EP2L 0.000 0.0 0.000 0.0 0.000 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


DB2 CPU:Total DB2 CPU time spent in all processors (CP plus SE/ZIIP).

%CPUA: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) and the sum of all displayed lines.


%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines.




AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) Program Name SSID(s) Request Code Source Explain Code Source Max Objects

AVAILABLE SORT FIELDS Sort Field Field Header PROG Program NameCPU DB2 CPU WAIT DB2 Wait ELAPSED DB2 Elapsed SQLS SQLs



237




(B)ProgC Report SRIC-Program List Catalog

(R)ProgS Report SRPG-Program Source Information


(C)CorrelationN Report NRCO-Correlation Summary

(X)XrefN Report NRXR-General Cross Reference (near real-time)


(E)Explain Report SREX-Statements Explain Information

(Z)Zoom



238

NRS1 - SQLs Summary (near real-time)

This report shows information about executed SQL statements grouped by programname, statement number and Unique number (according to product SQL inventoryfacility).

This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired. The information is based on SQL Cache Area. The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository).



SAMPLE REPORT


239

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 14 of 14 Option ===> NRS1 - SQLs Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Program : WsTrans/Corr: Table Owner : Table(first): Database: Line Actions ------------------------------------------------------------------ (D)Details (S)SQLText (E)Explain (L)XrefN (N)Expand (F)SQLCom (W)SQLW (B)ProgC (R)ProgS (P)ProgN (U)SUniqueN (X)SSimilN (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C Program Uniq T S Num Desc Gtab Gcol Gsrt DB2 CPU(ALL) %CPUA SQLs - -------- ---- - ----- ------ ---- ---- ---- --------------- ----- ----------- ZIVPBT01 90BB S 218 REFRES 90E4 0000 0000 1.45 99.2 1 ZIVPBT10 5A37 S 227 UPDATE E24D 32D0 0000 0.00 0.1 1 ZIVPBT02 4173 S 225 INSERT E24D 0000 0000 0.00 0.1 1 ZIVPBT06 5A37 S 226 UPDATE E24D 32D0 0000 0.00 0.1 1 ZIVPBT03 85E2 S 198 OPEN E24D 0000 0000 0.00 0.1 1 DSN@EP2L A816 D 1846 OPEN 90CE CF61 0000 0.00 0.1 1 ZIVPBT08 5A37 S 231 UPDATE E24D 32D0 0000 0.00 0.1 1 ZIVPBT09 5A37 S 233 UPDATE E24D 32D0 0000 0.00 0.1 1 DSN@EP2L 2CD2 S 1415 SET 0000 0000 0000 0.00 0.0 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Program:Program name.


T:Trace source. 'D' - This statement is Dynamic 'S' - This statement is Static Bind

S Num: SQL statement number from DB2 precompiler. DB2 SQL cache area doesn't record cursor commands:fetch/close/etc SQL Open is an exception. See below: -For static SQLs: SQL open command will be represented using statement number of SQL Declare. -For dynamic SQL: SQL open command will be represented using statement number of SQL Prepare.

Desc: Short SQL Statement description. Examples: Select, Insert. For SQLs with cursors, ONLY SQL open will be recorded by traces.

Gtab: Unique number that defines all group of tables found in this SQL.

Gcol: Unique number that defines all group of predicates found in this SQL.

Gsrt: Unique number that defines all group of columns in Order by or Group by clause

DB2 CPU(ALL): Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP).

%CPUA: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - it means, this object in fact represents less than 40% (maximum screen lines WAS exceeded) Value N/A means that this SQL may have executed but TurboTuneSQL was not able tocapture it from traces.

SQLs: Total times that sql statement was executed since when trace was turned on; For SQLs with cursors, this is the number of OPENs.


240


%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - it means, this object in fact represents less than 80% (maximum screen

lines WAS exceeded)

CPU avg SQL: Total DB2 CPU Average per SQL. Value N/A means that this SQL may have executed but TurboTuneSQL was not able tocapture it from traces.

DB2 Wait : Total DB2 Wait per command.

Owner: Table Qualifier of the table referenced.

Name (first table): First Table name referenced in the SQL statement. It may be any object name (table, view, synonym, etc).

C: Indicates if a SQL COMMENT was created for the statement. Valid Values: '*' - SQL COMMENT found '?' - SQL COMMENT may have been created by line command 'F' blank - SQL COMMENT was not found

Program Timestamp: DB2 Precompile Timestamp. Notes: (1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken' using z/OS macros (the final computed value is very close to Precompile Timestamp). (2) Please, do not consider this date for remote programs, Triggers and for programs with dynamic SQLs extracted from Cache


241

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID (DB2 ssid) Program (Program name – wildcard is allowed) Uniq: (Number that identifies 'IDENTICAL' SQLs (share the same SQL Text).WsTrans/Corr: Transaction name. Group Tab: Unique number that defines a group of tables Group col: Unique number that defines all group of predicates in this SQL. Table owner. First owner of the first table referenced in SQL. Name (first table) Database (Database name)

AVAILABLE SORT FIELDS Sort Field Field Header----------- --------------- PROG - Program SNUM - S Num T - T (Trace Source) UNIQ - Uniq DESC - Desc GTAB - Gtab GCOL - Gcol GSRT - Gsrt CPU - DB2 CPU(ALL) SQLS - SQLs ELAPSED - DB2 Elapsed CPUAVG - DB2 CPU Avg WAIT - DB2 Wait STMT - Stmt Id OWN - Owner NAME - Table Name COLL - Collid C - Comment Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


242



(S)SQLText Report STCX-SQL text

(E)ExplainReport SREX-Statement Explain Information

(L)XrefNReport NRXR-General Cross Reference (near real-time)

(N)ExpandReport NRDT-Show details grouped by date and time

(F)SQLComReport SSCO-User SQL Comments

(W)SQLWReport ST01-Statements Summary

(B)ProgCReport SRIC-Program list catalog


(P)ProgNReport NRPG-Program Summary (near real-time)

(U)SUniqueNReport NRS2-Identicals SQLs Summary (near real-time)

(X)SSimilNReport NRS3-SSimilar SQLs Summary (near real-time)

(Z)Zoom



243

NRS2 - SQLs Summary (near real-time)

This report shows information about executed SQL statements grouped by IdenticalSQLs (according to product SQL inventory facility).




SAMPLE REPORT


244

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 10 of 10 Option ===> NRS2 - Identicals SQLs Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Stmt Uniq: Line Actions ------------------------------------------------------------------ (S)SQLs (D)Details (N)Expand (R)ProgS (P)ProgN (L)XrefN (U)SUniqueW (Z)Zoom ------------------------------------------------------------------------------- C Uniq DB2 CPU(ALL) CPU avg SQL DB2 Elapsed Dprog SQLs - ---- ---------------- -------------- ---------------- ----- ----------- 90BB 1.453 1.453622 1.560 1 1 5A37 0.005 0.001105 0.006 5 5 4173 0.001 0.001217 0.001 1 1 85E2 0.001 0.001129 0.001 1 1 A816 0.000 0.000996 0.001 1 1 35B4 0.000 0.000852 0.000 1 1 16B2 0.000 0.000804 0.000 1 1 29B2 0.000 0.000754 0.000 1 1 AAFA 0.000 0.000733 0.000 1 1 2CD2 0.000 0.000200 0.000 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


DB2 CPU(ALL): Total DB2 CPU spent in all processors (CP plus SE/ZIIP).

CPU avg SQL: Total DB2 CPU Average per SQL. Value N/A means that this SQL may have executed but TurboTuneSQL was not able to capture it from traces.


Dprog: Total number of distinct programs using this same SQL.


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID (DB2 ssid) Program (Program name – wildcard is allowed) Uniq: (Number that identifies 'IDENTICAL' SQLs (share the same SQL Text).

AVAILABLE SORT FIELDS Sort Field Field Header----------- ---------------- UNIQ - Uniq CPU - DB2 CPU(ALL) CPUAVG - DB2 CPU AvgELAPSE - DB2 ElapsedDPROG - DprogSQLS - SQLs Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


245



(S)SQLs Report NRS1-Statements Summary (near real-time)

(N)ExpandReport NRDT-Show details grouped by date and time



(L)XrefNReport NRXR-General Cross Reference (near real-time)

(U)SUniqueWReport ST02-Identicals SQLs Summary

(Z)Zoom



246

NRS3 - Similar SQLs Summary (near real-time)

This report shows information about executed SQL statements grouped by SimilarSQLs (according to product SQL inventory facility).




SAMPLE REPORT


247

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 8 of 8 Option ===> NRS3 - Similar SQLs Summary (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Group Tab : Group Col: Line Actions ------------------------------------------------------------------ (S)SQLs (P)ProgN (D)Details (X)SSimilW (Z)Zoom ------------------------------------------------------------------------------- C Gtab Gcol DB2 CPU(ALL) CPU avg SQL DB2 Elapsed Dprog SQLs - ---- ---- ---------------- -------------- ---------------- ------ ----------- 90E4 0000 1.453 1.453622 1.560 1 1 E24D 32D0 0.007 0.001026 0.008 7 7 E24D 0000 0.001 0.001217 0.001 1 1 E24D 0000 0.001 0.001129 0.001 1 1 90CE CF61 0.000 0.000996 0.001 1 1 CB85 B33D 0.000 0.000754 0.000 1 1 90E4 901C 0.000 0.000733 0.000 1 1 0000 0000 0.000 0.000200 0.000 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS




CPU avg SQL: Total DB2 CPU Average per SQL.


Dprog: Total number of distinct programs using this same SQL.


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID (DB2 ssid) Group Tab: (Unique number that defines a group of tables) Group col: (Unique number that defines all group of predicates in this SQL.)

AVAILABLE SORT FIELDS Sort Field Field Header----------- --------------- GTAB - Gtab GCOL - Gcol CPU - DB2 CPU(ALL) CPUAVG - DB2 CPU Avg ELAPSED - DB2 Elapsed DPROG - Dprog SQLS - SQLs Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


248


(S)SQLs Report NRS1-Statements Summary (near real-time)



(X)SSimilWReport ST03-Similar Statements Summary

(Z)Zoom



249

NRTB - Table Summary (first table referenced – near real-time)

This report shows summary information about objects accessed by executed SQLfound in SQL Cache Area.

This report will be available only if add-on feature TurboTuneSQL-REAL TIMECACHE was acquired. Object can be tables, views, alias, synonym. Only the first object and Ownerreferenced in the SQL statement will appear. The information provided here is near real time (from time to time, an started taskcollects data from SQL Cache Area and stores it into product repository).



SAMPLE REPORT


250

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 4 of 4 Option ===> NRTB - Table Summary (First table. Near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID: Table Owner: First Table Name: DBname: Line Actions ------------------------------------------------------------------ (S)SQLs (Q)TableC (U)StatOverv (N)Expand (P)ProgN (X)XrefN (D)Detail (Z)Zoom ------------------------------------------------------------------------------> C Name (first table) Owner DB2 CPU(ALL) %CPUA DB2 Elapsed %ELAP - ------------------ -------- ---------------- ----- ---------------- ----- IVPTABLE_MQT IVPQUAL 1.454 99.2 1.561 99.1 IVPTABLE_T001 IVPQUAL 0.009 0.7 0.011 0.7 TAB1 IVPQUAL 0.000 0.1 0.001 0.1 IVPTABLE_T002 IVPQUAL 0.000 0.1 0.000 0.1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name (first table):Database name.

Owner:Table Owner.

DB2 CPU(ALL):Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP).

%CPUA: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - this object in fact represents less than 40% (maximum screen lines WAS exceeded) DB2 Elapsed:Total DB2 ELAPSED Time spend by this SQL in all processors.

%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <.

Examples: 80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - this object in fact represents less than 80% (maximum screen lines

WAS exceeded)



AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) SSID(s) Table Owner Table Name (first)


251

AVAILABLE SORT FIELDS Sort Field Field Header Name Table nameOWN Table OwnerCPU DB2 CPU ELAPSED DB2 Elapsed WAIT DB2 WaitSQLS SQLs








(Z)Zoom



252

NRXR - General Cross Reference (near real-time)

This report shows information about executed SQL statements. No grouping is doneto allow general cross reference.




SAMPLE REPORT


253

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 13 of 13 Option ===> NRXR - General Cross Reference (near real-time) Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR: 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Static: Y Dynamic: N Program : WsTrans/Corr: First Table: UserId: WsNm: Stmt Uniq : Database: SSID: Parameters -------------------------------------------------------------------- Field Target : CPU - DB2 CPU TIME Minimum Value: 0000.000000 Line Actions ------------------------------------------------------------------ (D)Details (S)SQLText (E)Explain (L)SQLXref (G)IXModel (Y)SQLs (P)ProgW (R)ProgS (U)SUniqueW (X)SSimilW (F)SQLCom (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C Program T Uniq S Num Desc Gtab Gcol Gsrt DB2 CPU(ALL) %CPUA SQLs - -------- - ---- ----- ------ ---- ---- ---- --------------- ----- ----------- ZIVPBT01 S 90BB 218 REFRES 90E4 0000 0000 1.453622 45.4 1 ZIVPBT10 S 5A37 227 UPDATE E24D 32D0 0000 0.001607 0.2 1 ZIVPBT02 S 4173 225 INSERT E24D 0000 0000 0.001217 0.1 1 ZIVPBT06 S 5A37 226 UPDATE E24D 32D0 0000 0.001166 0.1 1 ZIVPBT03 S 85E2 198 OPEN E24D 0000 0000 0.001129 0.1 1 ZIVPBT04 S 16B2 225 DELETE E24D 32D0 0000 0.000804 0.1 1 DSN@EP2L S 2CD2 1415 SET 0000 0000 0000 0.000200 0.0 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Program:Program name.

T:Trace source. 'D' - This statement is Dynamic 'S' - This statement is Static Bind


S Num: SQL statement number from DB2 precompiler. DB2 SQL cache area doesn't record cursor commands:fetch/close/etc SQL Open is an exception. See below: -For static SQLs: SQL open command will be represented using statement number of SQL Declare. -For dynamic SQL: SQL open command will be represented using statement number of SQL Prepare.

Desc: Short SQL Statement description. Examples: Select, Insert. For SQLs with cursors, ONLY SQL open will be recorded by traces.



Gsrt: Unique number that defines all group of columns in Order by or Group by clause


%CPUA: Percentage between DB2 CPU spent in all processors (DB2 CPU ALL) and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 40.0 - 40% (maximum screen lines was NOT exceeded) <40.0 - it means, this object in fact represents less than 40% (maximum screen lines WAS exceeded) Value N/A means that this SQL may have executed but TurboTuneSQL was not able tocapture it from traces.


Stmt Id: Dynamic: Unique statement identifier in prepared statement cache Static : Unique Id of statement in DB2 catalog


254


%ELAP: Percentage between DB2 Elapsed time and the sum of all displayed lines. If the message MAX SCREEN LINES WAS EXCEEDED is issued, this percentage value will be approximate and will be prefixed with character <. Examples: 80.0 - 80% (maximum screen lines was NOT exceeded) <80.0 - it means, this object in fact represents less than 80% (maximum screen lines WAS exceeded)

CPU avg SQL: Total DB2 CPU Average per SQL. Value N/A means that this SQL may have executed but TurboTuneSQL was not able tocapture it from traces.

DB2 Wait : Total DB2 Wait per command.

Owner: Table Qualifier of the table referenced.

Table: First Table name referenced in the SQL statement. It may be any object name (table, view, synonym, etc).

RID Storage: Number of times of RID that was not used because the storage was not enough.

Getpage Requests: The number of GETPAGE requests. This space will also display the correspondent information accordingly to the Field Target below: READ, PARL, ROWP, ROWE, SORT, WRIT, RIDL, LOCK, WAIT, SERV, GLOC, RDOT, WTOT, LATC Please, check the TurboTuneSQL User Guide for more details.

WsTrans/Corr: Transation Name - Value provided on RRS signon.

WsUserId: End User Id - Value provided on RRS signon.

WsName/Cn: Workstation Name - Value provided on RRS signon.

TBSpace Scan: Number of Table Space Scans.

Index Scan: Number of Index Scans.

Time Update in CACHE: Date/time when statement statistics was updated.


255

Snapshot Time (time update rounded): Date/time when statement statistics was updated (rounded).

Collid: DB2 Package Collection (from DB2 catalog) For Dynamic SQLs always 'DSNSDYNAMICSQL'

SSID: DB2 SSID.

Started Time Trace: Date/time when statistics collection has begun. Data collection begins when IFCID 318is started.

Time Insert in CACHE: Date/time when statement was inserted into cache.

Program Timestamp: DB2 Precompile Timestamp. Notes: (1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken' using z/OS macros (the final computed value is very close to Precompile Timestamp). (2) Please, do not consider this date for remote programs, Triggers and for programs with dynamic SQLs extracted from Cache

Hold: Cursor Hold. Valid Values: 'Y' - Statement was prepared for a held cursor 'N' - Statement was not prepared for a held cursor ' ' - Static SQLs from SQL Cache Area

Repl: Cache literal replacement indicator blank - no literal replacement 'R' - literals were replaced and were done 'D' - Same as 'R' but cached statement is a duplicated cache entry instance

Drop: This field indicates if the statement has been invalidated. Valid values: 1 - Statement has been invalidated: drop or alter was issued2 - Statement has been invalidated: revoke was issued 3 - Statement has been invalidated: removed from cache (LRU)4 - Statement has been invalidated: RUNSTATS '' - Statement is valid (or is a STATIC statement)

Degree: Current Degree - special register value Valid Values: 'A' - Current Degree is 'ANY' '1' - Current Degree is '1' blank - Static SQL from SQL Cache Area


256

Err Msgs: When 'Flag Error' field contains Y or W, this 7 bytes field indicates the the specific errorcode flagged by TurboTuneSQL. Valid Values:

blank - No Extract Errors. COMP=nn - compaction error, followed by Return Code. ERRCONV - Error on Unicode conversion to Ebcdic. Check Profile EBCDIC

parameter.NOTFND1 - Statement not found (rc=01). NOTFND2 - Statement not found (rc=01). NOTFND3 - Statement not found (rc=01). PKST=nn - Error on routine @SPK. Refer to Messages manual. Search for message @SPK0nn. SQD>32K - Statement exceeds 32K. SQL>32K - Statement exceeds 32K. TBHOST - Profile parameter #ENTRIES TB_HOST must be increased.

C: Indicates if a SQL COMMENT was created for the statement. Valid Values: '*' - SQL COMMENT found '?' - SQL COMMENT may have been created by line command 'F' blank - SQL COMMENT was not found

Prog Orig: Program name original. For remote DRDA programs,TurboTuneSQL may replace original program name by WsTrans/Corr field.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object was updated in cache - rounded) TimeR (Start/End Time when this object was updated in cache - rounded) Static (list static SQLs. Only DB2 V10 NFM and up Y – List cached static SQLs N – Do not list cached static SQLs ) Dynamic (list dynamic SQLs. Y – List cached dynamic SQLs N – Do not list cached dynamic SQLs ) Program (Program name – wildcard is not allowed)

Table (First table name referenced in the SQL statement. It may be any object name (table,view,synonym,etc. - wildcard is not allowed) WsTrans/Corr (Transaction name. Available only for DB2 V10 and up)Userid (End user userid – User identifier code. Available only for DB2 V10 and up)WsNm (End user WsNM – Workstation name. Available only for DB2 V10 and up)


257

Parameters Field Target: List of statistics field used to determine the cached statements. EXEC - Number of Statement executions READ - Number of buffer reads GETP - Number of GETPAGE requests INDX - Number of Index scans PARL - Number of Parallel Groups ROWP - Number of rows processed ROWE - Number of rows examined SORT - Number of sorts performed TABS - Number of tablespace scans WRIT - Number of buffer writtes RIDL - Number of times of RID was not used (exceeded the limit) RIDS - Number of times of RID was not used (not enough storage) CPU - Accumulated Cpu time ELAP - Accumulated Elapsed time WAIT - Accumulated wait time for synchronous I/O LOCK - Accumulated wait time for lock requests SERV - Accumulated wait time for service task GLOC - Accumulated wait time for global locks RDOT - Accumulated wait time for read activity by another thread WTOT - Accumulated wait time for write activity by another thread LATC - Accumulated wait time for lock requests TIME - The update timestamp when statistics were last changed TINS - The insertion timestamp when stetements first cached or EDM NONE - This field target will read everything from cache. It will accept any filter on screen except minimum value. Minimum Value: A number or time which determines the minimum value for the Field Target Ex.: Field Target: CPU Minimum Value: 0.001 Field Target: GETP Minimum Value: 1000

AVAILABLE SORT FIELDS Sort Field Field Header----------- --------------- PROG - Program T - T (Trace Source) UNIQ - Uniq SNUM - S Num DESC - Desc GTAB - Gtab GCOL - Gcol GSRT - Gsrt CPU - DB2 CPU(ALL) SQLS - SQLs STMT - Stmt Id ELAPSED - DB2 Elapsed CPUAVG - DB2 CPU Avg WAIT - DB2 Wait OWN - Owner NAME - Table Name WSTRANS - WsTrans (WorkStation Transaction Name)


258

WSUSERID - WsUserId (WorkStation User Id) WSNAME - WsName / User Routi TIMETRA - Started Time Trace SNAP - Time Update (rounded) COLL - Collid SSID - SSID TIMEUPD - Time Update in Cache TIMEINS - Time Insert in Cache PT - Program Timestamp HOLD - Cursor Hold REPL - Replace DROP - Drop DEGREE - Current Degree ERMG - Err Msgs C - Comment







(F)SQLComReport SSCO-User SQL Comments


(Y)SQLsReport SRPS-SQLs List

(S)SQLTextReport STCX-SQL Text

(E)ExplainReport SREX-Statement Explain Information

(U)SUniqueWReport ST02-Identical Statements Summary

(X)SSimiWReport ST03-Similar Statements Summary

(Z)Zoom



259

PGDT - Program Execution Details

This report will show detail information about an execution of a DB2 program. Thisreport has 3 separated sections: - ACCOUNTING DETAILS : Show information from DB2 Accounting Traces - PERFORMANCE DETAILS : Show information from DB2 Performance Traces - SQL CACHE AREA : Show information from DB2 SQL Cache Area

If information is not available because it was not collecte, string *n/a*' will be shown.



SAMPLE REPORT


260

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 32 of 86 Option ===> PGDT - Program Execution Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: ZIVPBT01 SSIDs : ------------------------------------------------------------------------------ -------------------------ACCOUNTING DETAILS-------------------------- TOTAL PROGRAMS OCCURRENCE: 1 TOTAL SQLs EXECUTED: 4 TOTAL STOR PROC EXECUTED: 0 TOTAL UDF EXECUTED: 0 DB2 ELAPSED TIME TOTAL: 1.570546 DB2 ELAPSED TIME(AVG PER OCCURRENCE): 1.570546 DB2 CPU TIME TOTAL: 1.458940 __DB2 CPU TIME (CP): 1.458940 __DB2 CPU TIME (SE/ZIIP): 0.000000 DB2 CPU TIME (AVG PER SQL): 0.364735 DB2 CPU TIME (AVG PER OCCURRENCE): 1.458940 DB2 WAIT TIME TOTAL: 0.009805 __DB2 WAIT TIME LOCK : 0.000000 __DB2 WAIT TIME LATCH : 0.000000

FIELD DESCRIPTIONS- ACCOUNTING DETAILS

TOTAL PROGRAMS OCCURRENCE: Total traces found.

TOTAL SQL EXECUTED:Total SQL Executed.Note that this counter could not be the real value when SQL was submited from DRDAconnections.

TOTAL STOR PROC EXECUTED:Total Stored Procedure Executed.

TOTAL UDF EXECUTED:Total User Define Function Executed.

DB2 ELAPSED TIME TOTAL:Total DB2 ELAPSED Time.

DB2 ELAPSED TIME(AVG PER OCCURRENCE)Average DB2 Elapsed Time per Program Trace Occurrence.

DB2 CPU TIME TOTAL:Total DB2 CPU spent on a normal CP processor plus SE/ZIIP processor.

__DB2 CPU TIME (SE/ZIIP) Total DB2 CPU spent on SE/ZIIP processor

__DB2 CPU TIME(CP):Total DB2 CPU spent on a normal CP processor

DB2 CPU TIME (SE/ZIIP) Total DB2 CPU spent on SE/ZIIP processor

DB2 CPU TIME (AVG PER SQL)Average DB2 CPU Time per SQL Execution (CPU time from CP plus SE/ZIIP)

DB2 CPU TIME(AVG PER OCCURRENCE)Average DB2 CPU Time per Program Trace Occurrence (CPU time from CP plus SE/ZIIP).

DB2 WAIT TIME TOTAL:Total DB2 WAIT Time Spent.

DB2 WAIT TIME LOCK/LATCH:Total DB2 WAIT Time Spent in Lock/Latch.

DB2 WAIT SYNC I/O DATABASE:Total DB2 WAIT Time in synchronous I/O to read/write DB2 application tables.

DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported


261

DB2 WAIT TIME OTHER WRITES:Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported

DB2 WAIT TIME SERVICE TASK:Total DB2 WAIT Time for Service Task. Services include here: – Open and close of a Data Set– Update of SYSLGRNG – HSM recall Data Set – Dataspace Manager Services – Define Data Set – Extend Data Set – Delete Data Set – Wait time due to synchronous execution unit switch to other DB2 service tasks – WAIT time spent in commit, abort or deallocation process.


_DB2 WAIT TIME ARCHIVE LOG: DB2 WAIT time to process archive log command

_DB2 WAIT TIME ARCHIVE READ: DB2 WAIT time for archieve reads, active reads, active log prefetch reads



_DB2 WAIT TIME AVAILABLE TCB STPROC: Total waiting time available for TCB before Stored Procedure could be scheduled

_DB2 WAIT TIME DATASHARING SENDING MESSAGES: Total waiting time caused by suspension of sending messages to other DB2 Members

_DB2 WAIT TIME GLOBAL CONT. PARENT L-LOCKS: Total waiting time caused by global contention for parent l-locks.

_DB2 WAIT TIME GLOBAL CONT. CHILD L-LOCKS: Total waiting time caused by global contention for child l-locks.

_DB2 WAIT TIME GLOBAL CONT. OTHER L-LOCKS: Total waiting time caused by global contention for other l-locks.

_DB2 WAIT TIME GLOBAL CONT. PAGESET P-LOCKS: Total waiting time caused by global contention for pagetset/partition p-locks.

_DB2 WAIT TIME GLOBAL CONT. PAGE P-LOCKS: Total waiting time caused by global contention for page p-locks.

_DB2 WAIT TIME GLOBAL CONT. OTHER P-LOCKS: Total waiting time caused by global contention for other p-locks.

_DB2 WAIT TIME TCP/IP LOB AND XML MATERIALIZ:Total waiting time for TCP/IP LOB and XML materialization.


262

DB2 TOTAL I/O EVENTS: Total wait trace events.

I/O RESPONSE TIME:Average Disk I/O time. This number is obtained dividing Sync I/O database by Total I/O Events.

FIELD DESCRIPTIONS - PERFORMANCE DETAILS

SQL TOTAL EXECUTIONS:Total SQLs executed.

DB2 ELAPSED TIME:Total DB2 Elapsed Time.

DB2 CPU TIME:Total DB2 CPU spent in all processors (CP plus SE/ZIIP).

DB2 CPU TIME (AVG PER SQL)Average DB2 CPU per SQL execution

TOTAL REOPT:Total Re-optimization occurred in run-time

TOTAL NOREOPT:Total Re-optimization NOT occurred in runtime

INDEXRows/index entries/pages processed in Index

DATARows/pages processed in DB2 Table

SORTRows/pages processed in Work File, a temporary table


– This number counts rows for the related DB2 TABLE only SegmentedTABLESPACES:


– This number counts rows for the related DB2 TABLE only Single TABLESPACESwith multiple tables:




263

ROWS QUAL STAG 1: Rows Qualified at Stage 1.This means:– Indexable predicates– Predicates not indexable, but contain columns that belong to indexes (Index

ScanningScanning)Stage 1 is faster than Stage 2 because they are resolved in DB2 Data Manager (DM). DB2 Data Manager resolves ROW-LEVEL processing.

ROWS QUAL STAG 2: Rows Qualified at Stage 2.DB2 will:– Resolve all other predicated not resolved in Stage 1– It will scan (normally) rows and reject some of themStage 2 is resolved in Relation Data Server (RDS). RDS resolves SORT and SET-LEVEL Processing.

ROWS INSERTED:Rows Inserted

ROWS UPDATED:Rows Updated

ROWS DELETED:Rows Deleted

TOTAL GETPAGES:Getpages issued

TOTAL GETPAGES RI: Additional Getpages issued to enforce ref. Constraints.

ROWS DEL RI: Additional Rows delete/set to null by ref. Constraints.

PAGES SCAN LOB:Additional pages scanned in a LOB TABLESPACE.

PAGES IN UP LOB:Additional pages update in a LOB TABLESPACE.

FIELD DESCRIPTIONS - SQL CACHE AREA






264










Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done.






_DB2 WAIT SYNC I/O:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables.

_DB2 WAIT TIME SERVICE TASK:Total DB2 Wait Time for Service Task (wait time due to synchronous execution unit

switch to other DB2 service tasks). Service that may be included here: – Open and close of a Data Set – Update of SYSLGRNG – HSM recall Data Set – Dataspace Manager Services


265

– Define Data Set – Extend Data Set – Delete Data Set


_DB2 WAIT TIME DATASHARING GLOBAL CONTENTIONTotal waiting time caused by global contention for parent l-locks, child L-locks, other

L-locks, pageset/partition P-locks, page P-locks and other P-locks.

_DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one:

– sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

_DB2 WAIT TIME OTHER WRITES: Total DB2 WAIT Time of other writes done under a thread other than this one:

– asynchronous write I/O – others synchronous write I/O not reported










266

PGSD - SQL Details

This report will show detail information about the execution of a SQL statement.

Information shown here is obtained from DB2 Performance Traces andperformance data available from SQL Cache Area. If data is not available because itwas not collected, string *n/a* will be shown.



SAMPLE REPORT


267

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 30 of 50 Option ===> PGSD - SQL Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: ZIVPBT10 Plan Name: Stmt Num : 0000000227 Table Owner : Table Name: Stmt Uniq: 5A3771B6 Group Tab : Group Col : SSID : ----------------------------------------------------------------------------- ------------------------PERFORMANCE DETAILS------------------------- TOTAL SQLs EXECUTED: 1 DB2 ELAPSED TIME: 0.002100 DB2 CPU TIME: 0.002075 DB2 CPU TIME (AVG PER SQL): 0.002075 TOTAL_REOPT: 0 TOTAL_NOREOPT: 0 INDEX DATA SORT ----- ---- ---- ROWS_PROCESSED: 0 0 0 ROWS_EXAMINED: 0 0 0 ROWS_QUAL_STAG_1: 0 0 0 ROWS_QUAL_STAG_2: 0 0 0 ROWS_INSERTED: 0 0 0

FIELD DESCRIPTIONS - PERFORMANCE DETAILS

SQL TOTAL EXECUTIONS:Total SQLs executed.



DB2 CPU TIME (AVG PER SQL)Average DB2 CPU per SQL execution.

TOTAL REOPT:Total Re-optimization occurred in run-time.

TOTAL NOREOPT:Total Re-optimization NOT occurred in runtime.

INDEX Rows/index entries/pages processed in Index.

DATA Rows/pages processed in DB2 TABLE.

SORT Rows/pages processed in Work File, a temporary table.



– This number counts rows for the related DB2 TABLE only Index Spaces: same asabove.




ROWS QUAL STAG 1: Rows Qualified at Stage 1.This means:– Indexable predicates– Predicates not indexable, but contain columns that belong to indexes (Index Scanning)Stage 1 is faster than Stage 2 because they are resolved in DB2 Data Manager (DM). DB2 Data Manager resolves ROW-LEVEL processing.


268

ROWS QUAL STAG 2: Rows Qualified at Stage 2. DB2 will:– Resolve all other predicated not resolved in Stage 1– It will scan (normally) rows and reject some of themStage 2 is resolved in Relation Data Server (RDS). RDS resolves SORT and SET-LEVEL Processing.

ROWS INSERTED:Rows Inserted.

ROWS UPDATED:Rows Updated.

ROWS DELETED:Rows Deleted.


TOTAL GETPAGES RI: Additional Getpages issued to enforce ref. Constraints.

ROWS DEL RI: Additional Rows delete/set to null by ref. Constraints.

PAGES SCAN LOB:Additional pages scanned in a LOB TABLESPACE.


FIELD DESCRIPTIONS - SQL CACHE AREA











269





TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done.






_DB2 WAIT SYNC I/O:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables.



- Wait time spent in commit, abort or deallocation process.

_DB2 WAIT TIME DATASHARING GLOBAL CONTENTIONTotal waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks.


270

_DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one:

– sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

_DB2 WAIT TIME OTHER WRITES: Total DB2 WAIT Time of other writes done under a thread other than this one:

– asynchronous write I/O – others synchronous write I/O not reported





_DB2 WAIT I/O LOG: Total wait time for LOG write I/O _DB2 WAIT TIME PAGE LATCH CONTENTION: DB2 WAIT time because of a page latch contention. Some DB2 utilities use page latch instead of lock table to collect statistics.




271

RF00 - Programs Cross Reference

This report shows complete cross reference of all executed DB2 Objects (programs,userid, plans, workstation name, etc) loaded into TurboTuneSQL database obtainedfrom DB2 Accounting traces, DB2 Performance traces and from DB2 SQL Cache Area



SAMPLE REPORT


272

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 26 of 46 Option ===> RF00 - General Cross Reference Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR : 00.00.00 23.59.59 Program Name: Correlation Name: Collid : Group Name : SSID: Plan Name : Line Actions ------------------------------------------------------------------ (P)ProgW (L)Plan (C)Correlation (X)SProcXref (Z)Zoom ------------------------------------------------------------------------------> C Program T Planname Correlation Connection Date Time S Num - -------- -- -------- -------------- ------------ ---------- -------- ----- DSN@EP2L CD *CACHE/D ZIVPBD01 TSO F/B 2019-11-13 06.00.00 1846 DSN@EP2L CS *CACHE/S *CACHE/S CACHE STATI 2019-11-13 06.00.00 1415 DSN@EP2L A DSNTEP11 ZIVPBD01 TSO F/B 2019-11-13 09.00.00 0 DSN@EP2L P DSNTEP11 ZIVPBD01 TSO F/B 2019-11-13 09.00.00 1846 DSN@EP2L P DSNTEP11 ZIVPBD01 TSO F/B 2019-11-13 09.00.00 1952 DSN@EP2L P DSNTEP11 ZIVPBD01 TSO F/B 2019-11-13 09.00.00 1982 DSN@EP2L P DSNTEP11 ZIVPBD01 TSO F/B 2019-11-13 09.00.00 2277 ZIVPBT01 CS *CACHE/S *CACHE/S CACHE STATI 2019-11-13 06.00.00 218 ZIVPBT01 CS *CACHE/S *CACHE/S CACHE STATI 2019-11-13 06.00.00 191 ZIVPBT01 A PLANSADV ZIVPJ01 TSO F/B 2019-11-13 09.00.00 0 ZIVPBT01 P PLANSADV ZIVPJ01 TSO F/B 2019-11-13 09.00.00 224 ZIVPBT01 P PLANSADV ZIVPJ01 TSO F/B 2019-11-13 09.00.00 230 ZIVPBT01 P PLANSADV ZIVPJ01 TSO F/B 2019-11-13 09.00.00 242 ZIVPBT02 CS *CACHE/S *CACHE/S CACHE STATI 2019-11-13 06.00.00 195 ZIVPBT02 CS *CACHE/S *CACHE/S CACHE STATI 2019-11-13 06.00.00 225 ZIVPBT02 A PLANSADV ZIVPJ02 TSO F/B 2019-11-13 09.00.00 0

FIELD DESCRIPTIONS

Program:Program Name. Sometimes when there is no program information (DB2 IFCIDs 3 or 239 not found) avalue *N/A* will be shown.

T: Trace Source: Valid Values: 'A' - Program found in Accounting Traces 'P' - Program found in Performance Traces 'CS' - Program found in SQL Cache Area (Static) 'CD' - Program found in SQL Cache Area (Dynamic)

PlanName:Plan name. Sometimes, where there is no Plan associated to this thread, a value *N/A* or *CACHE*will be shown.

Correlation:Correlation name.When this information comes from DB2 SQL Cache Area this field will contains: – STMT-TOKEN if it contains a valid value– String '*CACHE*' it STMT-TOKEN does not contain a valid value.

STMT-TOKEN is an identification string provided by programs.








S Num: SQL Statement Number from DB2 precompiler.


273

DB2 Elapsed: Total DB2 Elapsed time spent by this program in this Correlation.A value 'N/A' will be always generated when this information comes from DB2Performance Trace. This field was summarized by: DataSharing group nameDataSharing member nameSSID DB2 Plan nameDB2 Correlation nameProgram nameProgram precompile timeDB2 Connection typeDate and time when this thread finishedWorkStation User IdWorkStation Transaction NameStored Procedure schema/nameTrigger schema/nameUser Define Function (UDF) schema/nameCollection NamePrimary AuthorityDB2 Location Name (DRDA)

DB2 CPU: Total DB2 CPU time spent by this program in this correlation/plan.If trace type is: 'A' - CPU time spent on a normal CP processor. 'C' - CPU time spent on all processors (CP plus SE/ZIIP). 'P' - TurboTuneSQL are not computing this value when information comes performance traces. Value 'N/A' will be always generated. This field was summarized by: DataSharing group nameDataSharing member nameSSID DB2 Plan nameDB2 Correlation nameProgram nameProgram precompile timeDB2 Connection typeDate and time when this thread finishedWorkStation User IdWorkStation Transaction NameStored Procedure schema/nameTrigger schema/nameUser Define Function (UDF) schema/nameCollection NamePrimary AuthorityDB2 Location Name (DRDA)

DB2 Wait:Total DB2 Wait Time. When Trace Source is 'A' - Accounting trace: This is the total wait time spent by the

whole program in this reference (program, correlation, plan and time).

When Trace Source is 'C' - SQL Cache Area: This is the total wait time spent by this command in this reference (program, stmt number, correlation, plan and time).

When Trace Source is 'P' - Performance traces: No meaning. A value 'N/A' will be generated.


274



Primary Authorization:DB2 Primary Authorization for this thread.

LocationDB2 Location Name (DRDA).


WsTransWorkStation Transaction Name

WsConId or Schema Name:This field has 2 meanings:

– When this thread comes from a DB2 Remote location, this field will be thePrimary Authorization ID from Connection or Signon

– When this thread is the a Stored Procedure/User Define Function/Trigger, thisfield will be the corresponding schema name for the Stored Procedure, or UserDefined Function Name or Trigger Name.

WsName or User Rout:This field has 2 meanings:

– When this thread comes from a DB2 Remote location, this field will be theworkstation name

– When this thread is a Stored Procedure/User Define Function/Trigger, this fieldwill be the corresponding object name like Stored Procedure Name, User DefinedFunction Name or Trigger Name.

Program Timestamp: DB2 Precompile Timestamp. Notes:

(1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken' using z/OS macros (the final computed value is very close to Precompile Timestamp). (2) Please, do not consider this date for remote programs, Triggers and for programs extracted from SQL Cache Area (dynamic)

Occurrences:Total records found in DB2 Accounting traces. A value 'N/A' will be always generated when this information comes from DB2Performance Trace or from DB2 SQL Cache Area.This field was summarized by: DataSharing group nameDataSharing member nameSSID DB2 Plan nameDB2 Correlation nameProgram nameProgram precompile time


275

DB2 Connection typeDate and time when this thread finishedWorkStation User IdWorkStation Transaction NameStored Procedure schema/nameTrigger schema/nameUser Define Function (UDF) schema/nameCollection NamePrimary AuthorityDB2 Location Name (DRDA)

AVAILABLE FILTERS


Other Filters: DB2 Plan Name DB2 Connection Type DB2 Correlation Name Program Name Database Name Table Name(s) and Owner


Sort Field Field Header PROG Program Name T T (Trace Source) PLAN Plan Name CORR Correlation Name CONN Connection Name DATE DateTIME Time SNUM SQL Statement Number from DB2 precompilerELAPSED DB2 Elapsed CPU DB2 CPUWAIT DB2 Wait SQLS SQLs COLL Collection PRIM Primary Authorization LOCA Location


276

WSUSERID WorkStation User Id WSTRANS WorkStation Transaction Name WSCONID WsConId or Schema Name WSNAME WsTrans (User Routine) PT Program Timestamp OCCU Occurrence Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)



(L)Plan Report APLN-Plan Summary

(C)CorrelationReport ACOR-Correlation Summary

(X)SProcXref Create a cross reference list of all programs that has called this same currentStored Procedure. Report SRPG will be called to show this list.



277

SNEG - SQLCODEs Summary

This report shows the results of all negative sqlcodes or all sqlcodes where SQLCAWarning flags was turned on.

This information is based on DB2 Performance Traces.


SAMPLE REPORT


278

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> SNEG - SQLCODEs Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR: 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID : Line Actions ------------------------------------------------------------------ (S)SQLs -------------------------------------------------------- C SQL Code WARNINGS Dprog SQLs 0 1 2 3 4 5 6 7 A - ------------ ----------------- ----------- ----------- -803 _ _ _ _ _ _ _ _ _ 1 1 +000 W _ _ W _ _ _ _ _ 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

SQLCODE:DB2 SQLCODE.

Warnings:SQL Warnings from SQLCA. Short Description (check IBM documentation for updated information):– Warning0

– Contain blank if no other indicator is set– Warning1

– W: String was truncated– N: Non-scrollable cursor– S: Non-scrollable cursor

– Warning2 – W: Null were eliminated

– Warning3 – W: Number of result columns larger than host variables– Z: Few locator were provided in Associate Locator

– Warning4 – W: A prepared Update or Delete does not have Where – I: Insensitive cursor– S: Sensitive cursor

– Warning5– W: Statement was not executed/not valid statement – 1: Read Only Cursor – 2: Read and Delete Cursor – 4: Read, Delete and Update Cursor – N: For a disabled non-scrollable cursor

– Warning6– W: Invalid Date from computation

– Warning7– W: Nonzero digits were eliminated from computation

– Warning8– W: Character could not be converted

– Warning9– W: Exception in Count or Count Big processing – Z: Stored Procedure returned multiples result sets

– WarningA– W: Error in character conversion in SQLCA or SQLDA

Total Pgms:Total distinct programs found with this SQLCODE/Warning.

SQLs:Total executed SQLs with this same SQLCODE.


279

AVAILABLE FILTERS



Sort Field Field Header SQLCODE SQL Code DPROG DPROG SQLS SQLs



(S)SQLs Report SNGD-SQLs with SQLCODE negative


280

SNGD - SQLs with SQLCODE negative

This shows all statements from workload with same SQLCODE.


SAMPLE REPORT


281

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> SNGD - SQLs with SQLCODE negative Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR: 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 SSID : Sql Code: -803 Line Actions ------------------------------------------------------------------ (S)SQLText (D)Details (G)IXModel (P)ProgW (E)Explain (W)SqlW (Z)Zoom ------------------------------------------------------------------------------ C Program Desc S Num Uniq Gtab Gcol SQLs Warnings 0 1 2 3 4 5 6 7 A - -------- ------- ----- ---- ---- ---- ----------- ----------------- ZIVPBT02 INSERT 225 4173 E24D 0000 1 _ _ _ _ _ _ _ _ _ ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Desc:Short SQL Statement description. Examples: SELECT, DELETE, etc.

Unique:Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.





Sort Field Field Header PROG Program DESC Desc UNIQ Uniq GTAB GTAB GCOL GCOLSQLS SQLs



282


(S)SQLTextReport SRTX-SQL Text

(D)DetailsReport PGSD-SQL Details




(W)SQLWReport ST01-SQLs Summary



283

SRCD - Cost Details

DB2 provides are some additional Explain tables with more information to help you to explain a query. These additional tables contain valuable information.

This report will show the following additional Explain tables: DSN_DETCOST_TABLE


SAMPLE REPORT


284

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> SRCD - Cost Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: SADREXPO QueryNo: 0000005000 PlanTB Qual/Vs.: SADVQUAL / Explain Time: 2019-11-18-11.49.13.770000 Line Actions ------------------------------------------------------------------ (S)SQLText ------------------------------------------------------------------------------> C Qb Pl *------------- Open --------------* *-------------- Rows -------------* No No IO CPU Cost Qualif DM RDS - -- -- ----------- ----------- ----------- ----------- ----------- ----------- 1 1 0 0 0 47 47 47 1 2 0 0 0 0 0 0 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

QbNo:A number used to identify each query block within a query.

PlNo: The number of the step in which the query indicated in QBLOCKNO was processed

OpenIO: The I/O cost for the non-correlated subquery.

CPU: The CPU cost for the non-correlated subquery.

Cost:The Total Cost for the non-correlated subquery.

RowsQualif (OneCompRows): The number of rows qualified after applying local predicates.

DM: The number of data manager rows returned (after all stage 1 predicates are applied).

RDS:The number of RDS rows returned (after all stage 1 and stage 2 predicates are applied).

Sort New Input Table:Cols: The number of columns as sort input for a new table.

Rows:The number of rows as sort input for a new table.

Recsz: The record size for new table.

Pages:The page size for new table.

Runs:The number of runs generated for a sort of a new table.

Merge: The number of merges needed during a sort.


285

Sort Composite Table: Cols:The number of columns as sort input for a composite table.

Rows:The number of rows as sort input for a composite table.

Recsz:The record size for a composite table.

Pages:The page size for a composite table.

Runs: The number of runs generated during the sort of a composite table.

Merge:The number of merges needed during a sort of a composite table.

FilterIMFF:The filter factor of matching predicates only.

IMFFADJ: The filter factor of matching and screening predicates.

IMLEAF: The number of index leaf pages scanned by Data Manager.

COMPCARD: The total composite cardinality.


Sort Field Field Header QBNO Qb No PLNO Pl No IO OpenIO CPU OpenCPU COST OpenCostQUALIF Qualif DM DMRows RDS RDSRows SNCOLS SNCols SNROWS SNRows SNRECS SNRecs SNPAGES SNPages SNRUNS SNRuns SNMERGE SNMerge SNRUNS SNRuns SNMERGE SNMerge SCCOLS SCCols SCROWS SCRows SCRECS SCRecs SCPAGES SCPages SCRUNS SCRuns SCMERGE SCMerge


286

IMFF IMFF IMFFADJ IMFFADJ IMLEAF IMLEAF COMPCARD COMPCARD





287

SRCO - DB2 Column Cross Reference

This report shows a complete cross reference of DB2 columns and programs.

To work properly, you need to correctly setup the SQL source definition as defined inChapter 2, define SQL source.


SAMPLE REPORT


288

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 8 of 8 Option ===> SRCO - DB2 Columns Cross Reference Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner : IVPQUAL Table Name: IVPTABLE_T002 Program Name: Stmt Uniq : Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (P)ProgW (R)ProgS (S)SQLText (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C S Num Uniq Owner TableName T Colname Operator WPTR P V - ----- ---- -------- ------------------ ------------------ --------- ---- - 224 29B2 IVPQUAL IVPTABLE_T002 T COD_CLIENT_T2 C CY P 224 29B2 IVPQUAL IVPTABLE_T002 T NAME_CLIENT_T2 = WLCY P 224 29B2 IVPQUAL IVPTABLE_T002 T TOT_ROWS_T2 C CY P 197 F471 IVPQUAL IVPTABLE_T002 T COD_CLIENT_T2 C CY P 197 F471 IVPQUAL IVPTABLE_T002 T NAME_CLIENT_T2 C CY P 197 F471 IVPQUAL IVPTABLE_T002 T NAME_CLIENT_T2 = WLCY P 206 754C IVPQUAL IVPTABLE_T002 T COD_AREACLI = WLCY P 206 754C IVPQUAL IVPTABLE_T002 T COD_CLIENT_T2 C CY P ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

S Num: SQL Statement Number from DB2 precompiler.


Owner: Table Owner.

Name: This field normally represents a Table Name. But it also maybe a DB2 DDL Object, like Index Name (check field T (Object Type)

–T: Object type. Valid values: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY M MATERIALIZED QUERY TABLE P IMPLICIT TABLE CREATED FOR XML COLUMNS or TABLESPACET TABLE V VIEW X AUXILIARY TABLE Y SYNONYM I INDEX D DATA BASE S STORAGE GROUP K PACKAGE F FUNCTION O STORED PROCEDURE R TRIGGER E DISTINCT TYPE J JAR N NONE r Remote Object U UNKNOWN

Colname: Table Column Name.

Operator: This is the SQL operator. Examples: Like, =, > ALL, etc

WPTR: Column locator. This field is composed by several flags:

Flag W (Where column was found). Values: W - WHERE clause O - ON H - HAVING R - ORDER BY G - GROUP BY C - SELECTED, UPDATED, INSERTED V - VALUES Flag P (Position). Values: L - Found in the Left side


289

R - Found in the Right side Flag T (Variable types). Values: L - Literal C - Db2 Column H - Host Variable S - Special Register D - Host Variable (dynamic parameter mark '?') Q - Qualifier Flag R (Real table column name or view column name). Values: Y - This is a column name from a db2 table name N - This is a column name from a db2 view name

P/V Indicates if variable was found inside a DB2 View. Valid values: V - Variable found inside a view P - Variable found outside a view (for example:inside program)

Program: Program Name.

Desc: Short SQL Statement description. Examples: Select, Insert. Attention: For Dynamic SQLs, OPEN command can be sometimes be reported asSELECT command.

Program Timestamp: DB2 Precompile Timestamp. Notes: (1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken' using z/OS macros (the final computed value is very close to Precompile Timestamp). (2) Please, do not consider this date for remote programs, Triggers and for programs extracted from SQL Cache Area


Sort Field Field Header SNUM S Num UNIQ Uniq OWN Owner TAB Table Name COLN Colname OPER Operator WPTR WPTR (Column locator) PV P/V PROG Program



290







291

SRER - Explained Statements – Log Results

This report shows the results for all SQL statements explained for option “DO Explain” in report SREX.

Notes: (1) Numeric fields are shown using TurboTuneSQL Numeric format. Please, referto Appendix Numerical and Time formats for additional information.

SAMPLE REPORT


292

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> LOG RESULTS GENERATED - PRESS PF3 TO SEE EXPLAINS SRER - Explained Statements - Log Results Profile : IVP DB2 SSID : DBBG Totals ------------------------------------------------------------------------ Statements Read : 1 Explained OK : 1 Explain Failed : 0 Not explainable: 0 Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (S)SQLText (U)SUniqueW (X)SSimilW (K)SUniqueS (L)SSimilS (P)ProgW (Z)Zoom ------------------------------------------------------------------------------> C Program Desc F S Num Uniq Gtab Gcol F Extract Explain Bind Quali C Err Msg Err Msg Connect Id - ------------ ------- - ----- ---- ---- ---- - -------- ------- ---------- ZIVPBT01 DECLARE Q 191 AAFA 90E4 901C N OK SADVQUAL ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Desc:Short SQL Statement description. Examples: SELECT, DELETE, etc.Attention: For dynamic SQLs, OPEN command can be sometimes appear as a SELECT command.

FC:Flag Cast – Method used to explain statement.Valid values: Q, N , C

S Num:SQL Statement Number from DB2 Precompiler.




F:(Flag Error) Shows if TurboTuneSQL found an error while loading this SQL. Valid Values:

Y - This statement was flagged in error by TurboTuneSQL. Check field 'Extract Err Msg' for detail error code. N - This statement was NOT flagged in error by TurboTuneSQL. W - This statement was flagged in warning by TurboTuneSQL. When TurboTuneSQL can not resolve column in the SQL, a warning code is

generated. Check field 'Extract Err Msg' for detail error code. E - This statement was flagged in error by TurboTuneSQL when executing DB2

Explain command. Check field 'Explain Err Msg' for detail error code.

Extract Err Msg When 'Flag Error' field contains Y or W, this 7 bytes field indicates the the specific errorcode flagged by TurboTuneSQL. Valid Values: OK - No Extract Errors nnnnnnn - This is a 7 bytes field indicates the specific error code flagged by

TurboTuneSQL. How to proceed: lets suppose this field contains string MIIABCL:After searching for string MIIABCL in TurboTuneSQL-Messages Guide, youwill find message SQLTMIIABCLW. Other examples: - After searching string PGVIONF, you will find message SQLTPGVIONFW(table/view not found)


293

- After searching string FIX4001, you will find message SADBFIX4001W (Sqltext not found)

Other additional information may be obtained here: SQLs Recognized by TurboTuneSQL .

Explain Err Msg This field will contain error returned by TurboTuneSQL Explain Utility It may be a SQLCODE or other codes related to TurboTuneSQL Explain.Valid values: -nnn - DB2 Explain function has returned a negative sqlcode where nnnn is the

sqlcode. Refer to DB2 documentation to get SQL error descriptions. Example: EXP-204 (sqlcode = -204: Table not found).

'OK' - Explain was successfully executed (returned sqlcode was 0).

N??? - If value starts with "N", please refer to corresponding TurboTuneSQL messageSQLTSSAN??? Normally, explain command was not successfull executed. When a DECLARE statement does not contain a SELECT clause, or mayreceive codes: NCAS099, CAST091 or QCAS091.

S??? - If value starts with "S", please refer to corresponding TurboTuneSQL messageSQLTNCAS???

T??? - If value starts with "T", please refer to corresponding TurboTuneSQL messageSQLTCAST???

Bind Qualifier or Connect Id:This field has several meanings:

For Static SQLs imported from DB2 Catalog this is the DB2 Bind Qualifier– For Static SQLs imported from DBRM data set this is the default table owner– For Dynamic SQLs from remote connection collected by DB2 Performance Traces

this is the DB2 Connect Id – For Dynamic SQLs from SQL Cache Area this is the Current SQLID did at initial SQL

Prepare

Program Timestamp: DB2 Precompile Timestamp.Notes:– DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken'

using z/OS macros (the final computed value is very close to PrecompileTimestamp).

– Please, do not consider this date for remote programs, Triggers and for programsextracted from SQL Cache Area.

Collection:DB2 Package Collection.Other valid values:– It can be #NODBRM plus DB2 PLAN if this programs is a DBRM (not package).– It can be blank for some Dynamic SQLs capture from DB2 traces– It will be DSNDYNAMICSQLCACHE if program was loaded from DB2 SQL Cache Area.


294



(U)SUniqueWReport ST02-Identicals SQLs summary


(K)SUniqueSReport SRPS-SQLs List - Only Identical Statements

(L)SSimilSReport SRPS-SQLs List - Only Similar Statements




295

SREX - SQL Explain Information

This report shows SQL statements costs from Explain output and allows to executeexplains in case there is none or re-do to refreshment purpose.

It is available also to Explain commands directly from programs in DB2 SYSPACKAGEcatalog.

For showing Plan_Tables information, user can choose values among:'P' - Plan_tables from system property'U' - User Plan_tables'B' - for both options above

PlanTB Qual/Vs: PlanTB Qual is the qualifier name for Plan_table to retrieve the informationsVs is the DB2 version of this Plan_table. Examples:V8, V9, VA, etc. For a complete reference of supported DB2 version, check parameter DB2 version on Customize a TurboTuneSQL Profile.In case of this field is not informed, it will assume the value from DB2 version parameter previously setup on Customize a TurboTuneSQL Profile.

For 'Do Explain', the values can be:'N' - no explain process will be done'Y' - this option will show a panel to inform explain parameters


SAMPLE REPORT


296

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> SREX - SQLs Explain Information Profile : IVP DB2 SSID : DBBG Curr Loc : DALLASB Filters ----------------------------------------------------------------------- Program Name: SADREXPO Stmt Uniq: AC0BADCE Show PlanTB from: U (B/P/U) Stmt Num : 0000005000 Original Format: PlanTB Qual: SADVQUAL Source/Explain Request Code:( DBBG / DBBG ) DO Explain: N (Y/N) Line Actions ------------------------------------------------------------------ (E)PlanTables (R)ProgS (S)SQLText (F)SQLCom (W)SQLW (Y)SQLS (U)SUniqueW (X)SSimilW (K)SUniqueS (L)SSimilS (Z)Zoom (D)Delete ------------------------------------------------------------------------------> C Program S Num Desc Uniq Gtab Gcol OF CostCPU CostSU E C QryNo - ----------- ----- ------- ---- ---- ---- -- ---------------- ----------- - - SADREXPO 5000 SELECT AC0B AB12 0000 ? 0.007 255 ******************************* Bottom of data ********************************

HEADER DESCRIPTION

Profile : TurboTuneSQL Profile {?} : Profile Edit Mode (E - Edit Mode , B - Browse Mode)

DB2 SSID : Connected DB2 Curr Loc : DB2 Location, automatically obtained from the connected DB2

FIELD DESCRIPTIONS


S Num/QryNo:SQL Statement Number from DB2 precompiler or Queryno from user Plan_Table.




Gcol:Number which defines all groups of predicates found in this SQL statement. For more information, please refer to SQL Statement Group Columns Algorithm.

OF (Original Format):Y - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) WASpreserved. Check utility parameter Explain Parameter Mark option.N - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) was NOTpreserved. Check utility parameter Explain Parameter Mark option.C - TurboTuneSQL Explain Utility has executed Plan Table Copy Function for this SQL.Original program work variables format has been preserved. Only most recent BIND-TIME has been copied from User Plan Table to TurboTuneSQL Plan Table. Originalprogram work variables format has been preserved. Check utility parameter ExecutionMode. ? - Online Explain Utility has executed on online DB2 Explain.B/A - Explain created by TurboTuneSQL Automatic Index Recommendation B - Show Explains made BEFORE Index Recommendation A - Show Explains made AFTER Index RecommendationU - User Plan Table data was directly acessed and shown. For more information about SQL formats, go to program original format and non-original format.

CostCPU:Total CPU Costs provided by DB2 Explain Function.

CostSU:Total Service Units provided DB2 Explain Function.


297

E: Indicates the corresponding Statement Unique was found in workload. This does notmean that the current SQL statement was executed. Attention: Only Program Name and Precompile Time (contoken) are verified. Collection ID is not checked. Valid Values:

'*' - A SQL Command with this Statement Unique in this programs was found inWorkloadBlank - A SQL Command with this Statement Unique in this programs was NOTfound in Workload

C: Indicates if a SQL COMMENT was created for the statement:

‘*’ - SQL COMMENT found'?' - SQL COMMENT may have be created by line command 'F'Blank - SQL COMMENT was not found

Explain TimeShows Explain time. If field OF is NOT 'C','U', TurboTuneSQL has explained this SQL. For other values, this field has the same value of field EXPLAIN-TIME in DSN-STATEMNT-TABLE.

Bind Time from DB2 Catalog (most recent)For this program/collection, shows the most RECENT Bind Time for the most RECENTPRECOMPILE TIME.

Bind Time CheckStatus This field shows comparison results of Explain Time and Bind Time from DB2 Catalog. Valid values: MATCHED

Last Bind Time timestamp from SYSPACKAGE/SYSPLAN and Explain Time are equal.In this case, shows the most RECENT Bind Time for most RECENT PRECOMPILE TIME

UNMATCHED < Last Bind Time timestamp from SYSPACKAGE/SYSPLAN is LESS than Explain Timefrom Plan TAble

UNMATCHED > Last Bind Time timestamp from SYSPACKAGE/SYSPLAN is GREATER than ExplainTime from Plan Table

NOT FOUND Comparison could not be done: program not found SYSPACKAGE/SYSPLAN

NOT CHECKED Comparison could not be done: program was loaded into TurboTuneSQL using DBRMlibrary (PDS) instead of DB2 catalog.

NOT DBRM/PK Comparison could not be done: it is not DBRM nor PACKAGE

N.SUPPORTED Comparison could not be done: function not available for DB2 V8 in CM.

P.S.: Sometimes, explain times may not be equal because of ABEX subsystemparameter.The ABEXP subsystem parameter controls whether EXPLAIN processing is to occurduring an automatic rebind.

Cost CategoryThis represents the indication if DB2 was forced to use default values when making its estimates. Valid values:– A DB2 did not use default values to make a cost estimate– B DB2 used default values due to existing conditions


298

– * No value found (possible if Original Format is 'C' whe DSN-STATEMENT-TABLE was not found when copying from user plan table into TurboTuneSQL plan table)

ReasonReason of statement cost This value can be *NOT FOUND*, if Original Format is 'C' and record was not found.


Program Timestamp: DB2 Precompile Timestamp. Note(3): (3.1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken'using z/OS macros (the final computed value is very close to Precompile Timestamp).

(3.2) Please, do not consider this date for remote programs, Triggers and for programsextracted from SQL Cache Area. Note(4): Explain Information provided from User Plan Table (OF=U), can show Uniq, Gtab and Gcol as '----' it means the program could not be checked against TurboTuneSQL. Therefore, some Line Actions might not be available in these cases.


Sort Field Field Header PROG Program SNUM S Num DESC Desc UNIQ Uniq GTAB GTAB GCOL GCOL OF OF (Original Format) COSTCPU CostCPU COSTSU CostSU E E C Sql Comment EXPD Explain DateBTSTAT Bind Time Check StatusCATEG Cost Category REASON Cost Reason COLL Collection PT Program Timestamp



299


(E)PlanTablesFor OriginalFormat="P":

Report SRPT-Plan Table Information will be shownFor OriginalFormat="U" or '?':

More reports may be available as long as one of the user Explain Tables exists: "DSN_PREDICAT TABLE", "DSN_SORT_TABLE", "DSN_FILTER_TABLE", DSN_SORTKEY_TABLE" or "DSN_DETCOST_TABLE". If one of these tables exists, a popup window will appear with following options:

Report SRPT-Plan Table Information.Report SRPD-Predicate DetailsReport SRCD-Cost DetailsReport SRSD-Sort Details

If these tables do not exist, Report SRPT-Plan Table Information will be shown instead of the popup window.











(D)DeleteOption to delete the explainned statement from Plan Tables. Only available when the information of OriginalFormat is 'U'.To help you to not accidentally delete rows from the table plan, this command will only allow you to delete rows from the plan table only if there is nocorresponding package in the catalog (ie, the field will Program Timestamp '----')


300

AVAILABLE COMMAND LINE

LOGR: Shows report SRER (Statements Explained – Log Results).


301

SREX - DO EXPLAIN PANEL

This function allows you to Explain DB2 for one or more SQLs in real time.

SAMPLE SCREEN

Required Authorities:

– SYSADM authority OR Must have the authority to send SQL SET CURRENT SQLID (check optionUse this Plan Table Qualifier / Set Current SQLID)

– It may be necessary to have the same authority as required by DB2 toexecute the command that will be explained, except if job INST33BE wasexecuted during TurboTuneSQL Installation Process.

– SELECT, DELETE, UPDATE on tables (or Alias are in DB2 version 8 or up):PLAN_TABLE, DSN_STATEMNT_TABLE and DSN_FUNCTION TABLE(optional).



302

TurboTuneSQL V120 ------------------- Online Report --------------------- 09:4┌──────────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ CHOOSE ONE OPTION OR TYPE PF3 TO EXIT ││ ││ ││ Choose one option: ││ Execute a new explain : Y (N/Y) Execute new explain ││ or ││ Extract real explain behavior: N (N/Y/P/O) Extract explain data: ││ Y-Extract CURRENT version ││ P-Extract PREVIOUS version ││ O-Extract ORIGINAL version ││ N-Dont extract ││ Plan Table: ││ PlanTable Qualifier : SADVQUAL ││ Parameters for execute explain option: ││ Start explain with Queryno : 05000 Degree: ANY ││ Max Limit of Explain : 1000 SQLs ││ Store Explain Data : U P-Store into Product Plan Tables ││ U-Store into User Plan Tables ││ ││ F1=Help F3=Exit │└──────────────────────────────────────────────────────────────────────────────┘

FIELD DESCRIPTIONS

Execute new explainExecute Explain. Mutually exclusive with option Extract real explain behavior.Valid values:'Y' – Execute Explain and open explain log report SRER'N' – Leave this box without execute explain.

Extract real explain behavior:Extract current (real) access path behavior and store it into Plan Table. Mutually exclusive with option Execute new explain.Valid values: Y: Extract CURRENT version and open explain log report SRERP: Extract PREVIOUS version and open explain log report SRERO: Extract ORIGINAL version and open explain log report SRERN: Dont extract - Leave this box without execute explain.

Explain Parameters:Start explain with Queryno Query Number to be used in Plan Tables.Note: A Query Number will be generated randomly for each explain if the user leaves blanks or zeros; for any different value, Query Number will remain the same.

Degree Choose a valid current Degree. Set Current Degree command will be issued using theinformation provided before executing Explain command.

PlanTable Qualifier Choose a valid qualifier for PlanTable. Set Current SQLID command will be issued using the information provided before executing Explain command. If not informed, TurboTuneSQL will assume the current USERID as Plan Table qualifier. Attention:(1) Current explain data from 'qualifier.plan table' will be deleted and stored intoTurboTuneSQL tables using current Explain Request Code.(2) Also, previous explain data from TurboTuneSQL tables will be overriden.(3) The Plan Table Qualifier informed may be different from Plan Table Qualifier ( PlanTB Qual ) set in SREX report.

PlanTable Version DB2 Plan Tables MUST be defined using the layout according to DB2 version specified. Valid values: V8,V9,VAIf not informed, current DB2 version specified in TurboTuneSQL Profile will be assumedas Plan Table layout version.

Max Limit of ExplainSince the explain execution is online, TurboTuneSQL has limited a maximum number of1000 Statements for each program. In case of the program you chose to explain hasmore than this number of statements, please, use the Explain Utility to proceed.

Store Explain DataUse this option to decide where the explain data will be stored.Valid Values:'Y' – explain data will be moved from user plan tables to TurboTuneSQL explain tables (repository). SREX report will show data using Original Format=N; field Show PlanTB from will be automatically changed to 'P'. All previous data will be deleted. 'N' – Explain data will be stored into user plan table only.


303

SREX report will show data using Original Format=U; field Show PlanTB from will be automatically changed to 'U'. All previous data will be preserved and new explain data will be added. If you wish to delete use line action 'D'.Notes:(1) Sometimes the explain command may not work for one or more SQLs. For instance,a negative SQLCODE may be returned by DB2 explain function. When using option 'Y', to check explain errors, please refer to report SRPS, field Explain Err Msg.(2) Parameters above are shared by Online Explain Utility:

Start explain with Queryno Degree PlanTable Qualifier PlanTable Version

(3) Option Y is available only if program (or SQL) was loaded into TurboTuneSQL Repository.


304

SRIC - Shows Packages in Catalog

This report will show all DB2 Programs found from DB2 Catalog (Packages / DBRMs). This report may be excuted directy from Online report or by other reports using as a filter: – A DB2 index is associated to the program or plan. – A DB2 table is associated to the program or plan.– Program name.


SAMPLE REPORT


305

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 11 of 11 Option ===> SRIC - Shows Plans and Package from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name : ZIVPBT* Collid: Table Owner : Table Name : Ix Creator : Ix Name : Line Actions ------------------------------------------------------------------ (P)ProgW (R)ProgS (E)Explain (S)SQLs (M)PlanTableComp (Z)Zoom ------------------------------------------------------------------------------> C Program T Collection Precompile Timestamp Bind Time A E Plan - -------- - ---------- -------------------------- ------------------------ - - ZIVPBT01 K SADVCOL 2019-11-13-06.50.03.150767 2019-11-13-06.50.07.6784 * * ZIVPBT02 K SADVCOL 2019-11-13-06.50.13.277510 2019-11-13-06.50.17.7774 * * ZIVPBT03 K SADVCOL 2019-11-13-06.50.21.297217 2019-11-13-06.50.28.2190 * * ZIVPBT04 K SADVCOL 2019-11-13-06.50.23.696782 2019-11-13-06.50.31.1357 * * ZIVPBT05 K SADVCOL 2019-11-13-06.50.26.363359 2019-11-13-06.50.33.0440 * * ZIVPBT06 K SADVCOL 2019-11-13-06.50.28.876517 2019-11-13-06.50.36.1632 * * ZIVPBT07 K SADVCOL 2019-11-13-06.50.35.157686 2019-11-13-06.50.45.2817 * * ZIVPBT08 K SADVCOL 2019-11-13-06.51.57.132150 2019-11-13-06.52.01.5120 * * ZIVPBT09 K SADVCOL 2019-11-13-06.50.37.286116 2019-11-13-06.50.46.7261 * * ZIVPBT10 K SADVCOL 2019-11-13-06.50.39.359227 2019-11-13-06.50.47.3574 * * ZIVPBT33 K SADVCOL 2019-08-26-12.26.54.360256 2019-09-18-18.58.17.9614 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Program:DB2 Program Name. Exception: when Dependency Type is Plan (see below) and this report was triggered by HI00/TI00 or HT00/TB00, this field will show value '*NOT FOR PLANS*'because of DB2 Catalog restrictions when using Plans. T: Dependency Type.Valid Values: – K: Programs (packages)– P: Plans (dbrms)

Collection or Plan Name:Collection Name (when T is K) or Plan Name (when T is P).

Precompile Timestamp: DB2 Precompile Timestamp. When Dependency Type is Plan (see above) and this report was triggered by HI00/TI00 or HT00/TB00, this field will show value '*NOT FOR PLANS*' because of no program name available.

Bind Time: Indicates bind time for package or plan.

A: Indicates if this program was loaded into TurboTuneSQL Tables.Program name, Timestamp and Collid fields are used as filters.Valid Values: – '*' SQL Command was found– '?' SQL Command might be found for some other DBRM– Blank SQL Command was NOT found or this is a Plan

E: Indicates if this SQL Command was found in workload, according to current filters.Attention: Only Program Name and Precompile Time (contoken) are verified. Collection ID is not checked. Plan name is checked. Valid Values: – '*' SQL Command was found– Blank SQL Command was NOT found

LastUsed: The last date that the corresponding objects are used. Only available for DB2 V9 and up. This field is controlled by ZPARM parameter: DISABLE-EDMRTS DISABLE-EDMRTS (macro DSN6SPRM):

Specifies whether to disable the collection of real-time statistics by the environmental description manager (EDM).

HostLang: Host language for the package's DBRM. Valid Values: 'ASM' - Assembler 'COBOL' - VS COBOL II, IBM COBOL or OS/VS COBOL 'C' - C or C++ 'FORTRAN' - Fortran 'PL/I' - PL/I 'TRIGGER' - For remotely bound trigger packages 'PROCEDURE' - For remotely bound SQL procedure packages 'FUNCTION' - For remotely bound non-inline SQL scalar function packages


306

Bind Type: Identifies how the package is created. Valid Values: 'T' - CREATE TRIGGER statement 'N' - CREATE PROCEDURE or ALTER PROCEDURE statement 'F' - CREATE FUNCTION or ALTER FUNCTION statement blank - BIND PACKAGE command created

Precompile Timestamp: DB2 Precompile Timestamp.

Version: Version identifier for the package. The value is blank for a trigger package (TYPE='T'). Note: (1) DB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken'using z/OS macros (the final computed value is very close to Precompile Timestamp).(2) Please, do not consider this date for remote programs, Triggers and for programsextracted from SQL Cache Area.


Sort Field Field Header PROG Program T T (Dependency Type) COLL Collection PC Precompile TimestampBDTM Bind Timestamp A A (Indicates if this program was loaded into TurboTuneSQL) E E (Indicates if this SQL Command was found in workload)LUSED LastUsed PT Program Timestamp



(P)ProgW Report AC00-Programs Summary (from Accounting Traces)

(R)ProgS Report SRPG-Programs List


(M)PlanTableComp Report SRMI-Plan Table Comparison

(S)SQLsReport SRPC-List from DB2 Catalog



307

SRMI - Plan Table Comparison

This report shows the result of Plan Tables comparison. You must execute theCompare Plan Tables Utility before executing this report.

The SQLs statements compared here are:● New SQLs● Removed SQLs● SQLs having different Explain Costs● SQLs with different Access Path.

To get more details how the comparison is performed, go to Compare Plan Tables Utility.


SAMPLE REPORT


308

TurboTuneSQL V120 ------------------- Online Report --------------------- 09:54 Option ===> SRMI - Plan Table Comparison Results Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Explain Request Code (OLD) : IVP1 Explain Request Code (NEW): IVP1 Show Access Path Differences: N (Y/A/N/D) Other Filters ----------------------------------------------------------------- Table Owner : Table Name : Database: Program Name : Source Request Code (OLD/NEW): ( / ) Line Actions ------------------------------------------------------------------ (P)ProgW (E)ExpOld (Y)ExpNew (B)ProgC (O)ProgOld (R)ProgNew (S)SQLText (Z)Zoom ------------------------------------------------------------------------------> C Program Uniq S Num Desc Cost Comparison Access Path Cost E Cost-MS Cost-SU AMIP IX SR TN Categ - ------------ ---- ----- --------- --------- --------- ------------- ----- - ZIVPBT01 90BB 117 INSERT *stm with no mism* - - - - - ZIVPBT04 16A7 221 SELECT *stm with no mism* - - - - - ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Explain Request Code (OLD) Inform Explain Request Code OLD - same as used in Compare Plan Table utility.

Explain Request Code (NEW) Inform Explain Request Code NEW - same as used in Compare Plan Table utility.

Important: To list all previous keys stored in TurboTuneSQL repository, use LSTREQcommand.

Show Access Path Differences Filter to show the level of differences.Valid values: Y - Show statements only if Access Path has changed. Checked fields:

ACCESSTYPE, MATCHCOLS, INDEXONLY, SORT (all sort fields), ACCESSCREATOR andACCESSNAME. For more information, check Compare Plan Tables Utility

A - All statements will be shown. Statements with no Access Path and Costs

differences will be shown with message "*stm with no mism*". If all statements in a program have no differences, just one message "*pgm with nomism*" will be shown for the entire program.

N - Same as "A", but "*stm with no mism*" will not be shown. Therefore statements with no Access Path and Costs differences will not be shown. D - Same as "N", but "only new / only old" cases will not be shown.



S Num: SQL Statement Number from DB2 Precompiler.

Desc: Short SQL Statement description. Examples: Select, Insert. Attention: when this command is a dynamic SQL, OPEN, FETCH and CLOSE commands will sometimes appear as a SELECT command.

Cost Comparison:CostMSValid values:

worse-ms: This field will show worse-ms if CPU cost for new explain is worse thanold explain for this statement.better-ms: This field will show better-ms if CPU cost for new explain is better thanold explain for this statement.

CostSU Valid values:

worse-su: This field will show worse-su if Service Unit for new explain is worsethan old explain for this statement.

worse-su: This field will show better-su if Service Unit for new explain is better thanold explain for this statement.


309

Other possible values for CostMS or CostSU: only old: This SQL statement was only found in the Old Explain Request. only new: This SQL statement was only found in the New Explain Request.

stmt with no mism: When no mismatch was found for the statement.pgm with no mism: When no mismatch was found for all statements for thecurrent program. No extra information will be displayed (Unique, S Num andDescription).

Access Path: AMIP

This field will show "Y" if ACCESSTYPE, MATCHCOLS, PREFETCH or INDEXONLY are different comparing old explain and new explain for this statement.

IX This field will show "Y" if ACCESSCREATOR or ACCESSNAME are different comparing the old explain and the new explain for this statement. Normally, this field will contain the DB2 Index Name. SRT This field will show "Y" if any SORT is different for this statement. TN This field will show "Y" if CREATOR or TNAME are different for this statement.

Cost Categ:This field will show "Y" if the cost category is different for this statement.

E: Indicates if this SQL Command was found in workload, according to current filters.Attention: Only Program Name and Precompile Time (contoken) are verified. Collection ID is not checked. Valid Values: – '*' SQL Command was found– Blank SQL Command was NOT found

CostCPU(OLD):Total CPU Costs by DB2 Explain Function for Request Code (OLD).

CostSU(OLD): Total Service Unit by DB2 Explain Function for Request Code (OLD).

CostCPU(NEW):Total CPU Costs by DB2 Explain Function for Request Code (NEW).

CostSU(NEW): Total Service Unit by DB2 Explain Function for Request Code (NEW).

Program Timestamp: DB2 Precompile Timestamp. Notes: (1) TDB2 Precompile Timestamp or, in some cases, an expansion of field 'contoken'using z/OS macros (the final computed value is very close to Precompile Timestamp).(2) Please, do not consider this date for remote programs, Triggers and for programsextracted from SQL Cache Area.

Explain Date: This field shows the date/time for the last explain performed for this statement.

OF O Informed Original Format (OLD)


310

OF N Informed Original Format (NEW)

First Bind Time: This field shows the date/time for the first bind for this program regardless of whichcollection it was bound. This field is generated only from DB2 Packages.

Last Bind Time: This field shows the date/time for the last bind for this program regardless of whichcollection it was bound. This field is generated only from DB2 Packages.

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Source Request Code Explain Request Code Max Objects

Other Filters: Program Name Program Name Range Database Name Table Name(s) and Owner


Sort Field Field HeaderPROG Program UNIQ Uniq SNUM S NUM DESC DESC COST-MS Cost Comparison Cost-MS COST-SU Cost Comparison Cost-SU ACCESSPATH Access Path (AMI IX SRT TN) CATEG Cost category E E (Indicates if this program was found in workload) COSTCPUO CostCPU Old COSTSUO CostSU Old COSTCPUN CostCPU New COSTSUN CostSU New PT Program Timestamp EXPD Explain Date FBT First Bind Time LBT Last Bind Time



311



(E)ExpOld Report SREX-SQLs Explain Information(Using Request Code - OLD)

(Y)ExpNew Report SREX-SQLs Explain Information(Using Request Code - NEW)

(S)SQLText Report SRTX-SQL Text (Using Request Code - NEW)


(O)ProgOld Report SRPG-Programs List (Using Request Code - OLD)

(R)ProgNew Report SRPG-Programs List (Using Request Code - NEW)

(Z)Zoom Report ZOOM will be started (shows extended fields)


312

SROJ - Object List

This report shows the summary information about objects accessed by this SQL.


SAMPLE REPORT


313

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> SROJ - Object list Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: ZIVPBT08 Stmt Uniq : Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (Q)TableC (Z)Zoom ------------------------------------------------------------------------------- C T S Num Part1 Part2 Part3 Part4 P Location V - - ----- -------- ------------------ ------------------ -------- - ----------- T 203 IVPQUAL IVPTABLE_T001 IVPT001 IVPDB P T 231 IVPQUAL IVPTABLE_T001 IVPT001 IVPDB P ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

T: Object type: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY M MATERIALIZED QUERY TABLE P IMPLICIT TABLE CREATED FOR XML COLUMNS or TABLESPACET TABLE V VIEW X AUXILIARY TABLE Y SYNONYM I INDEX D DATA BASE S STORAGE GROUP K PACKAGE F FUNCTION O STORED PROCEDURE R TRIGGER E DISTINCT TYPE J JAR N NONE r Remote Object U UNKNOWN


Part1 / Owner: Normally Table Owner.

Part2 / Name: This field normally represents a Table Name.But it also maybe: - A DB2 DDL Object, like Index Name (check field T (Object Type) - A Dynamic SQL command when no DB2 table was accessed. Example: SQL SET CURRENT DATE. SQL commands will always be shown between parenthesis.

Part3: Normally TableSpace Name.

Part4: Normally Database Name.

P/V: Program or View. Indicates if variable was found inside a DB2 View. Valid values: V - Variable found inside a view P - Variable found outside a view (for example:inside program)


314


Sort Field Field Header SNUM S Num OBJ1 OBJ1 OBJ2 OBJ2 OWN Owner TAB Table Name OPER Operator WPTR WPTR (Column locator) PV PROGR/VIEW



(T)TableHReport HT00-Tables Definition from History




315

SRPC - SQLs List - from DB2 Catalog

This report shows all SQL statements from DB2 Catalog.

Only SQLs originated from DB2 Syspackstmt Catalog will be shown here.


SAMPLE REPORT


316

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 5 of 5 Option ===> SRPC - SQLs List - from Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: ZIVPBT01 Collid: SADVCOL Line Actions ------------------------------------------------------------------ (S)SQLText (E)Explain (F)SQLCom (Q)TableC (W)SQLW (G)IXModel (P)ProgW (U)SUniqueW (X)SSimilW (K)SUniqueS (L)SSimilS (Z)Zoom ------------------------------------------------------------------------------> C Program Desc S Num Uniq Gtab Gcol Gsrt Stmt Id Sectno Cursor I C - ------------ ------- ----- ---- ---- ---- ---- ---------- ------ -------- - - ZIVPBT01 DECLARE 191 AAFA 90E4 901C 0000 0000665360 1 CRMQT ZIVPBT01 REFRESH 218 90BB 90E4 0000 0000 0000665361 2 ZIVPBT01 OPEN 224 AAFA 90E4 901C 0000 0000665362 1 CRMQT ZIVPBT01 FETCH 230 AAFA 90E4 901C 0000 0000665363 1 CRMQT ZIVPBT01 CLOSE 242 AAFA 90E4 901C 0000 0000665364 1 CRMQT ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Desc:Short SQL Statement description. The description shown here is as how the statement has been read from DB2 Catalog.






Stmt ID:Unique statement identifier. This information is only available from DB2 V10 and up.

Sectno: The section number of the statement.

Cursor:SQL Declare Cursor Name

I:Isolation Level (from BIND option or at SQL level). Valid values:– R - RR - Repeatable Read. – S - CS - Cursor Stability. – T - RS - Read Stability. – U - UR - Uncommited Read. – L - RS - Read Stability with a lock-name – X - RR - Repeatable Read with a lock-name – Blank - The WITH clause was not specified on this statement. The isolation level is recorded in

SYSPACKAGE.ISOLATION and in SYSPLAN.ISOLATION.



Collection:DB2 Package Collection.

Precompile Timestamp:Field PCTIMESTAMP from SYSIBM.SYSPACKAGE.


317

Qualifier:Implicit qualifier for the unqualified table in the static SQL statements of the package.

Owner and TableName:Table owner and respective name referenced in the corresponding SQL statement.



generated. Check field 'Extract Err Msg' for detail error code. E - This statement was flagged in error by TurboTuneSQL when executing

DB2 Explain command. Check field 'Explain Err Msg' for detail error code.

Extract Msg When 'Flag Error' field contains Y or W, this 7 bytes field indicates the the specific errorcode flagged by TurboTuneSQL. Valid Values: blank - No Extract Errors nnnnnnn - This is a 7 bytes field indicates the specific error code flagged by

TurboTuneSQL. How to proceed: lets suppose this field contains string MIIABCL:After searching for string MIIABCL in TurboTuneSQL-Messages Guide, youwill find message SQLTMIIABCLW. Other examples: - After searching string PGVIONF, you will find message SQLTPGVIONFW(table/view not found) - After searching string FIX4001, you will find message SADBFIX4001W (Sqltext not found)

Dprog Uniq: Total number of distinct programs using identical SQL. This total is retrieved from product repository.

Dprog Simil: Total number of distinct programs using similar SQL. This total is retrieved from product repository.

SQL Text: First 77 bytes of SQL text

Other additional information may be obtained here: SQLs Recognized by TurboTuneSQL .


318

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Max Objects Other Filters: Program Name Program Name Range Table Name(s) Table Name and Qualifier Unique Name Database Name


Sort Field Field Header PROG Program Name DESC Desc SNUM S Num UNIQ Uniq GTAB GTAB GCOL GCOL GSRT GSRT STMT Stmt ID SECTNO Sectno CURS Cursor I I(Isolation Level) C Sql Comment COLL Collection PT Precompile Timestamp QUAL Bind Qualifier / Connect Id OWN OwnerTAB TableNameF F (Flag Error) ERMG ErrMsg DPROGU DistPgm Unique DPROGS DistPgm Simil



319



(E)ExplainReport SREX-SQLs Explain InformationAttention:As the commands UPDATE or DELETE relate to a DECLARE cursor, the explain Report will show as a SELECT command associated to the DECLARE cursor as well as the StmtNo of the corresponding DECLARE cursor.












320

SRPD - Predicate Details

DB2 provides some additional Explain tables with more information which will helpyou to explain a query. These additional tables contain valuable information.

This report will show the following additional Explain tables: DSN_PREDICAT_TABLE DSN_FILTER_TABLE DSN_DETCOST_TABLE


SAMPLE REPORT


321

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> SRPD - Predicate Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: SADREXPO QueryNo: 0000005000 PlanTB Qual/Vs.: SADVQUAL / Explain Time: 2019-11-18-10.00.50.560000 Line Actions ------------------------------------------------------------------ (L)TableLeftC (R)TableRightC (I)ColLBelongIx (J)ColRBelongIx (S)SQLText (Z)Zoom ------------------------------------------------------------------------------> C Qb Pd Pl Left Type Right Stage B N %Filter No No No Column Column T G Factor - -- -- -- ------------------ -------- ----------------- --------- - - -------- 1 1 1 CREATOR LIKE 'A%' MATCHING Y N <0.00001 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

QbNo(*): A number used to identify each query block within a query.

PdNo(*): Number used to identify a predicate withins a query. PlNo(**): The number of the step in which the query indicated in QBLOCKNO was processed

Left Column / Right Column(*): If Left Column or Right Column of the predicate is a table column (tabno > 0), then this column indicates the column name. Other possible values are: – VALUE– COLEXP– NONCOLEXP– CORSUB– NONCORSUB– SUBQUERY– EXPRESSION– blanks

Type(*): Indicates the type the operation of the predicate. Valid values: – AND– OR– EQUAL– RANGE– BETWEEN– IN– LIKE– NOT LIKE– EXISTS– NOTEXISTS– SUBQUERY– HAVING– OTHERS

Clause(*): The clause where the predicate exists. – HAVING– ON– WHERE– SELECT

BT(*): (Boolean Term) Whether this predicate can be used to determine the truth value of the whole WHERE clause.

NG(*): (Negation)Whether this predicate is negated via NOT.

% Filter Factor(*):


322

The estimate Filter Factor (in percentage). It estimates the proportion of rows in a table for which the predicate is true. Those rows are said to qualify by that predicate. For instance: 20% mean that 20% of table rows will be searched by this predicate. The lower the value, the less lines to scan and will have great cpu savings.Dt Manager/RDS/Idx Manager

Stage(**):Indicates at which stage the Predicate is evaluated. Valid values: – Matching– Screening– Stage 1– Stage 2

SrArg(*): (Search Argument)Whether this predicate can be processed by data manager (DM). If it is not, then the relational data service (RDS) needs to be used to take care of it, which is more costly.Pdown(**): (Push Down)Whether the predicate is pushed down the Index Manager or Data Manager subcomponents for evaluation. Valid Values: I - The Index Manager subcomponent evaluates the predicate. D - The Data Manager subcomponent evaluates the predicate. blank - The predicate is not pushed down for evaluation. KeyF(*): (KeyField)Whether the predicate includes the index key column of the involved table for all applicable indexes considered by DB2.

JoinJoin(*):Whether the predicate can be used as a simple join predicate between two tablesAft(*): (After Join)Indicates the predicate evaluation phase. Valid values: A - After Join D - During Join blank - Not Applicable

Pred Add(*): (Added Pred)Whether it is generated by transitive closure, which means DB2 can generate additional predicates to provide more information for access path selection, when the set of predicates that belong to a query logically imply other predicates.Red(*): (Redundant Pred)Whether it is a redundant predicate, which means evaluation of other predicates in the query already determines the result that the predicate provides

OpenIO(***): The I/O cost for the non-correlated subquery. CPU(***): The CPU cost for the non-correlated subquery.Cost(***):The Total Cost for the non-correlated subquery.

IMLEAF:The number of index leaf pages scanned by Data Manager.

RowsQualif (OneCompRows)(***): The number of rows qualified after applying local predicates. DM(***):


323

The number of data manager rows returned (after all stage 1 predicates are applied). RDS(***):The number of RDS rows returned (after all stage 1 and stage 2 predicates are applied).

COMPCARD:The total composite cardinality.

Text(*): The transformed predicate text; truncated if exceeds 67 characters.

Left Owner / Right Owner(****): If predicate is a table column or a column expression in an index on expression, this column identifies the corresponding table owner within a query

Left Table / Right Table(****): If predicate is a table column or a column expression in an index on expression, this column identifies the corresponding table within a query

Direct Access(*):Whether the predicate is direct access, which means one can navigate directly to the row through ROWID.

Literal(*):This column indicates the literal value or literal values separated by colon symbols


Sort Field Field Header QBNO Qb No PRED Pd No PLNO Pl No LCOL Left Column TYPE Type RCOL Right Column CLAUSE Clause BT B T NG N G FFAC Filter Factor STAGE Stage SA S A PDOWN PDown KEYF KeyF JOIN Join AFT Aft ADD ADD RED RED IO OpenIO CPU OpenCPU COST OpenCostIMLEAF IMLEAFQUALIF Qualif


324

DM DMRows RDS RDSRows COMPCARD COMPCARDTEXT Text LOWN Left Owner LTAB Left Table ROWN Right Owner RTAB Right Table DA Direct Access LIT Literal Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(L)TableLeftC Report TB00-Table Definition from DB2 Catalog(Left Column)

(R)TableRightC Report TB00-Table Definition from DB2 Catalog(Right Column)



NOTES:

Columns containing the value of '-' means that value is not applicable or not found.

(*) This information was extracted from table: DSN_PREDICATE_TABLE

(**) This information was extracted from table: DSN_FILTER_TABLE(Based on informations QbNo and PdNo obtained from table DSN_PREDICATE_TABLE)

(***) This information was extracted from table: DSN_DETCOST_TABLE(Based on informations PlNo obtained from table DSN_FILTER_TABLE) (Based on informations QbNo obtained from table DSN_PREDICATE_TABLE)

(****) This information was extracted from table: PLAN_TABLE(Based on informations QbNo and table number obtained from table DSN_PREDICATE_TABLE)


325

SRPG - Programs List - History

This report shows all programs loaded into TurboTuneSQL Repository.Only programs processed by TurboTuneSQL from DBRM data set, DB2 Catalog, SQLSequential data set and Dynamic SQLs will be shown here.


SAMPLE REPORT


326

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 13 of 13 Option ===> SRPG - Programs List - History Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner : Table Name : Program Name : Stmt Uniq : Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (P)ProgW (B)ProgC (S)SQLs (M)PlanTableComp (E)Explain (O)Objects (Q)TableC (Z)Zoom ------------------------------------------------------------------------------> C Program Collection S Bind Qualifier Program Timestamp E Schema - ------------ ------------- - -------------- -------------------------- - DSN@EP2L DSNDYNAMICSQL W IVPQUAL 1900-01-01-00.00.00.000000 * DSN@EP2L DSNTEP2 W IBMUSER 2013-11-06-10.21.30.449912 * DSN@EP2L DSNTEP2 S IBMUSER 2013-11-06-10.21.30.449912 * ZIVPBT01 SADVCOL S SADVQUAL 2019-11-13-12.50.03.150767 * ZIVPBT02 SADVCOL S SADVQUAL 2019-11-13-12.50.13.277510 * ZIVPBT03 SADVCOL S SADVQUAL 2019-11-13-12.50.21.297217 * ZIVPBT04 SADVCOL S SADVQUAL 2019-11-13-12.50.23.696782 * ZIVPBT05 SADVCOL S SADVQUAL 2019-11-13-12.50.26.363359 * ZIVPBT06 SADVCOL S SADVQUAL 2019-11-13-12.50.28.876517 * ZIVPBT07 SADVCOL S SADVQUAL 2019-11-13-12.50.35.157686 * ZIVPBT08 SADVCOL S SADVQUAL 2019-11-13-12.51.57.132150 * ZIVPBT09 SADVCOL S SADVQUAL 2019-11-13-12.50.37.286116 * ZIVPBT10 SADVCOL S SADVQUAL 2019-11-13-12.50.39.359227 * ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS



S:Source Type. Indicate where this program was found. Valid Values:– S: DB2 Catalog– T: Sequential File– W: Dynamic SQL– D: DBRM data set

Bnd Qualifier or Connect Id:This field has several meanings: – For Static SQLs imported from DB2 Catalog this is the DB2 Bind Qualifier– For Static SQLs imported from DBRM data set this is the default table owner– For Dynamic SQLs from remote connection collected by DB2 Performance Traces


Prepare


using z/OS macros (the final computed value is very close to PrecompileTimestamp). .


E: Indicates if this program was found in workload, according to current filters. Attention: Only Program Name and Precompile Time (contoken) are verified.Collection ID is not checked. Valid values: – '*' Program was found– Blank Program was NOT found

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source


327

Explain Code Source Max Objects Other Filters: Program Name Program Name Range - use wildcard '*' for programs started with a given name Table Name(s) Table Name and Qualifier Unique Name Database Name


Sort Field Field Header PROG Program COLL Collection S S (Source Type) BQUA Bnd Qualifier / Connect Id PT Program Timestamp E E (Indicates if this program was found in workload)







(E)PlanTablesReport SREX-SQLs Explain Information



328

SRPS - SQLs List from History

This report shows all SQL statements loaded into TurboTuneSQL Repository.

So, only SQLs processed by TurboTuneSQL from DBRM data sets, DB2 Catalog, SQLSequential data set and Dynamic SQLs will be shown here.



SAMPLE REPORT


329

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 5 of 5 Option ===> SRPS - SQLs List - History Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner : Table Name: Collid: SADVCOL Program Name: ZIVPBT01 Database : Stmt Uniq: Group Tab : Group Col : Stmt Num : Source/Explain Request Code:( DBBG / DBBG ) ColName: Line Actions ------------------------------------------------------------------ (S)SQLText (P)ProgW (R)ProgS (U)SUniqueW (K)SUniqueS (C)CallDet (E)Explain (W)SQLW (X)SSimilW (L)SSimilS (O)Objects (G)IXModel (D)Details (F)SQLCom (Z)Zoom ------------------------------------------------------------------------------> C Program Desc D S Num Uniq Gtab Gcol Gsrt Cursor E Dprog Dprog C Uniq Simil - ------------ ------- - ----- ---- ---- ---- ---- -------- - ------- ------- - ZIVPBT01 DECLARE N 191 AAFA 90E4 901C 0000 CRMQT * 1 1 ZIVPBT01 REFRESH N 218 90BB 90E4 0000 0000 * 1 1 ZIVPBT01 OPEN N 224 AAFA 90E4 901C 0000 CRMQT * 1 1 ZIVPBT01 FETCH N 230 AAFA 90E4 901C 0000 CRMQT * 1 1 ZIVPBT01 CLOSE N 242 AAFA 90E4 901C 0000 CRMQT * 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Desc:Short SQL Statement description. Examples: SELECT, DELETE, etc.Attention: For dynamic SQLs, OPEN command can be sometimes appear as a SELECT command.

D:Dynamic SQL Command. Valid values:– 'Y' This is a Dynamic SQL– Blank This is a Static SQL






Cursor:SQL Declare Cursor Name

E: Indicates if SQL command was found in Workload. Valid Values:– ‘*’ SQL was found in Workload– Blank SQL was not found in Workload– '?' SQL Command not supported (like SET), so we do not if was executed

For more information check SQLs Recognized by TurboTuneSQLAttention: Only Program Name, Precompile Time (contoken), statement number are verified. Collection ID is not checked.

Dprog Uniq: Total number of distinct programs using identical SQL. This total is retrieved from product repository.

Dprog Simil: Total number of distinct programs using similar SQL. This total is retrieved from product repository.




330


using z/OS macros (the final computed value is very close to PrecompileTimestamp).



I:Isolation Level (from BIND option or at SQL level). Valid values:– R - RR - Repeatable Read. – S - CS - Cursor Stability. – T - RS - Read Stability. – U - UR - Uncommited Read. – L - RS - Read Stability with a lock-name – X - RR - Repeatable Read with a lock-name – Blank: Unspecified. Valid only for:

– Dynamic SQLs– SQLs imported by option 'T' - SQL Sequential data set with SQLs DBRM from

the DBRMLIB data sets



generated. Check field 'Extract Err Msg' for detail error code. E - This statement was flagged in error by TurboTuneSQL when executing

DB2 Explain command. Check field 'Explain Err Msg' for detail error code.


TurboTuneSQL. How to proceed: lets suppose this field contains string MIIABCL:After searching for string MIIABCL in TurboTuneSQL-Messages Guide, youwill find message SQLTMIIABCLW. Other examples: - After searching string PGVIONF, you will find message SQLTPGVIONFW(table/view not found) - After searching string FIX4001, you will find message SADBFIX4001W (Sqltext not found)


331

Other additional information may be obtained here: SQLs Recognized by TurboTuneSQL . Explain Err Msg This field will contain error returned by TurboTuneSQL Explain Utility It may be a SQLCODE or other codes related to TurboTuneSQL Explain.Valid values: -nnnn DB2 Explain function has returned a negative sqlcode where nnnn is the


'OK' - Explain was successfully executed (returned sqlcode was 0).'----' - It may have 2 meanings:

- Explain was never performed OR Explain was successfully executed but it was done in a TurboTuneSQLrelease prior to V9R3.

N??? - If value starts with "N", please refer to corresponding TurboTuneSQL messageSQLTSSAN??? Normally, explain command was not successfull executed. When a DECLARE statement does not contain a SELECT clause, or mayreceive codes: NCAS099, CAST091 or QCAS091.

S??? - If value starts with "S", please refer to corresponding TurboTuneSQL messageSQLTNCAS???

T??? - If value starts with "T", please refer to corresponding TurboTuneSQL messageSQLTCAST???

CopyPlan Err Msg This 2 bytes fields contains the error code related to last time that was processed CopyPlan Table function of TurboTuneSQL Explain Utility : Valid values: 'OK' - Plan Table rows were copied successful '–' - It may have 2 meanings:

- Copy was never performed OR - Copy was successful executed but it was done in a TurboTuneSQL release prior to V9R3.

04 - Program loaded from DBRMLIB PDS are not processed06 - Program/Collid/Contoken not found in SYSPACKAGE07 - Plan Name not found in SYSPLAN08 - Statement not found in Stmt_info to be copied09 - Program/Bind Time not found in Plan Table 10 - More than one Statement Original = 0 can not be processed For more information about meaning of 'CopyPlan Err Msg' values, search TurboTuneSQL-Messages Guide . Use following convention: - For code 01: search message: SADBPLAN001 - For code 18: search message: SADBPLAN018

Bind Qualifier or Connect Id:This field has several meanings:

For Static SQLs imported from DB2 Catalog this is the DB2 Bind Qualifier– For Static SQLs imported from DBRM data set this is the default table owner– For Dynamic SQLs from remote connection collected by DB2 Performance Traces


Prepare


332

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Program Name Program Name Range Table Name(s) Table Name and Qualifier Unique Name Database Name


Sort Field Field Header PROG Program Name DESC Desc D D (Dynamic SQL Command) SNUM S Num UNIQ Uniq GTAB GTAB GCOL GCOL GSRT GSRT CURS Cursor E E (Indicates if this program was found in workload)DPROGU DistPgm Unique DPROGS DistPgm Simil C Sql Comment PT Program Timestamp COLL Collection I I(Isolation Level) F F (Flag Error) ERMG ErrMsg BQUA Bind Qualifier / Connect Id



333






(D)DetailsReport STIF-SQL Source Detail Information







(C)CallDet Report AC00-Programs Summary will be called to show the SQL program callcommand.

(O)ObjReport SROJ-List DB2 objects



334

SRPT- Plan Table TABLE Information

This report shows DB2 Explain information from TurboTuneSQL Repository or from user Plan Table.

Information here was generated from Plan_Table table.


SAMPLE REPORT


335

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> SRPT - Plan Table Information Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: SADREXPO Stmt Unique: E0DD0A54 Exp Time: 2019-11-18-10.03.39.600 Stmt Num : 0000005000 Original Format: ? PlanTB Qual/Vs.: SADVQUAL / Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (Q)TableC (C)IndexColsH (B)IndexColsC (F)SQLCom (Z)Zoom (G)IXModel (S)SQLText ------------------------------------------------------------------------------> C Pl ME TB AC MT I P SRTN SRTC Owner Name Accessname no th no ty co o f UJOG UJOG - -- -- -- -- -- - - ---- ---- -------- ------------------ ------------------ 1 0 1 I 1 N NNNN NNNN SYSIBM SYSTABLES DSNDTX01 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Query No:This information represents a number given to identify the statement being explained. Check TurboTuneSQL Explain Utility for more information.

Original format (OF): Y - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) WASpreserved. Check utility parameter Explain Parameter Mark option.N - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) was NOTpreserved. Check utility parameter Explain Parameter Mark option.C - TurboTuneSQL Explain Utility has executed Plan Table Copy Function for this SQL.Original program work variables format has been preserved. Only most recent BIND-TIME has been copied from User Plan Table to TurboTuneSQL Plan Table. Originalprogram work variables format has been preserved. Check utility parameter ExecutionMode. ? - Online Explain Utility (command EXPL) has executed on online DB2 Explain.B/A - Explain created by TurboTuneSQL Automatic Index Recommendation: B - Show Explains made BEFORE Index Recommendation A - Show Explains made AFTER Index RecommendationU - User Plan Table data was directly acessed and shown. For more information about SQL formats, go to program original format and non-original format.

PlanTB Qual/Vs:

Plan Table QualifierIs the qualifier name for Plan_table to retrieve the informations in its corresponding layout used according to DB2 version. In case of this field is not informed, it will assumethe value from profile registered previously. Plan Table Version:User Plan Table layout version used to retrieve the informations.

PlNo:The number of the step in which the query indicated in QBLOCKNO was processed.

MEth:Join method used for the step: - 0: First table accessed, continuation of previous table accessed - 1: Nested loop join - 2: Merge scan join - 3: Sorts needed by ORDER BY, GROUP BY, SELECT DISTINCT, UNION a quantified predicate, or an IN predicate - 4: Hybrid join

TBno:Values are for IBM use only.

ACty:Access Type. Valid Values:I - Index Access. I1 – Index Scan, one-fetch. N - Index Scan, predicate contains IN Keyword. R - Tablespace Scan. M - Multiple Index Scan(Check Access types: MX, MI or MU). MX - Index Scan. MI - Intersection - multiple indexes. MU - Union - multiple indexes.


336

T - Space Index (star join works file).DI - Intersection of DOCID DU - Union of DOCID DX - XML Index Scan E - Direct row access P - Dynamic pair-wise ix scan RW - Work file scan MQT V - By Buffer INSERT within SELECT blank - Not applicable.

MTco:Match Cols - Number of Index columns used in Index access. This can happenfor accesstypes: I, I1, N, DX, or MX.


Pf:Will DB2 use prefetch (read pages in advance) S – Yes. Sequential method will be used L – Yes. Page list method will be used D – Yes. Dynamic prefetch may occur blank – Not. Prefetch will be used. But this can be changed at run-time. Dynamicprefetch)



Owner:The creator of the new table accessed in this step, blank if METHOD is 3.

Name:Table Name

Accessname:DB2 Index Name used for accesstypes: I, I1, N, DX, or MX

Accesscreator:The creator of the new table accessed in this step

ExplanationShort explanation of DB2 Access Plan

For more information, please go to Appendix F- Plan tables description .


337


Sort Field Field Header PLNO Plno (PlaNo) METH MEth (Method) TBNO TBno (TableNo) ACTY ACty (Access Type) MTCO MTco (MathCols) IO IO (Index Only) PF PF (Prefetch) SRTN SRTN / UJOG SRTC SRTC / UJOG OWN Owner NAME Name ACES AccessnameACEC AccesscreatorEXPL Explanation



(T)TableHReport HT00-Tables Definition from History


(C)IndexColh Report HC01-History Index Columns

(B)IndexColCReport TC01-Table Index Columns






338

SRSD - Sort Details

DB2 provides some additional Explain tables with more information which willhelp you to perform explain for a query. These additional tablescontain valuable information.

This report will show the following additional Explain tables: DSN_SORT_TABLE DSN_SORTKEY_TABLE DSN_DETCOST_TABLE


SAMPLE REPORT


339

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> SRSD - Sort Details Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: SADREXPO QueryNo: 0000005000 PlanTB Qual/Vs.: SADVQUAL / Explain Time: 2019-11-18-10.06.28.070000 Line Actions ------------------------------------------------------------------ (S)SQLText (Z)Zoom ------------------------------------------------------------------------------> C Qb Pl Ord Srt Exp Length Key Data Type SrtN SrtC Text (short) No No No No Type Size - -- -- --- --- ---- ------ ---- --------------- ---- ---- -------------------- 1 2 1 1 COL 130 130 VARCHAR ---- G "SYSIBM"."SYSTABLES" 1 3 1 1 EXP 5 5 FIXED(31) ---- O SUM("SYSIBM"."SYSTAB ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

QbNo(*):A number used to identify each query block within a query.

PlNo(*): The number of the step in which the query indicated in QBLOCKNO was processed

OrdNo(**): The sequence number of sort Key.

SrtNo(*):The sequence number of the sort.

ExpType(**):The type of the sort key. Valid values: – COL– EXP– QRY

Length(**): Length of sort key.

KeySize(*):The sum of the lengths of the sort keys.

DataType(**):The data type of sort key. Valid values: – HEXADECIMAL– CHARACTER– PACKED FIELD– FIXED(31)– FIXED(15)– DATA– TIME– VARCHAR– PACKED FLD– FLOAT– TIMESTAMP– UNKNOWN DATA TYPE

SrtN(*):Indicates de reasons for sort of the New table. Valid values: – The first byte is 'G' (GROUP BY), or otherwise blank. – The second byte is 'J' (JOIN), or otherwise blank. – The third byte is 'O' (ORDER BY), or otherwise blank. – The fourth byte is 'U' (UNIQUENESS), or otherwise blank. '----' (value not found or not applicable).

SrtC(*):Indicates de reasons for sort of the Composite table. Valid values: – The first byte is 'G' (GROUP BY), or otherwise blank. – The second byte is 'J' (JOIN), or otherwise blank. – The third byte is 'O' (ORDER BY), or otherwise blank. – The fourth byte is 'U' (UNIQUENESS), or otherwise blank. – '----' (value not found or not applicable).


340

Text (short column)(**):The sort key text, can be a column name, an expression, or a scalar subquery, or Record ID.

Sort New Input Table(***):Cols: The number of columns as sort input for a new table. Rows:The number of rows as sort input for a new table. Recsz: The record size for new table.Pages:The page size for new table. Runs:The number of runs generated for a sort of a new table. Merge:The number of merges needed during a sort.

Sort Composite Table:(***)

Cols:The number of columns as sort input for a composite table. Rows:The number of rows as sort input for a composite table. Recsz:The record size for a composite table. Pages:The page size for a composite table. Runs: The number of runs generated during the sort of a composite table.Merge:The number of merges needed during a sort of a composite table.

Text(**):The sort key text, can be a column name, an expression, or a scalar subquery, or Record ID.


Sort Field Field Header QBNO Qb No PLNO Pl No SORT Sort No EXPT Exp Type LEN Length KEYS Key Size DTYPE Data Type SRTN SrtN SRTC SrtC TEXT Text SNCOLS SNCols SNROWS SNRows SNRECS SNRecs SNPAGES SNPages SNRUNS SNRuns SNMERGE SNMerge


341

SNRUNS SNRuns SNMERGE SNMerge SCCOLS SCCols SCROWS SCRows SCRECS SCRecs SCPAGES SCPages SCRUNS SCRuns SCMERGE SCMerge





OBSERVATIONS:

Columns with value '-' means that the value is not applicable or not found.

(*) This information was extracted from table: DSN_SORT_TABLE(**) This information was extracted from table: DSN_SORTKEY_TABLE

(Based on informations QbNo and PlNo obtained from table DSN_SORT_TABLE)

(***) This information was extracted from table: DSN_DETCOST_TABLE(Based on informations PlNo obtained from table DSN_SORT_TABLE) (Based on informations QbNo obtained from table DSN_PREDICATE_TABLE)


342

SRTX - SQL Text

This report shows SQL text stored in TurboTuneSQL Repository.

SAMPLE REPORT


343

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 9 of 9 Option ===> SRTX - SQL Text Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: ZIVPBT01 Stmt Uniq: AAFAC03D Gtab: 90E44245 Gcol: 901C2D1A Source/Explain Request Code:( DBBG / DBBG ) OPEN ONLINE EXPLAIN: Y/N ------------------------------------------------------------------------------ Text ------------------------------------------------------------------------------ DECLARE CRMQT CURSOR FOR SELECT * FROM IVPQUAL . IVPTABLE_MQT WHERE COD_CLIENT 1 = : H OPEN CRMQT FETCH FROM CRMQT INTO : H , : H CLOSE CRMQT ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

OPEN ONLINE EXPLAIN: Use this option to open Online Explain Utility using current SQL. Only explainable SQLs will be copied (examples: select, declare, insert, update, delete, merge, etc).

Text: SQL text. Attention: – This report always list all SQLs with same statement unique number in this same

program.– If you list a SQL Statement with a Cursor Name, SQL Declare, Open, Close, Fetch,

etc will be listed together because all of them have received the same Uniquenumber.

– In some cases, when you have several identical SQL commands in same program,SQL text will be shown several time.



344

SSCO - User SQL Comments

This report is used to show the SQL Comments input by users. This Report producessame information as in LSTCOM Online Command, but here Request Code is used asfilter. It will also allows you to update the SQL Comments.

SAMPLE REPORT WHEN STARTED FROM ONLINE MENU REPORT

SAMPLE REPORT WHEN STARTED FROM LINE ACTION

When triggered by Line Action (normally by letter `F`), SSCO will try to retrieve a SQLcomment using Unique Number. If not found, Group Table and Group Column numberswill be used.


345

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2Option ===> SSCO - User SQL Comments Profile : IVP DB2 SSID : DBBG ----------------------------------------------------------------------------- Command Line: NEWCOM Filters -----------------------------------------------------------------------Line Actions ------------------------------------------------------------------(P)Update (D)Delete (U)SUniqueW (X)SSimilW (K)SUniqueS (L)SSimilS (R)Refresh (Z)Zoom ----------------------------------------------------------------------------- C S Uniq Gtab Gcol Short Description Date - - ---- ---- ---- ---------------------------------- ---------- AAFA ANALYZED BY JOHN 2019-11-18 85E2 ANALYZED BY MARY 2019-11-18 ******************************* Bottom of data ********************************

TurboTuneSQL V120 ------------------- SQL Comments ---------------------- 10:10 Option ===> COMMENT FOUND USING UNIQUE SQL SSCO - User SQL Comments Profile : IVP DB2 SSID : DBBG Status : Choose the key format to access your comment: Identical SQLs: Unique Number : AAFAC03D OR Similar SQLs : Group Table Number : Group Columns Number : Description: ANALYZED BY JOHN

FIELD DESCRIPTIONS

Status:TurboTuneSQL will let you attribute value, therefore any character is valid.Suggestions: –Use 'O' for SQLs that need attention–Use 'C' for solved SQLs–etc

Unique:Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.



Short Description/Description:Free Text.

Date:Creation Date.

AVAILABLE FILTERS



Sort Field Field Header S S (Status) UNIQ Uniq GTAB GTABGCOL GCOL DESC Short Description DATE Date



346


(P)UpdateReport SSCO-SQL Comment – update option

(D)DeleteReport SSCO-SQL Comment – delete option



(K)SUniqueSReport SRPS-SQLs List - Only Identical SQLs

(L)SSimilW Report SRPS-SQLs List – Only Similar SQLs

(R)RefreshRefresh screen list


AVAILABLE COMMAND LINE

NEWCOM – Start Report SSCO – SQL Comment - create a new SQL comment


347

STCX - SQL Text

This report shows SQL text from SYSPACKSTMT DB2 catalog or from SQL Cache Area or other sources.

SAMPLE REPORT


348

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 2 of 2 Option ===> STCX - SQL Text Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Program Name: ZIVPBT01 Collid: SADVCOL Stmt Uniq: Stmt Id: 000000000000665360 Seq No: OPEN ONLINE EXPLAIN: Y/N ------------------------------------------------------------------------------ Text ------------------------------------------------------------------------------ DECLARE CRMQT CURSOR FOR SELECT * FROM IVPQUAL . IVPTABLE_MQT WHERE COD_CLIENT 1 = : H ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

OPEN ONLINE EXPLAIN: Use this option to open Online Explain Utility using current SQL. Only explainable SQLs will be copied (examples: select, declare, insert, update, delete, merge, etc). Text: SQL text as read from DB2 Catalog.



349

STIF - SQL Source Detail Information

This report shows detail information about SQL statements loaded intoTurboTuneSQL Repository (Source Information). So, only SQLs processed byTurboTuneSQL from DBRM data set, DB2 Catalog, SQL Sequential data set andDynamic SQLs will be shown here.


SAMPLE REPORT


350

TurboTuneSQL V120 ------------------- Online Report --------------------- 10:14 Option ===> STIF - SQL Source Detail Information Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Stmt Num : 0000000191 Stmt Uniq: AAFAC03D Gtab: 90E44245 Gcol: 901C2D1A Program Name: ZIVPBT01 Source/Explain Request Code:( DBBG / DBBG ) ----------------------------------------------------------------------------- Request Code : DBBG Flag Error: N - Extract Err Msg :OK Cursor Name : CRMQT Explain Err Msg :-- Prep-Exec Name: CopyPlan Err Msg:-- Bind Qualifier: SADVQUAL Collid: SADVCOL Source Type : S Contoken : 1AE0942C1A686BC0 PcTimeStamp (calculated) : 2019-11-13-12.50.03.150767 Version : 2019-11-13-06.50.03.150767 Date Defined : 2019-11-13-08.56.08.478397 Options : APOST / PERIOD HostLang : 3 Flags : Syn FSelect GBy OBy Or BadIns Dist Min Max N Y N N N N N N N Tables Views Synonyms Aliases 1 1 0 0

FIELD DESCRIPTIONS

Request Code:Source Request Code

Collid:DB2 Collection Name

Cursor Name:SQL declare cursor name

Prep-Exec Name:Prepares name in SQL declare statement

Bind Qualifier:This field has several meanings: – For Static SQLs imported from DB2 Catalog this is the DB2 Bind Qualifier– For Static SQLs imported from DBRM data set this is the default table owner– For Dynamic SQLs from remote connection collected by DB2 Performance Traces

this is the DB2 Connect Id – For Dynamic SQLs from SQL Cache Area this is the Current SQLID which initially

executed the SQL PREPARE.

Source Type:Source where this program was found. Valid Values:– T: Sequential File– S: DB2 Catalog– W: Dynamic SQL from DB2 Traces or SQL Cache Area– D: DBRM data set

Contoken:Consistency token for the package (in hexadecimal format).

Precompile Timestamp (calculated):DB2 Precompile Timestamp calculated from contoken conversion using z/OS macros.

Precompile Timestamp (from the DB2 system Catalog):DB2 Precompile Timestamp from DB2 Catalog.Note:– Please, do not consider this date for remote programs, Triggers and for programs

extracted from SQL Cache Area.

Date Define:This Timestamp indicates when this SQL statement was stored into TurboTuneSQL tables.

Options:Shows String Delimiter and Decimal Point option. Possible Results: Apost / Comma

Quote / Comma Apost / Period Quote / Period

F:(Flag Error) Shows if TurboTuneSQL found an error while loading this SQL. Valid Values: Y: This statement was flagged in error by TurboTuneSQL. Check field 'Extract Err Msg' for detail error code.


351

N: This statement was NOT flagged in error by TurboTuneSQL. W:This statement was flagged in warning by TurboTuneSQL.

When TurboTuneSQL can not resolve column in the SQL, a warning code isgenerated. Check field 'Extract Err Msg' for detail error code.

E: This statement was flagged in error by TurboTuneSQL when executing DB2 Explain command.

Check field 'Explain Err Msg' for detail error code.


TurboTuneSQL. How to proceed: lets suppose this field contains string MIIABCL:After searching above string in TurboTuneSQL-Messages Guide, you willfind message SQLTMIIABCLW. Other examples: - After searching string PGVIONF, you will find message SQLTPGVIONFW(table/view not found) - After searching string FIX4001, you will find message SADBFIX4001W (Sqltext not found) Other additional information may be obtained here: SQLs Recognized by TurboTuneSQL .

Explain Err Msg This field will contain error returned by TurboTuneSQL Explain Utility It may be a SQLCODE or other codes related to TurboTuneSQL Explain.Valid values: EXP-nnnn- DB2 Explain function has returned a negative sqlcode where nnnn is the


'OK' - Explain was successful executed (returned sqlcodes was 0).'----' - It may have 2 meanings:

- Explain was never performed OR Explain was successful executed but it was done in a TurboTuneSQL releaseprior to V9R3.

N??? - If value starts with "N", please refer to corresponding TurboTuneSQLmessage SQLTSSAN??? Normally, explain command was not successfull executed. When a DECLARE statement does not contain a SELECT clause, or mayreceive codes: NCAS099, CAST091 or QCAS091.

S??? - If value starts with "S", please refer to corresponding TurboTuneSQLmessage SQLTNCAS???

T??? - If value starts with "T", please refer to corresponding TurboTuneSQLmessage SQLTCAST???

CopyPlan Err Msg This 2 bytes fields contains the error code related to last time that was processed CopyPlan Table function of TurboTuneSQL Explain Utility : Valid values: 'OK' - Plan Table rows were copied successful '–' - It may have 2 meanings:

- Copy was never performed OR


352

- Copy was successful executed but it was done in a TurboTuneSQL releaseprior to V9R3.

04 - Program loaded from DBRMLIB PDS are not processed06 - Program/Collid/Contoken not found in SYSPACKAGE07 - Plan Name not found in SYSPLAN08 - Statement not found in Stmt_info to be copied09 - Program/Bind Time not found in Plan Table 10 - More than one Statement Original = 0 can not be processed For more information about meaning of 'CopyPlan Err Msg' values, search TurboTuneSQL-Messages Guide. Use following convention: - For code 01: search message: SADBPLAN001 - For code 18: search message: SADBPLAN018

Host Lang:Host Language indicator. Values: B – AssemblerD - C LanguageF – Fortran P - PL/I 2 - VS COBOL II or IBM COBOL Release 1 3 - IBM COBOL 4 – C Blank - Remote rebound package or trigger Check IBM DB2 documentation for more information.

Flags : Syn FSelect GBy OBy Or BadIns Dist Min Max Values for each flag: Syn: Y - There are table synonyms is this SQL

N - There aren’t any table synonyms FSelect: Y - There is a SELECT * in this SQL

N - There isn’t a SELECT *GBy: Y - There is a Group By in this SQL

N - There isn’t a Group By OBy: Y - There is an Order By in this SQL

N - There isn’t an Order By BadIns: Y - This is a SQL Insert without column name specifications

Like “Select *”, this SQL will always require re-work when the related table is altered.N - This is a SQL INSERT with column name specifications.

Dist: Y - This SQL has Distinct functionN - This SQL hasn’t got Distinct function

Min: Y - This SQL has Min functionN - This SQL hasn’t got Min function

Max Y - This SQL has Max functionN - This SQL hasn’t got Max function

Total Tables:Total Tables involved in this SQL.

Total View:Total Views involved in this SQL.

Total Synonyms:Total Synonyms involved in this SQL.

Total Alias:Total Alias involved in this SQL.


353



354

ST00 - Group Tables Summary

This report shows an overview of all DB2 Activities summarized by Group of Tablesin all SQLs.



SAMPLE REPORT


355

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 6 of 6 Option ===> ST00 - Group Tables Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Table Name: Database: Plan Name: Line Actions ------------------------------------------------------------------ (X)ProgXref (P)ProgW (S)SQLs (G)IXModel (Q)TableC (Z)Zoom ------------------------------------------------------------------------------ C Gtab Name Owner T DB2 CPU(ALL) CPU avg SQL SQLs - ---- ---------------- -------- - ---------------- -------------- ----------- 90E4 IVPTABLE_MQT IVPQUAL V 1.455 0.291185 5 90E4 IVPTABLE_T001 IVPQUAL T 1.455 0.291185 5 E24D IVPTABLE_T001 IVPQUAL T 0.023 0.001046 22 90CE VIEW2 IVPQUAL V 0.003 0.000686 5 CB85 IVPTABLE_T002 IVPQUAL T 0.001 0.000903 2 0000 (SET ) U 0.000 0.000200 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Name:This field normally represents a Table Name. Also, this field can be:– A DB2 DDL Object, normally a DB2 Table name (check field T (Object type)– A Dynamic SQL command when no DB2 table was accessed. Example: SQL SET

CURRENT DATE. SQL commands will be always presented between ‘()’.

Sometimes you will see an object called UNKNOWN. This can happen if the SQL sourcewas not found. You should check:

o If informed Request Code is the right Request Code.o This is a non-Extractable SQL command. Check Appendix E. Limits to get

more information.

Owner: Table Owner.

T: Object type: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY M MATERIALIZED QUERY TABLE P IMPLICIT TABLE CREATED FOR XML COLUMNS or TABLESPACET TABLE V VIEW X AUXILIARY TABLE Y SYNONYM I INDEX D DATA BASE S STORAGE GROUP K PACKAGE F FUNCTION O STORED PROCEDURE R TRIGGER E DISTINCT TYPE J JAR N NONE r Remote Object U UNKNOWN


CPU avg SQL:Total DB2 CPU Average per SQL.



356

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: DB2 Connection Type Database Name Table Name(s)


Sort Field Field Header GTAB GTAB NAME Name OWN Owner T T (Object type) CPU DB2 CPU CPUAVG DB2 CPU Avg SQLS SQLs



(X)ProgXref Report RF00-Programs Cross Reference


(S)SQLs Report ST01-SQLs Summary


(T)TableH Report HT00-Tables Definition from History

(Q)TableC Report TB00-Table Definition from DB2 Catalog



357

ST01 - SQLs Summary

This report shows information about executed SQL statements grouped by program name, statement number and Unique number (according to product SQL inventory facility). The information is based on DB2 Performance Traces and SQL Cache Area.



3 - When filtering by table, all referenced tables in the SQL will be searched (not only the first table that appears in SQL).

SAMPLE REPORT


358

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 24 of 35 Option ===> ST01 - SQLs Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: Correlation: Connection Type: Table Owner : Table Name: Stmt Uniq: Group Tab : Group Col : SSID: Plan Name : Collection: Line Actions ------------------------------------------------------------------ (D)Details (S)SQLText (E)Explain (L)SQLXref (N)Expand (G)IXModel (B)ProgC (P)ProgW (R)ProgS (U)SUniqueW (X)SSimilW (Y)SQLS (F)SQLCom (Z)Zoom ------------------------------------------------------------------------------> C Program T S Num Desc Uniq Gtab Gcol Gsrt DB2 CPU(ALL) %CPUA SQLs - -------- - ----- ------ ---- ---- ---- ---- --------------- ----- ----------- ZIVPBT01 C 218 REFRES 90BB 90E4 0000 0000 1.453622 97.9 1 ZIVPBT10 P 227 UPDATE 5A37 E24D 32D0 0000 0.002075 0.1 1 ZIVPBT10 C 227 UPDATE 5A37 E24D 32D0 0000 0.001607 0.1 1 ZIVPBT06 P 226 UPDATE 5A37 E24D 32D0 0000 0.001569 0.1 1 ZIVPBT02 P 225 INSERT 4173 E24D 0000 0000 0.001488 0.1 1 ZIVPBT09 P 233 UPDATE 5A37 E24D 32D0 0000 0.001292 0.1 1 ZIVPBT07 P 227 UPDATE 5A37 E24D 32D0 0000 0.001235 0.1 1 ZIVPBT02 C 225 INSERT 4173 E24D 0000 0000 0.001217 0.1 1 ZIVPBT08 P 231 UPDATE 5A37 E24D 32D0 0000 0.001214 0.1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


T: Trace Source: Valid Values:

'P' - This program comes from Performance Traces 'C' - This program comes from SQL Cache Area

S Num:SQL Statement Number from DB2 precompiler. - When Trace Source is 'C' (*CACHE*), this value represents the line number of a prepare command.






DB2 CPU(ALL):Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP). Value N/A mean that this SQL may have executed but TurboTuneSQL is not able tocapture it from traces.




DB2 Elapsed: Total DB2 Elapsed Time. Value N/A mean that this SQL may have executed but TurboTuneSQL is not able to capture it from traces.


359



CPU avg SQL:Total DB2 CPU Average per SQL.

F: Fetch sensitivity. Valid Values: 'S' - Fetch sensitive 'I' - Fetch insensitive Blank - Fetch sensitivity unspecified. Dynamic SQLs from SQL Cache Area will always be ' ' - blank



Owner: First owner of first table name referenced in the SQL statement.

Table (first): First table name referenced in the SQL statement. It may be any object name (table, view, synonym, etc).

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Program Name Program Name Range Table Name(s) Table Name and Qualifier DB2 Connection Type


360


Sort Field Field Header PROG Program T T (Trace Source) SNUM S Num DESC Desc UNIQ Uniq GTAB GTAB GCOL GCOL GSRT GSRT CPU DB2 CPU SQLS SQLs ELAPSED DB2 Elapsed CPUAVG DB2 CPU Avg F F (Fetch sensitivity) C Sql Comment Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)






(N)Expand Report ST1N-Show details grouped by date and time


(B)ProgC Report SRIC-Program List Catalog


(R)ProgSReport SRPG-Programs Summary Source




361





362

ST02 - Identicals SQLs Summary

This report shows information about executed SQL statements grouped by IdenticalSQLs (according to product SQL inventory facility). The information is based on DB2 Performance Traces and SQL Cache Area.



SAMPLE REPORT


363

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 10 of 10 Option ===> ST02 - Identicals SQLs Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Stmt Uniq : Table Name : Plan Name: Database : Connection Type: Line Actions ------------------------------------------------------------------ (D)Detais (S)SQLs (L)SQLXref (N)Expand (P)ProgW (Z)Zoom ------------------------------------------------------------------------- C Uniq DB2 CPU(ALL) CPU avg SQL DB2 Elapsed Dprog SQLs - ---- ---------------- -------------- ---------------- ----- ----------- 90BB 1.453 1.453622 1.560 1 1 5A37 0.012 0.001291 0.015 5 10 A816 0.003 0.000686 0.003 1 5 85E2 0.003 0.000775 0.004 1 4 4173 0.002 0.001352 0.002 1 2 35B4 0.002 0.000594 0.002 1 4 AAFA 0.002 0.000576 0.002 1 4 16B2 0.001 0.000958 0.005 1 2 29B2 0.001 0.000903 0.002 1 2 2CD2 0.000 0.000200 0.000 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS



CPU avg SQL:Total DB2 CPU Average per command.

DB2 Elapsed:Total DB2 Elapsed Time.

Dprog:Total distinct programs using this SQL.


AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Database Name Table Name(s) Unique Number DB2 Connection Type


Sort Field Field Header UNIQ Uniq CPU DB2 CPU CPUAVG DB2 CPU Avg ELAPSED DB2 Elapsed DPROG DPROG SQLS SQLs



364




(N)Expand Report ST1N-Show details grouped by date and time





365

ST03 - Similar SQLs Summary

This report shows information about executed SQL statements grouped by SimilarSQLs (according to product SQL inventory facility). The information is based on DB2 Performance Traces and SQL Cache Area.



SAMPLE REPORT


366

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 8 of 8 Option ===> ST03 - Similar SQLs Summary Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Group Tab : Group Col : Table Name: Plan Name: Database : Connection Type: Line Actions ------------------------------------------------------------------ (S)SQLs (P)ProgW (D)Details (Z)Zoom ------------------------------------------------------------------------------- C Gtab Gcol DB2 CPU(ALL) CPU avg SQL DB2 Elapsed Dprog SQLs - ---- ---- ---------------- -------------- ---------------- ------ ----------- 90E4 0000 1.453 1.453622 1.560 1 1 E24D 32D0 0.017 0.001075 0.023 7 16 90CE CF61 0.003 0.000686 0.003 1 5 E24D 0000 0.003 0.000775 0.004 1 4 E24D 0000 0.002 0.001352 0.002 1 2 90E4 901C 0.002 0.000576 0.002 1 4 CB85 B33D 0.001 0.000903 0.002 1 2 0000 0000 0.000 0.000200 0.000 1 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS




CPU Avg SQL:Total DB2 CPU Average per statement.



AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Database Name Table Name(s) DB2 Connection Type


Sort Field Field Header GTAB GTAB GCOL GCOL CPU DB2 CPU CPUAVG DB2 CPU Avg ELAPSED DB2 Elapsed DPROG DPROG SQLS SQLs



367







368

ST04 - SQLs with TABLE or INDEX SCAN

This report shows information about executed SQL statements where an DB2 indexor a DB2 Table Scans may have happened (product Plan Table is read to search forscans). The information is based on DB2 Performance Traces and SQL Cache Area and fromDB2 Explain data.



SAMPLE REPORT


369

TurboTuneSQL V120 ------------------- Online Report --------------------- 10:19 Option ===> ST04 - SQLs With TABLE or INDEX SCAN Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 Program Name : Stmt Uniq : Connection Type: SSIDs : Line Actions ------------------------------------------------------------------ (S)SQLText (D)Details (Y)SQLS (E)Explain (G)IXModel (Z)Zoom (P)ProgW (R)ProgS (F)SQLCom (U)SUniqueW (X)SSimilW ------------------------------------------------------------------------------- C Program S Num Desc Uniq Gtab Gcol DB2 CPU(ALL) SQLs C - -------- ----- ------- ---- ---- ---- ---------------- ----------- - ZIVPBT78 456 SELECT FABC AAB2 ACBC 1.888 112 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS




Uniq: Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.






‘*’ - SQL COMMENT found'?' - SQL COMMENT may have be created by line command 'F'Blank - SQL COMMENT was not found nd

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Program Name Unique Number DB2 Connection Type


370


Sort Field Field Header PROG Program SNUM S Num DESC Desc UNIQ Uniq GTAB GTAB GCOL GCOL CPU DB2 CPU SQLS SQLs C Sql Comment









(R)ProgSReport SRPG-Programs Summary Source






371

ST1N - SQL Details Grouped by Date and Time

This report shows the activity of the selected SQL grouped by date and time.



SAMPLE REPORT


372

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> ST1N - SQL Details Grouped by Date and Time Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Program Name: ZIVPBT10 Stmt Num : 0000000227 Stmt Uniq: 5A3771B6 Correlation : Plan Name: Type: P SSID: Collection : Cnty: Summarize by: (M/D/Y) Line Actions ------------------------------------------------------------------ (S)SQLs (L)SQLXref (D)Details (E)Explain (Z)Zoom ------------------------------------------------------------------------------- C DateR TimeR I Desc T DB2 CPU(ALL) DB2 Elapsed SQLs - ---------- -------- -- ----- -- ---------------- ---------------- ----------- 2019-11-13 09.00.00 60 UPDAT P 0.002 0.002 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Summarize by (option to summarize DB2 time values based on the original display): M - Overall DB2 CPU and Elapsed Time by YEAR/MONTH D - Overall DB2 CPU and Elapsed Time by YEAR/MONTH/DAY Y - Overall DB2 CPU and Elapsed Time by YEAR ' ' - To switch back to the original display for this report which is ordered by Date

and Time as default Note: On every option, the fields Time, I, Desc and T are applicable

DateR:Date when the SQL was ended

TimeR:Time when the SQL was ended (rounded by parameter “Reduce Trace Data”)



T: Trace Source: Valid Values: 'P' – This SQL comes from Performance Traces 'CS' – This SQL comes from SQL Cache Area (Static)

'CD' - This SQL comes from SQL Cache Area (Dynamic)




AVAILABLE SORT FIELDS Sort Field Field Header DATE DateR TIME TimeR I I (Trace Interval)DESC DESCCPU DB2 CPU ELAPSED DB2 Elapsed Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


373








374

STRF - SQLs Cross Reference

This report will show a cross reference of all SQLs captured by TurboTuneSQL. Thisinformation shown here is based on Performance Traces and DB2 SQL Cache Area.

SAMPLE REPORT


375

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> STRF - SQLs Cross Reference Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 2019-11-13 2019-11-13 TimeR: 09.00.00 09.00.00 GrName: Program Name: ZIVPBT10 Stmt Num: 0000000227 Stmt Uniq: 5A3771B6 SSID: Correlation: Plan Name: CnTy: Source/Explain Request Code:( DBBG / DBBG ) Line Actions ------------------------------------------------------------------ (P)ProgW (R)ProgS (E)Explain (S)SQLText (Y)SQLS (W)SQLW (C)Correlation (N)Plan (Z)Zoom ------------------------------------------------------------------------------> C Program T S Num DB2 CPU DB2 Elapsed DB2 Wait - -------- - ----- ------------------- ------------------- ------------------- ZIVPBT10 P 227 *N/A* *N/A* *N/A* ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


T:Trace Source. Valid Values: 'P' - This program comes from Performance Traces. 'C' - This program comes from SQL Cache Area.


Unique: Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm. Other possible values: '-SRCNF-' - Unique number not found. Please check Request Code for Source'-DYNAM-'- This SQL is dynamic. Cross reference of dynamic SQLs is not

fully supported by TurboTuneSQL. In this case, the Unique number usedas filter may have executed in any current line shown in this report.

'-ST/DY-' - This SQL is both dynamic and static. In this case, crossreference is not fully supported (like dynamic SQLs).

'-MORE1-'- This SQL is static, but there are more than one SQL (uniquenumber) in same statement number (normally precompile number is 0).In this case, cross reference is not fully supported (like dynamic SQLs).

PlanName:Plan name. Sometimes, where plan name information is not available a value *N/A* or *CACHE* willbe shown.

Correlation:Correlation name.When this information comes from DB2 SQL Cache Area this field will contains: – STMT-TOKEN if it contains a valid value– String '*CACHE*' it STMT-TOKEN does not contain a valid value.

STMT-TOKEN is an identification string provided by programs.




*CACHE/S* - CONNECTION IS UNKNOWN. A STATIC SQL WAS EXECUTED


376


UNKNOWN - CONNECTION IS UNKNOWN.

A value '*CACHE*' will be always generated when this information comes from DB2 SQLCache Area.




Primary Authorization:DB2 Primary Authorization for this thread.


WsTransWorkStation Transaction Name

WsConId or Schema Name:This field has 2 meanings:

– When this thread comes from a DB2 Remote location, this field will be thePrimary Authorization ID from Connection or Signon– When this thread is the a Stored Procedure/User Define Function/Trigger,

this field will be the corresponding schema name for the Stored Procedure,or User Defined Function Name or Trigger Name.

WsName or User Rout:This field has 2 meanings:

– When this thread comes from a DB2 Remote location, this field will be theworkstation name

– When this thread is a Stored Procedure/User Define Function/Trigger, this fieldwill be the corresponding object name like Stored Procedure Name, User DefinedFunction Name or Trigger Name.

Location:DB2 Location Name (DRDA).





377

DB2 Wait:Total DB2 Wait Time. When Trace Source is 'A' - Accounting trace: This is the total wait time spent by the

whole program in this reference (program, correlation, plan and time).

When Trace Source is 'C' - SQL Cache Area: This is the total wait time spent by this command in this reference (program, stmt number, correlation, plan and time).

When Trace Source is 'P' - Performance traces: No meaning. A value 'N/A' will be generated.

This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.

DB2 CPU: Total DB2 CPU time spent by this program in this correlation/plan.If trace type is: 'A' - CPU time spent on a normal CP processor. 'C' - CPU time spent on all processors (CP plus SE/ZIIP). 'P' - TurboTuneSQL are not computing this value when information comes performance traces. Value 'N/A' will be always generated. This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information. This field was summarized by: DataSharing group nameDataSharing member nameSSID DB2 Plan nameDB2 Correlation nameProgram nameProgram precompile timeDB2 Connection typeDate and time when this thread finishedWorkStation User IdWorkStation Transaction NameStored Procedure schema/nameTrigger schema/nameUser Define Function (UDF) schema/nameCollection NamePrimary AuthorityDB2 Location Name (DRDA)

DB2 Elapsed: Total DB2 Elapsed time spent by this program in this Correlation.A value 'N/A' will be always generated when this information comes from DB2Performance Trace. This field was summarized by: DataSharing group nameDataSharing member nameSSID DB2 Plan nameDB2 Correlation nameProgram nameProgram precompile timeDB2 Connection typeDate and time when this thread finishedWorkStation User IdWorkStation Transaction Name


378

Stored Procedure schema/nameTrigger schema/nameUser Define Function (UDF) schema/nameCollection NamePrimary AuthorityDB2 Location Name (DRDA)This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.




Sort Field Field Header PROG Program Name SNUM SQL Statement Number from DB2 precompiler UNIQ UniquePLAN Plan Name CORR Correlation Name CONN Collection Name DATE Date TIME TimeCOLL Collection PRIM Primary Authorization WSUSERID WorkStation User Id WSTRANS WorkStation Transaction Name WSCONID WsConId or Schema Name WSNAME WsTrans LOCA Location PT Program TimestampWAIT DB2 WaitCPU DB2 CPU ELAPSED DB2 Elapsed SQLS SQLs



379



(R)ProgS Report SRPG-Programs Summary Source

(E)Explain Report SREX-Statement Explain Information

(S)SQLText Report SRTX-SQL Text

(Y)SQLS Report SRPS-SQLs List

(W)SQLW Report ST01-Statements Summary

(C)Correlation Report ACOR-DB2 CORRELATION Summary

(N)Plan Report APLN-DB2 PLAN Summary



380

SW01 - SQLs by Statement type and Table

This report shows an overview of SQL activities by command type for a table.



SAMPLE REPORT


381

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 3 of 3 Option ===> SW01 - SQLs by Statement type Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 TimeR: 00.00.00 23.59.59 GrName: Table Owner : Table Name : Database: Program Name: ZIVPBT03 Correlation: Plan Name : Line Actions ------------------------------------------------------------------ (Z)Zoom ------------------------------------------------------------------------------- C Desc DB2 CPU(ALL) CPU avg SQL DB2 Elapsed SQLs - ---------------- ---------------- -------------- ---------------- ----------- OPEN 0.001 0.000734 0.002 2 FETCH 0.001 0.001210 0.002 1 CLOSE 0.000 0.000423 0.000 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Desc: SQL command short description.

DB2 CPU(ALL):Total DB2 CPU spent by this statement in all processors (CP plus SE/ZIIP). This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to AppendixNumerical and Time formats for additional information.

DB2 CPU Avg:Total DB2 CPU Average per statement. This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.

DB2 Elapsed: Total DB2 Elapsed Time. This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.

SQLs: Total SQLs executed.

AVAILABLE FILTERS

Table Name / Source Request Code


Sort Field Field Header DESC Name CPU DB2 CPU CPUAVG DB2 CPU AvgELAPSED DB2 ElapsedSQLS SQLs





382

TB00 - Table Definitions from DB2 Catalog

This report shows all Tables found in DB2 Catalog.

Note: All other fields are shown using TurboTuneSQL Numeric format. Please, refer to Appendix Numerical and Time formats for additional information.

SAMPLE REPORT


383

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 16 of 16 Option ===> TB00 - Table Definition from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name: IVPTABLE_T* Database: Line Actions ------------------------------------------------------------------ (C)Columns (O)ColXref (I)Indexes (G)IXModel (V)IXVirt (B)IXRecom (W)TableW (F)ForeignK (L)AllIxColum (X)PlanTable (S)SQLs (A)AutIdxRec (R)ProgS (D)CatlgDep (M)PlanTableComp (H)PlanTableSum (Z)Zoom ------------------------------------------------------------------------------> C Name Owner T Rows Npages Statstime - ------------------ -------- - ----------- ----------- ----------------------- IVPTABLE_T000 IVPQUAL T 0 0 2019-10-02-09.37.01.749 IVPTABLE_T001 IVPQUAL T 9,999 313 2019-10-02-09.37.01.749 IVPTABLE_T002 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T003 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T004_X IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T005 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T006 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T008 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T009 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T100X IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T100Y IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_T900 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_TABLE_WIT IVPQUAL T 9 1 2019-10-02-09.37.01.749 IVPTABLE_TC01 IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_TDUP IVPQUAL T -1 -1 0001-01-01-00.00.00.000 IVPTABLE_TYYY IVPQUAL T -1 -1 0001-01-01-00.00.00.000 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name: Table name.

Owner: Table Owner.

T: Object type: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY H History M MATERIALIZED QUERY TABLE P IMPLICIT TABLE CREATED FOR XML COLUMNS or TABLESPACET TABLE V VIEW X AUXILIARY TABLE Y SYNONYM

Rows:Total Table Rows.

NPages:Total Number of Active Pages.


Database: Database Name.

Tablespace: Tablespace Name.

Parents: Number of relationships in which the table is a dependent. It will be 0 in some cases:


Child: Number of relationships in which the table is a parent. It will be 0 in some cases:


Audit: Value of the audit option: Value of the audit option: A - All C - Change blank- None or the row describes a view, an alias, or a created temporary table.


384

DataCap: Records the value of the DATA CAPTURE option for a table: blank - No Y - Yes For a created temporary table, DATACAPTURE is always blank.

Scheme: Encoding scheme for tables, views, and local aliases: E - EBCDIC A - ASCII M - Multiple CCSID set or multiple encoding schemes M - Multiple CCSID set or multiple encoding schemes U - UNICODE blank- For remote aliases;

EDPROC: Name of the edit procedure. It will be blank in some cases:

–View–Alias–Table without an edit procedure

VALPROC: Name of the validation procedure. It will be blank in some cases:

–View–AliasTable without a validation procedure

AVAILABLE FILTERS

Basic Filters (always used - Online Menu or Line Action) DateR (Start/End Date when this object has ended - rounded) TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Explain Code Source Max Objects Other Filters: Table Name(s) - use wildcard '*' for tables started with a given name Table Name(s) and Owner Owner Database Name Database Name Range


385


Sort Field Field Header NAME Name (Table Name)OWN Owner T T (Object type) ROWS Rows NPAGES Npages STAT StatstimeDBASE Database Name TSPACE Tablespace Name PARENTS Parents CHILD Children AUDIT Auditing DTCAP Data capture SCHEME Encoding Scheme EDPROC EDPROC VALPROC VALPROC Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(C)ColumnsReport TC00-Table Columns

(O)CoXrefReport SRCO-DB2 Columns Cross Reference

(I)IndexesReport TI00-Table Indexes


(V)IXVirtStart IXVT Utility

(B)IXRecomTurboTuneSQL Index Recommendation (manual and automatic) will be launched

(report XMNU).

(U)UpdStatUtility to update table statistics (UPDT).

(P)UpdHistTurboTuneSQL will read DB2 Catalog and will update TurboTuneSQL repository for

this current table.

(L)AllIxColumnsReport TC01-Table Index Columns

(X)Plan TableReport EX01-Cross Reference from PLAN TABLE


386

(W)TableWReport DB10-Table Summary





(H)PlanTableSumReport EX02-Plan Table Summary



387

TC00 - Columns Definitions from DB2 Catalog

DB2 Table Columns definition from DB2 Catalog.


SAMPLE REPORT


388

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 10 of 10 Option ===> TC00 - Column Definition from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Line Actions ------------------------------------------------------------------ (J)ColBelongIxC (S)SQLs (U)UpdStat (Z)Zoom ----------------------------------------------------------------------------- C ColName Data Type Null Length Precision Scale ColCardf - ------------------ ----------- ---- ------ --------- ----- ---------------- COD_CLIENT1 DECIMAL N 4 6 0 9,999 COD_AREACLI DECIMAL N 4 6 0 9,999 COD_CLIENT1_T1 DECIMAL N 4 7 0 9,999 COD_CLIENT_NUL_T1 DECIMAL Y 4 6 0 9,999 NAME_CLIENT1 CHAR N 30 30 0 9,999 NAME_CLIENT_NULT1 CHAR Y 30 30 0 3,714 ADDRESS_CLIENT1 CHAR Y 30 30 0 3,714 SSN_CLIENT1 INTEGER N 4 10 0 9,999 SSN_CLIENT_SMALLT1 SMALLINT N 2 5 0 9,999 TOT_ROWS SMALLINT N 2 5 0 1 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Colname:Column Name.

Data Type:Column Data Type. Examples:INTEGER Large integerSMALLINT Small integerFLOAT Floating-pointCHAR Fixed-length character stringVARCHAR Varying-length character stringLONGVAR Varying-length character stringDECIMAL DecimalGRAPHIC Fixed-length graphic stringVARG Varying-length graphic stringLONGVARG Varying-length graphic stringDATE DateTIME TimeTIMESTMP TimestampBLOB Binary large objectCLOB Character large objectDBCLOB Double-byte character large objectROWIDRow ID data typeDISTINCT Distinct type XML XML data typeBIGINT Big integerBINARY Fixed-length binary stringVARBIN Varying-length binary stringDECFLOAT Decimal floating point

Null:Null indicator.Y - null values can be acceptedN - null values can NOT be accepted


Precision:Precision. Number of digits for this column.



AVAILABLE FILTERS

Table Qualifier / Source Request Code Table Name(s) / Source Request Code


389


Sort Field Field Header COLN ColName TYPE Data Type N N (Null indicater) LEN Length PREC Prec SCALE Scale COLC ColCardf



(I)ColBelongIxHReport HI00-History Indexes

(J)ColBelongIxCReport TI00-Table Indexes

(S)SQLs Report SRPS-SQLs List

(U)UpdStat Utility to update columns statistics (UPDC)



390

TC01 - Index Columns from DB2 Catalog

This report shows DB2 Index Columns from DB2 Catalog. Note: Numeric fields are shown using TurboTuneSQL Numeric format. Please, refer toAppendix Numerical and Time formats for additional information.

SAMPLE REPORT


391

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 6 of 6 Option ===> TC01 - Indexes Columns from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Ix Creator : IVPQUAL Ix Name : IXTB105 Line Actions ------------------------------------------------------------------ (Z)Zoom ------------------------------------------------------------------------------> C ColName ColSeq O Data Type N Length Scale ColCardf - ------------------ ------ - --------- - ------ ----- --------------- COD_CLIENT1 1 A DECIMAL N 6 0 9,999 COD_AREACLI 2 A DECIMAL N 6 0 9,999 COD_CLIENT1_T1 3 A DECIMAL N 7 0 9,999 COD_CLIENT_NUL_T1 4 A DECIMAL Y 6 0 9,999 SSN_CLIENT1 5 A INTEGER N 4 0 9,999 SSN_CLIENT_SMALLT1 6 A SMALLINT N 2 0 9,999 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS


Colseq:Column sequence definition number.

O:Order of this column in the index. Valid values:A - Ascending D – DescendingBlank – Included columns

Data Type:Column Data Type. Examples: Decimal, Char, etc.

N:Null indicator. Valid values:Y - accept null values N - do not accept null values


Prec:Precision: number of digits for this column.




Sort Field Field Header COLN ColName COLS ColSeq O O (Column order) TYPE Data Type N N (Null indicater) LEN Length SCALE Scale COLC ColCardf Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)




392

TD00 - Database List from DB2 Catalog

This report will show all Databases found in DB2 Catalog Table. Note: Numeric fields are shown using TurboTuneSQL Numeric format. Please, refer toAppendix Numerical and Time formats for additional information.

SAMPLE REPORT


393

TurboTuneSQL V120 ------------------- Online Report -------- Row 1 to 29 of 59 Option ===> TD00 - Database List from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Database Name From: To: Line Actions ------------------------------------------------------------------ (S)TableSpace (Q)TableC (Z)Zoom ------------------------------------------------------------------------------ C Name CreateBy Bpool StGroup Member Create Timestamp - -------- -------- ----- -------- -------- -------------------------- DSN00001 SYSIBM BP0 SYSDEFLT 2013-05-16-14.43.30.845657 DSN00002 SYSIBM BP0 SYSDEFLT 2013-05-16-14.44.22.218075 DSN00003 SYSIBM BP0 SYSDEFLT 2013-05-16-14.44.46.838210 DSNDB01 SYSIBM 0001-01-01-00.00.00.000000 DSNDB04 SYSIBM BP0 SYSDEFLT 1985-04-01-00.00.00.000000 DSNDB06 SYSIBM 1985-04-01-00.00.00.000000 DSNDB07 IBMUSER BP0 SYSDEFLT 2019-01-17-17.25.25.459962 DSNRLST IBMUSER BP2 SYSDEFLT 2019-01-17-17.26.46.129946 DSNRGFDB IBMUSER BP2 SYSDEFLT 2019-01-17-17.26.53.938447 DSNOPTDB IBMUSER BP2 DSNOPTSG 2019-01-17-17.26.56.569128 DSNMDCDB IBMUSER BP2 SYSDEFLT 2019-01-17-17.27.18.045846 DEVQDB IBMUSER BP1 ADVSTG 2019-11-13-07.15.40.344682 ZJSDB IBMUSER BP1 ZJSSTG 2019-01-20-23.20.42.729694 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name:Database Name.

CreateBy: Database Creator.

BPool:Name of the default buffer pool of the table space.

Stgroup:Name of the default storage group of the database.

Member: The DB2 data sharing member name of the DB2 subsystem that uses this work file database. This column is blank if the work file database was not created in DB2 data sharing environment, or if the database is not a work file database as indicated by the TYPE column.

Create TimeStamp:Time when the CREATE statement was executed for the Database.

AVAILABLE FILTERS

Database Name.


Sort Field Field Header NAME NAMECREATEBY CreateBy STGROUP StGroup MEMBER Member CREATETS Create Timestamp



(S)TableSpaceReport T S 00 -Table Space Definition from Db2 Catalog




394

TI00 - Index Definitions from DB2 Catalog

This report show DB2 Indexes definitions from DB2 catalog.


SAMPLE REPORT


395

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 7 of 7 Option ===> TI00 - Index Definition from DB2 Catalog Profile : IVP DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Column Name: Line Actions ------------------------------------------------------------------ (C)Column (X)PlanTable (D)CatlgDep (H)PlanTableSum (V)IXVirt (U)UpdStat (Z)Zoom ------------------------------------------------------------------------------> C Creator IXName U C CRtio FullKeyCard Statstime - -------- ------------------ - - ----- ----------- -------------------------- IVPQUAL IXTB101 P N 100 9,999 2019-10-02-09.37.01.749879 IVPQUAL IXTB102 U N 100 9,999 2019-10-02-09.37.01.749879 IVPQUAL IXTB103 U N 100 9,999 2019-10-02-09.37.01.749879 IVPQUAL IXTB104 U N 100 9,999 2019-10-02-09.37.01.749879 IVPQUAL IXTB105 U N 100 9,999 2019-10-02-09.37.01.749879 IVPQUAL IXTB106 D N 100 9,999 2019-10-02-09.37.01.749879 IBMUSER IXSUB D N 100 1 2019-10-02-09.37.01.749879 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Creator: Index Creator.

IXName:Index Name.


D - Duplicates are allowed U - Unique P – Unique and primary indexC - Unique, used to enforce UNIQUE constraint or hash key N - Unique, defined with UNIQUE WHERE NOT NULL R - Unique, enforce the uniqueness of a non-primary parent keyG - Unique, enforce the uniqueness of ROWID

X - Unique, enforce the uniqueness value of XML column C: Clustering – Whether CLUSTER option was specified when the index was created. Valid values: N - No Y - Yes

CRatio:Cluster Ratio.

FullkeyCard:Number of distinct values of this Index.


FirstKeyCardf: Number of distinct values of the first key column

IndexSpc: Name of the index space

Bpool: Name of the buffer pool used for the index

Nlevl: Number of levels in the index tree


Compress: Indicates whether index compression is active: N - Index compression is not active Y - Index compression is active.

–LastUsed:The date when the index is used for SELECT, FETCH, searched UPDATE, searched DELETE, or used to enforce referential integrity constraints.


396

ReorgLastTime:The timestamp that the REORG INDEX utility was last run on the index space or partition.

–IXType:Indicates whether this is a partitioned index: Valid values: D - This is a partitioned secondary index on a table in a partitioned table space. This is a DPSI - Data-partitioned secondary index.

N - This is a nonpartitioned index (primary or secondary) on a table in a table space (partitioned or nonpartitioned). If table space is partitioned this is a NPSI - nonpartition secondary index.

P - This index is both partitioned and partitioning index on a table in a partitioned table space that uses table-controlled partitioning.

I - This index is both partitioned and partitioning index on a table in a partitioned table space that uses index-controlled partitioning.

Piecesize: Maximum size of a data set in kilobytes for secondary indexes.If value is 0, this is a partitioned index.

PQTY: The value is the primary space allocation.

CurVs: The version number describing the newest format of data index space. A zero indicates that the index space had never been versioned.

AvgKeyLen: Average length of keys within the index.

X: Identifies the type of extended index. This information is only available for DB2 V9 and UP which will be shown as '-' for back level DB2 version. Valid values:

N - Node ID index S - Index on a scalar expression T - Spatial index V - XML index blank - Simple Index


Sort Field Field Header CREATOR Creator IXNM Name (Index Name) U U (Index Type) C C (Clustering) CRTIO CRtio (Cluster Ratio) FKEY FullKeyCard STAT Statstime CARDF FirKeyCardf INDEX IndexSpc BPOOL Bpool NLEVL Nlevl (Number of levels) NLEAF Nleaf (Number of active leaf)


397

PART Partitioned COMP Compress Examples: SORT field D (sort field using descending order) SORT field A (sort field using ascending order)


(C)ColumnsReport TC01-Table Index Columns

(X)PlanTableReport EX01-Cross Reference from PLAN TABLE


(H)Access SummaryReport EX02-Plan Table Summary

(V)IXVirtStart IXVT Utility

(U)Access SummaryUpdate statistics for iindexes (UPDI)



398

TS00 – Table Space Definition from DB2 Catalog

This report show DB2 Table Space definitions from DB2 catalog.


SAMPLE REPORT


399

TurboTuneSQL V120 ------------------- Online Report ---------- Row 1 to 1 of 1 Option ===> TS00 - Table Space Definition from DB2 Catalog Profile : DBBG DB2 SSID : DBBG Filters ----------------------------------------------------------------------- Database: DSN00026 Line Actions ------------------------------------------------------------------ (Q)TableC (Z)Zoom ------------------------------------------------------------------------------- C Name Database BPool N.Parts PGSize N.Tables - ------------------ -------- -------- ------- -------- -------- TABLE01 DSN00026 BP2 0001 0004 0001 ******************************* Bottom of data ********************************

FIELD DESCRIPTIONS

Name: Table Space name.

Database:Database name for this table space.

BPoolBuffer pool for this table space.

N.PartsNumber of partitions for this table space.

PGSizePage size for this table space.

N.TablesNumber of tables in this table space.

AVAILABLE FILTERS

Database Name.


Sort Field Field Header NAME NAMEBPOOL BPOOLNTABLES N.TablesPGSIZE PGSize






400

UPDC - Update columns statistics

This utility will assist you to update access path statistics in DB2 Catalog.It is triggered by report TC00.

SAMPLE REPORT


401

TurboTuneSQL V120 ------------------- Virtual Indexes ------------------- 10:29 Option ===> UPDC - Update Column statistics Profile : IVP DB2 SSID : DBBG Filter------------------------------------------------------------------------- Table Owner: IVPQUAL Table Name : IVPTABLE_T001 Column Name: COD_CLIENT1 ------------------------------------------------------------------------------- Column statistics ------------------------------------------------------------- Colcardf : 9999 Number of distinct values for the column Low2Key : Second lowest value of the column / (type / to input hex values)column F0000002 High2Key : Second highest value of the column / (type / to input hex values) F0009998

FIELD DESCRIPTIONS

Table Owner/Name: Table owner and table name.

Column name: Column name.

ColCardf: Number of distinct values for the column Valid values: >=-1

HIGH2KEY: Second highest value of the column If you type '/' in the indicated field, input must be in hexadecimal. Example: In hexadecimal format : F1F2F3 Not in hexadecimal format: 123

LOW2KEY: Second lowest value of the column. If you type '/' in the indicated field, input must be in hexadecimal.


402

UPDI - Update Index statistics

This utility will assist you to update access path statistics in DB2 Catalog.It is triggered by report TI00.

SAMPLE REPORT


403

TurboTuneSQL V120 ------------------- Virtual Indexes ------------------- 10:30 Option ===> UPDI - Update Index statistics Profile : IVP DB2 SSID : DBBG Filter------------------------------------------------------------------------- Table Owner: IVPQUAL Table Name: IVPTABLE_T001 Ix Creator : IVPQUAL Ix Name : IXTB101 ------------------------------------------------------------------------------- Index statistics -------------------------------------------------------------- FirstKeyCardf: 9999 Number of distinct values of the first key column FullKeyCardf : 9999 This is the number of distinct values for this Index Nlevels : 2 Number of levels in the index tree Nleaf : 28 Number of leaf pages in the index ClusterRatiof: 100 Clustering percentage Clustered : Y Cluster indicator (yes/no) DataRepeatFactorF: 313 Number of times that data pages are repeatedly scanned after the index key is ordered ordered

FIELD DESCRIPTIONS


Ix Creator/Name:Index creator and name.

Index statistics FirstKeyCardf: Number of distinct values of the first key column Valid values: >=-1

FullKeyCardf: This is the number of distinct values for this Index Valid values: >=-1

Nlevels: Number of levels in the index tree Valid values: >=-1

Nleaf: Number of leaf pages in the index Valid values: >=-1

ClusterRatiof: Clustering percentage Valid values: >=0 and <=100 (exception value: -2).

Clustered: Cluster indicator (yes/no) Valid values: 'N' or 'Y' DataRepeatFactorF:Number of times that data pages are repeatedly scanned after the indexkey is ordered Valid values: >=-1


404

UPDT - Update Table statistics

This utility will assist you to update access path statistics in DB2 Catalog.It is triggered by report TB00.

SAMPLE REPORT


405

TurboTuneSQL V120 ------------------- Virtual Indexes ------------------- 12:18 Option ===> UPDT - Update Table statistics Profile : IVP DB2 SSID : DBBG Filter------------------------------------------------------------------------- Table Owner: IVPQUAL Table Name: IVPTABLE_T001 ------------------------------------------------------------------------------- Table statistics -------------------------------------------------------------- Cardf : 9988 Total number of rows in the table Npagesf : 313 Total number of pages used by the table Pctrowcomp: 0 Percentage of rows compressed Pctpages : 99 Percentage active table space pages that contain rows Spacef : 1252 Kilobytes of DASD storage Tablespace statistics --------------------------------------------------------- Nactivef : 372 Number of active pages in the table space

FIELD DESCRIPTIONS


Table statistics FirstKeyCardf: Total number of rows in the table Valid values: >=-1

Npagesf:Total number of pages used by the table Valid values: >=-1

Pctrowcomp:Percentage of rows compressed Valid values: >=-1

Npagesf:Total number of pages used by the table Valid values: >=-1

Pctrowcomp:Percentage of rows compressed Valid values: >=-1

Pctpages:Percentage active table space pages that contai Valid values: >=-1

Spacef:Kilobytes of DASD storage Valid values: >=-1 Tablespace statisticsNactivef:Number of active pages in the table space Valid values: >=-1


406

ZOOM - ZOOM Panel

This report will show all previous fields in extended format which do not fiton the screen. Fields with 128 bytes will be shown here.

Note: Fields related to CPU, WAIT and ELAPSED time are shown using hhhhhh:mm:ss.tttttttime format. The time spent in special processor ZIIP is not shown.All other fields are shown using TurboTuneSQL Numeric format. Please, refer to Appendix Numerical and Time formats for additional information.

SAMPLE REPORT

FIELD DESCRIPTIONS

This report show most of all fields in previous panel in extend format size.



407

TurboTuneSQL V120 ------------------- ZOOM Report ---------- Row 1 to 24 of 24 Option ===> ZOOM PANEL Profile : IVP DB2 SSID : DBBG ------------------------------------------------------------------------------- Extended FIELDs from Panel: SRPG - Program Source Information ------------------------------------------------------------------------------ Program ------------------------------------------------------------------------ ZIVPBT01 Collection ------------------------------------------------------------------------ SADVCOL S (Source) ------------------------------------------------------------------------ S Bnd Qual / Conn Id ------------------------------------------------------------------------ SADVQUAL Version ------------------------------------------------------------------------ 2019-11-13-06.50.03.150767 Time inserted ------------------------------------------------------------------------ 2019-11-13-08.56.08.478397 ******************************* Bottom of data ********************************

Chapter 4. Batch Report Reference

This chapter has a reference of all TurboTuneSQL Batch Reports. Like Online Reports,information is obtained from TurboTuneSQL Repository.

After start TurboTuneSQL CLIST, Batch reports are located at “4.3 – Batch Reports“ or “5.4 Batch Reports for Indexes”.

Batch Reports screen for option 4.4 – Batch Reports:

Batch Reports for option 5.4 – Batch Reports for Indexes:


408

TurboTuneSQL V120 ------------------ Batch Reports ---------------------- 13:32 Option ===> TYPE "JCL" TO GENERATE JOBS Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Filters --------------------------------------------------------------------- DateR : 1900-01-01 2100-12-31 Plan Name : CnTy: TimeR : 00.00.00 23.59.59 Correlation Name : Program: SSID: Source/Explain Req Code DBBG / DBBG Unique : Table Creator: Table Name: Level : 3 Trace Origin: A Max Objects: 00250 Type / to select a report ---------------------------------------------------- WORKLOAD (REPOSITORY) WORKLOAD SHORT (REPOSITORY) / AW00: Accounting Cache Summary / SH01: Programs (all) / LG01: SQLs Log Impact / SH02: Program Batch / NW01: SQLs Network Impact / SH03: Program Online / PG00: Program Summary / SH04: Stor Procedure / ST02: SQLs Identicals / SH05: CICS/IMS / SH06: Programs Batch/Online / SH07: Tables Summary / SHFE: Fetch/Open Summary

TurboTuneSQL V120 -------------- Index Batch Reports ---------------- 13:35 Option ===> TYPE "JCL" TO GENERATE JOBS Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Filters --------------------------------------------------------------------- Program Name : Table Creator : Source/Explain Req Code: DBBG / DBBG Table Name : Index LastUsed: months Level: 3 Max Objects: 00250 Type / to select a report ---------------------------------------------------- / TI00: Index Usage / TI01: Duplicated Indexes



All TurboTuneSQL Batch Reports have a Report code and a Report name. Use ‘/’ toselect reports you want to be executed.

Notes: ● For Batch reports is possible select relative dates.

If informed '*' in year, month or day, it will be processed as current date.Example:****/**/01 until ****/**/31. It will be interpreted: current year/current month/01 until current year/current month/31

● TurboTuneSQL always uses dot (“.”) as decimal point notation.● Fields related to CPU, WAIT and ELAPSED time are shown using

hhhhhh:mm:ss.tttttt time format. The time spent in special processor ZIIP is not shown.

● All other fields are shown using TurboTuneSQL Numeric format. Please, refer to Appendix Numerical and Time formats for additional information.

● When running TurboTuneSQL on Trial mode, a number of lines selected to“Trial Mode” will be shown with wildcards in batch reports. For any questionscontact your local representative.

● After changing any parameter, you will only need to re-create the JCL if it isspecified.

Filters

TurboTuneSQL has some basic filters to help you select what you want to print in thereports. Use TurboTuneSQL FILTER command to setup what will be printed.

Tip: Filter is an Online command used to filter both Batch and Online Reports.TurboTuneSQL Report Program always uses information stored in TurboTuneSQLProfiles to select which filters will be used. That means if you use the FILTER Onlinecommand while reports are running, unexpected results may occur. So the best optionis to create a new TurboTuneSQL Profile just to start up and run Batch Reports. In afuture release, this will no longer be necessary.

Requires JCL modification if any field changed: No

JCL

Type ‘JCL’ command to create the JCL necessary to execute selected reports. A newscreen is displayed to choose a data set where TurboTuneSQL Batch Report JCL toexecute the report will be stored. The TurboTuneSQL default member name forTurboTuneSQL Workload Batch Report is J900REPW. Member name can be changed bythe user.

This is a sample JCL for TurboTuneSQL Batch Report:

//SQLTREPW EXEC PGM=SQLTMAIN,PARM='SADBTREPW' //STEPLIB DD DISP=SHR,DSN=<HLQSADV>.LINKLIB // DD DISP=SHR,DSN=<DB2>.SDSNEXIT


409

// DD DISP=SHR,DSN=<DB2>.SDSNLOAD // DD DISP=SHR,DSN=<CEE>.SCEERUN//SADVRPL DD DISP=SHR,DSN=<HLQSADV>.LINKLIB //* //AW00 DD SYSOUT=* //ST02 DD SYSOUT=* ….MORE REPORT CODES//SYSIN DD DSN=<your.profile.data set (profile.name), DISP=SHR

Notes: (1) For each Report Code there is a corresponding ddname. Example, ddname AW00

will receive data from AW00 Report.(2) Some information may not show up in the report if the SQL Extractor failed for any

reason or failed to load its results into TurboTuneSQL Repository (Source Tables).Check Appendix E. Limits to get more information.

(3) Always check If you informed the correct Request Code field on FILTER screen.(4) Check Appendix JCL Description for a concise of all JCL generated by TurboTuneSQL.(5) <HLQSADV> is the TurboTuneSQL installation HLQ where product libraries were

installed.

Batch Report Summary

These are TurboTuneSQL batch reports. Every time you choose a new report, you mustregenerate JCL. Any other fields, if changed, does not requires JCL regeneration.

DB2 CATALOG TI00 Index Usage (from DB2 Catalog)TI01 Duplicate Index Over – Catalog (from DB2 Catalog)

WORKLOAD REPOSITORYAW00 Accounting Summary (from product repository) LG01 SQLs log activity (from product repository) NW01 SQLs impact in Network (from product repository) PG00 Program Summarized (from product repository)ST02 Overview of all ‘identical’ SQLs (from product repository) WORKLOAD SHORT (REPOS.) Report data will be taken from product repository. These are 'short' reports: just oneline of information will be shown for each object.SH01 Programs Accounting Traces (from product repository) SH02 Batch Programs Accounting Traces (from product repository) SH03 Online Programs Accounting Traces (from product repository) SH04 Stored Stored Procedures (from product repository) SH05 CICS and IMS transactions (from product repository) SH06 Online/Batch Programs (from product repository) SH07 Table Summary from Workload (from product repository) SHFE Fetch/Open Summary (from product repository)


410

Code Description

AW00 Accounting Summary

LG01 Prints all SQLs with the highest impact in DB2 log activity

NW01 Show SQLs with the highest impact in Network and DB2 Cross Memory

PG00 Program Summarized

SH01 Short description of all programs found in DB2 Accounting Traces

SH02 Short description of all batch programs found in DB2 Accounting Traces

SH03 Short description of all online programs found in DB2 Accounting Traces

SH04 Short description of all Stored Procedures found in DB2 Traces

SH05 Short description of all CICS and IMS transactions found in Traces

SH06 Short description of all online/batch programs found in DB2 Traces

SH07 Table Summary from Workload

SHFE Fetch/Open Summarized

ST02 Overview of all ‘identical’ SQLs

TI00 Index Usage - Catalog

TI01 Duplicate Index Over - Catalog


411

AW00 - ACCOUNTING SUMMARY REPORT

List objects from DB2 accounting trace. Information printed in this report is grouped by:● DB2 SSID● CONNECTION ID● CONNECTION TYPE● CORRELATION NAME● PLAN NAME

Always check field Accumulation Type to know what type of information is beingreported.Field Report Level controls which Accumulation Type will be reported.

SAMPLE REPORT


412

====================================================================================================================================AW00 ACCOUNTING SUMMARY REPORT DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 10MEMBER NAME: PRINT SQL TEXT: N SSIDS: TRACE ORIGIN : ALLSOURCE REQUEST CODE:IVP1 REPORT LEVEL: 1EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00TOTAL CPU : 36:42.827323 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

ACCUMULATION TYPE:CONNECTION ID SUMMARY (CNID) TRACE ORIGIN:ACCT-RRSAF (TYPE=CNID) COMMITS : 976 SELECTS : 15 %CPU(WKLD) : 4.25% INSERTS : 9 TOTAL TIMES AVERAGE UPDATES : 414 ----------- ----------- DELETES : 6 APL ELAPSED : 36:55:07.867352 19.318003 OPENS : 7,138 APL CPU : 2:06.450130 0.018379 FETCHES : 17,922 DB2 ELAPSED : 2:45:09.720121 1.440366 CLOSES : 7,138 DB2 CPU(CP) : 1:33.802017 0.013634 LOCK_TABLES : 0 DB2 WAIT : 2:43:39.056810 1.427188 CRT_TEMP_TABS : 0 TIMEOUTS : 0 OCCURRENCES : 6,880 RDPOOL_NOSTGS : 0 RDPOOL_INTLMTS: 0------------------------------------------------------------------------------------------------------------------------------------

TRACE ORIGIN:ACCT-BATCH (TYPE=CNID) COMMITS : 10,386 SELECTS : 6,203,806 %CPU(WKLD) : 33.85% INSERTS : 248,356 TOTAL TIMES AVERAGE UPDATES : 203,674 ----------- ----------- DELETES : 3,870 APL ELAPSED : 1:59:04.373122 33.075801 OPENS : 868,575 APL CPU : 16:56.484700 4.705947 FETCHES : 2,413,405 DB2 ELAPSED : 1:26:20.052874 23.981726 CLOSES : 835,424 DB2 CPU(CP) : 12:25.770380 3.452640 LOCK_TABLES : 0 DB2 WAIT : 1:05:58.973723 18.328582 CRT_TEMP_TABS : 0 TIMEOUTS : 5 OCCURRENCES : 216 RDPOOL_NOSTGS : 0 RDPOOL_INTLMTS: 0

AVAILABLE FILTERS

Basic Filters: DateR (Start/End Date when this object has ended - rounded)

TimeR (Start/End Time when this object has ended - rounded) DataSharing Group Name DataSharing Member Name SSID(s)

Max Objects Report Level. Valid values:

1 – Only Accumulation Type PLAN NAME will be reported2 - Only Accumulation Type CORRELATION NAME will be reported3 - All Accumulation Type will be reported

REPORT HEADER

Report code: Internal report code. In example above, string 'AW00' is shown. Report title:

In example above, string 'ACCOUNTING SUMMARY REPORT' is the report name.Page:Page number. GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.TRACE ORIGIN: If it was specified: "A”, only data from Accounting will be reported. "C”, only data from CACHE will be reported. "P', only data from Performance will be reported. "*', all data from Accounting, CACHE and Performance will be reported. SOURCE REQUEST CODE: Request code used to retrieve information from source repository tables.REPORT LEVEL: If it was specified: 1 - Only print information about ACCOUNT DATA, PERFORMANCE DETAIL and SQL CACHE; 2 - Only print information about ACCOUNT DATA, PERFORMANCE DETAIL,

SQL CACHE and SQL SUMMARY; 3 - Print all information available in this report about ACCOUNT DATA,

PERFORMANCE DETAIL, SQL CACHE, SQL SUMMARY and EXPLAIN.

EXPLAIN REQUEST CODE: Request code used to retrieve information from explain repository tables.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.Total CPU:Total CPU(CP) spent for all DB2 SSID.


413

FIELD DESCRIPTIONS

Accumulation type:SSID : SSIDCNID : DB2 Connection IDCNTY : Connection Type Summary. It can be:

TSO F/B TSO FOREGROUND, BACKGROUND CALL ATT DB2 CALL ATTACHDL/I BAT DL/I BATCH CICS ATT CICS ATTACH IMS ATT BMP IMS ATTACH BMP IMS ATT MPP IMS ATTACH MPP DB2 PRIV DB2 PRIVATE PROTOCOL DRDA DRDA PROTOCOL IMS CTL IMS CONTROL REGION IMS TRN IMS TRANSACTION BMP UTILITY DB2 UTILITIES RRSAF RRSAF ATTACH

CORR : DB2 Corrrelation Name. Some examples of Correlation names are jobname,CICS transactions, tso userid, etc.PLAN : Plan NameObject name: Each Accumulation Type holds its own kind of object. For instance, when AccumulationType is PLAN, this field will contain Plan Names.In sample report, string 'BATCH' is shown.

When Accumulation type is CORR, the specific Connection Type for the current objectis shown at right side.%CPU(WLKD): Percentage of total amount of CPU spent by this object compared with all workloadfrom DB2 accounting traces. APL Elapsed: Total application elapsed.Average APL Elapsed time is this field divided by TOTAL OCCURRENCE.APL CPU and average: Total application CPU time.Average APL CPU time is this field divided by TOTAL OCCURRENCE.DB2 Elapsed and average:Total elapsed time spent in DB2.Average DB2 Elapsed time is this field divided by TOTAL OCCURRENCE.DB2 CPU(CP) and average: Total DB2 CPU time spent in in all processors (CP plus SE/ZIIP).Average DB2 CPU time is this field divided by TOTAL OCCURRENCE.DB2 Wait and average: Total accumulated wait time spent in DB2.Average DB2 Wait time is this field divided by TOTAL OCCURRENCE.OCCURENCES: Total occurrences for the current object being listed.COMMITS: Total number of COMMITs issuedSELECTS: Total number of SELECTs issued

INSERTS: Total number of INSERTs issued UPDATES: Total number of UPDATEs issued DELETES: Total number of DELETEs issued


414

OPENS:Total number of OPENs issued FETCHS: Total number of FETCHs issuedCLOSES:Total number of CLOSEs issued LOCK_TABLS: Total number of LOCK-TABLEs issued CRT_TEMP_TABS:Total number of CREATEs for temporary tables issued TIMEOUTS: Total number of TIMEOUTs from DB2 accounting traces.RDPOOL_NOSTGS: Total number of times no storage was available during a RID LIST process in DB2. RDPOOL_INTLMTS: Total number of times a RID was LISTed as exceeded one or more internal limits whenprocessing a RID POOL or RID LIST in DB2.


415

LG01 - LOG SIZE SUMMARIZED

List all SQL statements with highest DB2 log activity.

This report must be used as a general guide to see which are the top SQLs logconsumers. It checks all executed SQL found in DB2 Workload and multiplies the rowsize (report field SIZE) by the number of affected bytes (report field ROWS PROCS).

It does not compute all DB2 log information generated by all SQLs in all cases andsituations. For instance: it does not compute Referential Integrities updates.

To work properly, you need to setup the SQL source definition correctly as defined inChapter 2, define SQL source.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR

Start/End Date when this object has ended - roundedTimeR

Start/End Time when this object has ended - roundedDataSharing Group Name DataSharing Member Name SSID(s)

Program names range.Program name "FROM" can be informed using wildcard '*' at the end which will fetch a range of programs with the same starting name. Therefore, leave the field "TO" as blank.

Max ObjectsPrint SQL Text


416

====================================================================================================================================LG01 LOG SIZE SUMMARIZED DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 10MEMBER NAME: PRINT SQL TEXT: N SSIDS:SOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

PROGRAM NAME T STMT NUM UNIQUE STMT TYPE TOTAL EXECUTIONS SIZE ROWS PROCS TOTAL LOG SIZE------------ - -------- -------- -------------- ---------------- ---------- ---------- --------------ST8UPD02 P 124 5720A1F8 UPDATE 1 65368 3 196,104ST8UPD02 P 104 098827C1 UPDATE 1 65318 3 195,954ST8UPD02 P 74 503AF62E UPDATE 1 65304 2 130,608ST8INS02 P 134 2B6A58A1 UPDATE 1 65024 1 65,024ST8INS02 P 98 F1DC54F4 INSERT 1 32714 1 32,714ST8INS02 P 80 8C5574BA INSERT 1 32714 1 32,714ST8INS02 P 154 BA76991D INSERT-SELECT 1 32547 1 32,547ST8INS02 P 120 619B4292 INSERT 1 32547 1 32,547SADRDPLU C 2599 A9F06472 DELETE 6 2745 3 8,235DSN@EP2L P 1908 77CBCB35 DELETE 1 120 26 3,120

REPORT HEADER

Report code: Internal report code. In example above, string 'LG01' is shown. Report title:

In example above, string 'LOG SIZE SUMMARIZED' is the report name.Page:Page number. GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.PRINT SQL TEXT: Indicates if command SQL text should be printed.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

PROGRAM NAME: Program name.T: Trace Source: Valid Values:


STMT NUM: Statement numberSTMT NUM UNIQUE: Statement unique numberSTMT TYPE NAME: Statement type name. (INSERT, DELETE or UPDATE)TOTAL EXECUTIONS: Total executions for this statement (STMT NUM) from DB2performance traceSIZE: Log size is calculated as follows:

For INSERT with SELECT:- Record length of Systables for Table used

For INSERT without SELECT:- Record length of Systables for Table used.

For DELETE:- Record length of Systables for Table used

For UPDATE:– All columns being updated are added by the range defined in SET clause according to the table order copied from catalog.

The final result is multiplied by 2.

Examples:


417

Let suppose a table name TABLE1 has columns A , B , C , D , E

(1) UPDATE FROM TABLE1 SET B = :HIn this case, only column B size is considered and multiplied by 2

(2) UPDATE FROM TABLE1 SET B = :H , D = :HColumns B, C and D sizes will be added and the total multiplied by 2

ROWS PROC: Rows processed by Statement. When overflowing the capacity for this field, the System will set value 999999999 on the report.

TOTAL LOG SIZE: Total log size spent by this SQL using the actual filters. This is LOG SIZE multiplied by ROWS PROC.


418

NW01 - SQL LENGTH WORKLOAD SUMMARIZED

List all SQL statements having the highest impact on Network and DB2 Cross MemoryActivity.

This report must be used as a general guide to see the top SQLs Network and DB2Cross Memory Activities. This report does not compute all technical details aboutNetwork and Cross Memory Activities.

To work properly, you need to correctly setup the SQL source definition as defined inChapter 2, define SQL source.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR


Start/End Time when this object has ended - roundedDataSharing Group Name DataSharing Member Name SSID(s)

Program names range. Program name "FROM" can be informed using wildcard '*' at the end which will fetch a range of programs with the same starting name. Therefore, leave the field "TO" as blank.

Max ObjectsPrint SQL Text


419

====================================================================================================================================NW01 SQL LENGTH WORKLOAD SUMMARIZED DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 10MEMBER NAME: PRINT SQL TEXT: N SSIDS:SOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

PROGRAM NAME STMT NUM UNIQUE STMT NAME LENGTH TOTAL EXECUTIONS TOTAL LENGTH------------ -------- -------- -------------- --------- ---------------- --------------DSNA6DB2 516 89A16CE6 FETCH 8120 709 5757080ADB2REM 7322 CBB91A39 FETCH 32680 16 522880ADB2REP 15330 5191C60E SELECT 4007 121 484847STACIC13 233 A0B0F350 FETCH 84 5001 420084ADB2REM 15548 82D96109 INSERT 651 430 279930CLP C:\TEMP\FTP\SP 210 AC0BADCE FETCH 2265 41 92865ST9UPD02 115 08250CA4 UPDATE 65419 1 65419ST8UPD02 104 098827C1 UPDATE 65337 1 65337ST8UPD02 124 5720A1F8 UPDATE 65334 1 65334ST8UPD02 74 503AF62E UPDATE 65324 1 65324

REPORT HEADER

Report code: Internal report code. In example above, string 'NW01' is shown. Report title:

In example above, string 'SQL LENGTH WORKLOAD SUMMARIZED' is the report name.Page:Page numberGROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.PRINT SQL TEXT: Indicates if command SQL text should be printed.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

PROGRAM NAME: Program name. STMT NUM: Statement numberSTMT UNIQUE: Statement unique number

STMT NAME: Statement type name

“PREP->” indicates the statement comes from a PREPARE.LENGTH : Network calculated as follows:

For PREPARE: - only compute statement size

For SELECT:- only compute host variables sizes from INTO and WHERE clauses

For OPEN: - check SELECT (or DECLARE CURSOR) and compute host variables fromWHERE clause

For FETCH:- check SELECT (or DECLARE CURSOR) and compute all columns fromSELECT clause

For INSERT (STATIC):- compute all host variables from VALUES clause

For INSERT with SELECT (STATIC): - compute columns from SELECT clause plus host variables from WHERE

clause For INSERT (DYNAMIC):

- compute host variables from VALUES clause For INSERT with SELECT (DYNAMIC):

- compute host variables from WHERE clause For INSERT (from EXECUTE IMMEDIATE):


420

- compute only the statement size For INSERT with SELECT (from EXECUTE IMMEDIATE):

- compute only the statement size. For UPDATE (STATIC):

- compute host variables from SET and WHERE clauses. For UPDATE (from EXECUTE):

- compute host variables from SET and WHERE clauses. For UPDATE (from EXECUTE IMMEDIATE):

- we only compute statement size For DELETE (STATIC):

- compute host variables from WHERE clause. For DELETE (from EXECUTE):

- compute host variables from WHERE clause. For DELETE (from EXECUTE IMMEDIATE):

- compute only the statement size

TOTAL EXECUTIONS: Total executions for this statement from DB2 traceTOTAL LENGTH:Total network size. This is LENGTH Multiplied by TOTAL EXECUTIONS.


421

PG00 - DB2 PROGRAMS SUMMARIZED

Overview of all Programs found in DB2 Traces (Acctg, Perf and SQL CACHE). This reportis similar to AC00 online report.

SAMPLE REPORT

(ACCOUNTING DATA)

(PERFORMANCE DATA)

(SQL CACHE DATA)


422

====================================================================================================================================PG00 ALL DB2 PROGRAMS SUMMARIZED DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: PRINT SQL TEXT: N SSIDS:DBAG TRACE ORIGIN : ALLSOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

PROGRAM NAME: ST9UPD52 ( %CPU-WKLD = 0.01% )

----------------------- ACCOUNTING DATA -------------------------TOTAL PROGRAMS OCCURRENCE: 1TOTAL SQLs EXECUTED: 3TOTAL STOR PROC EXECUTED: 0TOTAL UDF EXECUTED: 0DB2 ELAPSED TIME: 0.027722DB2 ELAPSED TIME(AVG PER OCCURRENCE): 0.027722DB2 CPU TIME (CP): 0.018479DB2 CPU TIME (SE/ZIIP): 0.000000DB2 CPU TIME (AVG PER SQL): 0.006159DB2 CPU TIME (AVG PER OCCURRENCE): 0.018479DB2 WAIT TIME LOCK : 0.000000DB2 WAIT TIME LATCH : 0.000000DB2 WAIT SYNC I/O DATABASE: 0.001115DB2 WAIT TIME OTHER READS: 0.003075DB2 WAIT TIME OTHER WRITES: 0.000000DB2 WAIT TIME SERVICE TASK: 0.000000DB2 WAIT TIME AVAILABLE TCB STPROC: 0.000000DB2 WAIT TIME DATASHARING SENDING MESSAGES: 0.000000DB2 WAIT TIME DATASHARING GLOBAL CONTENTION: 0.000000

====================================================================================================================================PG00 ALL DB2 PROGRAMS SUMMARIZED DATE:2015/01/19 - PAGE: 2====================================================================================================================================


---------------------- PERFORMANCE DETAILS ----------------------TOTAL SQL EXECUTED: 3DB2 ELAPSED TIME: 0.004966DB2 CPU TIME: 0.004278DB2 CPU TIME (AVG PER SQL): 0.001426TOTAL_REOPT: 0TOTAL_NOREOPT: 0 INDEX DATA SORT ----- ---- ----ROWS_PROCESSED: 7 38 0ROWS_EXAMINED: 6 38 0ROWS_QUAL_STAG_1: 3 0 0ROWS_QUAL_STAG_2: 3 0 0ROWS_INSERTED: 0 0 0ROWS_UPDATED: 0 3 0ROWS_DELETED: 0 0 0TOTAL GETPAGES: 2 5 0TOTAL GETPAGES RI: 0 0 0ROWS_DEL_RI: 0 0 0PAGES_SCAN_LOB: 0 0 0PAGES_IN_UP_LOB: 0 0 0


PROGRAM NAME: SADVRF00 ( %CPU-WKLD = < 0.01% )

---------------------------- SQL CACHE ---------------------------TOTAL SQLs EXECUTED: 0DB2 ELAPSED TIME: 0.000000DB2 CPU TIME: 0.000000DB2 CPU TIME (AVG PER SQL): 0.000000ROWS_PROCESSED: 0ROWS_EXAMINED: 0NUMBER OF SORTS: 0INDEX SCAN: 0TABLESPACE SCAN: 0TOTAL EXCEED RIDPOOL INT LIMIT: 0TOTAL RIDPOOL NO STORAGE: 0TOTAL GETPAGES: 0SYNCHRONOUS BUFFER READ: 0SYNCHRONOUS BUFFER WRITE: 0DB2 WAIT SYNC I/O: 0.000000DB2 WAIT TIME SERVICE TASK: 0.000000DB2 WAIT TIME DATASHARING GLOBAL CONTENTION: 0.000000DB2 WAIT TIME OTHER READS: 0.000000DB2 WAIT TIME OTHER WRITES: 0.000000DB2 WAIT TIME LOCK : 0.000000DB2 WAIT TIME LATCH : 0.000000DB2 WAIT TIME DRAIN LOCK: 0.000000DB2 WAIT TIME DRAIN WAIT FOR CLAIM TO BE REL: 0.000000DB2 WAIT I/O LOG: 0.000000DB2 WAIT TIME PAGE LATCH CONTENTION: 0.000000NRO PARALLEL GROUPS CREATED: 0

(SQL SUMMARY and EXPLAIN DATA)


423



--------------------------- SQL SUMMARY --------------------------------------------------------------------------T S Num Desc Uniq Gtab Gcol Gsrt F DB2 CPU DB2 CPU Avg SQLs- ----- ---------------- -------- -------- -------- -------- - ------------------- ------------------- -----------P 84 UPDATE ECAC0300 DB694F04 6047B73D 00000000 0.002024 0.002024 1P 110 SELECT E0C3F4C8 8482F726 0739CEFB 00000000 0.001375 0.001375 1P 98 SELECT E7DA674F DB694F04 CD76C143 00000000 0.000879 0.000879 1

----------------------------- EXPLAIN --------------------------------------------------------------------------------------------

PLAN TABLE PROGRAM TIMESTAMP:2012-02-14-17.46.58.491751 (ORIGINAL FORMAT = N)----------PROGRAM___:ST9UPD52 STMT_NUM____:000000084 STMT_NUM_UNIQ_:ECAC0300QUERYNO___:000007833 STMT_TYPE___:UPDATE APPLNAME______:SEQUENTIAL:000000002 FLAG_CAST___: COLLID EXPLAIN:SADVCOLPROCMS____: 0.001 GROUP_MEMBER: COST_CATEGORY_:APROCSU____: 1

QBLOCKNO__:0001TBTYPE____:T PLANNO______:0001 CREATOR_______:IVPQUAL TNAME__________:IVPTABLE_CUSTOMSEQUENTIAL:000000001 TABNO_______:0001 ACCESSCREATOR_:IVPQUAL ACCESSNAME_____:IXTBCTM3METHOD____:0000 ACCESSTYPE__:N MATCHCOLS_____:0001 INDEXONLY______:NSORTN_U___:N SORTN_JOIN__:N SORTN_ORDERBY_:N SORTN_GBY______:NSORTC_U___:N SORTC_JOIN__:N SORTC_ORDERBY_:N SORTC_GBY______:NTSLOCKM___: IX PREFETCH____: COL_FN_EVA____: QBLOCK_TYP_____:UPDATEMIXOPSQ___:0000 ACCESS_PID__:0000 ACCESS_DEGREE_:0000 COLLID_EXPL____:SADVCOLJOIN_DG___:0000 JOIN_PGRP_ID:0000 SORTC_PGRP_ID_:0000 SORTN_PGID_____:0000PARAL_M___: MERGE_JOIN_C:0000 PAGE_RANGE____: CORRELATION____:JOIN_TP___: GROUP_MEMBER: WHEN_OPTIMIZE_: PARENT_QBLOCK__:0000TABLE_TYPE:T OPTHINT_____: HINT_USED_____: PRIM_ACCESSTYPE:BIND_TM___:2014-12-26-11.40.42.470000 TIMESTAMP_____:201412261140

AVAILABLE FILTERS

Basic Filters: DateR

Start/End Date when this object has ended - rounded TimeR

Start/End Time when this object has ended - rounded DataSharing Group Name DataSharing Member Name SSID(s)

Max Objects Report Level

1 – Only print information about ACCOUNT DATA PERFORMANCE DETAIL SQL CACHE

2 – Only print information about ACCOUNT DATA PERFORMANCE DETAIL SQL CACHE SQL SUMMARY

3 - Print all information available in this report PERFORMANCE DETAIL SQL CACHE SQL SUMMARY EXPLAIN

Print SQL Text (Y/N) – Show SQL TEXT (report level must be equal 3)

Other Filters: DB2 Plan Name DB2 Connection Type DB2 Correlation Name Program Name Program Range – use wildcard '*' for programs started with a given name Unique Name Database Name Table Name(s) Table Name(s) and Owner

REPORT HEADER

Report code: Internal report code. In example above, string 'PG00' is shown. Report title:

In example above, string 'ALL DB2 PROGRAMS SUMMARIZED' is the report name.Page:Page number. GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.

Start/End DATE: Start/End range date as specified in FILTER command.


424

Start/End TIME: Start/End range time as specified in FILTER command.Program Name:Program name.

FIELD DESCRIPTIONS

ACCOUNTING DATA

TOTAL PROGRAMS OCCURRENCE: Total traces found.TOTAL SQL EXECUTED:Total SQL Executed.Note that this counter could not be the real value when SQL was submited from DRDAconnections.TOTAL STOR PROC EXECUTED:Total Stored Procedure Executed. TOTAL udf EXECUTED:Total User Define Function Executed. DB2 ELAPSED TIME:Total DB2 ELAPSED Time. DB2 ELAPSED TIME(AVG PER OCCURRENCE)Average DB2 Elapsed Time per Program Trace Occurrence. DB2 CPU TIME(CP):Total DB2 CPU time spent on a normal CP processor.DB2 CPU TIME(SE/ZIIP):Total DB2 CPU spent in all processors (CP plus SE/ZIIP). DB2 CPU TIME (AVG PER SQL)Average DB2 CPU per SQL execution. This is (DB2 CPU TIME) divided by (TOTAL EXECUTIONS) DB2 CPU TIME(AVG PER OCCURRENCE)Average DB2 CPU Time per Program Trace Occurrence. DB2 WAIT TIME LOCK/LATCH:Total DB2 WAIT Time Spent in Lock/Latch. DB2 WAIT SYNC I/O DATABASE:Total DB2 WAIT Time in synchronous I/O to read/write DB2 application tables. DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported DB2 WAIT TIME OTHER WRITES:Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported DB2 WAIT TIME SERVICE TASK:Total DB2 WAIT Time for Service Task. Services include here: – open and close of a data set– update of SYSLGRNG – HSM recall data set – Dataspace Manager Services – Define data set – Extend data set – Delete data set – Wait time due to synchronous execution unit switch to other DB2 service tasks


425

– WAIT time spent in commit, abort or deallocation process. DB2 WAIT TIME AVAILABLE TCB STPROC: Total waiting time available for TCB before Stored Procedure could be scheduled DB2 WAIT TIME DATASHARING SENDING MESSAGES: Total waiting time caused by suspension of sending messages to other DB2 MembersDB2 WAIT TIME DATASHARING GLOBAL CONTENTION:Total waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks.

PERFORMANCE DETAILS

SQL TOTAL EXECUTIONS:Total SQLs executed. DB2 ELAPSED TIME:Total DB2 Elapsed Time. DB2 CPU TIME:Total DB2 CPU spent in all processors (CP plus SE/ZIIP)DB2 CPU TIME (AVG PER SQL)Average DB2 CPU per SQL execution TOTAL REOPT:Total Re-optimization occurred in run-time TOTAL NOREOPT:Total Re-optimization NOT occurred in runtimeINDEXRows/index entries/pages processed in IndexDATARows/pages processed in DB2 TableSORTRows/pages processed in Work File, a temporary table ROWS PROCESSED:Number of Rows of all record types processed.For example, number of rows returned for a SELECT, or number of rows affected by anINSERT, UPDATE or DELETE TABLESPACES with only 1 table:


– This number counts rows for the related DB2 TABLE only Index Spaces: same asabove.


– This number counts all rows for all tables,not only for the related table.ROWS EXAMINED:Number of Rows of all record types processed.This number counts rows for the related table only.So, in some situations, this number will be the same value as ROWS PROCESSED ROWS QUAL STAG 1: Rows Qualified at Stage 1.This means:– Indexable predicates– Predicates not indexable, but contain columns that belong to indexes (Index

Scanning)Stage 1 is faster than Stage 2 because they are resolved in DB2 Data Manager (DM).DB2 Data Manager resolves ROW-LEVEL processing. ROWS QUAL STAG 2: Rows Qualified at Stage 2.DB2 will:– Resolve all other predicated not resolved in Stage 1– It will scan (normally) rows and reject some of themStage 2 is resolved in Relation Data Server (RDS).


426

RDS resolves SORT and SET-LEVEL Processing. ROWS INSERTED:Rows InsertedROWS UPDATED:Rows UpdatedROWS DELETED:Rows DeletedTOTAL GETPAGES:Getpages issuedTOTAL GETPAGES RI: Additional Getpages issued to enforce ref. Constraints.ROWS DEL RI: Additional Rows delete/set to null by ref. Constraints.PAGES SCAN LOB:Additional pages scanned in a LOB TABLESPACE.PAGES IN UP LOB:Additional pages update in a LOB TABLESPACE.

SQL CACHE

TOTAL SQL EXECUTED: Total SQLs executed. For SQLs with cursor, this is the number of OPENs. DB2 ELAPSED TIME: Total DB2 Elapsed Time. DB2 CPU TIME: Total DB2 CPU spent in all processors (CP plus SE/ZIIP). DB2 CPU TIME (AVG PER SQL):Average DB2 CPU Time per SQL Execution. DB2 WAIT TIME LOCK/LATCH: Total DB2 Wait Time Spent in Lock/Latch. DB2 WAIT SYNC I/O:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables. DB2 WAIT TIME OTHER READS:Total DB2 Wait Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

DB2 WAIT TIME OTHER WRITES: Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported

DB2 WAIT TIME SERVICE TASK: Total DB2 Wait Time for Service Task. Services includes here:

– Open and close of a data set – Update of SYSLGRNG – HSM recall Data Set – Dataspace Manager Services

– Define data set – Extend data set – Delete data set –

DB2 WAIT TIME DATASHARING GLOBAL CONTENTION:Total waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks. TOTAL GETPAGES:Getpages issued. SYNCHRONOUS BUFFER READ: The number of synchronous buffer reads.


427

SYNCHRONOUS BUFFER WRITE: The number of buffer writes. ROWS EXAMINED:Number of Rows of all record types processed.This number counts rows for the related table only.So, in some situations, this number will be the same value as ROWS PROCESSED ROWS PROCESSED:Number of Rows of all record types processed.For example, number of rows returned for a SELECT, or number of rows affected by an INSERT, UPDATE or DELETE TABLESPACES with only 1 table:– This number counts rows for the related DB2 TABLE only Segmented TABLESPACES: – This number counts rows for the related DB2 TABLE only Index Spaces: same as

above. – This number counts rows for the related DB2 TABLE only Single TABLESPACES with

multiple tables:– This number counts all rows for all tables,not only for the related table. SORT: Total Number of sort performed. INDEX SCAN: Total Number of index scan performed. TABLESPACE SCAN:Total Number of index scan performed. NRO PARALLLEL GROUPS CREATED: Total Number of parallel groups created by the statement. TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done. TOTAL RIDPOOL NO STORAGE: Total access using RID List has failed because of size of RIDPOOL. If its possible,increase RIDPOOL size. A DB2 Table Scan will be done.

SQL SUMMARY

T: Trace Source: Valid Values:


S Num:SQL Statement Number from DB2 precompiler. Desc:Short SQL Statement description. Examples: SELECT, INSERT, etc. S Unique:Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.Gtab:Number which defines all groups of DB2 TABLES found in this SQL statement. For moreinformation, please refer to SQL Statement Group Tables Algorithm. Gcol:Number which defines all groups of predicates found in this SQL statement.For more information, please refer to SQL Statement Group Columns Algorithm.Gsrt:Unique number which defines all groups of columns in group by and order by clause.For more information, please refer to SQL Statement Group Sort Columns Algorithm.DB2 CPU:


428

Total DB2 CPU Spent by this statement.DB2 CPU AVG:Total DB2 CPU Average per SQL.SQLs:Total executed SQLs.

EXPLAIN / EXPLAIN AND SQL TEXTExplain information will be written. For more information, please go to Appendix F- Plantables description .


429

SH01- CPU CONSUMPTION BY PROGRAMS (ALL)

This report gives a short description of all programs found in DB2 Accounting Traces ,according to current report filters.Just one line for each program will be shown.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR


Start/End Time when this object has ended - roundedDataSharing Group Name DataSharing Member Name SSID(s) Max Objects


430

====================================================================================================================================SH01 CPU CONSUMPTION BY PROGRAMS (ALL) DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Program DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------ADB2PRP 29.98 1:12.229271 0.080613ADB2REP 14.65 35.300609 0.016067DSN@EP2L 11.67 1.875726 0.004574DSNUTIL 10.94 0.303144 *N/A*STACIC13 10.75 25.917672 0.000863ADB2REM 7.14 17.215691 0.005711ADBMAIN 2.40 5.795371 0.002454CLP C:\TEMP\ 2.26 0.227126 0.031327DSNA6DB2 1.12 *N/A* 0.000931DSNESM68 1.03 1.247922 0.002332DSSNAP_UTILI 0.84 *N/A* 0.339394ADB2RET 0.64 1.543297 0.025299CLP C:\PROGR 0.50 0.018001 0.005798SADRTRIN 0.45 *N/A* 0.001478DY8DEC51 0.34 0.837055 0.017809DYADEC51 0.30 0.726105 0.016135DYASTM80 0.30 0.724294 0.012487ST9DEC28 0.23 0.557798 0.042907DSNADMIZ 0.21 *N/A* 0.000260

REPORT HEADER

Report code: Internal report code. In example above, string 'SH01' is shown. Report title:

In the example above, string 'CPU CONSUMPTION BY PROGRAMS (ALL)' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Program:Program nameDB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by totalocurrence.Ocurrence is total records found in DB2 Accounting traces for this current program. DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


431

SH02- CPU CONSUMPTION BY PROGRAMS (BATCH)

This report gives a short description of batch programs found in DB2 Accounting Tracesaccording to current report filters. Just one line for each program will be shown.

* Connection types selected in this report: TSO FOREGROUND AND BACKGROUND DB2 CALL ATTACH DL/I BATCH DB2 UTILITIES

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR


Start/End Time when this object has ended - rounded DataSharing Group Name DataSharing Member Name SSID(s) Max Objects


432

====================================================================================================================================SH02 CPU CONSUMPTION BY PROGRAMS (BATCH) DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Program DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------ADB2PRP 36.20 1:12.229271 0.080613ADB2REP 17.69 35.300609 0.016067DSN@EP2L 14.10 1.875726 0.004574DSNUTIL 13.22 0.303144 *N/A*ADB2REM 8.63 17.215691 0.005711ADBMAIN 2.90 5.795371 0.002454DSNESM68 1.25 1.247922 0.002332ADB2RET 0.77 1.543297 0.025299DY8DEC51 0.41 0.837055 0.017809DYADEC51 0.36 0.726105 0.016135DYASTM80 0.36 0.724294 0.012487ST9DEC28 0.27 0.557798 0.042907DY8DEC52 0.21 0.423897 0.009634

REPORT HEADER


In the example above, string 'CPU CONSUMPTION BY PROGRAMS (BATCH)' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Program:Program nameDB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by totalocurrence.Ocurrence is total records found in DB2 Accounting traces for this current program.DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


433

SH03- CPU CONSUMPTION BY PROGRAMS (ONLINE)

This report gives a short description of online programs found in DB2 Accounting Tracesaccording to current report filters. Just one line for each program will be shown.

* Connection types selected in this report: CICS ATTACH IMS ATTACH MPP DRDA PROTOCOL

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR




434

====================================================================================================================================SH03 CPU CONSUMPTION BY PROGRAMS (ONLINE) DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Program DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------STACIC13 71.22 25.917672 0.000863CLP C:\TEMP\ 14.98 0.227126 0.031327DSSNAP_UTILI 5.59 *N/A* 0.339394CLP C:\PROGR 3.31 0.018001 0.005798STACIC12 0.57 0.008720 0.001453STACIC11 0.47 0.007535 0.001255STACIC10 0.43 0.007240 0.001206STACIC01 0.43 0.022404 0.005601STACIC09 0.41 0.007135 0.001189STACIC06 0.39 0.007995 0.001332STACIC08 0.39 0.007151 0.001191STACIC07 0.37 0.007190 0.001198STACIC05 0.34 0.007302 0.001217STACIC03 0.32 0.007936 0.001322STACIC04 0.31 0.007241 0.001206STACIC02 0.18 0.006273 0.002091JAVAW.EXE 0.17 0.063579 0.002889STACIC14 0.03 0.013187 0.002197

REPORT HEADER


In the example above, string 'CPU CONSUMPTION BY PROGRAMS (ONLINE)' is the reportname.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Program:Program nameDB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by totalocurrence.Ocurrence is total records found in DB2 Accounting traces for this current program. DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


435

SH04- CPU CONSUMPTION BY STORED PROCEDURES

This report gives a short description of programs found in DB2 Accounting Tracesaccording to current report filters. Just one line for each program will be shown.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR



REPORT HEADER


In the example above, string 'CPU CONSUMPTION BY STORED PROCEDURES' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS:


436

====================================================================================================================================SH04 CPU CONSUMPTION BY STORED PROCEDURES DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Stored Proc DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------DY8INS06 62.84 0.061193 0.030596STADEC26 37.15 0.007236 0.001206

Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Stored Procec.:Program name (stored procedure)DB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by totalocurrence.Ocurrence is total records found in DB2 Accounting traces for this current program. DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


437

SH05- CPU CONSUMPTION BY TRANSACTIONS (CICS/IMS)

This report gives a short description of all transaction found in DB2 Accounting Tracesaccording to current report filters. Just one line for each program will be shown.

* Connection types selected in this report:CICS ATTACH IMS ATTACH MPP

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR




438

====================================================================================================================================SH05 CPU CONSUMPTION BY TRANSACTIONS (CICS/IMS) DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Transaction DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------ZIAD 92.99 17.474912 0.001164ZIA1 3.34 0.089667 0.002490ZIA2 1.22 0.057682 0.001747ZIA3 1.11 0.052263 0.001742ZIA4 0.25 0.048688 0.001803ZIA5 0.22 0.041827 0.001742ZIA6 0.20 0.037711 0.001795ZIA7 0.16 0.031740 0.001763ZIA8 0.13 0.024977 0.001665ZIA9 0.10 0.019737 0.001644ZIAA 0.08 0.016049 0.001783ZIAE 0.05 0.011152 0.003717ZIAB 0.05 0.010946 0.001824ZIAC 0.02 0.005550 0.001850

REPORT HEADER


In the example above, string 'CPU CONSUMPTION BY TRANSACTIONS (CICS/IMS)' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Transaction:Transaction name DB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by totalocurrence.Ocurrence is total records found in DB2 Accounting traces for this current transaction.DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


439

SH06- CPU CONSUMPTION BY PROGRAMS (BATCH-ONLINE)

This report gives a short description of programs batch and online found in DB2Accounting Traces according to current filters. Just one line for each program will be shown.

* Connection types selected in this report: Batch TSO FOREGROUND AND BACKGROUND DB2 CALL ATTACH DL/I BATCH DB2 UTILITIES Online CICS ATTACH IMS ATTACH MPP DRDA PROTOCOL

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR




440

====================================================================================================================================SH06 CPU CONSUMPTION BY PROGRAMS (BATCH-ONLINE) DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS: START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Program DB2 CPU Time DB2 CPU Time DB2 CPU Time (Total - %) (Occurrence Average) (SQL Average)------------ ------------ -------------------- -------------------ASGT99CA 2.18 0.020938 0.000025PSR0057 1.65 1.393435 0.000018PQR0115 0.81 0.342472 0.000037AMD0005 0.67 1.041687 0.000415MIR0191 0.65 0.020570 0.000031PSD0041 0.40 0.008446 0.000021PER0025 0.32 0.427731 0.000249ASGT97CA 0.24 0.161236 0.000029AMD0003 0.20 0.316961 0.000241PQR0114 0.18 0.217670 0.000075PED0062 0.16 0.254966 0.000140PER0117 0.15 0.243422 0.000054SCD0159 0.14 0.114416 0.001343PER0045 0.13 0.322628 0.000017PED0063 0.09 0.037404 0.000092PQR0269 0.08 0.084090 0.000058

REPORT HEADER


In the example above, string 'CPU CONSUMPTION BY TRANSACTIONS (CICS/IMS)' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Program:Program name DB2 CPU Time (Total %): Percentage of total DB2 CPU spent in all processors (CP plus SE/ZIIP) by this programdivided by total amount spent of all programs.DB2 CPU Time (Occurrence average):Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by TOTALOCCURRENCE. Ocurrence is total records found in DB2 Accounting traces. DB2 CPU Time (SQL average): Average DB2 CPU time spent in all processors (CP plus SE/ZIIP) divided by total sqlissued by this program.


441

SH07- TABLE SUMMARY FROM WORKLOAD

This report shows an overview of all DB2 Tables found in DB2 traces.

Note: This same report will also show the activity of SQLs with no tables presented,like DCLs, SET command, COMMIT, etc. These kind of SQLs will only be shown if they were dynamic prepared.

The information presented here was basically obtained from DB2 Traces. Request code for Source is also used.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR


Start/End Time when this object has ended - rounded


442

====================================================================================================================================SH07 TABLE LIST WORKLOAD DATE:2015/01/19GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: TRACE ORIGIN : ALL SSIDS:DBAG START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Name Owner T DB2 CPU(All) DB2 CPU(All) DB2 Elapsed Sqls (All Sql Types) (Ins/Del/Merge/Tru)------------------ -------- - ---------------- ------------------- ---------------- -----------

SYSCOLUMNS SYSIBM T 53.050 0.000 58.379 470ADBHV SESSION U 20.389 0.068 25.048 1,366IVPTABLE_T001 IVPQUAL T 19.362 0.354 1:35.386 18,594IVPTABLE_T001 IVPQUAL r 11.555 0.314 42.921 15,853IVPTABLE_T001 IBMUSER U 11.555 0.314 42.921 15,853IVPTABLE_T002 IVPQUAL T 7.442 0.126 55.419 2,960SYSTABLES SYSIBM T 2.946 0.000 3.344 519ADMIN_TASKS SYSIBM T 2.700 0.000 3.391 2,900(DECLARE CURSOR ) 2.089 0.000 3.462 1,214ADBGEN SESSION U 1.679 0.696 3.263 255IVPTABLE_TABELA_CO IVPQUAL U 1.323 0.086 6.774 132SYSINDEXSPACESTATS SYSIBM T 1.264 0.000 1.292 3IVPVIW_ADDIN2 IVPQUAL V 1.160 0.000 2.736 870STMT_CACHE_MON SADVQUAL T 1.105 0.927 1.204 748IVPVIW_ADDINV IVPQUAL V 1.090 0.000 3.072 870ADBGENP SESSION U 0.889 0.542 1.102 864IVPTABLE_CUSTOMER IVPQUAL T 0.868 0.176 3.658 76SYSPACKAGE SYSIBM T 0.861 0.262 1.025 130SYSTABLESPACESTATS SYSIBM T 0.771 0.000 0.786 3IVPTABLE_T002 URGENT1 U 0.699 0.126 6.583 435IVPTABLE_T002 IBMUSER U 0.699 0.126 6.583 435SYN_IVP_T001_T002 IBMUSER U 0.695 0.000 21.496 51SYN_IVP_T001_T002 URGENT1 U 0.695 0.000 21.496 51IVPVIW_T001_T002 IVPQUAL T 0.695 0.000 21.496 51SYN_IVP_T001_T002 IVPQUAL Y 0.695 0.000 21.496 51SYSPACKDEP SYSIBM T 0.686 0.262 1.066 493

DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source Max Objects

Other Filters: Table Name(s) - use wildcard '*' for tables started with a given name Table Name(s) and Owner Database Name Database Name Range

REPORT HEADER


In the example above, string 'TABLE LIST WORKLOAD' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.

FIELD DESCRIPTIONS

Name:This field normally represents a Table Name. Also, this field can be:

– A DB2 DDL Object, normally a DB2 Table name (check field T (Object type)– A Dynamic SQL command when no DB2 table was accessed. Example: SQL SET

CURRENT DATE. SQL commands will be always presented between ‘()’.Owner: Table Owner.

T: (Object Type)Object type: Code Description ----- ----------------------------- A ALIAS C CLONE G GLOBAL TEMPORARY H History M MATERIALIZED QUERY TABLE


443

P IMPLICIT TABLE CREATED FOR XML COLUMNS or TABLESPACET TABLE V VIEW X AUXILIARY TABLE Y SYNONYM I INDEX D DATA BASE S STORAGE GROUP K PACKAGE F FUNCTION O STORED PROCEDURE R TRIGGER E DISTINCT TYPE J JAR N NONE r Remote Object DB2 CPU(ALL) / (All Sqls Type):Total DB2 CPU spent by this table in all processors (CP plus SE/ZIIP).Note: The total CPU time consumption by DB2 are not broken by each table involved ina SQL Join. Therefore, DB2 total time shown here could be related to other tables too,not only the table exposed here.DB2 CPU(ALL) / (Ins/Del/Merge/Tru):Total DB2 CPU spent by statements INSERT, INSERT WITH SELECT, DELETE, DELETECURSOR, MERGE and TRUNCATE in this current table for all processors (CP plusSE/ZIIP). This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to AppendixNumerical and Time formats for additional information.DB2 Elapsed:Total DB2 ELAPSED Time spent by this object. Note: The total Elapsed time consumption by DB2 are not broken by each tableinvolved in a SQL Join. Therefore, DB2 total time shown here could be related to othertables too, not only the table exposed here.SQLs:Total executed SQLs.


444

SHFE- FETCH/OPEN SUMMARY

This report gives a short description of all correlations found in DB2 Accounting Traces. Only correlations if total fetches or total opens greater than zeros will be printed.

SAMPLE REPORT

AVAILABLE FILTERS

Basic Filters:DateR


Start/End Time when this object has ended - roundedDataSharing Group Name DataSharing Member Name SSID(s) Max Objects

Other Filters:DB2 Plan Name DB2 Connection Type DB2 Correlation Name (wildcard may be used)DB2 Correlation Name + Connection Type DB2 Correlation Name + Program Name Program Name (wildcard may be used)


445

====================================================================================================================================SHFE FETCH/OPEN SUMMARY DATE:2015/01/19GROUP NAME: PLAN NAME: MAX OBJECTS: 1110MEMBER NAME: CORRELATION: SSIDS:DBAG CONNECTION TYPE: START DATE:1900-01-01 START TIME:00.00.00PROGR. NAME: END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Correlation Connect Fetch/Open Fetch Open Select Ins/Upd/Del DB2 CPU(All) AVG DB2 CPU(ALL) RD-------------- ------------- ----------- ----------- ----------- ----------- ----------- ---------------- ---------------- --IBMUSER TSO F/B 30 571 19 0 2 1.438 0.479UNICOVA4 TSO F/B 14 238 17 0 3 0.988 0.988UNICOVA3 TSO F/B 14 238 17 0 3 1.018 1.018UNICOVA2 TSO F/B 14 238 17 0 6 1.143 1.143UNICOVA1 TSO F/B 14 238 17 0 6 1.173 1.173JSPUFVA4 TSO F/B 14 240 17 0 6 1.836 1.836JSPUFVA3 TSO F/B 14 240 17 0 6 1.783 1.783JSPUFVA2 TSO F/B 14 240 17 0 6 1.632 1.632JSPUFVA1 TSO F/B 14 240 17 0 6 1.766 1.766URGENT1 TSO F/B 10 2,698 269 271 687 1:10.701 35.350DB2BP.EXE DRDA 2 42 16 0 0 2.837 0.141DBAGADMT_II RRSAF 1 1 1 0 1 0.000 0.000ZIA9 CICS ATTACH 1 4 4 0 0 0.019 0.019ZIA8 CICS ATTACH 1 5 5 0 0 0.024 0.024DBAGADMT_DMN RRSAF 1 391 391 0 391 0.000 0.000ZIA7 CICS ATTACH 1 6 6 0 0 0.031 0.031ZIA6 CICS ATTACH 1 7 7 0 0 0.037 0.037ZIA5 CICS ATTACH 1 8 8 0 0 0.041 0.041ZIA4 CICS ATTACH 1 9 9 0 0 0.048 0.048ZIA3 CICS ATTACH 1 40 40 0 0 0.209 0.052JOB154DB TSO F/B 1 2 2 1 1 0.027 0.027JOB153DB TSO F/B 1 2 2 1 1 0.029 0.029

REPORT HEADER

Report code: Internal report code. In example above, string 'SHFE' is shown. Report title:

In the example above, string 'FETCH/OPEN SUMMARY' is the report name.Date:Date of report execution.GROUP NAME: Datasharing Group name as specified in FILTER command.PLAN NAME:Plan Name.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.CORRELATION:Correlation name. SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.CONNECTION TYPE:Connection Type. Valid Codes: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W UDF 0Y TRIGGER 0Z STORED PROCEDURE EA CACHE (FOR DYNAMIC SQLS)EB CACHE (FOR STATIC SQLS) Program Name:Program NameStart/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.


446

FIELD DESCRIPTIONS

Correlation:Correlation name. Examples: JOBNAME, CICS Transaction, etc

Connect:DB2 Connection name. Examples: CICS Attach, TSO F/B, etc Fetch/Open: Total Fetches divided by Opens. Value will be rounded. Fetch:Total FetchOpen:Total OpenSelect:Total SelectIns/Upd/Del:Total of Insert + Update + DeleteDB2 CPU(All):Total DB2 CPU spent in all processors (CP plus SE/ZIIP)This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.AVG DB2 CPU(ALL):Average DB2 CPU per occurrence.This field is shown using hhhhhh:mm:ss.ttt time format. Please, refer to Appendix Numerical and Time formats for additional information.RD:This field indicates if a RidPool access has failed and a table scan has occurred. Valid values are: ' ' - RIDPOOL List not used or RIDPOOL List access was OK. 'S' - Access using RID List has failed because of size of RIDPOOL. If you can,




447

ST02 - WORST STMT UNIQUE CPU SUMMARIZED

This report will show an overview of all DB2 Activities by ‘identicals’ SQLs, accordingto TurboTuneSQL Statement Unique Algorithm. This report is very similar to ST02Online Report.

SAMPLE REPORT

(Details , PERFORMANCE and SQL CACHE DATA)

(EXPLAIN DATA)


448

====================================================================================================================================ST02 WORST STMT UNIQUE CPU SUMMARIZED DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: PRINT SQL TEXT: N SSIDS:DBAG TRACE ORIGIN : ALLSOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Unique DB2 CPU(ALL) %CPU-WKLD DB2 CPU Avg DB2 Elapsed SQLs Dprog-------- ------------------- ------------------- ------------------- ------------------- ----------- -----------80278CC4 35.829890 24.027800 0.100083 39.366871 358 1

---------------------- PERFORMANCE DETAILS ----------------------TOTAL SQLs EXECUTED: 358DB2 ELAPSED TIME: 39.366871DB2 CPU (ALL): 35.829890DB2 CPU TIME (AVG PER SQL): 0.100083TOTAL_REOPT: 0TOTAL_NOREOPT: 0 INDEX DATA SORT ----- ---- ----ROWS_PROCESSED: 0 3,072,972 0ROWS_EXAMINED: 0 3,043,194 0ROWS_QUAL_STAG_1: 0 232 0ROWS_QUAL_STAG_2: 0 232 0ROWS_INSERTED: 0 0 0ROWS_UPDATED: 0 0 0ROWS_DELETED: 0 0 0TOTAL GETPAGES: 0 118,650 0TOTAL GETPAGES RI: 0 0 0ROWS_DEL_RI: 0 0 0PAGES_SCAN_LOB: 0 0 0PAGES_IN_UP_LOB: 0 0 0

---------------------------- SQL CACHE -------------------------- TOTAL SQLs EXECUTED: 32 DB2 ELAPSED TIME: 0.022246 DB2 CPU TIME: 0.021737 DB2 CPU TIME (AVG PER SQL): 0.000679 ROWS_PROCESSED: 32 ROWS_EXAMINED: 32 SORT: 0 INDEX SCAN: 32 TABLESPACE SCAN: 0 RIDLIST NOT USED - INTERNAL DB2 LIMITS REACHED: 0 RIDLIST NOT USED - NO AVAILABLE STORAGE: 0 GETPAGES: 96 SYNCHRONOUS BUFFER READ: 0 SYNCHRONOUS BUFFER WRITE: 0 DB2 WAIT SYNC I/O: 0 DB2 WAIT TIME SERVICE TASK: 0 DB2 WAIT TIME DATASHARING GLOBAL CONTENTION: 0DB2 WAIT TIME OTHER READS: 0DB2 WAIT TIME OTHER WRITES: 0DB2 WAIT TIME LOCK/LATCH: 0NRO PARALLEL GROUPS CREATED: 0

----------------------------- EXPLAIN ---------------------------------------------------------------------------------------------

PLAN TABLE PROGRAM TIMESTAMP:2010-07-22-21.51.08.634645 (ORIGINAL FORMAT = N)----------PROGRAM___:ADB2PRP STMT_NUM____:000000635 STMT_NUM_UNIQ_:80278CC4QUERYNO___:000005665 STMT_TYPE___:SELECT APPLNAME______:SEQUENTIAL:000000002 FLAG_CAST___:N COLLID EXPLAIN:SADVCOLPROCMS____: 0.002 GROUP_MEMBER: COST_CATEGORY_:APROCSU____: 5 QBLOCKNO___0001TBTYPE____:T PLANNO______:0001 CREATOR_______:SYSIBM TNAME__________:SYSCOLUMNSSEQUENTIAL:000000001 TABNO_______:0001 ACCESSCREATOR_:SYSIBM ACCESSNAME_____:COLUMNSXMETHOD____:0000 ACCESSTYPE__:I MATCHCOLS_____:0002 INDEXONLY______:NSORTN_U___:N SORTN_JOIN__:N SORTN_ORDERBY_:N SORTN_GBY______:NSORTC_U___:N SORTC_JOIN__:N SORTC_ORDERBY_:N SORTC_GBY______:NTSLOCKM___: N PREFETCH____: COL_FN_EVA____: QBLOCK_TYP_____:SELECTMIXOPSQ___:0000 ACCESS_PID__:0000 ACCESS_DEGREE_:0000 COLLID_EXPL____:SADVCOLJOIN_DG___:0000 JOIN_PGRP_ID:0000 SORTC_PGRP_ID_:0000 SORTN_PGID_____:0000PARAL_M___: MERGE_JOIN_C:0000 PAGE_RANGE____: CORRELATION____:JOIN_TP___: GROUP_MEMBER: WHEN_OPTIMIZE_: PARENT_QBLOCK__:0000TABLE_TYPE:T OPTHINT____: HINT_USED_____: PRIM_ACCESSTYPE:BIND_TM___:2014-12-26-11.35.39.750000 TIMESTAMP_____:201412261135

PLAN TABLE PROGRAM TIMESTAMP:2011-02-17-18.13.31.076443 (ORIGINAL FORMAT = N)----------PROGRAM___:ADB2PRP STMT_NUM____:000000644 STMT_NUM_UNIQ_:80278CC4QUERYNO___:000005669 STMT_TYPE___:SELECT APPLNAME______:SEQUENTIAL:000000002 FLAG_CAST___:N COLLID EXPLAIN:SADVCOLPROCMS____: 0.002 GROUP_MEMBER: COST_CATEGORY_:APROCSU____: 5

AVAILABLE FILTERS

Basic Filters: DateR


Start/End Time when this object has ended - rounded DataSharing Group Name DataSharing Member Name SSID(s) Request Code Source

Max Objects Report Level

1 – Only print information about UNIQUE 2 – Only print information about PERFORMANCE DETAIL (until TOTAL_REOPT)

SQL CACHE (until DB2 CPU TIME) EXPLAIN (until PROCSU)

3 – Print all information Print SQL Text (Y/N) – Show SQL TEXT (report level must be equal 3)

Other Filters: DB2 Plan Name Database Name Table Name(s) Unique Number DB2 Connection Type

REPORT HEADER

Report code: Internal report code. In example above, string 'ST02' is shown. Report title:

In example above, string 'ALL DB2 PROGRAMS SUMMARIZED' is the report name.Page:Page number. GROUP NAME: Datasharing Group name as specified in FILTER command.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTER command.MEMBER NAME: Datasharing member name as specified in FILTER command.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command.Start/End DATE: Start/End range date as specified in FILTER command.Start/End TIME: Start/End range time as specified in FILTER command.


449

FIELD DESCRIPTIONS

Unique:Unique Number that defines this SQL Text. For more information, please refer to SQLStatement Unique Algorithm.DB2 CPU(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP) %CPU-WKLD Percentage of total amount of CPU spent by this statement with same unique numbercompared with all workload.DB2 CPU Avg:Total DB2 CPU Average per command. This is (DB2_CPU) divided by total SQL executions with same unique number fromDB2 performance trace. DB2 Elapsed:Total DB2 Elapsed Time. Dprog:Total distinct programs using this SQL. SQLs:Total executed SQLs.

PERFORMANCE DETAILS

SQL TOTAL EXECUTED:Total SQLs executed. DB2 ELAPSED TIME:Total DB2 Elapsed Time. DB2 CPU TIME(ALL):Total DB2 CPU spent in all processors (CP plus SE/ZIIP).DB2 CPU TIME (AVG PER SQL)Average DB2 CPU per SQL execution TOTAL REOPT:Total Re-optimization occurred in run-time TOTAL NOREOPT:Total Re-optimization NOT occurred in runtimeINDEXRows/index entries/pages processed in IndexDATARows/pages processed in DB2 TableSORTRows/pages processed in Work File, a temporary table ROWS PROCESSED:Number of Rows of all record types processed.For example, number of rows returned for a SELECT, or number of rows affected by an INSERT, UPDATE or DELETE TABLESPACES with only 1 table:– This number counts rows for the related DB2 TABLE only Segmented TABLESPACES: – This number counts rows for the related DB2 TABLE only Index Spaces: same as


multiple tables:– This number counts all rows for all tables,not only for the related table. ROWS EXAMINED:Number of Rows of all record types processed.This number counts rows for the related table only.So, in some situations, this number will be the same value as ROWS PROCESSED ROWS QUAL STAG 1: Rows Qualified at Stage 1.


450

This means:– Indexable predicates– Predicates not indexable, but contain columns that belong to indexes (Index

Scanning)Stage 1 is faster than Stage 2 because they are resolved in DB2 Data Manager (DM). DB2 Data Manager resolves ROW-LEVEL processing. ROWS QUAL STAG 2: Rows Qualified at Stage 2.DB2 will:– Resolve all other predicates not resolved in Stage 1– It will scan (normally) rows and reject some of themStage 2 is resolved in Relation Data Server (RDS). RDS resolves SORT and SET-LEVEL Processing. ROWS INSERTED:Rows InsertedROWS UPDATED:Rows UpdatedROWS DELETED:Rows DeletedTOTAL GETPAGES:Getpages issuedTOTAL GETPAGES RI: Additional Getpages issued to enforce ref. Constraints.ROWS DEL RI: Additional Rows delete/set to null by ref. Constraints.PAGES SCAN LOB:Additional pages scanned in a LOB TABLESPACE.


SQL CACHE

TOTAL SQL EXECUTED: Total SQLs executed. For SQLs with cursor, this is the number of OPENs. DB2 ELAPSED TIME: Total DB2 Elapsed Time. DB2 CPU TIME: Total DB2 CPU spent in all processors (CP plus SE/ZIIP). DB2 CPU TIME (AVG PER SQL):Average DB2 CPU Time per SQL Execution. DB2 WAIT TIME LOCK/LATCH: Total DB2 Wait Time Spent in Lock/Latch. DB2 WAIT SYNC I/O:Total DB2 Wait Time in synchronous I/O to read/write DB2 application tables. DB2 WAIT TIME OTHER READS:Total DB2 WAIT Time of other reads done under a thread other than this one: – sequential prefetch– sequential detection– list prefetch – others synchronous read I/O not reported

DB2 WAIT TIME OTHER WRITES: Total DB2 WAIT Time of other writes done under a thread other than this one: – asynchronous write I/O – others synchronous write I/O not reported

DB2 WAIT TIME SERVICE TASK: Total DB2 Wait Time for Service Task (wait time due to synchronous execution unit switch to other DB2 service tasks). Service that may be included here: – Open and close of a data set


451

– Update of SYSLGRNG – HSM recall data set – Dataspace Manager Services

– Define data set – Extend data set – Delete data set Wait time spent in commit, abort or deallocation process.

DB2 WAIT TIME DATASHARING GLOBAL CONTENTION:Total waiting time caused by global contention for parent l-locks, child L-locks, other L-locks, pageset/partition P-locks, page P-locks and other P-locks. TOTAL GETPAGES:Getpages issued. SYNCHRONOUS BUFFER READ: The number of synchronous buffer reads. SYNCHRONOUS BUFFER WRITE: The number of buffer writes. ROWS EXAMINED:Number of Rows of all record types processed.This number counts rows for the related table only.So, in some situations, this number will be the same value as ROWS PROCESSED ROWS PROCESSED:Number of Rows of all record types processed.For example, number of rows returned for a SELECT, or number of rows affected by an INSERT, UPDATE or DELETE TABLESPACES with only 1 table:– This number counts rows for the related DB2 TABLE only Segmented TABLESPACES: – This number counts rows for the related DB2 TABLE only Index Spaces: same as


multiple tables:– This number counts all rows for all tables,not only for the related table.SORT: Total Number of sort performed. INDEX SCAN: Total Number of index scan performed. TABLESPACE SCAN:Total Number of index scan performed. NRO PARALLLEL GROUPS CREATED: Total Number of parallel groups created by the statement. TOTAL EXCEED RIDPOOL INT LIMIT:Total access using RID List has failed because of internal DB2 limits. So, even if youchange RIDPOOL size, nothing will change. In the past, some internal limit were: DataManager limit (16 million) or RDS reach 25 percent of table size.A DB2 Table Scan will be done. TOTAL RIDPOOL NO STORAGE: Total access using RID List has failed because of size of RIDPOOL. If its possible,increase RIDPOOL size. A DB2 Table Scan will be done.

EXPLAIN / EXPLAIN AND SQL TEXT

Explain information will be written. For more information, please go to Appendix F-Plan tables description.


452

TI00 - INDEX USAGE - CATALOG

This report show DB2 Indexes definitions from DB2 catalog.Also, it will indicate if indexes are in fact are being used according to DB2 ExplainTables (TurboTuneSQL repository) and DB2 catalog tables (DB2 RTS).

SAMPLE REPORT

AVAILABLE FILTERS Basic Filters:

Request Code Source Request Code Explain

Max Objects Other Filters:

Table Name(s). Wildcards are valid for this field. Table Name(s) and Owner Owner Database Name Database Name Range Index lastused: NN months


453

====================================================================================================================================TI00 INDEX USAGE OVERVIEW - CATALOG DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: PRINT SQL TEXT: N SSIDS:DBAGSOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00INDEX LASTUSED :00 MONTHS END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

OWNER: BBZTABLE: ACAO_BDP------------------------------------------------------------------------------------------------------------------------------------ U C CLCREATOR INDEX R COLCOUNT L RATIO FIRSTKEYCARDF FULLKEYCARDF NLEAF BPOOL INDEXSPACE STATSTIME-------- ------------------ - -------- - ----- ------------- ------------- ------- -------- ---------- --------------------------BBZ XABEAFKI D 1 N 0 -1 -1 -1 BP1 XABEAFKI 0001-01-01-00.00.00.000000 DUPLICATES ALLOWED

COL O SQL DATA COL COL COL F FOREIGN FLD COL_NAME SEQ R TYPE TYPE LENGTH PREC SCALE N HIGH2KEY LOW2KEY KEY PROC COLCARDF ------------------ ----- - -------- ---- ------ ----- ----- - ---------------- ---------------- ------- ---- ----------- COD_ESP_BBZ 1 A SMALLINT 501 2 5 0 N 8062 800D N 66

----------------------------- INDEX CROSS REFERENCE -------------------------------------------------------------------------------

TOTAL LINES FOUND IN PLAN TABLE: 0

TOTAL LINES FOUND IN CATALOG PACKAGES: 0

TOTAL LINES FOUND IN CATALOG DBRMS: 0

>> INDEX NOT USED << (LASTUSED FIELD IN DB2 CATALOG INDICATES: ----------)

REPORT HEADER

Report code: Internal report code. In example above, string 'TI00' is shown.

Report title: In example above, string 'INDEX USAGE OVERVIEW - CATALOG' is the report name.Page:Page number. GROUP NAME: Datasharing Group name as specified in FILTER command. Not used.MAX OBJECTS: Specify the maximum number of main objects to be printed as specified in FILTERcommand.MEMBER NAME: Datasharing member name as specified in FILTER command. Not used.SSID1, SSID2, SSID3, SSID4: DB2 SSIDs as specified in FILTER command. Not used.Start/End DATE: Start/End range date as specified in FILTER command. Not used.Start/End TIME: Start/End range time as specified in FILTER command. Not used.Index lastused: NN months'NN' represents the number of months that the index has not been used. For instance, if today is 2012-03-25 and value 05 was informed, only indexes which has not been used since 2011-10-25 (inclusive) will be listed. Notes:– LASTUSED field is retrieved from SYSINDEXSPACESTATS.– This date is updated when the index is used for SELECT, FETCH, searched

UPDATE, searched DELETE, or used to enforce referential integrity constraints.– This information is only available for DB2 V9 and UP. – All index that contais NULL value in column LASTUSED or not found in table

SYSINDEXSPACESTATS will be listed in this report , regardless parameter Index lastused

FIELD DESCRIPTIONS

Owner: Owner Table nameTable name: Table nameCreator: Index CreatorName: Index nameUR: Whether the index is unique: Valid values: D - Duplicates are allowed

U - Unique P – Unique and primary indexC - Unique, used to enforce UNIQUE constraint or hash key N

- Unique, defined with UNIQUE WHERE NOT NULL R - Unique, enforce the uniqueness of a non-primary parent keyG - Unique, enforce the uniqueness of ROWIDX - Unique, enforce the uniqueness value of XML column

COLCOUNT: The number of columns in the key

CL: Indicate if this is a CLUSTER index.


454

Valid Values: N - No Y - Yes CL RATIO: Percentage of rows that are in clustering orderFIRSTKEYCARDF: Number of distinct values of the first key columnFULLKEYCARDF: Number of distinct values of the key. Value -1 means that statistics have not been processedNLEAF: Number of active leaf pages in the index. Value -1 means that statistics have not beenprocessedBPOOL: This is the name of the buffer pool used for the indexINDEXSPACE: This is the name of the index spaceSTATSTIME: This is the date and time when RUNSTATS updated the statistics.COL_NAME: Column nameCOL_SEQ:Numeric place of a column in a view or table. Example: column number 3 of 15

columns.OR: Ordering. Valid values:

A – AscendingB - Descending

SQL DATA TYPE: Column definition type. Examples:

INTEGER Large integer SMALLINT Small integer FLOAT Floating-point CHAR Fixed-length character string VARCHAR Varying-length character string LONGVAR Varying-length character string DECIMAL Decimal GRAPHIC Fixed-length graphic string VARG Varying-length graphic string LONGVARG Varying-length graphic string DATE Date TIME Time TIMESTMP Timestamp BLOB Binary large object CLOB Character large object DBCLOB Double-byte character large object ROWID Row ID data type DISTINCT Distinct type COL TYPE: Values are for internal use only.LENGTH: Length (in bytes)

COL PREC: Precision. Number of digits for this column.COL SCALE: Scale of decimal columns.FN:


455

Flag null. Whether the column contains a null value. Valid values: Y – Yes N - NoHIGH2KEY: Second highest value of the columnLOW2KEY: Second lowest value of the column FOREIGNKEY: Only for columns defined as character. (shows the subtype of the data). Valid values: B - BIT data S - SBCS data FLDPROC: Shows if field procedure for a column: Valid values: Y - Yes N – NoCOLCARDF: Rows Cardinality for this column.

INDEX CROSS REFERENCE

Check if index are being used.

TOTAL LINES FOUND IN PLAN TABLE: Total number of plan table lines showing that this current table was found inTurboTuneSQL Repository (Source Explain Tables).

TOTAL LINES FOUND IN CATALOG PACKAGES:Total number of lines showing that this current index are being used by a DB2 Package.

TOTAL LINES FOUND IN CATALOG DBRMS: Total number of lines showing that this current index are being used by a DB2 DBRM.

When fields TOTAL LINES FOUND IN PLAN TABLE, TOTAL LINES FOUND IN CATALOGPACKAGES and TOTAL LINES FOUND IN CATALOG DBRMS are showing zero, message<<INDEX NOT USED>> will be shown in DDNAME TI00 and DDNAME TI00IXNU,meaning that this index are not being used by any program. Otherwise, message LASTUSED will be shown. Examples:a) If current Index is not being used, above message will be shown. Note that filterIndex lastused: NN months was applied: >> INDEX NOT USED << (LASTUSED FIELD IN DB2 CATALOG INDICATES: ----------)

b) If current Index is being used, message may be shown:LAST USED: 2012-04-01

Notes:– LASTUSED field is retrieved from SYSINDEXSPACESTATS– Value '--------' will be listed is LASTUSED contains NULL value or DB2 is not V9

and up– Value 'NOT FOUND' will be listed if current index not found in

SYSINDEXSPACESTATS.

Click here to find tips about dropping an index.


456

TI01 – DUPLICATED INDEX ANALYSIS

Analyze all DB2 indexes from DB2 catalog and print similar or identical indexes. Also, for DB2 V10 and up, help users to use INCLUDE index option.

SAMPLE REPORT

AVAILABLE FILTERS Basic Filters:

Max Objects Print SQL Text (Y/N) – Show SQL TEXT

Other Filters: Table Name(s). Wildcards are valid for this field.

Table Name(s) and Owner Owner

REPORT HEADER

Report code: Internal report code. In example above, string 'TI01' is shown. Report title:

In example above, string 'INDEX ANALYSIS' is the report name.Page:Page number. Max Objects: Specify the maximum number of main objects to be printed as specified in FILTERcommand.


457

====================================================================================================================================TI01 DUPLICATED INDEX ANALYSIS DATE:2015/01/19 - PAGE: 1GROUP NAME: MAX OBJECTS: 1110MEMBER NAME: PRINT SQL TEXT: N SSIDS:DBAGSOURCE REQUEST CODE:IVP1 REPORT LEVEL: 3EXPLAIN REQUEST CODE:IVP1 START DATE:1900-01-01 START TIME:00.00.00 END DATE:2100-01-01 END TIME:23.23.00====================================================================================================================================

Creator Table Name Reason-------- ------------------ ------------------ ----------------------------------------------------------------------------

IVPQUAL EMP IXEMP RIXTI0101 - IDENTICAL INDEX. RELATED INDEX: EMPABCDE_#_SPXIVPQUAL IVPTABLE_CUSTOMER IXTBCTM1 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXTBCTM2IVPQUAL IVPTABLE_INCL IXINC01 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXINC05IVPQUAL IVPTABLE_INCL IXINC01 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXINC07IVPQUAL IVPTABLE_INCL IXINC07 RIXTI0101 - IDENTICAL INDEX. RELATED INDEX: IXINC05IVPQUAL IVPTABLE_INCL_T1 IXTBT101 RIXTI0102 - UNNECESSARY INDEX. RELATED INDEX: IXTBT102IVPQUAL IVPTABLE_INCL_T3 IXTBT302 RIXTI0101 - IDENTICAL INDEX. RELATED INDEX: IXTBT301IVPQUAL IVPTABLE_INCL_T4 IXTBT402 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXTBT401IVPQUAL IVPTABLE_INCL_T5 IXTBT501 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXTBT502IVPQUAL IVPTABLE_INCL_T8 IXTBT801 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXTBT802IVPQUAL IVPTABLE_ORDER IXTBORD1 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXCLUSTERIVPQUAL IVPTABLE_ORDER IXTBORD1 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXMAYBEIVPQUAL IVPTABLE_ORDER IXTBORD1 RIXTI0103 - MAYBE IS A DUPLICATED INDEX. RELATED INDEX: IXUNNECESSARY

FIELD DESCRIPTIONS

Creator: Table creatorTable: Table nameName: index name that has violated a TurboTuneSQL ruleReason: Valid value for identical indexes (Index ixname is identical to Index related index):(ixname)RIXTI0101-IDENTICAL INDEX. RELATED INDEX: (related index)

Valid values for similar indexes (Index ixname is similar to Index related index):(ixname)RIXTI0102-UNNECESSARY INDEX. RELATED INDEX: (related index) (ixname)RIXTI0103-MAYBE IS A DUPLICATED INDEX. RELATED INDEX: (related index)

Notes: 1 - Click on How indexes are compared to identify similar and identical indexes to findmore about how indexes are compared and which indexes should be dropped.2 - For DB2 V10 and up: this report can help users to generate DDLs to ALTER INDEXwith ADD INCLUDE clause and to DROP INDEX whenever the comparison detected thatan INDEX might be duplicated. The result will be generate on ddname DDLS.Details:

2.1 - A warning message will be issued to aware users that an INDEX altered withINCLUDE clause must be done carefully because its matchols may decrease.Please refer to IBM DB2 documentation for more details.

2.2 - Altered index will became in Rebuild Pending Status.

2.3 - Altered index will grow in terms of disk space.

2.4 - You must be awared to proceed the ALTER INDEX paired to DROP INDEX withreserve. The same index to DROP can appears as to ALTER INDEX due to thecomparison between them.

Click here to find tips about dropping an index.


458

Chapter 5. Utilities

This chapter describes the utilities available in TurboTuneSQL. Almost allTurboTuneSQL Utilities are batch jobs.

After start TurboTuneSQL CLIST, Utilities are located at “4.4 – Utilities“:



FILTERS

Each TurboTuneSQL utilities has it own filters. They are NOT influenced by OnlineTurboTuneSQL FILTER command.

JCLFor Batch utilities, type ‘JCL’ online command to create the JCL to be submited. A newscreen will prompt you to choose a data set where TurboTuneSQL Utility Reportprogram will be stored.

Notes: - Check Appendix JCL Description for a summary of all JCL generated byTurboTuneSQL.- After changing any parameter, you will only need to re-create the JCL if it isspecified.


459

TurboTuneSQL V120 ------------------- Utilities ------------------------- 13:3 Option ===> Profile : IVP {E} DB2 SSID : DBBG Utility: Curr Loc : DALLASB BATCH UTILITIES ON-LINE UTILITIES CLEA: Clear Product Tables EXPL: DB2 Explain CPLA: Compare Plan Tables SQL : Execute SQL commands DDLG: DDL Generator DB2 : Execute DB2 commands EXPB: Explain Utility SQLG: SQL Sequential Data set STAR: Start DB2 Trace SUPPORT (LAB DIAGNOSIS) XREF: SQL Tables Cross Reference SEND: Send data to lab MRFC: Multi-Row Fetch Converter MEM : Storage Manager Summary

UTILITIES SUMMARY

These are TurboTuneSQL Utilities Summary. Every time you choose a new report, youmust regenerate JCL. Any other fields, if changed, does not requires JCL regeneration.

Utilities are located at main screen “Utilities“.

Name Description

CLEA - Clear Tables Utility Utility to delete rows from TurboTuneSQL Repository Tables.

CPLA - Compare Plan Tables Utility Utility to compare two TurboTuneSQL Plan Tables

DDLG - DDL Generator Utility Utility to generate DDLs – internal use only. For use only under the direction of your local

representative.

EXPB - Explain Utility Utility to execute EXPLAIN against SQL commandsstored in TurboTuneSQL Repository (Source Tables).

SQLG- SQL Sequential data set Utility to create a sequential data set with SQLs. This sequential data set can manipulated and re-input into TurboTuneSQL.

STAR- Start DB2 Trace Utility Utility to collect trace records from DB2.

XREF -SQL Tables Cross Reference Utility to obtain a cross reference of tables related in SQL commands like Joins, Subselect, View, etc.

MRFC - Multi-Row Fetch Converter Online Utility to perform interactive explanation for any SQL text.

EXPL-DB2 Explain Command Online Utility to perform interactive explanation for any SQL text.

SQL-Execute SQL commands Utility to execute SQL commands (except for SELECTs or other commands which return rows).

DB2-Execute DB2 commands Utility to execute DB2 commands.

SEND-Send Data to lab For use only under the direction of your localrepresentative.

MEM-Storage Manager Summary For use only under the direction of your localrepresentative.


460

Start DB2 Trace Utility

Utility to collect trace records from DB2. This utility is called: TurboTuneSQL TraceCollector (or TurboTuneSQL TCD). This utility can use sampling, so DB2 traces can bestarted and stopped in intervals. DB2 traces will be started for DB2 SSID from currentprofile.

Note: At run-time, if you wish to cancel the job generated by utility, always issue STOPconsole command. Never issue CANCEL command. This procedure will guarantee thatall DB2 traces started by this utility will be properly stopped.

SAMPLE SCREEN


461

TurboTuneSQL V120 ------------------- Setup DB2 Trace ------------------- 13:45 Option ===> More: + Start DB2 Trace Profile : IVP {E} DB2 SSID : DBBG General Parameters: Trace times: Start/End date: 1900-01-01 2100-12-31 (yyyy-mm-dd or ********) Start/End time: 00.00.00 23.59.59 (hh.mm.ss) Sampling: Trace duration : 00.00.10 (hh.mm.ss) Trace delay: 00.10.00 (hh.mm.ss) General options for CACHE traces: Trace options: (type '/') Collect Dynamic SQLs from DB2 CACHE Collect Static SQLs from DB2 CACHE Store Mode : B L/R/B L:Local R:Remote B:Both Ip Address/Port : 192.168.11.11 / 09190 Sampling mode option : N Y/N Y:Turn on/off traces in sampling mode Reduce trace data : 30 (Minutes) - At n minutes,DB2 date and time will be rounded up using this parameter Capture full cross reference: Y Y/N Y:Capture correlation, userid, etc. Use default trace for cache : O Start trace to: S:SMF G:GTF O:OPX N:Dont start Area Size : 00000 Internal getmain size (default:00000) Request Code for Source : Request code to search repository

FIELD DESCRIPTIONS

Trace time: Start/End dateStart and end date to start/stop collections in the format yyyy-mm-dd. Use '********' to accept current date.

Start/End timeStart and end time to start/stop collections in the format hh.mm.ss.

Sampling: Trace duration Duration for collections. The DB2 trace will be ON during for this amount of time in theformat of hh.mm.ss

Trace delay Delay for collections. DB2 trace will be OFF during this amount of time in the format ofhh.mm.ss.

Note: when sampling are enabled, if the product misses a PREPARE statement becauseit occurs during a period in which the product is not collecting data, you might get OPEN,FETCH, and CLOSE statements not registered. This occurs because the product mustcollect the PREPARE statement to compute Uniques numbers (for more informationcheck Appendix Algorithms). This is side effect of sampling process.

Trace optionOption to :

1 - Check SMF or GTF activity when have asked to TurboTuneSQL to start a DB2 Accounting or Performance Trace. 2 - Get Dynamic SQLs from DB2 SQL Cache Area, regardless you DB2 trace you want (or not) to start.

Valid Values SMF, GTF and CACHE.

SMF: TurboTuneSQL will check SMF buffer status. If SMF buffer is full, TurboTuneSQL will stop turn on DB2 traces until its relieved.

Tip: (1) When using SMF as DB2 trace destination, you can issue console command 'DSMF' to control and eventually check how fast are growing SMF data sets.(2) Also, specify SMF buffering on the VSAM BUFSP parameter of the accessmethod services to DEFINE CLUSTER statement of SMF data set. Specify CISZ(4096)and BUFSP(81920) on the DEFINE CLUSTER statement for each SMF VSAM data set.These values are the minimum required for DB2; you might have to increase them,depending on your z/OS environment. DB2 runs above the 16MB line of virtual storagein a cross-memory. Check IBM DB2 documentation for more details.

GTF:

If GTF was not started, TurboTuneSQL will stop turn on DB2 trace until GTF PROC isstarted.

CACHE:


462

TurboTuneSQL will read dynamic SQL from SQL Cache Area (DB2 EDM POOL).TurboTuneSQL will:– Start the following DB2 trace: -START TRACE(MON) IFCID(318) DEST(OPX) CLASS(1)

BUFSIZE(1024)The overhead for these traces is about 2% for each dynamic SQL commandexecuted.

– Execute DB2 Explain function. – If you wish to read all SQL from SQL cache area, you should have SYSADM

authority (see exception). If PTF PK15155 are not installed, you must have INSTALLSYSADM authority to execute this function. If you don't have this authority, onlySQLs issued by you your userid will be read from SQL Cache Area. Exceptions: ForDB2 V8 and up: SYSADM authority may be not necessary if job INST33BE wasexecuted during TurboTuneSQL installation process. Check Installation Guidemanual for more details. DB2 V10 has implemented new Explain, SQLADM andSYSTEM DBADM authorities. Check IBM DB2 documentation for moreinformation.

– Authority to execute SET CURRENT SQLID to "TurboTuneSQL Install Qualifier" isrequired.

– Data will be stored into STMT_CACHE_MON table.– DB2 wait time information spent by each SQL in cache will be available only if

accounting trace class(3) is active.

Restriction: “It is not recommended to have IFCID trace 318 turned on when the profiling facility is active, since the IFCID trace activity interferes with the data collection and statistics reported by the profiling facility. Please ensure that IFCID trace 318 is not turned on prior to issuing START PROFILE command.”

Valid Combinations: SMF and CACHE, GTF and CACHE, CACHE.

Very important recommendation: - Starting Performance Traces:

To reduce the total overhead. Do not start performance trace with a long duration.This can slow down your DB2 and generate too much trace records.

Also, consider make use of GTF. It consumes less CPU if compared to SMF.

Here follows some examples, but each installation should set these numbers to themost appropriate values. Examples:

(A): Set Trace Duration to: 10 seconds and Set Trace Delay to: 10 minutes

(B): Set Trace Duration to: 30 seconds and Set Trace Delay to: 05 minutes

- Starting Accounting Traces:

To reduce the total overhead and disk space, we recommend you to set up Trace Delay time to a value greater than 1 minute.

Here follows some examples, but each installation should set these to the most appropriate values. Examples:

(A): Set Trace Duration to: 1 minute and

Set Trace Delay to: 1 minute

(B): Set Trace Duration to: 5 minutes and Set Trace Delay to: 2 minutes


463

- Getting Dynamic SQLs from cache:

When using this option, TurboTuneSQL will store SQLs from DB2 SQL Cache Areaintoa DB2 table every time a period of Trace Duration finish.So, the recommendation here is to setup a long Trace Duration, with short TraceDelay time. If you do not follow this recommendation, too many SQLs will be storedin DB2 table and this will slow down TurboTuneSQL batch processing.

Here follows some examples, but each installation should set these numbers to themost appropriate values. Examples:

(A): Set Trace Duration to: 5 hours and

Set Trace Delay to: 10 seconds

Therefore, in 24 hours, SQLs from Cache will stored 4 times (24/5).

(B): Set Trace Duration to: 2 hours and Set Trace Delay to: 1 second

- Create separate TurboTuneSQL Profiles for each configuration Because Trace Duration and Trace Delay will vary depending on the trace you will bestarting (Accounting, Performance, Cache) you should create separate profiles.

Specify trace command (command 1,2,3,4)Enter any DB2 command

Extra information: 1 - DB2 Accounting Traces.

Accounting class 1: This class provides data about application time, like elapsed and cpu time.Accounting class 2: This class provides data about Plans, basically elapsed and cpu time.Accounting class 3: This class provides data about Plans, basically DB2 Wait timeAccounting class 7: This class provides data about DB2 packages and dbrms, basically elapsed and cputime. Accounting class 8: This class provides data about DB2 packages and dbrms, basically DB2 Wait time.IFCIDs 3 and 239. These IFCIDs are the main information processed by TurboTuneSQL. So, other IFCIDswill not be processed here.

2 - DB2 Performance traces. Performance class 30: This class permits specification of only some IFCIDs. This facility allows us to getseveral pieces of DB2 information with minimum overhead. IFCIDs used by TurboTuneSQL: 58 - End of a SQL command. This is a MANDATORY IFCID for TurboTuneSQL.59 - Start of SQL Fetch command. This is a customer decision to turn it on

because it can bring up a lot of information. 60 - Start of SQL Select command. 61 - Start of SQL Insert, Delete or Update command. 62 - Start of SQL DDL or DCL command. 63 - This IFCID is used only to get text of dynamic SQLs. 64 - Start of SQL Prepare or Execute command.


464

65 - Start of SQL Open cursor. 66 - Start of SQL Close cursor.

3 - TDATA(CPU,COR,DIST) This option is MANDATORY to TurboTuneSQL to get all correct information from DB2traces.

4 - BUFSIZE(1024) Adjust this option according to your DB2 installation. 5 - DB2 trace internally started by TurboTuneSQL to read dynamic SQLs from DB2 SQL Cache Area.

-START TRACE(MON) IFCID(318) DEST(OPX) CLASS(1) BUFSIZE(1024)

Attention:1 - DB2 SQL Cache Area does not contain Correlation information. So, if you areusing SQL Cache Area to monitor dynamic SQL from DB2 Connect, the 'correct'program name will not appear. So, if you want this information use IFCID 63.2 - DB2 SQL Cache Area does not contain the time spent by DB2 to execute SQLPrepare command. Again, if you want this information use IFCID 63.3 - if you are getting dynamic SQL from SQL Cache Area, you can save disk space ifyou don't use IFCID 63, but you will loose some information about the executesSQLs, like Correlation , Prepare time, number of individuals scanned records bytablespace and indexes space, etc.4 – Make use of GTF, mainly when starting DB2 Performance Traces.5 – FILTERS. You can used them to minimize DB2 overhead and save disk space: - DB2 Version 7,8 allows you to create filters by Plan, Authid, Location, etc.

- DB2 Version 9 allows you to create filters by Plan, Authid, Location, Package, Workstation, etc. - If you are using GTF, you can also FILTER by JOBNAME using following sysin example in GTF PROC:

– TRACE=JOBNAMEP,USRP – USR=FB9 – JOBNAMEP=jobname– END

6 – The traces turned on/off by this utility DOES NOT interfere with any other traces turned on by any user or any other programs. Also for all traces involved for CACHE processing. Note that IFCID318 does not appear in any CLASS. 7 - If you request CACHE and IFCID318 is already being colleted, the batch process may issue warning messages (check for message SADBCAV8DUPW).

Check IBM DB2 documentation for more information.

Note: This utility will issue SQL COMMIT every 5 collections. Parameter NCOMMIT(see TurboTuneSQL Profile) will not be used here.


465

Explain Utility

Utility to execute DB2 EXPLAIN function against SQL commands stored intoTurboTuneSQL Repository (Source Tables). This utility can copy user Plan Tables intoTurboTuneSQL Repository.

For Explain function, it can perform EXPLAIN for all SQL source or only for SQLsexecuted in workload.

To execute this utility, user must have the following authorities:

– SELECT authority on tables: PLAN_TABLE, DSN_STATEMNT_TABLE andSYSPACKAGE for execution mode "2" only

– For execution Explain function (execution modes "1" and "3"), users must have: – SYSADM authority OR

Must have the authority to send SQL SET CURRENT SQLID (check optionUse this Plan Table Qualifier / Set Current SQLID)

– It may be necessary to have the same authority as required by DB2 toexecute the command that will be explained, except if job INST33BE wasexecuted during TurboTuneSQL Installation Process.

– SELECT, DELETE, UPDATE on tables (or Alias are in DB2 version 8 or up):PLAN_TABLE, DSN_STATEMNT_TABLE and DSN_FUNCTION TABLE(optional).


This utility makes use of Dynamic SQL to access DB2 Plan table. Therefore, you mayhave to setup DB2 RLF. Also, it may not work properly if SQL text was input usingDBRMLIB data set.

Also, we strongly recommend the creation of non-unique indexes on all PLAN TABLEs.

We recommend an index creation on columns:

INDEX 1: NON UNIQUE INDEX ON PLAN_TABLE (PROGNAME ASC, QUERYNO ASC, QBLOCKNO ASC, PLANNO ASC, MIXOPSEQ ASC)

INDEX 2: NON UNIQUE INDEX ON PLAN_TABLE (ACCESSCREATOR ASC, ACCESSNAME ASC)

INDEX 3: NON UNIQUE INDEX ON DSN_STATEMNT_TABLE (PROGNAME ASC, QUERYNO ASC)


466

Notes:

(1) This utility does not accept wildcards. The only exception is parameter programname.

(2) DB2 provides some additional Explain tables (ENHANCED EXPLAIN TABLES) withmore information to help you to explain queries. These additional tables containvaluable information. Supported Enhanced explain tables are: "DSN_PREDICAT TABLE", "DSN_SORT_TABLE","DSN_FILTER_TABLE", “DSN_SORTKEY_TABLE" and "DSN_DETCOST_TABLE".

(3) When DB2 execute an Explain, Virtual Index Table will be checked and accessplans will be stored into PLAN TABLEs (all available PLAN TABLEs).

(4) You must be aware that MASSIVE BATCH EXPLAINs will execute faster if:- There is NO VIRTUAL INDEXES TABLE- There is NO ENHANCED EXPLAIN TABLES

(5) However, information provided from ENHANCED EXPLAIN TABLES are veryinteresting. This is a trade-off.

(6) Conclusion: This a user decision, however you should consider have on set ofPLAN TABLEs for MASSIVE EXPLAIN and OTHER for single/online explains.

SAMPLE SCREEN


467

TurboTuneSQL V120 ----------------- Explain Utility --------------------- 13:56 Option ===> More: + Profile : IVP {E} DB2 SSID : DBBG Execution Mode: 1 Values: 1 - Execute Explain Only 2 - Execute Plan Table Copy Only 3 - Execute both functions Back-up Plan Table : N Y/N Backup explain data before execute this process --------------------------------------------------- Execute Explain PARAMETERS (Execution Mode 1 and 3) --------------------------------------------------- General Parms: Explain Request Code: IVP Store explains in this Req Code Source Request Code: IVP Retrieve SQL from this Req Code Get SQLs from programs: S Values: W - Workload (only executed statements) P - Last Trace (current trace) S - Source (all precompile versions) L - Source (last precompile versions)

FIELD DESCRIPTIONS



Execution Mode: This Explain Utility has 3 execution modes:

1 - Execute Explain Only: This option is the default and executes DB2 Explain funcion against SQLstatements stored into TurboTuneSQL Repository.

2 - Execute Plan Table Copy Only:This option copies the user Plan Table data into TurboTuneSQL Repository andno Explain will be performed. Just data will be copied from user Plan Table intoTurboTuneSQL Repository.All data from Plan Table will be processed but they will be only stored into TurboTuneSQL if the corresponding program (package or DBRM) was previoulyprocessed from DB2 catalog into TurboTuneSQL Repository.Plan Table data will not be processed if the corresponding program (package orDBRM) was not found.This option will work well only if you have loaded your application program intoTurboTuneSQL tables using DB2 Catalog option. In this case, do not loadprograms from the DBRMLIB data set.

3 - Execute Both Functions:This option executes modes "1" and "2".

Back-up Plan Table Valid Values:

Y: Yes. Backup-up TurboTuneSQL Explain Data before executing Explain or Copy PlanTable process. This option will generate a process (J700COPY) in order to copyTurboTuneSQL Plan Table with a backup request_code informed by user.N: No. Back-up will not be performedIf you change this parameter, JCL needs to be re-created.

PARAMETERS USED BY OPTIONS EXECUTION MODE 1 OR 3 (EXPLAIN)

Explain Request Code This is a 5 character code to be used as key identifier to store DB2 Explain results intoTurboTuneSQL Repository.If you want to create a history of explains, use a different request code at each newrun.

Source Request Code This is a 5 character code used as key identifier to read stored SQL commands fromTurboTuneSQL Repository.

Get SQLS from programs found inSpecify:

'W' - Explain only executed SQLs'P' - Explain ALL SQL for programs found in last DB2 Trace'S' - Explain ALL SQLs found in source. 'L' - Explain ALL SQLs found in source, but do only the oldest program version from precompile time.


468

Process all STMTS Specify:'Y' - Process all SQL statements. This will include SQL statements with processingerrors. Table Synonyms will be included. (To learn more about processing errors, please refer to Appendix E. Limits and checkfield flag error in STIF Report.)'N' - Process only SQL statements with no errors; Table synonyms will not be included.

Process Static/Dynamic Specify: 'D' to process only dynamic statements 'S' to process only static statements 'B' to process both dynamic and static statements

Process all collections Specify:'Y' - Process all SQL statements found in all DB2 Collections.'N' - Process only SQL statements for the first valid DB2 Collections.

Stop When Find an Error Inform NNNNN to stop after this number of negative SQLCODEs. Inform 00000 for no limit.

Control to delete Explain Tables

Specify:

NORMALDeletes exactly the same program from TurboTuneSQL Repository Tables (Explain Source Tables).Program, token, collection_id and statement number will be used as filters fordelete action.

KEEPIt will check whether TurboTuneSQL has already performed explain against thisstatement. In case of it has already performed, explain will be skipped.Otherwise, explain will continue. Note: It is considered the collection_id to perform the inquiry whether thestatement has explain information already.

NEVERNever deletes previous explain data from TurboTuneSQL Repository (ExplainSource Tables).Consider this option for best performance if you have not changed explainrequest code or if this is the first run.


469

Plan Table Setup

Use this Plan Table Qualifier/Set Current SQLID Use this parameter to control whether TurboTuneSQL should issue SQL Set Current SQLID command before executing Explain command Valid Values: - Blank: TurboTuneSQL will issue Set Current SQLID using the owner ofTurboTuneSQL tables (configured in TurboTuneSQL Profile) Effects: - Job submitter must have GRANT authority to issue this SQL Set

Current SQLID and must have GRANT to DELETE/INSERT/UPDATE/DELETE in these tables: Owner of TurboTuneSQL tables.PLAN TABLE Owner of TurboTuneSQL tables.DSN STATEMNT TABLE Owner of TurboTuneSQL tables.DSN FUNCTION TABLE

(creation of DSN_FUNCTION_TABLE table is optional) (creation of DSN_PREDICAT_TABLE, DSN_FILTER_TABLE, DSN_DETCOST_TABLE, DSN_SORT_TABLE and DSN_SORTKEY_TABLE enhanced explain tables is optional) - All DB2 Explain results will be also stored the above tables (check

parameter Delete rows from Plan Tables) - *USERID: If you choose option string *USERID, TurboTuneSQL will issue Set Current SQLID using the current Userid of the Job submitter Effects: - Job submitter must hold its own DB2 Plan Tables: Job submitter.PLAN_TABLE Job submitter.DSN_STATEMNT_TABLE Job submitter.DSN_FUNCTION_TABLE

(creation of DSN_FUNCTION_TABLE table is optional)

- All DB2 Explain result will be also stored in: Userid of job submitter.Plan table(S) - Any string: If you choose a string different from *USERID*/Blank TurboTuneSQLwill issue Set Current SQLID using supplied string. Effects: - Job submitter must have GRANT authority to issue this SQL Set

Current SQLID to Any string and must have GRANT to DELETE/INSERT/UPDATE/DELETE in these tables: Any string .PLAN TABLE Any string .DSN STATEMNT TABLE Any string .DSN FUNCTION TABLE

(creation of DSN_FUNCTION_TABLE table is optional) - All DB2 Explain results will be also stored in the above tables (check

parameter Delete rows from Plan Tables)


470

Delete rows from Plan Table after Explain Specify 'Y' to delete Plan Table rows after explain.

Data will delete using key queryno=current value (as specified in parm start explain with queryno) and progname=SQLTEXPL.

Specify 'N' to maintain Plan Table rows after explain.In this case progname field will have the current program name being explained. Also, queryno field will contain the value as specified in parm start explain with queryno.

Explain in cloned Table. If so, set parms below:

Use this Table Qualifier: Inform a Table Qualifier to be forced in each DB2 table before executing Explain command when table informed in parm For this Table Name is found during Explain process.

For this Table name: Inform a specific table name for the qualifier forced, only for this table name.For instance, any reference found in SQLs for the table name informed will have the qualifier replaced.

Start explain with queryno Specify a start number to be stored as an initial value for queryno into Plan tables and it will be incremented by 1 at each new SQL statement.If you specify '00000', the unique statement value will be used as a queryno in all PlanTables.

Explain Method: Inform type of explain to be performed

Specify:

CAST Cast Syntax will be used to explain the statements: TurboTuneSQL always executes dynamic Explain, but this method tries to generate thesame DB2 explain behavior as if it was performed by DB2 Bind command with ExplainOption.

This is done using DB2 Cast syntax with the same data type and size as specified inhost variables.

Therefore host variable :H will be changed by: CAST ( ? AS datatype ( size ) )

So, if there are data type mismatches between DB2 table columns and host variablethe bad access path behavior generated by explain command will be shown.

In TurboTuneSQL terminology this is called CAST-MAX.

All reports (field OF) will show this information using: Original Format = Y


471

NCASNCAS - TurboTuneSQL will try to explain the statements using the steps below: (1) At first, parameter mark (?) will be used.Therefore host variable :H will be changed by '?'. In TurboTuneSQL terminology this is called Q-MARK

(2) If the step above does not work, it will try to explain using DB2 Cast Syntax likeCAST option, using the same data type as specified at host variables but usingminimum size.Therefore host variable :H will be changed by: CAST ( ? AS datatype ( minimum size ) )

In TurboTuneSQL terminology this is called CAST-MIN

All reports (field OF) will show this information using: Original Format = N

For any version of DB2 this is the best method.

BOTHBOTH - Both syntaxes will be tried: CAST and NCAS

Use this option when you want to check for mismatch problems which are not fullyresolved even in the most recent DB2 versions.IMPORTANT: When you use this option performance can be degraded and the job willtake much longer than using only NCAS.

For more information about SQL formats, go to program original format and non-original format.

FILTERS

Database Name FROM / TO Inform a range of databases Table Qualifier Inform a qualifier

Table Name Inform up to 6 table namesFirst slot for this field can be informed using wildcard '*' at the end which will fetch a range of tables with the same starting name. Therefore, no other table names is allowed. Note: This facility is only available for HT00 and TB00 reports

FROM Program Name - TO Program Name Inform program names range.Program name "FROM" can be informed using wildcard '*' at the end which will fetch a range of programs with the same starting name. Therefore, leave the field "TO" as blank. Note: This facility is only available for AC00 and SRPG reports

FROM Plan Name - TO Plan Name Inform plan names from range.

FROM Collection Name - TO Collection Name Inform Collection names from range.


472

FROM Correlation Name - TO Correlation Name Inform Correlation names from range.

Connection Type Inform Connection Type. Valid Codes: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W UDF 0Y TRIGGER 0Z STORED PROCEDURE EA CACHE (FOR DYNAMIC SQLS)EB CACHE (FOR STATIC SQLS)

Start/End DATE Inform start/end range date

Start/End TIME Define start/end range time

DB2 Group Name DB2 Data Sharing Group Name

DB2 Member Name FROM / TO DB2 Data Sharing Member Names

SSID DB2 Subsystem ID

Log parameters (control messages in log data set – DDNAME MESSAGES) Show stmt process: Logs all SQL statements being processed Show stmt SQL txt: Shows all SQL texts Show sqlcode -104: Shows all SQL texts when explain SQLCODE is -104

Show sqlcode -117: Shows all SQL texts when explain SQLCODE is -117

Show sqlcode -204: Shows all SQL texts when explain SQLCODE is -204 Show sqlcode -206: Shows all SQL texts when explain SQLCODE is -206


473

Show sqlcode -407: Shows all SQL texts when explain SQLCODE is -407 Show sqlcode -408: Shows all SQL texts when explain SQLCODE is -408 Show quote and comma mismatches Shows whether there is a difference between quote/comma defined in SQL statementand DYNRULES from DB2


474

PARAMETERS USED BY OPTIONS EXECUTION MODE 2 OR 3 (COPY PLAN TABLE)

Explain Request Code This is a 5 character code to be used as key identifier to store DB2 Explain results intoTurboTuneSQL Repository.If you want to create a history of explains, use a different request code at each new run.

Source Request Code This is a 5 character code used as key identifier to read stored SQL commands fromTurboTuneSQL Repository.

Plan Table Qualifier This is the qualifier for Plan Tables (PLAN TABLE and DSN STATEMENT TABLE) wherethe information is going to be imported. These tables will be read using dynamic sql.

Plan Table Version It define which layout from DB2 Plan Tables will be used to get informations to beinserted in TurboTuneSQL Plan_table.In case of this field is not informed, it will assume the value from DB2 versionparameter previously setup on Customize a TurboTuneSQL Profile.

Valid values: Blank, V8, V9, VA, etc. For a complete reference of supported DB2version, check valid range on parameter DB2 version Customize a TurboTuneSQLProfile.

Note: All Explain reports (for instance, SREX ), will show copied plan table informationusing value 'C' under field OF (Original Format). For more information about SQLformats, go to program original format and non-original format.

FILTERS Program NameInform program as a filter. You can use DB2 LIKE function syntax to specify which programs must be processed.Examples:

–'*' or blank: No filter, all programs will be included–PGM* : Only programs starting with PGM* will be included

PARAMETERS USED TO BACK-UP PLAN TABLE

If you have set parameter Back-up Plan Table to Yes, configure parameters below:Original Request CodeThis is a free 5 characters code to be used as the Explains has been copied intoTurboTuneSQL Tables. This information is mandatory when user asked to back-up actual Plan Table.If you change this parameter, JCL needs to be re-created.

Request Code to back-upThis is a free 5 characters code to be used to copy from the Original Request Codeabove. This information is mandatory when user asked to back-up actual Plan Table.If you change this parameter, JCL needs to be re-created.


475

ATTENTION:We strongly recommend to create a Request Code exclusively for thispurpose.

DatabaseInform the same database name used during TurboTuneSQL installation.If you change this parameter, JCL needs to be re-created.

Note: All parameters informed for the back-up process which generates J700COPY canbe changed as shown below:

Sample for step SYNP01:PARM='1,DB=SADVDB,TS=SPT,QL=SADVQUAL'

DB is for TurboTuneSQL Tables DATABASE TS is the TABLESPACE name for TurboTuneSQL Table SRC_EXP_PLAN_TABLEQL is the Table Qualifier of TurboTuneSQL Table SRC_EXP_PLAN_TABLE created

Sample for step SYNP02:PARM='1,DB=SADVDB,TS=SST,QL=SADVQUAL'

DB is for TurboTuneSQL Tables DATABASE TS is the TABLESPACE name for TurboTuneSQL Table SRC_EXP_STMT_TABLEQL is the Table Qualifier of TurboTuneSQL Table SRC_EXP_PLAN_TABLE created

Sample for step SYNP03:PARM='2,RC=PRODC,RO=PRODRC is the Request Code to copyRO is the Original Request Code for copy


476

Clear Tables Utility

This utility is used to delete rows from TurboTuneSQL tables. The following group of tables can be deleted by this utility:

- Workload Tables Accounting/Performance/Cache Tables

- Source Tables Source Tables Explain Tables History Tables Plan Table Comparison Tables

- Temporary Tables Cache Table Work Tables

SAMPLE SCREEN


477

TurboTuneSQL V120 ------------------- Clear Tables ---------------------- 13:58 Option ===> More: + Clear Tables Profile : IVP {E} DB2 SSID : DBBG CLEAR WORKLOAD TABLES Accounting/Performance/Others (Workload History): Y Y/N Cache Table (Workload Near Real Time) : N Y/N Filters: DB2 identification: Group Name : Data Sharing Group Name Member Name From: To: Data Sharing Member Name DB2 SSID name : DB2 SSIDs Date: Start/End DATE : 1900-01-01 2100-12-31 YYYY-MM-DD Start/End TIME : 00.00.00 23.59.59 HH.MM.SS or Keep only last day(s) Timeout parameters for Cache Interval minutes : 30 Maximum time to wait resource be released End job on timeout : N Y/N Y:End job N:Skip clear process

FIELD DESCRIPTIONS

DELETE WORKLOAD TABLES

Accounting/Performance Tables: Option Y will delete data loaded into TurboTuneSQL tables from 3 different Sources:

- Accounting Traces - Performance Traces - Cache Tables (Dynamic SQLs from DB2 Cache Area - EDM Pool) Cache Tables: Option Y will delete data from TurboTuneSQL STMT_CACHE_MON TABLE. This table is loaded with data collected from the Cache Tables (Dynamic SQLs from DB2 Cache Area - EDM Pool)

Note: Once the data in this tables repository has no dependency on Request Code,

choose option 'Y' to clear the tables with absolute certainty.Data used by the following reports will be deleted:

AC00, AC01, ACNI, ACNT, IMSM, CICS, ST01, ST02, ST03, ST04, etc.

Filters used by WORKLOAD TABLES DB2 identification Group Name Specify Data Sharing Group Name. Member Name Specify Data Sharing Member Name. DB2 SSID name Specify up to 4 DB2 SSIDs. Date Start/End DATE Specify start and end date which will be used to clear workload tables. Start/End TIME Specify start and end time which will be used to clear workload tables.

Keep only last NNN day(s) (NNN - Number of days (1 - 999)) Specify number of days that should be preserved, according to the following datecomputation:

(Current Date - Number of Last Days)

Example: Current date : 2000-01-05 (yyyy-mm-dd) Keep only last days : 05

Therefore, rows preserved will be from : 2000-01-01 to 2000-01-05 Rows deleted : everything before 2000-01-01 00.00.00

Note: "Start/End DATE" and "Keep only last NNN days" are mutually exclusive.


478

Timeout parameters for Cache Specify the actions when table STMT_CACHE_MON TABLE is locked by another process. Valid only if Clear Cache parameters was set to Y. Interval minutes: When table STMT_CACHE_MON TABLE is held by another process, this parameter will be used to determine how long this batch process must wait until above table be released. Values: 00 to 99 minutes End job on timeout: Specify the condition code for the step when Interval minutes expires: Valid values: Y: Clear processing will skip for this table and condition code will be set to 12. N: Clear processing will skip for this table and condition code will be set to 4. Notes: User may restart the execution when the resource is released. Process to clear other tables was performed.

DELETE SOURCE TABLES

Choose group of tables

Source Tables Valid Values:Y - to clear TurboTuneSQL Source Tables which contains data related to SQL text, usedcolumns, predicates, etc.There is a dependency on 'Keep last version' and 'Keep source found in workload'options, please, refer to this parameters below.N - no deletion will be done for source tables repository. This option will clear data used by reports: SRPG, SRPS, IXMD, etc. Note: When you choose to delete source tables, the option to explain tables must be

set to Y either, and the parameter Original Format must be blank, doing this, the clearing utility will garantee that all data in the repository remains syncronized.

Explain TablesValid values:Y - to clear TurboTuneSQL Explain Tables which contains explained data related to DB2 Plan Tables. N - no deletion will be done for Explain tables repository. This option will clear data used by reports: SREX, SRPT, etc. Note: Deleting only explain tables, the parameters below must be set as: Keep Last Version = N

Keep Workload = N History Tables Valid Values: Y - to clear History Tables which holds application DDL definition into portion of TurboTuneSQL database. N - no deletion will be done for History tables repository. This option will clear data used by reports: HT00, HI00, HC00, HC01, etc. Note: Deleting only History Tables, the parameters below must be set as:

Source Tables = YKeep Last Version = N


479

Keep Workload = N If anyother parameters are different as above, history tables will not be deleted

and a warning message will be issued in DDNAME MESSAGES.Indexes suggested to be created through Automatic Index Recommendation will

not be deleted.

Plan Table ComparisonValid Values:Y - to clear Plan Table Comparison stored results from TurboTuneSQL 'Compare Plan Table' utility wich compares 2 Plan Tables. N - no deletion will be done for Plan Table Comparison table repository. This option will clear data used by report: SRMI

Filters (Source/Explain/History Tables)

Source Request Code: Inform Request Code used by Source/History Tables. Explain Request Code: Inform Request Code used by Explain Tables. Request Code created exclusively for Automatic Index Recommendation will not be accepted as filter parameter. More filters (Source/Explain tables only) Keep Last Version: Valid values: Y/N

Specify Y to keep the most recent version from program/precompile version.

Here, all data related to the most recent version of a program, like its Explain Data, will be preserved.

If you want to keep only last version of programs, this is the best option.

Specify N to clear data from Source Tables, therefore, no versions will be preserved since the parameter below Keep source found in workload is set to N as well.

Keep source found in workload: Valid values: Y/N

Specify Y in order to prevent deletion of programs from TurboTuneSQL Source tables that still have references in TurboTuneSQL Trace Tables (Acctg, Perf, Cache).

This is the best option because it will avoid inconsistencies when using online reports to find source information about the program found in workload.

Specify N to clear data from Source Tables without checking whether a program exists in TurboTuneSQL Trace Tables. In this case, a program found in traces will not have its DB2 source data information available.

Attention for Dynamic SQLs:For dynamic SQLs stored into TurboTuneSQL repository, parameter Keep source found in workload will be always forced automatically to value Y, even you have informed 'N', only if Keep Last Version was set to Y.

OF (Original Format): This parameter allows you to clear specific explain data from TurboTuneSQL Plan Tables.This parameter is valid only if Explain Tables was set to Y.

C - Clear record only TurboTuneSQL Plan Tables were field OF (original format) is CN - Clear record only TurboTuneSQL Plan Tables were field OF (original format) is NY - Clear record only TurboTuneSQL Plan Tables were field OF (original format) is Y


480

blank – No filter. Clear all types of Original Format field.

Note: All Explains or Comparison Plan Tables results originated from Automatic Index Recommendation can not be cleared from this utility. (See chapter Automatic index recommendations utility).


Examples:

A) Keep Last Version: Y Keep Source found in Workload = Y

TurboTuneSQL database BEFORE executing the Clear Table Utility

Collection Program Name SQL Precompile Time Found traces COLA PROG1 (static program) 2000-01-01.10.10.10.000000 no COLA PROG1 (static program) 2003-01-01.10.10.10.000000 yes COLB PROG1 (static program) 2006-01-01.10.10.10.000000 no COLD PROG2 (static program) 2009-01-01.10.10.10.000000 yes COLE PROG3 (static program) 2008-01-01.10.10.10.000000 no COLF PROG3 (static program) 2008-01-01.10.10.10.000000 no COLL PROG4 (static program) 2009-01-01.10.10.10.000000 yes COLM PROG4 (static program) 2009-01-01.10.10.10.000000 no COLN PROG5 (static program) 2010-01-01.10.10.10.000000 no COLO PROG5 (static program) 2010-01-01.10.10.10.000000 no NULLID JAVA.EXE Update CUSTOMER 1900-01-01.10.10.10.000000 yes NULLID JAVA.EXE Select ADDRESS 1900-01-01.10.10.10.000000 no

TurboTuneSQL database AFTER executing the Clear Table Utility

Collection Program Name SQL Precompile Time Found traces(1) COLA PROG1 (static program) 2003-01-01.10.10.10.000000 yes (2) COLB PROG1 (static program) 2006-01-01.10.10.10.000000 no (1) COLD PROG2 (static program) 2009-01-01.10.10.10.000000 yes (3) COLF PROG3 (static program) 2008-01-01.10.10.10.000000 no(4) COLL PROG4 (static program) 2009-01-01.10.10.10.000000 yes(5) COLM PROG4 (static program) 2009-01-01.10.10.10.000000 no(6) COLN PROG5 (static program) 2010-01-01.10.10.10.000000 no(7) COLO PROG5 (static program) 2010-01-01.10.10.10.000000 no(8) NULLID JAVA.EXE Update CUSTOMER 1900-01-01.10.10.10.000000 yes

1 - Not deleted because this is a static program and it was found in workload2 - Not deleted because this is a static program and this is the last version3 - Not deleted because this is a static program and this is the last version. Only one program will be preserved. Collection COLE/PROG3 was deleted.4 – Not deleted because this is a static program and it was found in workload5 – Not deleted because this is a static program and it was found in workload6 – Not deleted because this is a static program and this is the last version for this collid7 – Not deleted because this is a static program and this is the last version for this collid8 - Not deleted because this is a dynamic SQL and it was found in workload


481

B) Keep Last Version: YKeep Source found in Workload = N




Collection Program Name SQL Precompile Time Found traces(1) COLB PROG1 (static program) 2006-01-01.10.10.10.000000 no (1) COLD PROG2 (static program) 2009-01-01.10.10.10.000000 yes (2) COLF PROG3 (static program) 2008-01-01.10.10.10.000000 no(3) COLL PROG4 (static program) 2009-01-01.10.10.10.000000 yes(4) COLM PROG4 (static program) 2009-01-01.10.10.10.000000 no(5) COLN PROG5 (static program) 2010-01-01.10.10.10.000000 no(6) COLO PROG5 (static program) 2010-01-01.10.10.10.000000 no(7) NULLID JAVA.EXE Update CUSTOMER 1900-01-01.10.10.10.000000 yes

1 - Not deleted because this is a static program and this is the last version2 - Not deleted because this is a static program and this is the last version. Only one program will be preserved. Collection COLE/PROG3 was deleted.3- Not deleted because this is a static program and this is the last version for this collid4- Not deleted because this is a static program and this is the last version for this collid5- Not deleted because this is a static program and this is the last version for this collid6- Not deleted because this is a static program and this is the last version for this collid7- Not deleted because this is a dynamic SQL and it was found in workload. This is a dynamic SQL; dynamic SQL will always have parameter Keep Source Found in Workload set to Y.

C) Keep Last Version: NKeep Source found in Workload = Y





482

Collection Program Name SQL Precompile Time Found traces(1) COLA PROG1 (static program) 2003-01-01.10.10.10.000000 yes (1) COLD PROG2 (static program) 2009-01-01.10.10.10.000000 yes(1) COLL PROG4 (static program) 2009-01-01.10.10.10.000000 yes(2) COLM PROG4 (static program) 2009-01-01.10.10.10.000000 no(1) NULLID JAVA.EXE Update CUSTOMER 1900-01-01.10.10.10.000000 yes

1 - Not deleted because they were found in workload. Due to parameter Last Version is N,it does not take in consideration static programs and last version.

2 - Not delete because it was found in workload (in fact, another program with sameprecompile time was found in workload, but TurboTuneSQL does use collid as a key tofind programs in workload)

D) Keep Last Version: NKeep Source found in Workload = N


Collection Program Name SQL Precompile Time Found traces COLA PROG1 (static program) 2000-01-01.10.10.10.000000 no COLA PROG1 (static program) 2003-01-01.10.10.10.000000 yes COLB PROG1 (static program) 2006-01-01.10.10.10.000000 no COLD PROG2 (static program) 2009-01-01.10.10.10.000000 yes COLE PROG3 (static program) 2008-01-01.10.10.10.000000 no COLL PROG4 (static program) 2009-01-01.10.10.10.000000 yes COLM PROG4 (static program) 2009-01-01.10.10.10.000000 no COLN PROG5 (static program) 2010-01-01.10.10.10.000000 no COLO PROG5 (static program) 2010-01-01.10.10.10.000000 no NULLID JAVA.EXE Update CUSTOMER 1900-01-01.10.10.10.000000 yes NULLID JAVA.EXE Select ADDRESS 1900-01-01.10.10.10.000000 no


Collection Program Name SQL Precompile Time Found traces(1)

1 – All records using this request code were deleted. Workload and Last version were notverified.

Filters (Plan Table Comparison)Explain Request Code (OLD) Explain Request Code (NEW)

Note: You may inform program filter. See Program filter for Source Tables above.

Program Range (FROM/TO) Inform program names range.Program name "FROM" can be informed using wildcard '*' at the end which will deletea range of programs with the same starting name. Therefore, leave the field reservedfor "TO" as blank.

Program is a filter for Source Tables and also for Plan Table comparison.

Program Name Inform program name or a list of up to 20 programs. To insert more program names, type '/' in the next field.Wildcards CAN NOT be used. (Mutually exclusive with Program Range used as filter)


483

Important: To list all previous keys stored in TurboTuneSQL repository, please refer toonline command LSTREQ. CLEAR WORK TABLES

Valid values: Y - Work Tables will be cleared. These tables are normally cleared automatically by TurboTuneSQL process, like batch/online reports. But if you are having problems related to this tables, you may use this option to clear all of them. Best Option: Y Note: Work Tables do NOT have FILTERS. All data will be cleared.


484

Compare Plan Tables Utility

Use this utility to find and report differences in DB2 Access Path for all SQLs explainedand stored in the TurboTuneSQL Plan Tables. Before you execute this utility, you shouldexecute the TurboTuneSQL Explain Utility (or SREX report) for the Request Codes usedby the Compare Plan Tables Utility.

Use report SRMI report to show the comparison results in the online Panel.

SAMPLE SCREEN

Output generated by this utility:● Batch Report (ddnames):

○ SRMCDET : A detailed comparison for each SQL statement is beingcompared. Some extra fields like SQL text, Bind time and Explain Time arelisted here.

○ SRMCDIF : A short comparison for each SQLs being compared is listedhere.The difference is listed if the access path is diferent regardlesswhether procms or prosu is different.

○ SRMCWOR: A short comparison for each SQLs being compared is listedhere.The difference is listed if the access path is diferent AND procsu isworse. The ddname will list programs using PROCSU in descending order.

● Stored the results: A list of all the comparisons are stored in theSRC_COM_PLAN_TABLE table.

TIP: If you enter 'Y' in the Original Format (OLD) field and 'N' or 'C' in Original Format(NEW), this utility will help you to discover the occurrence of DB2 Access Path errorswhen there are data type mismatches between DB2 table columns and program workvariables. The mismatch problems are not fully resolved even in the most recent DB2versions.


485

TurboTuneSQL V120 ------------------- Compare Plan Tables --------------- 13:59 Option ===> Compare Plan Tables Profile : IVP {E} DB2 SSID : DBBG STATEMENTS (OLD) STATEMENTS (NEW) Explain Request Code: EXRQ1 Explain Request Code: EXRQ2 Original Format : * Original Format : * Source Request Code : EXSR1 Source Request Code : EXSR2 OTHER OPTIONS Print extra report with all details: N Y/N Max Objects to be compared : 00256 (Inform zeros for no lim it) Show SQL Texts : Y Y/N Check Bind Time : N Y/N

COMPARISON RULES

The main method used by this utility to compare Plan Tables is a Balance Line usingProgram Name, Contoken and SQL statements (by Unique Number) read from bothRequest Codes for explain (Old and New).

Additional comparison rules:

● This utility has adopted the following convention:■ OLD Request Code for Explain is the LEFT side of the comparison.■ NEW Request Code for Explain is the RIGHT side of the comparison.

● Only the newest program (last Precompile time - Contoken) in both sides are usedin the comparison. Therefore, if a program has several versions, only the oldestPrecompile date for both sides are used.Also:

■ Flag DIFFERENT-TOKEN will be shown Program Precompile date are differentfrom both sides.

■ Otherwise, flag SAME-TOKEN will be shown.■ If a program exists only in LEFT side, it is flagged as “REMOVED-PROGRAM”.■ If the program exists only in RIGHT side, it is flagged as “NEW-PROGRAM”.

● SQL Unique Number is used for this balance line purpose and not the SQL numberfrom DB2 Precompiler.

● DB2 Collection Name or DB2 Plan Name are not used in the comparison. Therefore,if, for any reason a program has multiples collids (like DBRMs will multiplies Plans,programs with both static and dynamic SQLs), only one collid will be compared forLEFT to RIGHT.

● Only the most recent Explain Time from both sides are used in the comparison.● COST COMPARISON: TurboTuneSQL will consider that DB2 Explain COSTs has

changed if fields PROCMS (Processor estimates cost in milliseconds - reportkeyword: PROC-MS) or PROCSU (Processor estimates cost in service units - reportkeyword: PROC-SU) has changed. The results of comparison can be:

■ same-ms or same-su: ● Report keywords COST-MS or COST-SU have identical values in both

sides (LEFT side – Old Request Code and RIGHT side – New RequestCode)

● The information is printed only in report SRMCDET.■ better-ms or same-su:

● Report keyword COST-MS/COST-SU values in the RIGHT side is lessthan LEFT side.

■ worse-ms or worse-su: ● Report keyword COST-MS/COST-SU value in the RIGHT side is greater

than LEFT side.■ '--- only old ---'

● The current Program Name and statement unique number only existsin LEFT side.

■ '--- only new ---' ● The current Program Name and statement unique number only exists

in RIGHT side.● ACCESS PATH COMPARISON: TurboTuneSQL will consider that DB2 Access Path in

Plan Table has changed. These are the Access Path fields used in the comparison:■ ACCESSCREATOR and ACCESSNAME - Often is the index name

(report keyword: IX)■ CREATOR and TNAME - Owner and Table Name

(report keyword: CT)■ ACCESSTYPE, MATCHCOLS, PREFETCH, INDEX ONLY - Method of accessing

type (index,scan,etc), Number of used Index Keys, Index alone processing(report keyword: AMIP)


486

■ SORT FIELDS:● SORTN_UNIQ - New table, sort, duplicate rows removed● SORTN_JOIN - New table, sort, join method● SORTN_ORDERBY - New table, sort, order by● SORTN_GROUPBY - New table, sort, group by● SORTC_UNIQ - Composite table,sort, duplicate row removed● SORTC_JOIN - Composite table,sort, join method● SORTC_ORDERBY - Composite table, sort, order by● SORTC_GROUPBY - Composite table, sort, group by

(report keyword: SORT)■ COST CATEGORY - Cost Category

(report keyword: COST-CATEG)

Very important: When no differences found for a entire program, *pgm with nomism* description will appear in Report SRMI.

FIELD DESCRIPTIONS

Old Plan Table Means all objects that will be compared at left side

New Plan Table Means all objects that will be compared at right side

Report Key Main key used to store the results into TurboTuneSQL repository. It is composed bythe OLD and NEW Request Code for Explain. Also, these Request Codes are used as filters to select which Plan Table lines will beused in the left and right side of the comparison.

Important: To list all previous keys stored in TurboTuneSQL repository use onlinecommand LSTREQ

Attention: If you execute this report more than once, previous results using same report key (Oldand New Explain Request Code) will be deleted.

Explain Request CodeExplain Request Code used in the comparison.

Original Format (0F)Valid values: Y - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) WASpreserved. Check utility parameter Explain Parameter Mark option.N - TurboTuneSQL Explain Utility or Explain facility under Report SREX has executedExplain Function for this SQL. Original program work variables (type and size) was NOTpreserved. Check utility parameter Explain Parameter Mark option.C - TurboTuneSQL Explain Utility has executed Plan Table Copy Function for this SQL.Original program work variables format has been preserved. Only most recent BIND-TIME has been copied from User Plan Table to TurboTuneSQL Plan Table. Originalprogram work variables format has been preserved. Check utility parameter ExecutionMode.


487

Explain. B/A - Explain created by TurboTuneSQL Automatic Index Recommendation B - Show Explains made BEFORE Index Recommendation A - Show Explains made AFTER Index Recommendation“*” - This character when chosen, will automatically make comparison for OriginalFormat 'N' and 'C'. For more information about SQL formats, go to program original format and non-original format.

TIP: If you inform 'Y' in Original Format (OLD) and 'N' or 'C' in Original Format (NEW),this utility will help you to discover the occurrence of DB2 Access Path errors becauseof data type mismatch between DB2 table columns and program work variables. Themismatch problems are not fully resolved even in the most recent DB2 versions.

Source Request Code Source Request Code used to read source information, like SQL text.

Details: Print extra report with all details: - N: Only a resume of all differences will be written. DDNAME SRMCDIF will be used. - Y: All information will be written. DDNAME SRMCDET and SRMCDIF will be used.

Max Objects to be compared: Inform the number of statements that utility must stop to compare. If zeros is informed, there will be no limit.

Show SQL Texts: Valid values: Y/N Print SQL Text of each statement being compared in ddname SRMCDET?

Check Bind time:Valid values: Y/N Indicates if this utility must capture from DB2 catalog the first and last bind time forthe current program regardless of which collection is was bound. This bind time isgenerated only from DB2 packages. Tip: if you have a large SYSPACKAGE table, set this option to N because batch job cantake a long time for finish. Therefore for best performance set this option to N. Also, even using option N, this same information can visualized using Online ReportSRMI.


488

SAMPLE REPORT- (SRMCDIF)

FIELD DESCRIPTIONS - REPORT HEADER

(1) - Report code(2) - Report name(3) - Page number(4) - Maximum statements to be printed within the same SQL code

FIELD DESCRIPTIONS – REPORT DATA

(5) – Program name(6) – Statement Unique Number(7) - Statement number(8) – COST COMPARISON

CostMS This field will show worse-ms if CPU cost for new explain is worse than old explain for this statement.

Otherwise, will show better-ms.

CostSU This field will show worse-su if Service Unit for new explain is worse than old explain for this statement. Otherwise, will show better-su.

Other values for CostMS or CostSU

only old - this SQL statement was only found in the Old Explain Request. only new - this SQL statement was only found in the New Explain Request.

(9) – ACCESS PATH

AMIP This field will show "Y" if (A)CCESSTYPE, (M)ATCHCOLS, (P)PREFETCH or (I)NDEXONLY are different comparing old explain and new explain for this statement.

IX This field will show "Y" if ACCESSCREATOR or ACCESSNAME are different comparing the old explain and the new explain for this statement. Normally, this field will contain the DB2 Index Name.

SRT This field will show "Y" if any SORT is different for this statement.


489

TN This field will show "Y" if CREATOR or TNAME are different for this statement.

(10) – Cost Categ

This field will show "Y" if the cost category is different for this statement.

(11) – This field shows the date/time for the last explain performed for this statement.

(12) – Statement executed.

(13) – First Bind Time This field shows the date/time for the first bind for this program regardless of which collection it was bound. This field is generated only from DB2 Packages.

(14) – Last Bind Time

This field shows the date/time for the last bind for this program regardless of which collection it was bound. This field is generated only from DB2 Packages.


490

SAMPLE REPORT- (SRMCDET)

FIELD DESCRIPTIONS - REPORT HEADER

(1) - Report code(2) - Report name(3) - Page number (4) - Maximum statements to be printed within the same SQL code (5) – Comparation type. Valid values:

NO COMPARISON - ONLY DATA FROM OLD: Program was found only under Old Request Code

NO COMPARISON - ONLY DATA FROM NEW: Program was found only under New Request Code

COMPARISON FOR OLD REQUEST CODE (req) / NEW REQUEST CODE (req):Program was found in both request codes

(6) - Old request code(7) - New request code(8) - Program name(9) - Precompile DB2 Timestamp for this program from Old Request Code(10) - Precompile DB2 Timestamp for this program from New Request Code(11) - Status

SAME-TOKEN: comparing same version of this program DIFF-TOKEN : comparing different version of this program


491

FIELD DESCRIPTIONS – REPORT DATA

(10) - DB2 Collection ID for this program from New Request Code

(12) – Bind Time This field shows the bind date/time for this program under this collection. This field is generated only from DB2 Packages.

(13) - DB2 Precompile Timestamp.

Notes:This data was expanded by TurboTuneSQL from 'contoken' field using z/OSmacros. The final value computed by TurboTuneSQL will be very similar toDB2 Precompile date column in DB2 Catalog tables. Please, do not considerthis date for remote programs, Triggers and for programs extracted from SQLCache Area.

(14) – Collection id when this program was bound for this Bind Time (12).

(15) - Reason for this statement cost (PROCMS and PROCSU).Same-MS: statements have same cost for PROCMS worse-MS: statements from new request code have worse cost for PROCMSbetter-MS: statements from new request code have better cost for PROCMSSame-SU: statements have same cost for PROCSU worse-SU: statements from new request code have worse cost for PROCSUbetter-SU: statements from new request code have better cost for PROCSU

(16) - Request codes for explain

(17) – SQL Statement Number from DB2 precompiler.

(18) - Unique Number.

(19) - Statement type name.

(20) - Original Format. Valid values:Y – Original FormatN – No mismatches

C - Copy from Plan TableB/A - Explain created by TurboTuneSQL Automatic Index Recommendation

B - Show Explains made BEFORE Index Recommendation A - Show Explains made AFTER Index Recommendation


(21) - PROCMS – CPU Cost by DB2 Explain Function.

(22) - PROCSU – Service Units by DB2 Explain Function.

(23) - Indicates if DB2 was forced to use default values when making its estimates. A Indicates that DB2 had enough information to make a cost estimate

without using default values.B Indicates that some condition exists for which DB2 was forced to use

default values.

(24) - Reason: When (20) = B, this field will have the following values to indicateThe estimate into this cost category.


492

HOST VARIABLES: Value set when the statement uses special registers, parameter marks or host variables.

TABLE CARDINALITY:Value set when missing cardinality statistics for one or more of the tables used in this statement.

UDF: Value set when user-defined functions are used for this statement.

TRIGGERS: Value set when there are triggers defined on the target table if this statement is an INSERT, DELETE or UPDATE.

REFERENTIAL CONSTRAINTS:Value set if this is a DELETE statement and referential constraints type CASCADE or SET NULL exist on the target table.

(25) – SQL text for this statement.

(26) - Data for Plan Table from Old Request Code

(27) - Data for Plan Table from New Request Code

(28) - Reasons SAME-LINE: When QBLOCKNO, PLANNO and MIXOPSEQ are the same for Old

and New Request Codes.ONLY-OLD-LINE:

When QBLOCKNO, PLANNO and MIXOPSEQ are Old Request Code only.

NEW-LINE: When QBLOCKNO, PLANNO and MIXOPSEQ are New Request Code only.

SAME-CT: When CREATOR and TNAME are the same for Old and New Request Codes.

DIFFERENT-CT: When CREATOR or TNAME are different for Old and New Request Codes.

SAME-IX: When ACCESSCREATOR and ACCESSNAME are the same for Oldand New Request Codes.

DIFFERENT-IX: When ACCESSCREATOR or ACCESSNAME are different for Old and New Request Codes.

SAME-AMIP: When ACCESSTYPE, MATCHCOLS, PREFETCH and INDEXONLY are the same for Old and New Request Codes.

DIFFERENT-AMIP:When ACCESSTYPE or MATCHCOLS, PREFETCH or INDEXONLY are different for Old and New Request Codes.

SAME-SORT: When SORTN and SORTC are the same for Old and New Request Codes.

DIFFERENT-SORT:When SORTN or SORTC are different for Old and New Request Codes.


493

DB2

Execute any DB2 command. Example: -dis trace(*). Notes: 1: To execute a command place cursor at command line and hit enter (or type numbers 1,2,3,4,5) 2: Only one command can be executed at a time. 3: Command results will be shown at the bottom.

SAMPLE SCREEN:


494

----------------------------- DB2 command ------------------------------- 14:01 Option ===> More: + DB2 Commands Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB (1) -DISPLAY TRACE(*) (2) -DISPLAY BUFFERPOOL(BP1) (3) (4) (5) ------------------------------------------------------------------------------- DSNB401I -DBBG BUFFERPOOL NAME BP1, BUFFERPOOL ID 1, USE COUNT 198 DSNB402I -DBBG BUFFER POOL SIZE = 20000 BUFFERS AUTOSIZE = NO VPSIZE MINIMUM = 0 VPSIZE MAXIMUM = 0 ALLOCATED = 20000 TO BE DELETED = 0 IN-USE/UPDATED = 0

SQL Tables Cross Reference Utility

Utility to obtain a cross reference of tables from TurboTuneSQL Repository (SourceTables), found or not found in workload.Examples:

select * from TableA, TableB where A=1 select * from TableA where A is in (select A from TableC)

If you use TableA as a filter, this utility will return the following cross reference results:TableATableBTableC

Note: Do NOT use any kind of wildcards like ‘*’ or ‘%’ here.

SAMPLE SCREEN


495

TurboTuneSQL V120 ------------------- Tables XREF ----------------------- 14:02 Option ===> Tables Cross Reference Utility Profile : IVP {E} DB2 SSID : DBBG General Parms: Source Request Code: IVP Get tables from programs found in: * Valid Values: W - Get table names from programs found in workload S - Get table names from programs found in source L - Get table names from programs found in source - last version only * - Process W,S and L General Filters: Database Name From: To: Table Name:

FIELD DESCRIPTIONS

Source Request Code This is a 5 character code to be used as an unique identifier key for the TurboTuneSQL Repository (Source and History Tables) All source information will be associated with this source request code

Get SQL from programs found in Specify:W: To get table names from workload S: To get table names from source L: To get table names from source - last version only *: To process all above options (W,S and L)

FILTERS

FROM Database Name TO Database Name Inform a range of databases

Table Qualifier Inform a qualifier

Table Name Inform up to 6 table names

FROM Program Name - TO Program Name: Inform program range

FROM Plan Name - TO Plan Name:Inform plan name range

FROM Collection Name - TO Collection Name Inform collection range

FROM Correlation Name - TO Correlation Name Inform collection range

Connection Type Inform Connection Type. Valid Codes: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W UDF 0Y TRIGGER 0Z STORED PROCEDURE EA CACHE (FOR DYNAMIC SQLS)EB CACHE (FOR STATIC SQLS)


496

DB2 Group Name DataSharing Group Name

FROM DB2 Member Name - TO DB2 Member Name DataSharing Member Name


The result will be stored in ddname DSTBS or DSTBL or DSTBW.


497

DDL Generator Utility

Utility to generate DDLs from DB2 Catalog.

Disclaimer: This utility has several limitations and is provided "as is".

It doesn’t reproduce all supported DB2 DDL syntax. There is no support forthis utility. It must be used only if asked by your local representativesupport.

Note: Do NOT use any kind of wildcards like ‘*’ or ‘%’ here.

SAMPLE SCREEN:


498

TurboTuneSQL V120 ------------------- Generate DDLs --------------------- 14:03 Option ===> More: + DDL Generator Utility Profile : IVP {E} DB2 SSID : DBBG Please, see disclaimer at Users Guide. This utility has several limitations and is provided AS IS. Exclusive use under the direction of your local representative. Available Actions: *** (Generate all objects) TSP (Generate tablespaces) TAB (Generate tables) VIW (Generate tables and views) IDX (Generate tables and indexes) PKY (Generate tables and primary keys) FKY (Generate tables and foreign keys) REF (Generate primary keys) TRG (Generate triggers) SYN (Generate synonyms) ALI (Generate aliases) Choose where table list will be taken: D D - from database T - from a list of tables Database name : DB001 OR Table or View Name: (Format: owner.tablename)

FIELD DESCRIPTIONS

Available Actions: Specify type of objects to be generated.

'***' Indicates that all options will be combined simultaneously'TSP' generate DDLs to create all Tablespaces'TAB' generate DDLs to create all tables 'VIW' generate DDLs to create all Views 'IDX' generate DDLs to create all Indexes 'PKY' generate DDLs to create all Primary keys'FKY' generate DDLs to create all Foreign Keys'REF' generate DDLs to create all Constraints 'TRG' generate DDLs to create all Triggers'SYN' generate DDLs to create all Synonyms'ALI' generate DDLs to create all Aliases

Choose where table list will be taken Specify:

D - Filter by Database T - Filter by Table Name


Database name Specify Database name when filtering by database.

Table or View Name Specify up to 20 table names in the format of OWNER.TABLENAME

Priqty If you wish, force this priqty to replace the original values in generated DDL fortablespace(s) and indexspace(s).

Secqty If you wish, force this secqty to replace the original values in generated DDL fortablespace(s) and indexspace(s).

Force storage Group If you wish, force this DB2 Storage Group to replace the original in generated DDL.

Force owner If you wish, force this owner to replace the original in generated DDL for tables andindex definitions.

Force Buffer Pool If you wish, force this buffer pool to replace the original values in generated DDL fortablespace(s) and indexspace(s).

Unload This is an internal TurboTuneSQL parameter. It should be set to 'N'.

The results will be stored in the following ddnames:


499

//DDLOBJS - will contain DDL to create results. data set name will be:hlq.GDDLGGEN.DDLOBJS

//DDLTRGS - will contain DDL Trigger results. data set name will be:hlq.GDDLGGEN.DDLTRGS

//DROPOBJ - will contain DDL Drop results. data set name will be:hlq.GDDLGGEN.DROPOBJ

The above hlq will have the same name as defined in “HLQ work files” field in JCLcommand.


500

DB2 Explain Command

Utility to perform an interactive DB2 explain both locally or remotely. This utility can beaccessed from Utilities Menu or from online command EXPL.

You do not need to remove non explainable strings like `Declare Cursor`, or change :Hby ?. This utility may automatically make this changes to you.

Notes:• You can use '--' to comment out portions of SQL text.• You can use ';' to end a SQL text. Attention: Do NOT use Erase-Eof. It will clear only the first page.• Required Tables (or Alias): 'PLAN TABLE' and 'DSN STATEMNT TABLE' • When you leave this screen, all new Plan Table information are deleted. • Authorities:

▪ SYSADM authority OR Authority to execute SET CURRENT SQLID ▪ SELECT, DELETE, UPDATE on tables/ALIAS (DB2 Version 8 or above):

PLAN TABLE, DSN STATEMNT TABLE ▪ If using TurboTuneSQL Stored Procedure: Grant execute on procedure "TurboTuneSQL Install Qualifier"."SADBEXST ▪ It may be necessary to have the same authority as required by DB2 to execute thecommand that will be explained, except if job INST33BE was executed during TurboTuneSQL installation process.▪ EXPLAIN or SQLADM or System DBADM.(consult IBM DB2 documentation for more information.)

SAMPLE SCREEN:


501

TurboTuneSQL V120 ------------------- DB2 Explain ----------------------- 14:05 Option ===> More: + DB2 Explain Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB EXPLAIN Queryno: 05000 Degree: ANY PlanTable Qualifier: SADVQUAL SQL Modify SQL Text: Y (Y/N/O) Dynamic or Static: S Default Owner : Comma/Quote: N N EDIT Dataset: Member: (Commands: FORMAT, EDIT, IXVT, CLEAR, FULLSCREEN... see HELP for more commands) ----------------------------------------------------------------------||------- SELECT NAME, CREATOR INTO :H , :H FROM SYSIBM.SYSTABLES WHERE CREATOR LIKE '%A' ORDER BY 1

FIELD DESCRIPTIONS



EXPLAIN Queryno:Choose any valid number to be used as queryno field in TurboTuneSQL Plan tables.

Note: A Query Number will be generated randomly for each explain if the user leaves blanks or zeros; for any different value, Query Number will remain

the same. Degree:Choose a valid Degree. SQL Set Current Degree command will be issued using the information provided

before executing Explain command. PlanTable Qualifier:Choose a valid SQLID. SQL Set Current SQLID command will be issued using the information provided before executing Explain command.

You must have GRANT DELETE/INSERT/UPDATE/DELETE in those tables (oralias if you are in DB2 version 8 or up):

QUALIFIER.PLAN TABLE QUALIFIER.DSN STATEMNT TABLE

PlanTable Version:DB2 Plan Tables MUST be defined using the layout according to DB2 version specified. Valid values: V8, V9, VA. For a complete reference of supported DB2 version,check parameter DB2 version on Customize a TurboTuneSQL Profile.Remote Explain-DB2 Location

TurboTuneSQL Explain Stored Procedure can be executed both locally orremotely. Valid values: - BLANK: choose this option if you want to execute it locally - Location: choose a valid DB2 location to execute it remotely.Note: Even when executing Explain remotely, SREX and following reports will notused Explain Location to be access DB2 tables. TurboTuneSQL reports alwaysaccess DB2 tables located at Current Location (according to connected PlanTable).

SQLModify SQL Text Use this option to remove non explainable text and to calculate product

SQL identifiers (unique, group table, etc).Valid values: Y – Yes. Explanation:

•SQL Identifiers will be calculated. SQL Unique Number, SQL Group Table and SQL Group column will be calculated.

•SQL text will modified. TurboTuneSQL will try to modify SQL text to remove non explainable strings like `Declare Cursor`, or change :H by ?.

•Explain will be executed: If an error was returned by explain, a panel named SQL Modified will appear to show modified SQL.

N – No. Explanation:•SQL Identifiers will not be calculated. Value zero will be shown.


502

•SQL text will not be modified.•Explain will be executed.

O – Modify text Only. Explanation:•SQL Identifiers will be calculated. SQL Unique Number, SQL Group Table and SQL Group column will be calculated.

•SQL text will modified. TurboTuneSQL will try to modify SQL text to remove non explainable strings like `Declare Cursor`, or change :H by ?.

•Explain will not be executed.Note: The SQL Identifiers, like Unique number, maybe is not the same as computed inoriginal program. To better understand how this number is computed, pleasecheck SQL Statement Unique AlgorithmDynamic/StaticValid values:D - Text is a Dynamic SQL S - Text is a Static SQL Inform to TurboTuneSQL if this SQL you are trying to Explain (and/or) computing Unique Identifier should be considered a dynamic or a static SQL. TurboTuneSQL requires this information because Unique Identifer are computed in different ways for both situations. Example: lets suppose the following SQL:

SELECT A-B FROM TABLE For DB2 precompile (in this case, embedded/static SQL), DB2 thinks A-B is a column.

Unique number will be:12886374 For dynamic SQLs, DB2 thinks there are 2 columns: A minus B Unique number will be: A1E8DBA2

Valid only if Modify SQL Text was set to Y or O. Default OwnerIf informed, command 'SET CURRENT SCHEMA' will be issued. If a default owner was set and Modify SQL Text was set to 'Y' or 'O'SQL text will be modified and this owner will be inserted on unqualified objects.Also, even if Modify SQL Text was set to Y or O. If informed, SQL text will be modified to include a default qualifier name for SQLstatement with unqualified objects. Valid only if Modify SQL Text was set to Y or O. COMMA/QUOTE: To execute dynamic explain, TurboTuneSQL must know your default QUOTE andCOMMA precompiler options.This will help TurboTuneSQL to better understand your SQL and reduceSQLCODE errors in explain process.Also, TurboTuneSQL requires this information to compute Unique Identifier. For instance, the following SQL is an explainable SQL: SELECT column from table where column-a > 0,8 But this SQL may NOT be an explainable SQL: SELECT column from table where column-a > 0 , 8 ('0,8' may be modified to '0 , 8') Valid only if Modify SQL Text was set to Y or O.

COMMA TurboTuneSQL Extractor period or comma. N - Means PERIOD is being used. Y - Means COMMA is being used.

QUOTE TurboTuneSQL Extractor apost or quote. N - Means that APOST is being used. Y - Means that QUOTE is being used.


503

This will help TurboTuneSQL to better understand your SQL and reduceSQLCODE errors in explain process.

EDIT data set specification for online commands: EDIT, IMPORT and EXPORT. When

working with data sets, only the first 72 bytes from each line will be used.data set: data set Name to edit, import or export SQL text.Member:

Member name in case you are editing from a PDS or Library.

Available line commands: CLEAR

Reset SQL Text on screen to blanks. DIR

List PDS directory. EDIT

Use this command to edit, import or export SQL Texts from/to data sets and screen.Both sequential and PDS data sets are supported. Use command EDITOPT to set defaults for EDIT command.

EDITOPTUse this command to set defaults for EDIT command.The behavior of IMPORT or EXPORT commands are not affected by EDITOPT. Check below for more information.

EXPORT Export text from screen to data set.

EXP or EXPO are abbreviations of EXPORT command.Note: User will be asked for a confirmation to replace the data on data set with the SQL Text from screen.

FORMAT Format SQL. This facility will help to understand the SQL Text more clearly formatting the SQL Text. The SQL text will be formatted according with defined configuration.Use command FORMATOPT to configure how SQL Text should be

formatted. Notes:

– Formatting SQL text will work fully when SQL Text has no syntax errors. Otherwise, it will use a basic formatting.

– If you wish to restore the text previous each format command use SAVETEXT before formatting the text. This will allow you to use command RESTORE to restore the original text.

- Comments '--' will be removed from text after FORMAT command. FORMATOPT

Show a screen with options to be used by FORMAT command. Use this command to configure the way you want to formatthe SQL Text.

FULLSCREENSwitch screen to full mode on or off.FULL is abbreviations of FULLSCREEN.

IMPORTImport text from data set to screen. IMP or IMPO are abbreviations of IMPORT command. Notes:

– If there is already a SQL Text on screen, user will be asked for aconfirmation to replace the SQL text on screen.


504

– SQL Text from data set will be truncated to 72 bytes depending on EDITOPT option.

IXVTOpen Virtual Index Table Configuration Utility.

RESTORE Restore screen text from previous SAVETEXT command.

SAVETEXT Save screen text into memory temporarily.

Notes:– You can use '--' to comment out SQL text

FORMAT command will remove all comments from SQL text.– You can use ';' to end a SQL.– If you want to clear the screen text, use command CLEAR. Attention: Do NOT use Erase-Eof. It will clear only the first page. – Required Tables (or Alias): 'PLAN_TABLE' and 'DSN_STATMNT_TABLE'


505

SQL MODIFIED PANEL

This is an overview of modified SQL. Show how SQL was automatically changed by option Modify SQL Text.

Unique: Unique Number that defines this SQL Text.

Gtab: Unique number that defines all group of tables found in this SQL


Search/Update Comment?: Inform a valid value to show or update comments for the SQL. Choosing value 'Y' produces same information as in SSCO Online Report. Valid values:

Y - Do want to show or update comments N - Do not want to show or update comments


506

TurboTuneSQL V120 ------------------- DB2 Explain ----------------------- 14:25 Option ===> ------------------------------------------------------------------------------ More: + DB2 Explain Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB SQL Modified ------------------------------------------------------------------------------ Unique: 42DE374D Gtab: AB121B92 Gcol: 8D7A42B8 Search/Update Comment?: N (Y/N) ------------------------------------------------------------------------------ SELECT NAME , CREATOR FROM SYSIBM . SYSTABLES WHERE CREATOR LIKE '%A' ORDER BY 1

EDITOPT PANEL

Use this panel to configure your option to edit SQL text.

IMPORT TEXT After editing data set, replace screen text from data set Valid values: C - to confirm before replacing screen text from data set Y - to replace screen text from data set N - to not replace text from data set

EXPORT TEXT Before editing, export screen text to data set Valid values: C - to confirm before exporting screen text to data set Y - to export screen text to data set N - to not export screen text to data set

RESET ABOVE OPTIONS TO DEFAULT AT START: When entering explain online for the first time, reset Import and Export options to C Valid values:

Y - to reset Import and Export options to C N - do NOT reset options.

TRUNCATE 72 BYTES WHEN IMPORTING:When editing or using IMPORT command truncate record in 72 bytes from data set toscreen. Valid values: Y - Truncate in 72 bytes N - do NOT truncate in 72 bytes (default)


507

┌────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ ││ More: + ││ ││ DB2 Explain - Edit Options ││ ││ Import TEXT: C Y/N/C (Default C-Confirmation) ││ Export TEXT: C Y/N/C (Default C-Confirmation) ││ Reset above options to default at start: Y (Y/N) ││ ││ Truncate 72 bytes when importing : N (Y/N) ││ ││ F1=Help F3=Exit │└────────────────────────────────────────────────────────────────────────┘

FORMATOPT PANEL

Use this panel to configure your option to format SQL text.

SELECT Choose this option to break lines when is a command SELECT, INSERT, DELETE orUPDATE. WHERE Choose this option to break lines when is a WHERE, ON or HAVING clause. FROM Choose this option to break lines when is a FROM clause.

PREDICATES Choose this option to break lines for each predicate. It will break lines whenever there is an "AND" or "OR" operand. ORDER Choose this option to break lines when is a GROUP BY or ORDER BY clauses. COMMA Choose this option to break lines when is a GROUP BY or ORDER BY clauses. INTO/SET/VALUES Choose this option to break lines when is a INTO, SET or VALUES clauses.

UNION Choose this option to break lines when is a UNION or UNION ALL clauses.


508

┌─────────────────────────────────────────────────────────────────────────┐│ Option ===> ││ ││ ││ ││ DB2 Explain - Format Options ││ ││ Break lines for : ││ / SELECT (SELECT, INSERT, DELETE, UPDATE commands) ││ / WHERE (WHERE/ON/HAVING Clauses) ││ / FROM (FROM Clause ) ││ / PREDICATES (AND/OR operands) ││ / ORDER (ORDER BY or GROUP BY Clauses) ││ COMMA (Commas between columns) ││ INTO/SET/VALUES(INTO/SET/VALUES CLauses) ││ UNION (UNION or UNION ALL Clauses) ││ JOIN (Any JOIN Clause like Left Join, Right Join, etc) ││ ││ ││ TIPS: ││ -Use RESTORE command to restore SQL text prior to command SAVETEXT ││ ││ F1=Help F3=Exit │└─────────────────────────────────────────────────────────────────────────┘

JOIN Choose this option to break lines when is any of the JOIN clauses: Example: "LEFT OUTER JOIN" , "FULL OUTER JOIN", etc.

Remove spaces between words for: FUNCTION Choose this option to remove spaces between funcions and parenthesis or parenthesis and other key words or literals. Examples:"CHAR (" , it will be changed to "CHAR(".") )" , it will be changed to "))".


509

SQL Sequential data set Utility

Utility to export SQLs from TurboTuneSQL repository to a sequential data set.

This sequential data set can be manipulated and re-input into TurboTuneSQL usingoption `T` in Define SQL Source panel.

The result of this utility will be stored in ddname SQLFREQ. Generated data set nameshould be:

HLQ.IXADIXAD.SQLFREQ

The above HLQ will have the same name as defined in “HLQ work files” field in JCLcommand.

Notes: – This utility does not accept wildcards.– SQLs statement Update and Delete from Cursor are not supported by this utility.

SAMPLE SCREEN:


510

TurboTuneSQL V120 ------------------- SQL Sequential Dataset ------------ 14:28 Option ===> More: + SQL Sequential Dataset Profile : IVP {E} DB2 SSID : DBBG General Parms: Source Request Code: IVP Write SQLS stmts only for programs found in: W Valid values: W - Workload (only executed statements) S - Source (all source) L - Source (last precompile versions) Process all stmts : N Valid values: Y - Process all statements (including stmts in error). This is the recommended option N - Process only statements with no errors Process Static/Dynamic: B Values: D - Process only dynamic statements S - Process only static statements B - Process both static and dynamic stmts Process all collections : N Valid values: Y - Process all sqls found in all DB2 collections N - Process only the first valid DB2 collection Use clone table? If so, set parms below: Force this Table qualifier: For this Table name :

FIELD DESCRIPTIONS

Source Request Code This is a 5 character code to be used as unique identifier key for TurboTuneSQLRepository (Source and History Tables)

All source information will be retrieved using this request code

Write SQLs from programs found in Specify:

W - Only Write SQLs Text if found in DB2 traces already loaded into TurboTuneSQLrepository. S - Write all SQLs Text found into into TurboTuneSQL repository.L - Write all SQLs Text found into into TurboTuneSQL repository but only for themost recent Precompile Time.

Process all STMTS Y - Process all statements, including SQLs with TurboTuneSQL processing errors.To learn more about processing errors, please refer to Appendix E. Limits andcheck field flag error in STIF Report.N - Process only statements without TurboTuneSQL processing errors.

Process all collections Specify:

Y - to process all SQLS found in all DB2 CollectionsN - to process only the first valid DB2 Collections

Using clone table? If so, set parms below: Optional parameter. If you want to force a new table qualifier for all SQLs written by this utility, please inform:

Use this Table qualifier: table ownerFor this Table name : table name

When table name is found, owner will be changed to table owner.

Parameter Mark option: Define the way how host variables (:H) will be changed before write an SQL to sequential data set. Valid values:

CAST: SQL text will be changed and written using DB2 Cast Syntax.

DB2 cast syntax will be used to force same data type and size as specified inoriginal program host variables.

Therefore host variable :H will be changed by: CAST ( ? AS datatype ( size ) )

In TurboTuneSQL terminology, this is known as ORIGINAL FORMAT (CAST-MAX).

NCAS: SQL text will be changed and written using question parameter mark.

Therefore host variable :H will be changed by ?. In TurboTuneSQL terminology, this is known as NON-ORIGINAL FORMAT (Q-MARK).

For DB2 version 9 (and above) this is the best method.


511

FILTERS

FROM Database Name TO Database Name Inform a range of databases


Table Name Inform up to 6 table names

FROM Program Name - TO Program Name

Inform program names rangeProgram name "FROM" can be informed using wildcard '*' at the end which will fetch arange of programs with the same starting name. Therefore, leave the field "TO" as blank. FROM Plan Name - TO Plan Name Inform plan name range FROM Collection Name - TO Collection Name Inform collection range FROM Correlation Name - TO Correlation Name Inform collection range Connection Type

Inform Connection Type. Valid values: Code Description ----- ----------------------------- 01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W UDF 0Y TRIGGER 0Z STORED PROCEDURE EA CACHE (FOR DYNAMIC SQLS)EB CACHE (FOR STATIC SQLS)

Start/End DATE Inform start/end range date

Start/End TIME Inform start/end range time DB2 Group Name Inform DB2 Data Sharing Group Name FROM DB2 Member Name - TO DB2 Member Name Inform DB2 Data Sharing Member Name range


512

SSID Inform DB2 Subsystem ID

Show all statementsShow program and SQL statement being processed.

DESCRIPTION OF SQLFREQ DATA SET

This a sample content of SQLFREQ data set:

-- _PROGRAM_NAME=PGM00001 -- _STMT_NUM_ORIG=00001 -- _BIND_QUALIFIER=SYSIBM --_TOTAL_ELAPSED=0000010 --_TOTAL_CPU= 0000010--_COLLID=COL01--_DYNAMIC_STATIC=D--_UNICODE=Y--_CCSID_UNICODE=1140--_CCSID_EBCDIC= 0037--_VERSION=FROM SEQUENTIAL FILE-- _COMMA=N -- _QUOTE=N SELECT * FROM SYSIBM.SYSTABLES -- _END

-- _PROGRAM_NAME=PGM00001 -- _STMT_NUM_ORIG=00002 -- _BIND_QUALIFIER=SYSIBM -- _COMMA=N -- _QUOTE=N SELECT * FROM SYSIBM.SYSCOLUMNS -- _END

Keyword description:

_PROGRAM_NAME: Program name_VERSION: Set a DB2 precompile version_STMT_NUM_ORIG: SQL statement number_BIND_QUALIFIER: Default Bind Qualifier_TOTAL_ELAPSED: Total DB2 elapsed time_TOTAL_CPU: Total DB2 CPU_COLLID: Set a fake DB2 collection name_DYNAMIC_STATIC: Treat SQL as a dynamic SQL or Static (D/S)_UNICODE: SQL in Unicode format_CCSID_UNICODE: CCSID Unicode_CCSID_EBCDIC: CCSID EBCDIC _COMMA: Valid Values: N – Period is used; Y – Comma is used_QUOTE: Valid Values: N – Apost is used; Y – Quote is used_TOTAL_EXECUTIONS: Total time this SQL has executed

_END: End of SQL text. (do not use ';' )

This sequential data set can be manipulated and re-input into TurboTuneSQL usingoption `T` in Define SQL Source panel.


513

DESCRIPTION OF SEQUENTIAL DATA SET TO BE USED BY OPTION 'T'

If you want to create a sequential data set to be imported using option `T` in Define SQL Source panel, these are the required keywords:_PROGRAM_NAME, _STMT_NUM_ORIG, _BIND_QUALIFIER, _COMMA, _END.

Notes:– Data set format is: DSORG=PS, RECFM=FB, LRECL=80– Only use columns from 1 to 72 to write your SQL text. Columns 73 to 80 are not

used.


514

Execute SQL commands

Utility to execute any SQL command.Except those with return rows, like “SELECT” SQL command.

SAMPLE SCREEN:


515

TurboTuneSQL V120 ------------------- Execute SQL Commands -------------- 14:33 Option ===> SQL STATMENT EXECUTED OK! COMMIT DONE! More: + Execute SQL commands Profile : IVP {E} DB2 SSID : DBBG Curr Loc : DALLASB Inform: ---------------------------------------------------------------------- Current Sqlid : IBMUSER * SQL SELECT is not allowed ------------------------------------------------------------------------------- CREATE TABLE IBMUSER.TABLE001 (COL01 CHAR(03) NOT NULL, COL02 CHAR(04) NOT NULL, COL03 CHAR(08) NOT NULL, COL04 CHAR(08) NOT NULL) IN DB01.TS01

FIELD DESCRIPTIONS



Current Sqlid:Choose a valid SQLID. If you leave this field blank, your TSO ID will be used asSQLID.


516

Multi-row Fetch Converter

Utility to convert source code to Multi-row fetch.

Exceptional gains are obtained when converting a SQL DECLARE CURSOR from normal FETCH to Multi-row Fetch.

SAMPLE SCREEN:

FIELD DESCRIPTIONS

Program NameProgram name to be converted.

Default rows for MRFNumber of rows to be fetched.

Source DatasetDataset containing the source program to be converted.

BOOKs Datasets

Dataset containing the source copy books used by the source program(PDS or LIBRARY).

Inform up to 3 datasets.

CHANGE CODE FOR CURSORSInform “*” to change code for all cursors, or inform the cursors you desire to convert.


517

TurboTuneSQL V120 ------------------- MRF Converter --------------------- 20:50 Option ===> TYPE "JCL" TO GENERATE JOBS Profile : DBBG {E} DB2 SSID : DBBG INPUT Program Name : Default rows for MRF: Source Dataset : BOOKs Datasets : CHANGE CODE FOR CURSORS * OUTPUT Source Dataset : BOOKs Dataset :

Output Source DatasetDataset where the converted source code will be written.

Output BOOKs DatasetDataset where the converted copy books will be written.


518

Copy Utilities

Menu to configure Copy Utitilies. These utilities must be used only under the direction of your local support representative.


519

Appendix A. TurboTuneSQL Tables Reference

TurboTuneSQL data are stored into DB2 in a Database called TurboTuneSQLRepository. All input Information processed by TurboTuneSQL is done via Batchprocesses before being stored in TurboTuneSQL Repository. TurboTuneSQL Reports andUtilities retrieve information from this Database.

There are 6 TurboTuneSQL table categories: Accounting Tables DDL History Definition Tables Performance Tables Source SQL Tables Work Tables General Tables

You MUST not update TurboTuneSQL tables manually, except if your localrepresentative has requested.

All information here is subject to be changed any time and may be changed to describeproduct changes available via fixes or future releases or to correct inadvertentmisrepresentations.

A short description of all TurboTuneSQL tables and categories will follow.

ACCOUNTING TABLESThis section describes all information stored in TurboTuneSQL Accounting Tables.

ACCTG_OBJ_ACUMThis table stores some captured traces grouped by some DB2 objects, like DB2 connectid.

ACCTG_PGM_ACUMThis table stores package and DBRM information captured by traces grouped by dateand time.

ACCTG_PERF_PGM_REFThis table stores cross reference information about package and DBRM executions.This information is captured from traces. This is the only table that holds informationfrom both traces.

AUTOMATIC INDEX RECOMMENDATION TABLESThis section describes all information stored in TurboTuneSQL Automatic IndexRecommendation Utility.

IXA_IDX_RECOMMENDThis table store the result of all indexes recommendations.

IXA_IDX_PARMSThis table stores all indexes recommendations.

IXA_IDX_SQLSThis table stores all SQLs used as input to indexes recommendations.


520

DDL HISTORY DEFINITON TABLES

This section describes all information stored in TurboTuneSQL DDL History DefinitionTables. When collecting source information about programs and statements, this tablewill hold DDL definitions from DB2 Catalog at that moment in time.

The Online field Request Code is the key field to allow TurboTuneSQL to keep ahistorical view of this information. It also allows you to repeat and maintain severalversions of the same basic information by just putting a different value in the RequestCode field.

HIST_CHILD_INDEXESThis table stores information about DB2 table Indexes in child tables.

HIST_CHILD_FOREIGNThis table stores information about DB2 foreign keys in child tables.

HIST_INDEXESThis table stores information about DB2 table Indexes.

HIST_TABLE_COLSThis table stores information about table columns.

HIST_TABLE_FOREIGNThis table stores information about DB2 foreign keys.

HIST_TABLE_INFOThis table stores information about DB2 Tables from DB2 Catalog.

HIST_TABLESPACEThis table stores information about TABLESPACES from DB2 Catalog.

PERFORMANCE TABLES

This section describes all information stored in TurboTuneSQL Performance Tables.

PERF_PGM_STMTThis table stores performance information about all executed SQL statementssupported by TurboTuneSQL from traces.

PERF_PGM_STMT_NEGThis table stores performance information about all executed SQL statementssupported by TurboTuneSQL from traces with SQLCODE negative or positive withwarning.

SOURCE TABLES

This section describes all information stored in TurboTuneSQL Source Tables. Thistables store information about programs and SQL statements extracted from severalsources supported by TurboTuneSQL, like DBRMLIB data set. Also, these tables storethe results of DB2 Explain function.

The Online field Request Code is the key field to allow TurboTuneSQL to keep ahistorical view of this information. It also allows you to repeat and maintain several


521

versions of the same basic information by just entering a different value in the RequestCode field.

SRC_COM_PLAN_TABLEThis table stores information about Compare Plan Table Utility and some others Online Reports.

SRC_EXP_FUNC_TBThis table stores information about EXPLAIN FUNCTION TABLE for each SQL statement explained in both formats (Original Format, No Mismatches and Copy from Plan Table). For more information, please go to Appendix F- Plan tables description.

SRC_EXP_PLAN_TABLEThis table stores information about EXPLAIN PLAN TABLE for each SQL statementexplained in both formats (Original Format and No Mismatches). For more information, please go to Appendix F- Plan tables description.

SRC_EXP_STMT_TABLEThis table stores information about EXPLAIN STMT TABLE for each SQL statementexplained in both formats (Original Format, No Mismatches and Copy From Plan Table).For more information, please go to Appendix F- Plan tables description.

SRC_PGM_STMT_COLSThis table stores information about all columns, host variables, literals extracted fromSQL statements. There may be the same extracted SQL statement columns but fordifferent Request Codes.

SRC_PGM_STMT_FUNCThis table stores information about SQL statement columns which were used infunctions. Examples: MAX(column), DATE(column), etc.

SRC_PGM_STMT_INFOThis table stores information about every SQL statement. Statement columns, objectsand texts are stored on other TurboTuneSQL Source Tables.

SRC_PGM_STMT_OBJSThis table stores information about objects found in SQL statements.

SRC_PGM_STMT_TEXTThis table stores information about SQL statement texts. There may be the same extracted SQL statement columns but for different Request Codes.

SRC_UNIQUE_COMMENTThis table stores information about user comments about SQL statements.

SRC_UNIQUE_NAMESThis table stores the full value for fields compacted by TurboTuneSQL.

WORK TABLES

This section describes all information about TurboTuneSQL Work Tables. These tablesare used for temporary processing only and will be erased at the end of each batchexecution.

WK_PGM_TOKENThis table stores information about programs found in workload for that FILTER.


522

WK_PGM_UNI_TOKENThis table stores information about programs and SQLs found in workload for thatFILTER.

WK_TABLE_UNIQThis table stores information about tables found in workload or found in TurboTuneSQLSource Tables.

WK_STMT_CACHE_MONThis table stores temporary information about statements during collection processingof DB2 SQL Cache Area (EDM POOL).

CACHE TABLES

This section describes all information about TurboTuneSQL CACHE Tables. These tablesare used to store information about dynamic and static statements found in DB2 SQLCache Area (EDM POOL).

STMT_CACHE_MONThis table stores all information about dynamic and static statements found in DB2 SQLCache Area (EDM POOL).

SETUP TABLES

This section describes all information about TurboTuneSQL SETUP Tables. These tablesare used for SETUP and Configure TurboTuneSQL.

REQUEST CODEThis table stores information about Request Code create using NEWREQ LineCommand.

SRC_UNIQUE_NAMESThis table holds internal codes for each DB2 compacted columns.

STMT_TYPEThis table holds internal codes for each DB2 SQL command.


523

Appendix B. Console Commands

TurboTuneSQL allows you to use z/OS console commands to display information aboutstatus of jobs, turn tracing on or off, and stop batch jobs using the MODIFY consolecommand. These commands will be described below.

DISPLAY Internal use only. This command will work in a few batch jobs.

This command shows information about status of a job being executed.

The following information is displayed: TurboTuneSQL module being executed Value assigned to JCL COND CODE when the job step ends Number of application programs processed so far Current application program being processed

Syntax

F JOBNAME,DISPLAY

Example

F JADV0001A,DISPLAY

SQLTOPER014I- EXECUTING SQLTSSAN PROGRESS= 00000032 CC=0000 PROGRAMS= 00000003 CURRENT PROGRAM=DSN@EP2L

Refer to message SQLTOPER014I in TurboTuneSQL-Messages Guide for more details.

DISPLAY(DIAG)Internal use only. This command will work in a few batch jobs. Shows information about module and routine being executed. This is a diagnosticcommand normally requested by your local support representative.

The following information is displayed:

TurboTuneSQL module being executed TurboTuneSQL subroutine being executed Internal area name if any storage violation has occurred

Syntax

F JOBNAME,DISPLAY(DIAG)

Example

F JADV0001A,DISPLAY(DIAG)

SQLTOPER013I- EXECUTING SQLTSSAN IN ROUTINE SQLTEXPL



524

STOPStops a job being executed.

Syntax

F JOBNAME,STOP orP JOBNAME

Example

F JADV0001A,STOP


TRACETRACE (OFF)Internal use only. This command will work in a few batch jobs. Turns tracing off for the current job being processed. Once trace is off no more information is written to DDNAME MESSAGES.

If trace is already off message SQLTOPER006I will be displayed and no action is taken.

Syntax

F JOBNAME,TRACE(OFF)

Example

F JADV0001A,TRACE(OFF)

SQLTOPER005I- TRACE TURNED OFF BY OPERATOR

Refer to messages SQLTOPER005I/SQLTOPER006I in TurboTuneSQL-Messages Guidefor more details.

TRACE(ON) Turns tracing on for the current job being processed.

Once trace is on, all information is written to DDNAME MESSAGES.

There are several levels of traces. They can vary from level 1 up to level 3, where level3 will give more data.

If trace is already on message SQLTOPER008I will be displayed and no action is taken.

In order to turn tracing off, use command TRACE(OFF).

ATTENTION: This command can cause too many messages.Consider to redirect MESSAGES to a DATA SET.Use this command only when requested by your localrepresentative for problem diagnosis.


525

Syntax

F JOBNAME,TRACE(ON)This will turn trace on, with level 1

F JOBNAME,TRACE(ON2)This will turn trace on, with level 2

F JOBNAME,TRACE(ON3)This will turn trace on, with level 3

Example

F JADV0001A,TRACE(ON)

SQLTOPER007I- TRACE TURNED ON BY OPERATORSQLTOPER007I- TRACE TURNED ON BY OPERATOR

->ATTENTION! TRACE ON CAN CAUSE TOO MANY MESSAGES ->CONSIDER TO REDIRECT MESSAGES TO A DATA SET


F JADV0001A,TRACE(ON2)

SQLTOPER009I- TRACE TURNED ON (LEVEL=2) BY OPERATOR ->ATTENTION! TRACE ON CAN CAUSE TOO MANY MESSAGES ->CONSIDER TO REDIRECT MESSAGES TO A DATA SET


F JADV0001A,TRACE(ON3)

SQLTOPER011I- TRACE TURNED ON (LEVEL=3) BY OPERATOR ->ATTENTION! TRACE ON CAN CAUSE TOO MANY MESSAGES ->CONSIDER TO REDIRECT MESSAGES TO A DATA SET



526

Appendix C. Online Commands

TurboTuneSQL has several Online commands to help you navigate through the ISPFonline screens and also to help set up variables as a filter for online and help reports.

Note: Not all commands are available on all screens. See specific help for more details.

DB2Perform DB2 commands.

EXPLShows “DB2 Explain” panel to execute Explain function. For more information, go toDB2 Explain Command(EXPLAIN command is the same as EXPL).

FILTER OR FLTShows “Report Filters” panel to set up filters to be used in both Online and BatchReports.

Note:– The filter values that you enter here will be saved in TurboTuneSQL Profile if youhave entered FILTER on the main report screen.– Do NOT use any kind of wildcards like ‘*’ or ‘%’ except for Online Reports AC00,SRPG (filtering programs); ACOR, CICS, IMSM (filtering correlations); APLN, (filteringplans); HT00 and TB00 (filtering tables).– Normally, if you are using an online report triggered by an Action Line, FILTERcommand will only allow you to change the following fields and these changes areremained temporary until you return to Online Report Menu:

○ Request Code Fields○ Maximum number of lines


527

TurboTuneSQL V120 ------------------- Report Filters -------------------- 21:36 Option ===> More: + Report Filters (Online and Batch) Profile : PROFCAC1 {E} DB2 SSID : DBBG General Parms: Explain Request Code: IVP1 Source Request Code: IVP1 Maximum Lines to be displayed in Online Reports: 02000 BATCH Reports: Report Level : 3 1/2/3 Print Sql Text in Batch Reports : N Y/N Maximum Objects to be displayed in Batch Reports: 00250 Trace Origin: A Accounting, Performance, Cache or *(ALL) General Filters: Database Name From: To: Table Owner: Table Owner Table Name: Table Name <- Always use this line first when filtering by table

FIELD DESCRIPTION Explain Request Code This is a 5 character code to be used as an unique identifier key for TurboTuneSQLRepository (Source Explain Tables).

Source Request Code This is a 5 character code to be used as an unique identifier key for TurboTuneSQL Repository (Source and History Tables).

Report Level: Controls the level of information being written to Batch Reports.Each report has its own level of detail. Valid values are 1,2 or 3.

Maximum Objects to be displayed in Batch Reports: Specify the maximum number of main objects to be printed in Batch Reports. Example:if you specify 10 in this field, batch report AC00 will show only 10 programs.

Maximum Line to be displayed in Online Reports: Specify the maximum number lines to be displayed in Online Reports. Example: if youspecify 10 in this field, online report ST01 will show only 10 lines/SQLs.

Print SQL Text in Batch Reports If you specify Y, some batch reports will print SQL text corresponding to the currentSQL command.

Database Name FROM/TO (*)Inform a range of databases


Table Name Inform up to 6 table names or simply inform using wildcard '*' to display tables started with a given name. This facility is only available for Online Reports HT00 and TB00.

Program Name FROM/TO (*)Inform program name range or simply inform using wildcard '*' to display programs started with a given name. This facility is only available for Online Reports AC00 and SRPG.

Plan Name FROM/TO (*)Inform plan name range or simply inform using wildcard '*' to display plans started witha given name. This facility is only available for Online Report APLN.

Collection Name FROM/TO (*)Inform DB2 COLLECTION name range

Correlation Name FROM/TO (*)Inform Correlation name range or simply inform using wildcard '*' to display correlations started with a given name. This facility is only available for Online Reports ACOR, CICS and IMSM.

Connection Type Inform Connection Type. Valid values:

Code Description ----- -----------------------------


528

01 TSO FOREGROUND AND BACKGROUND 02 DB2 CALL ATTACH 03 DL/I BATCH 04 CICS ATTACH 05 IMS ATTACH BMP 06 IMS ATTACH MPP 07 DB2 PRIVATE PROTOCOL 08 DRDA PROTOCOL 09 IMS CONTROL REGION 0A IMS TRANSACTION BMP 0B DB2 UTILITIES 0C RRSAF ATTACH 0W udf 0Y TRIGGER 0Z STORED PROCEDURE

Note: In fact, UDF, Trigger and Stored Procedure are not Connection Types.TurboTuneSQL has created these new codes here just to help customers to easilyidentify these DB2 objects.

Start/End DATE (**) Inform start/end range date

Start/End TIME (**) Define start/end range time

DB2 Group Name DB2 Data Sharing Group Name. This is an 8 bytes field namw, so do not use the attachgroup name. Use the DB2 group name as it appears in the ´-DIS GROUP´ DB2 command.

DB2 Member Name FROM/TO (*)DB2 Data Sharing Member Names


SQL Uniq NumberUnique Number that defines a SQL Text to be used as a filter.

Other data Internal use only.These fields will be shown only when the FILTER command was NOT entered on themain online report screen. When this occurs, only the fields 'Explain Request Code', 'Source Request Code'and 'Maximum Line to be displayed in Online Reports' can be changed.

(*) Rules for using the range 'FROM' and 'TO' parameters: - 'FROM' is mandatory only when the 'TO' parameter has been entered. - 'TO' is not mandatory, even if the 'FROM' parameter has been entered. - When the 'TO' parameter has not been enteres, it will receive the same value as the 'FROM' parameter. Examples: Lets suppose we have following programs in TurboTuneSQL Database: PROGA0001 PROGA0002 PROGB PROGB0001 PROGC0001


529

PROG01 (1) FROM: PROGA TO: PROGC will bring: PROGA0001 PROGA0002 PROGB PROGB0001 (2) FROM: PROGB TO: PROGC0002 will bring: PROGB PROGB0001 PROGC0001 (3) FROM: PROG TO: PROG99999 will bring: PROGA0001 PROGA0002 PROGB PROGB0001 PROGC0001 PROG01

(**) For both filters - Date and Time, put here the Date/Time has been Rounded by this parameter Reducing Traced Data. This computation is madeby using the time when the object was ended.

GENALLShows “Generate Jobs” panel to generate all batch jobs to Load Workload and SourceData into Tables.

HELPOpen a Help description for the current screen.Note: F1 will activate the same function.

HELPCMDOpen a short Help description for all Online Commands.

INFOShows applied product FIXES (Changes) and some other general information.

For more information, please check Appendix M.

JCLShows “Create JCL” panel to inform PDS data set to create JCL for a specific function.

For more information, please check Appendix JCL Description for specific informationfor TurboTuneSQL.


530

JCLOPT

To define all JCL Run Options for all TurboTuneSQL batch processing, useTurboTuneSQL command JCLOPT.

JCLOPT command shows “Run Options” panel:

Note: – TurboTuneSQL has JCL Restart Points. Check Appendix JCL Description for moreinformation.– TurboTuneSQL always uses NOCOPYPEND as a parameter in Load Utility. For recoverypurposes, you must always backup all TurboTuneSQL tables before executing anyTurboTuneSQL batch process.

FIELD DESCRIPTIONS

JOB Cards Enter JOB Cards to be used in this run If you change this parameter, JCL needs to be re-created. Allocation specifications for Work/Sort Files HLQ work files Data set High Level Qualifier for work, log and sort files Example: WRK.RUN01


531

TurboTuneSQL V120 ---------------- JCL Specifications ------------------- 21:44 Option ===> Profile : PROFCAC1 {E} DB2 SSID : DBBG HLQ work files : TWORK10 Unit Names Work Datasets : UNIT=SYSDA Example: UNIT=SYSDA Sort Datasets : UNIT=SYSDA Volumes Work Datasets : Example: VOL=SER=(VVVVV1,VVVVV2), Sort Datasets : SMS DATACLAS WK: SMS STORCLAS WK: SMS DATACLAS ST: SMS STORCLAS ST: JOB Cards: (Recommended region size is 24M or 0M) //JSAMPLE JOB 'IVP-TEST',MSGCLASS=A,CLASS=D,NOTIFY=, // REGION=0M //*

Note: All sequential generated data sets by TurboTuneSQL will use thisHLQ. There are 2 important sequential files used by all TurboTuneSQL batch(Utilities, Batch Reports, Loading SQL text, DB2 traces, etc). They are:

<HLQ work files>.MESSAGES: This is the TurboTuneSQL LOG data sets

<HLQ work files>.TOTALSThis data set contains all TurboTuneSQL counters (recordsread, records write, explains dones, etc)


Unit Name WK JCL Unit Name used in all TurboTuneSQL WORK data sets. Example: UNIT=SYSDA If you change this parameter, JCL needs to be re-created.

Unit Name STJCL Unit Name used in all TurboTuneSQL SORT data sets. Example: UNIT=SYSDA If you change this parameter, JCL needs to be re-created.

Volser WKJCL VOL SER used in all TurboTuneSQL WORK data sets. If you don’t need to setupVOLUMES in you site, just leave this field blank.Syntax Example:VOL=SER=(Volume1, Volume2), (always put ‘,’ at end) If you change this parameter, JCL needs to be re-created.

Volser STJCL VOL SER used in all TurboTuneSQL SORT data sets. If you don’t need to setupVOLUMES in you site, just leave this field blankSyntax Example:VOL=SER=(Volume1, Volume2), (always put ‘,’ at end) If you change this parameter, JCL needs to be re-created.

SMS DATACLAS WKIf you need to, setup SMS DATACLASS JCL syntax for all TurboTuneSQL WORK data setsIf you change this parameter, JCL needs to be re-created.

SMS STORCLAS WKIf you need to, setup SMS STORCLAS JCL syntax for all TurboTuneSQL WORK data sets. If you change this parameter, JCL needs to be re-created.

SMS DATACLAS STIf you need to, setup SMS DATACLASS JCL syntax for all TurboTuneSQL SORT data sets. If you change this parameter, JCL needs to be re-created.

SMS STORCLAS STIf you need to, setup SMS STORCLAS JCL syntax for all TurboTuneSQL SORT data sets. If you change this parameter, JCL needs to be re-created.

DELETE Parms This parameters controls if all intermediate sequential files (WORK and SORT) must be delete when they are not more necessary.


532

Options: Delete all files at end. Use: DISP=(OLD,DELETE)

This is the recommended option.

Do NOT Delete all files at end. Normally this option will be setup only whenrequested by your local representative for debug purposes. Use: DISP=(OLD,KEEP)


LSTCOMList all SQL Comments made by Users. This command produces the same informationas in SSCO Online Report, but Request Code is not used as a filter.

LSTREQList all Request Codes. For more information, click here.

MEMShow memory information for TurboTuneSQL CLIST and TurboTuneSQL batch jobs. Alsoshow DB2 internal memory allocation: :– Sql Statement Cache– Other DB2 areas (get from IFCID 255).

Sample screen.

For more information, please consult IBM DB2 documentation.


533

TurboTuneSQL V120 ------------------- DB2 ifcid 225 -------- Row 1 to 37 of 59 Option ===> Storage Manager Pool Summary Profile : PROFCAC1 DB2 SSID : DBBG ------------------------------------------------------------------------------ ----------------------------------------------------------- ------------ INTERNAL MEMORY ALLOCATION - ISPF AND BATCH -- ----------------------------------------------------------- MEMORY ALLOCATION FOR INTERNAL TABLES: TABLE TB-TEXT: 1,000 TABLE TB-DBRM: 25,000 TABLE TB-WORD: 10,000 TABLE TB-FUNC: 200 TABLE TB-HOST: 1,500 TABLE TB-CRCWORD: 1,500 TABLE TB-CRCNUMBERS: 1,500 TABLE TB-EXTRACT : 16,000 MEMORY ALLOC WHEN GETMAIN IS ZERO FOR DYN: *********** MEMORY ALLOC WHEN GETMAIN IS ZERO FOR STAT: 1,072,502

NEWCOM

Create a new SQL comment.

FIELD DESCRIPTIONS

Request Code This is a free 5 characters code to be used as an unique identifier key intoTurboTuneSQL Tables (Request Code for Source). Status Here you can create your own status rules, so any character is valid. Sugestion: O - open, C - close, etc Choose Choose a Key to STORE SQL comment Unique Number or Group Table Number AND Group Columns Number are mutuallyexclusive.

IDENTICAL SQLsUnique Number Unique Number that defines this SQL Text.

SIMILAR SQLsGroup Table Number Unique number that defines all group of tables found in this SQL. Group Column Number Unique number that defines all group of predicates found in this SQL.

Description User SQL Comments


534

TurboTuneSQL V120 ------------------- SQL Comments ---------------------- 21:50 Option ===> SSCO - User SQL Comments Profile : PROFCAC1 DB2 SSID : DBBG Status : Choose the key format to access your comment: Identical SQLs: Unique Number : OR Similar SQLs : Group Table Number : Group Columns Number : Description:

NEWREQShows panel to create a new Request Code.

Field Description: Code Request code Type Type of request code – E, S or I

(S) Request code for a Source - Used as an index key when storing SQLs fromDBRMs, DB2 Catalog, Sequential data set, SQL Cache Area and DB2performance traces.Also, it will be used as a key when storing DDL history definitions.(E) Request code for an Explain- Used as an index key when storing the result ofTurboTuneSQL Explain Utility. (I) Request code for an Index - Request code for Index Recommendation- Usedas index key to store results of TurboTuneSQL Automatic Index recommendationutility.

Date Request Code Creation date for type S or E. Submitted date for type I.

Records Amount of records found in a TurboTuneSQL table. Use this field to verify thatTurboTuneSQL tables contain records associated with this Request Code.

Short Description Brief description about the request.

QUITAll consistency will be skipped for all fields and the previous panel is shown.

REFRESH OR REFScreen Refresh for some online Panels. Attention: You cannot use this command inOnline Reports. If you want to refresh an Online Report, please type FILTER.

REPBShows “Batch Reports” panel.

REPOShows “Online Reports” panel.

RESTORERestore panel fields to their original values before entering the current panel.


535

SAVEAll active configurations are saved into current TurboTuneSQL Profile. Attention: SAVE is only allowed when profile is in Edit Mode {E}.

SECONTurn on security check for resources. TurboTuneSQL will first check if the user isauthorized to update/read any resource. The security will be turned on the next timethe user starts a new session.

SECOFFTurn off security check for resources. TurboTuneSQL will never check if the user isauthorized to update/read any resource. For example, If the user turns off securitywhile generating a JCL, a system abend S913 my occur and TurboTuneSQL session maybe terminated abnormally. The security will be turned off the next time the user startsa new session.

SETUPShows “Product profile” panel.

TurboTuneSQL Profile controls all functions of TurboTuneSQL. It contains parametersused by all TurboTuneSQL process (batch and online programs). TurboTuneSQL Profilesare members stored into PDS data sets.

Another way to setup a Profile: at main screen choose option “Product profile”.

For more information, go to Customize a TurboTuneSQL Profile.

SORTSort fields in Online Report Panels. Use SORT blank to check all available fields for the current Panel.Fields with default descending: - DATE - TIME - DATE+TIME - CPU - WAIT - ELAP - COST - TOTAL - QUANTITY - LENGTH - SCALE - PRECISION - RATIO - NLEVEL - NLEAF - CARDF - MATCHCOLS - FLAG ERROR - FLAG EXIST - FLAG EXECUTED

Fields with default ascending: - UNIQUE NUMBER - GROUP NUMBER - INTERVAL


536

- SEQUENCE - NAME - USERID - ORDERING - INDEXONLY - ALL OTHER FLAGS

SPACESShows “Space Options” panel to calculate DASD spaces for batch jobs. Clickhere formore information.

SQLShows “Execute SQL Commands” panel to execute SQLs commands. For moreinformation go to Execute SQL commands.

VIRTOpen TurboTuneSQL-VIRT main menu. For more information, please refer toTurboTuneSQL-VIRT documentation.


537

Appendix D. Algorithms

SQL INVENTORY

The SQL Inventory facility of TurboTuneSQL has the ability to create new identifiers foreach SQL command. TurboTuneSQL creates four new identifiers for each SQLcommand as shown below. This facility is used throughout the entire product. The newidentifiers are:

● SQL Statement Unique: This number identifies `same` SQLs● SQL Statement Group Tables: identify SQLs using ‘same’ DB2 tables● SQL Statement Group Columns: identify SQLs using ‘same’ DB2 predicates● SQL Statement Group Sort: identifies SQLs using ‘same’ columns in GROUP BY and

ORDER BY clauses.

TurboTuneSQL assumes that identical SQLs share the same Unique number.

TurboTuneSQL assumes that similars SQLs share the same Group Table and GroupColumn numbers.

Each identifier has a different algorithm used to create these numbers, but all of theidentifiers follow the following general rules:

● Related SQL statements will be assigned the same new identifier. Examples:A) Using cursor (static or dynamic):

– DECLARE CURSOR CS1 FOR SELECT * FROM TABLE_1– OPEN CS1– FETCH CS1– UPDATE ...WHERE CURRENT OF CS1– DELETE ...WHERE CURRENT OF CS1– CLOSE CS1All SQLs above will assign the same new identifier because they are related. Text 'SELECT * FROM TABLE_1' will be used to generate these values.

B) Dynamic SQL: – DECLARE DT1MISM CURSOR FOR PREPP1– PREPARE PREPP1 FROM :STMTBUF– OPEN DT1MISM USING :H– FETCH /DELETE/UPDATE WHERE CURRENT OF DT1MSIMAll SQLs above will assign the same new identifier because they arerelated.

At execution time, SQL text obtainned from traces (from programvariable 'STMTBUF' as in above example) will be used to generatesame identifier for all related commands (prepare, execute, open,fetch, etc).

- Dynamic SQL OPEN will be registered as SELECT command in SourceTables.

● Uppercase and lower case are considered the same

● If SQL was issued in a DB2 View, only the view name are used. Therefore, DB2 tablesinside views are not used.


538

● The algorithm takes in consideration the parameters quote/coma from the profileand not only the rules above. Therefore, the quote/comma should the checked andconfigured according to your DB2 environment. If configured improperly,unpredictable values may be generated for statement unique, group table, groupcolumn and group sort calculation.

Note: SQL Inventory may not work when SQL command is not supported byTurboTuneSQL . Check Appendix E. Limits for more information.

SQL Statement Unique Algorithm

This section describes the algorithm used to calculate the unique number statement foridentical SQL Texts.

This is a 4 bytes identifier that allows you to identify and group ‘exactly’ the same SQLcommands. This number will always be presented in hexadecimal format.

RULES

To calculate this new identifier, some rules will be applied before the computation ofthis new identifier:

More than one space outside literals are changed to only one space Spaces may generated by TurboTuneSQL to try to recognize more identical SQLs String 'Declare Cursor' is always removed before any computation Uppercase and lower case are considered the same word, except for literals Quote/Comma TurboTuneSQL Profile parameter are used

Note: (2) The above rules will not be applied when TurboTuneSQL thinks there are syntax

errors (Please check Appendix Limits for more details). In this case, TurboTuneSQLwill not apply the rule above and only the original SQL text will be used as input forthe calculation.

(3) When the SQL text is not found, it will not be extracted. Some examples of situationswhere this can happen:

● A wrong DBRMLIB data set was used● DB2 IFCID 63 (sql text from DB2 performance traces) was not found into

traces● DB2 Precompile time does not match (Traces and DBRMLIB member)● Other reasons

EXAMPLES:

A) SELECT * FROM TABLE1

will get the same unique identifier as

SELECT * FROM TABLE1

B) Select … where Col1 = ‘Literal1’

will NOT get the same unique identifier as


539

Select … where Col1 = “Literal1”

C) Select “COL2” From Table1


Select COL2 From Table1

D) Select A.COL1 From Table1 A


Select B.COL1 From Table1 B

E) Select A.COL1 From Table1 A


Select COL1 From Table1

F) DECLARE CURSOR CUR001A FOR SELECT * FROM TABLE1


SELECT * FROM TABLE1

G) SELECT * FROM TABLE1


Select * From Table1

H) SELECT * FROM TABLE1 WHERE COD = ?


SELECT * FROM TABLE1 WHERE COD = :H

I) SELECT * FROM TABLE1 WHERE COD=?


SELECT * FROM TABLE1 WHERE COD = ?

J) SELECT COL1 FROM TABLE1 WHERE COD = :H


SELECT COL1 INTO :H FROM TABLE1 WHERE COD = :H

K) SELECT COL1 FROM TABLE1 WHERE COD = :WK-COD


540


SELECT COL1 INTO :H FROM TABLE1 WHERE COD = :H


541

SQL Statement Group Tables Algorithm

This section describes the algorithm used to calculate the group of tables statement.

This is a 4 bytes identifier that allows you to identify and group SQL commandsaccessing ‘exactly’ the same group of tables. This number will always be presented inhexadecimal format.

RULES


SQL Statements with no TABLES clause will receive internal TurboTuneSQL statement type code as the SQL group table identifier

When a table name is referred to more than once, only one is considered prior to the calculation

Owner and Location are not considered for calculation

Note: The above rules will be not applied when TurboTuneSQL thinks there are syntaxerrors (Please check Appendix Limits for more details). In this case, a zero value will begenerated.

EXAMPLES:

A) SELECT * FROM TABLE1, TABLE2 WHERE A IN

(SELECT B FROM TABLE2 WHERE C = 1)

will get the same group tables identifier as

SELECT * FROM TABLE1,TABLE2

B) Select * From Table1, TABLE2


SELECT * FROM TABLE2, TABLE1

C) Select * From OWNER1.Table1


SELECT * FROM OWNER2.TABLE1

SQL Statement Group Columns Algorithm

This section describes the algorithm used to calculate group of columns statementfound in predicate (WHERE/ON/HAVING). In fact, it allows you to identify and group SQLcommands with ‘exactly’ the same group of DB2 predicates.

This is a 4 bytes identifier and it will always be presented in hexadecimal format.


542

RULES


● SQL Statements with no where/on/having clause will receive internal TurboTuneSQLstatement type code as the SQL group column identifier.

Examples: Create Database will receive code x’FB00’. Insert will receive code X’1000’

Exceptions: For the following commands, a zero value will be generated: SELECT, UPDATE, DELETE, DECLARE CURSOR, INSERT WITH SELECT and CREATE VIEW.

● The position of the Predicate (or group of predicates) are not relevant.

● Operators are joined as identical according to the following rules:● Equal operators:

“=”, “IN”, “IS” ,”IS NOT” ● Negative Operators:

“<>”, “¬”,'¬=',”¬>”,”'¬<”,”!”,”!=”, “'!>”,”'!<”, “NOT BETWEEN”, “NOT LIKE”, “NOT IN” and “NOT EXISTS”

● Range Operators: “<”, “>”, “>=” and “<=”, “BETWEEN”, “LIKE” and “EXISTS”

● Subselect “any operator (subselect)”, “any operator SOME”, “any operator ALL”

and “any operator ANY”

● The SQL type is not relevant. Therefore DELETE, SELECT, UPDATE, etc can havesame Group Column number.

● Only the column name will be considered. Table name are not considered by thealgorithm.

Note:(2) The above rules will be not applied when TurboTuneSQL thinks there are syntax

errors (Please check Appendix Limits for more details) or when SQL source text wasnot found. In this case, a X´303F´ value will be generated.

(3) If you have an Insert SQL with Select, the Select command will be used to createthe Group Column value.

EXAMPLES:

A) Select … where cola = colb

will NOT get the same group columns identifier as

Select … where cola <> colb

B) Select … where cola = colb

will get the same group columns identifier as

Select … where cola > colb

C) SELECT … WHERE COLA = COLB AND COLC = COLD


543


SELECT … WHERE COLD = COLC AND COLB = COLA

D) SELECT … WHERE COLA = COLB


SELECT … WHERE COLB = COLA

E) UPDATE … where Col1 = ‘1’


SELECT … where Col1 = ‘1’

F) Select … where cola = colb


Select … where COLA = COLB

G) SELECT … FROM TABLE_CUSTOMER where Col1 = ‘1’


SELECT … FROM TABLE_ADDRESS where Col1 = ‘1’

SQL Statement Group Sort Columns Algorithm

This section describes the algorithm used to calculate the group number statement for SQLs with same columns in SORT BY and GROUP BY.

This is a 4 bytes identifier that allows you to identify and group SQL commands with‘exactly’ the same group columns in group by and order by. This number will alwaysbe presented in hexadecimal format.

RULES

To calculate this new identifier, some rules will be applied before the computation of this new identifier:

SQL Statements with no group by or order by will receive a zero value

The sort column position is relevant.

When both GROUP BY and ORDER BY clauses are present in the statement, onlyGROUP BY columns are considered input for the calculation

Note: The above rules will not be applied when TurboTuneSQL think there are syntaxerrors (Please check Appendix Limits for more details). In this case, a zero value will begenerated.


544

EXAMPLES

A) Select * From Table1 where cola = colborder by cola

Will get the same group sort columns identifier as

Select * From Table 1 where cola = 1order by COLA

B) Select … group by cola


Select … order by cola

C) Select * from table1 where cola = colborder by cola, colb

Will NOT get the same group sort columns identifier as

Select * from table1 where cola = colborder by colb, cola

D) Select cola, colb from table1 where cola = colborder by cola

Will NOT get the same group sort columns identifier as

Select cola, colb from table1 where cola = colborder by 1

E) Select cola, colb from table1 where cola = colborder by cola desc


Select cola, colb from table1 where cola = colborder by cola asc


545

PROGRAM ORIGINAL FORMAT AND NON-ORIGINAL FORMAT

This is a facility to help you:–To easy find probable DB2 columns data type mismatches between DB2 tabledefinition and host variables. The mismatch problems are not fully resolved even in themost recent DB2 versions. –To identify where Plan Table data are coming from.

In some reports, you will see the following report headers: OF or Ofmt. These headersmean Program Original Format.

Valid values:–Value 'Y' means that SQL are in their original format (Program Original Format).Program Original Format (value 'Y') is a method used by TurboTuneSQL to guess whatis the actual program behavior is in terms of DB2 Access Path Behavior. So in this case,it will use DB2 cast function to simulate the data type definition of working hostvariables to be set exactly as defined in the programs.

–Value 'N' means that SQL are not in their original format (Program Non-OriginalFormat).Program Non-Original Format (value 'N') is a method used by TurboTuneSQL to guesswhat would be program behavior in terms of DB2 Explain function considering therearen't columns and work variable data type mismatches. In this case, it will not useDB2 cast function and it will change ‘:H’ by ‘?” parameter mark.

–Value 'C' means that TurboTuneSQL Explain Utility has executed Plan Table CopyFunction. Only most recent BIND-TIME has been copied from User Plan Table toTurboTuneSQL Plan Table. Original program work variables format has been preserved,like method Program Original Format.

–Values 'B' and 'A' means that this explain was made by TurboTuneSQL AutomaticIndex Recommendation B - Show Explains made BEFORE Index Recommendation take effect A - Show Explains made AFTER Index Recommendation take effect

–Value 'U' means that this explain was made by user through DB2 Bind utility.


546

HOW INDEXES ARE COMPARED TO IDENTIFY SIMILAR AND IDENTICAL INDEXES

Here we will describe how indexes are compared to discover identical and similarindexes. This facility is available in TurboTuneSQL Automatic Index RecommendationUtility and in Batch Report TI01.

Note: if you decide to drop an index, before dropping it, please, read dropping an indexto get some important tips.

HOW AUTOMATIC INDEX RECOMMENDATION UTILITY IDENTIFIES IDENTICAL INDEXES

When Automatic Index Recommendations Utility find two identical indexes, an DROP orATTN ACTION will be sent. Report IXRM will show the name of compared indexes onfield IxName (or Index Name) and field Related index (or Related Index Name).

The following applies when finding identical indexes:1. Index Name and Related Index Name has exactly same list of columns.2. Catalog field ibmreqd must be different to 'Y'.3. Ordering (ASC,DESC,etc) will be checked. Examples of identical indexes:- All columns has exactlly same ordering.

IX1: COL1(ASC), COL2 (ASC)IX2: COL1(ASC), COL2 (ASC)

- All columns has different ordering.IX1: COL1(ASC), COL2 (ASC)IX2: COL1(DESC), COL2 (DESC)

4. Include index option will not be checked. Example non-identical indexes:

IX1: COL1(ASC), INCLUDING (COL2, COL3)IX2: COL1(ASC), COL2 (ASC), COL3(ASC)

5. If indexes are identicals, one of them will receive DROP ACTION (if no restrictionswas defined at Drop Option parameters). This utility will automatically choose whichindex should be dropped. To do that indexes are scored. The index with less pointswill appear on field IxName and this index may be automatically dropped (virtually).Indexes are score as follows:Points Index attribute

4 Unique 2 Cluster 1 Not Unique and not Cluster

Example: Index1 has Unique and Cluster attribute. Total points: 6Index2 has Unique attribute. Total points: 4Therefore, if Index1 and Index2 are identicals (columns), Index2 should be droppedbecause it has received less points.

More examples of Identical Indexes:1. IX1(UNIQUE): COL1(RANDOM)

IX2(DUPLIC): COL1(RANDOM)

2. IX1(DUPLIC): COL1(ASC), COL2(ASC)IX2(UNI/PK): COL1(DESC), COL2(DESC)

3. IX1(DUPLIC): COL1(ASC), COL2(DESC), COL3(ASC)IX2(DUPLIC): COL1(ASC), COL2(DESC), COL3(ASC)

HOW AUTOMATIC INDEX RECOMMENDATION UTILITY IDENTIFIES SIMILAR INDEXES


547

When Automatic Index Recommendations Utility find two similar indexes, an DROP orATTN ACTION will be sent. Report IXRM will show the name of compared indexes onfield IxName (or Index Name) and field Related index (or Related Index Name).

The following applies when finding similar indexes:1. Index Name has partial list of columns when compared to Related Index Name.2. The value of catalog field nlevels will be considered only if Index Name and RelatedIndex Name are physical indexes. If nlevels are considered and not equals, theseindexes will not be compared.3. Index Name does allow duplicate rows (catalog field uniquerule must be = 'D'). IfRelated Index Name is a virtual index, uniquerule will not be considered.4. Index Name is not a partitioning index 5. Catalog field ibmreqd must be different to 'Y'6. Ordering (ASC, DESC, etc) will be checked. Examples of similar indexes:

- Partial columns list and same ordering:IX1: COL1(ASC), COL2 (ASC)IX2: COL1(ASC), COL2 (ASC) , COL3 (DESC)

- Partial columns list and different ordering:IX1: COL1(ASC), COL2 (ASC)IX2: COL1(DESC), COL2 (DESC) , COL3 (DESC)

7.Include index option will be checked. Example of similar indexes:

IX1: COL1(ASC), INCLUDING (COL2 , COL3)IX2: COL1(ASC), COL2 (ASC), COL3(ASC), COL4 (ASC)

8. If indexes are similars, one of them will receive DROP ACTION (if no restrictions wasdefined at Drop Option parameters). IxName may be automatically dropped (virtually)only if:

- This index is NOT a Data-partitioned secondary index- This index is NOT a partitioned/partitioning index

9. If IxName has Cluster attribute and it receives an DROP ACTION, a ATTNrecommendation will also be issued to warn you that you should add Cluster attributeto Related Index Name.

More examples of similar Indexes:1. IX1(DUPLIC): COL1(RANDOM), COL2(ASC)

IX2(DUPLIC): COL1(RANDOM), COL2(ASC), COL3(ASC)

2. IX1(DUPLIC): COL1(ASC)IX2(UNI/PK): COL1(ASC), COL2(ASC)

3. IX1(DUPLIC): COL1(RANDOM)IX2(UNIQUE): COL1(RANDOM), COL2(ASC)

4. IX1(DUPLIC): COL1(RANDOM)IX2(DUPLIC): COL1(RANDOM), COL2(RANDOM)

5. IX1(DUPLIC): COL1(RANDOM)IX2(DUPLIC): COL1(RANDOM), COL2(ASC), COL3(ASC)

6. IX1(DUPLIC): COL1(ASC), COL2(ASC)IX2(DUPLIC): COL1(ASC), COL2(ASC), COL3(ASC), COL4(ASC)

HOW AUTOMATIC INDEX RECOMMENDATION UTILITY IDENTIFIES MAYBE DUPLICATED INDEXES

When Automatic Index Recommendations Utility find two indexes that may beduplicated, an DROP or ATTN ACTION will be sent. Report IXRM will show the name ofcompared indexes on field IxName (or Index Name) and field Related index (or RelatedIndex Name).


548

The following applies when finding indexes that maybe duplicated:1. Exactly same rules as in HOW AUTOMATIC INDEX RECOMMENDATION UTILITYIDENTIFIES SIMILAR INDEXES, but different from other, Index Name does not allowduplicate rows (catalog field uniquerule must be <> 'D').2. if Index Name is a physical index and Related Index Name allows duplicate rows, anATTN (attention) recommendation will be created to warn you that you can add uniqueattribute to Related Index Name. if Related Index Name is a virtual index, it will beautomatically turned Unique.3. If indexes may be duplicated, one of them will receive DROP ACTION (if norestrictions was defined at Drop Option parameters). IxName may be automaticallydropped (virtually) only if:

- This index is NOT a Data-partitioned secondary index- This index is NOT a partitioned/partitioning index - Parameter Drop indexes with Unique attribute was set to 'N

4. Index Name might be dropped, but this can damage your application data integrity.

Examples of Maybe duplicated Index:

1. IX1(UNIQUE): COL1(RANDOM), COL2(ASC)IX2(DUPLIC): COL1(RANDOM), COL2(ASC), COL3(ASC)

2. IX1(UNIQUE): COL1(ASC), COL2(ASC)IX2(DUPLIC): COL1(ASC), COL2(ASC), COL3(ASC)

3. IX1(PK): COL1(ASC)IX2(UNIQUE): COL1(ASC), COL2(ASC), COL3(ASC), COL4(ASC), COL5(ASC)

HOW REPORT TI01 IDENTIFIES IDENTICAL INDEXES

When Batch Report TI01 find two identical indexes, the following message will be sent:(Index Name)RIXTI0101– IDENTICAL INDEX. RELATED INDEX: (Related Index Name)

The following applies when finding identical indexes:1. Index Name and Related Index Name has exactly same list of columns.2. Index Name is not a partitioning index 3. Catalog field ibmreqd must be different to 'Y'.4. Both indexes are physical index.5. Ordering (ASC, DESC, etc) will be checked. Examples of identical indexes:- All columns has exactlly same ordering.

IX1: COL1(ASC), COL2 (ASC)IX2: COL1(ASC), COL2 (ASC)

- All columns has different ordering.IX1: COL1(ASC), COL2 (ASC)IX2: COL1(DESC), COL2 (DESC)

6. Include index option will be checked. Example of identical indexes:

IX1: COL1(ASC), INCLUDING (COL2, COL3)IX2: COL1(ASC), COL2 (ASC), COL3(ASC)

7. If indexes are identical, one of them should be dropped. To help you to decide whichindex should be dropped, indexes are scored. The index with less points in appear inabove message as Index Name and should be dropped. Indexes are score as follows:Points Index attribute

4 Unique 2 Cluster 1 Not Unique and not Cluster

Example: Index1 has Unique and Cluster attribute. Total points: 6


549

Index2 has Unique attribute. Total points: 4Therefore, if Index1 and Index2 are identicals (columns), Index2 should be droppedbecause it has received less points.

More examples of Identical Indexes:1. IX1(UNIQUE): COL1(RANDOM)

IX2(DUPLIC): COL1(RANDOM)

2. IX1(DUPLIC): COL1(ASC), COL2(ASC)IX2(UNI/PK): COL1(DESC), COL2(DESC)

3. IX1(DUPLIC): COL1(ASC), COL2(DESC), COL3(ASC)IX2(DUPLIC): COL1(ASC), COL2(DESC), COL3(ASC)

4. IX1(UNIQUE): COL1(ASC), INCLUDING (COL2, COL3)IX2(UNIQUE): COL1(ASC), INCLUDING (COL2, COL3)

HOW REPORT TI01 IDENTIFIES UNNECESSARY (OR SIMILARS) INDEXES

When Batch Report TI01 find two similars indexes, the following message will be sent:(Index Name)RIXTI0102-UNNECESSARY INDEX.RELATED INDEX:(Related Index Name)

The following applies when finding similar indexes:1. Index Name has partial list of columns when compared to Related Index Name.2. The value of catalog field nlevels will be considered. If nlevels are not equal, theseindexes will not be compared.3. Index Name does allow duplicate rows (catalog field uniquerule must be = 'D') orinclude colums option was specified.4. Index Name is not a partitioning index 5. Catalog field ibmreqd must be different to 'Y'6. Ordering (ASC, DESC, etc) will be checked. Examples of similar indexes:

- Partial columns list and same ordering:IX1: COL1(ASC), COL2 (ASC)IX2: COL1(ASC), COL2 (ASC) , COL3 (DESC)

- Partial columns list and different ordering:IX1: COL1(ASC), COL2 (ASC)IX2: COL1(DESC), COL2 (DESC) , COL3 (DESC)

7.Include index option will be checked. Example of similar indexes:

IX1: COL1(ASC), INCLUDING (COL2 , COL3)IX2: COL1(ASC), COL2 (ASC), COL3(ASC), COL4 (ASC)

8. If indexes are similars, one of them should be dropped. In the above message, IndexName should be dropped.

More examples of Unnecessary Indexes:1. IX1(DUPLIC): COL1(RANDOM), COL2(ASC)


2. IX1(DUPLIC): COL1(ASC)IX2(UNI/PK): COL1(ASC), COL2(ASC)

3. IX1(DUPLIC): COL1(RANDOM)IX2(UNIQUE): COL1(RANDOM), COL2(ASC)

4. IX1(DUPLIC): COL1(RANDOM)IX2(DUPLIC): COL1(RANDOM), COL2(RANDOM)

5. IX1(DUPLIC): COL1(RANDOM)


550


6. IX1(DUPLIC): COL1(ASC), COL2(ASC)IX2(DUPLIC): COL1(ASC), COL2(ASC), COL3(ASC), COL4(ASC)

7. IX1(UNIQUE): COL1(RANDOM), INCLUDING (COL2)IX2(UNIQUE): COL1(RANDOM), INCLUDING (COL2, COL3)

8. IX1(UNI/PK) : COL1(ASC)IX2(UNIQUE): COL1(ASC), INCLUDING (COL2, COL3, COL4, COL5, COL6)

9. IX1(UNIQUE): COL1(ASC), INCLUDING (COL2)IX2(UNIQUE): COL1(ASC), INCLUDING (COL2, COL3)

HOW REPORT TI01 IDENTIFIES MAYBE DUPLICATED INDEXES

When Batch Report TI01 find two indexes that may be duplicated, the followingmessage will be sent:(Index Name)RIXTI0103-MAYBE IS A DUPLICATED INDEX. RELATED INDEX:(RelatedIndex Name)

The following applies when finding indexes that maybe duplicated:1. Exactly same rules as in HOW REPORT TI01 IDENTIFIES UNNECESSARY (OR SIMILARS)INDEXES, but: Index Name does not allow duplicate rows (catalog field uniquerule mustbe <> 'D').2. If indexes are similars, one of them might be dropped. In the above message, IndexName might be dropped, but this can damage your application data integrity.

Examples of Maybe duplicated Index:

1. IX1(UNIQUE): COL1(RANDOM), COL2(ASC)IX2(DUPLIC): COL1(RANDOM), COL2(ASC), COL3(ASC)

2. IX1(UNIQUE): COL1(ASC), COL2(ASC)IX2(DUPLIC): COL1(ASC), COL2(ASC), COL3(ASC)

3. IX1(PK): COL1(ASC)IX2(UNIQUE): COL1(ASC), COL2(ASC), COL3(ASC), COL4(ASC), COL5(ASC)


551

Appendix E. Limits

This appendix describe TurboTuneSQL product limitations.

Workload Limits

TurboTuneSQL only processes the following DB2 IFCIDs: 3, 239, 58, 59, 60, 61, 62, 63,64, 65, 66 from DB2 DB2 Accounting and Performance Traces.

In terms of SQL statements, TurboTuneSQL only can processes the following types ofcommand types from DB2 traces:

FETCH SELECT INSERT/DELETE/UPDATE OPEN CLOSE PREPARE/EXECUTE DDLs DCLs

Therefore, any other SQL commands not listed here will not be extracted from DB2traces by TurboTuneSQL. Example: VALUES SQL command are not extracted fromDB2 Traces.

There are only 2 exceptions for the above list: SQL commands CALL and SET. ● SQL command CALL and SET are indirectly supported by TurboTuneSQL: they

will be shown in some Reports only if TurboTuneSQL thinks that they could have been executed. TurboTuneSQL tries to discover if they have been executed usingDB2 Accounting trace. So, because DB2 Accounting trace (not Performance trace) was used to discover if these SQLs were executed, CPU, ELAPSED and WAIT time for commands will stored as 0.

The total amount of CPU, WAIT, Elapsed spent for the entire Stored Procedure,Triggers and udf is supported by TurboTuneSQL, but some specific details, as statedbefore, the CPU spent in a SQL CALL is not supported.

DB2 Performance traces normally are turned on and turned off in sampling mode.Some DB2 IFCID records may not be captured when the traces were turned off andTurboTuneSQL will not be able to compute Unique number and CPU values, that areobtainned from subtracting the start and the termination of IFCID values for these SQLcommands in this condition.

Therefore, in order to avoid a wrong computation, if an individual SQL command wasfound in the DB2 Performance traces and exceeds the total amount of DB2 CPUinformed on parameter “CPU MAX LIMIT” or exceeds the total amount of DB2 Elapsedinformed on parameter “ELAPSED MAX LIMIT”, both values will be reset to zeros byTurboTuneSQL. This implementation was made by the CHANGE N0910. If user wants tocollect Performance Traces for specific programs spending CPU or ELAPSED more thaninformed on parameters “CPU MAX LIMIT” or “ELAP MAX LIMIT”, change theseparameters in your “Load DB2 Traces into Tables” option accordingly. (For moredetails, see “Load DB2 Traces into Tables” option).

SQLs Recognized by TurboTuneSQL


552

For several reasons TurboTuneSQL sometimes may not recognize a SQL command.When this happens, this unrecognized SQL command will be flagged in error byTurboTuneSQL (check STIF Report).

There are 2 kinds of SQL recognized by TurboTuneSQL:- SQLs identified by TurboTuneSQL - SQLs extractable

SQLs Identified

TurboTuneSQL only supports some SQL types. If TurboTuneSQL cannot identify a SQLcommand, it will be stored as an unknown SQL command. This is the current list ofSQLs identified by TurboTuneSQL:

CALL ALLOCATE ASSOCIATE ALTER STOGROUP ALTER TABLE ALTER FUNCTION ALTER INDEX ALTER PROCEDURE ALTER TABLESPACE ALTER DATABASE BEGIN_DECLARE CONNECT COMMIT COMMENT CLOSE DECLARE CURSOR DECLARE TABLE DECLARE STATEMENT DECLARE GLOBAL TEMPORARY TABLE DECLARE VARIABLE CREATE JAR CREATE ALIAS CREATE AUXILIARY CREATE TABLE CREATE GLOBAL CREATE INDEX CREATE FUNCTION CREATE TABLESPACE CREATE PROCEDURE CREATE SYNONYM CREATE DATABASE CREATE DISTINCT CREATE STOGROUP CREATE TRIGGER CREATE VIEW CREATE INDEX DESCRIBE DROP JAR DROP ALIAS DROP TABLE DROP INDEX DROP TABLESPACE DROP UDF DROP SYNONYM DROP PROCEDURE DROP DATABASE


553

DROP DISTINCT (or DATA) DROP STOGROUP DROP TRIGGER DROP VIEW DROP PACKAGE (or PROGRAM) DROP TABLESPACE END_DECLARE EXECUTE EXECUTE IMMEDIATE FETCH FREE GET DIAGNOSTICS GRANT HOLD INSERT LABEL LOCK MERGE OPEN PREPARE REFRESH REVOKE RENAME RELEASE ROLLBACK SAVEPOINT SELECT SET CURRENT SQLID SET CURRENT PATH SET (all other will receive same statement type identifier) TRUNCATE UPDATE VALUES WITH WHENEVER

Once a SQL is identified, TurboTuneSQL will check if it is possible to extract it byTurboTuneSQL Extractor feature.

SQLs Extractable

TurboTuneSQL Extractor feature reads SQL texts and tries to break them into smallpieces of information to be stored into the product Repository. It can:

● Create a cross reference of columns used in a SQL● Separates all DB2 function used in a SQL● Separates DB2 predicates and operators● Separates Order by and Group By clauses● Creates the number to be assigned to similar and identical SQLs● Identifies the object name being manipulated in the DDL, DML, DCL● Etc

This feature doesn’t intend to be another DB2 SQL syntax analyzer. Therefore, it doesnot validate all SQL syntaxes and it can not predict if SQLs are valid or not.

If SQL Extractor could not extract a SQL command some reports will show the string asan UNKNOWN object name.

TurboTuneSQL Extractor works only if:


554

● SQL command was found in DB2 Catalog (SYSPACKSTMT or SYSSTMT) or itwas found in other sources, like DBRMLIB data set. For SQLs found in DB2Catalog, it must have:

● SYSPACKAGE.COLLID <> 'NULLID' ● SYSPACKAGE.OPERATIVE = 'Y'

● This TurboTuneSQL version cannot extract SQL text direct from DB2 Triggersand Stored Procedures. Only SQLs found in SYSPACKSTMT or SYSSTMTcatalog tables are supported, except for triggers. Stored Procedures aresupported only SQL commands become a DBRM (precompiled version).

● SQLs command was issued to valid DB2 table (table name must be found inSYSIBM.SYSTABLES)

● SQL is not complicated. TurboTuneSQL cannot understand complex queries. General speaking, TurboTuneSQL can not understand all kinds of SQL syntax.

● SQL does not contain a DB2 UDF/remote location/synonym/complex views/view inside another view, etc.

● SQL belong to the following list: ALTER TABLE CALL CREATE ALIAS CREATE DATABASE CREATE INDEX CREATE STOGROUP CREATE SYNONYM CREATE TABLE CREATE TABLESPACE CREATE VIEW DELETE DECLARE GLOBAL TEMPORARY TABLE DROP ALIAS DROP DATABASE DROP INDEX DROP TABLE DROP TABLESPACE INSERT MERGE (with some restrictions) REFRESH SELECT TRUNCATE UPDATE WITH (with some restrictions)

● DB2 traces say that a dynamic SQL results in a SQLCODE –104.● DB2 column was not found in any referred SQL table in the SELECT

command.

If something goes wrong in the TurboTuneSQL batch processes, SQL statements will beflagged in error by TurboTuneSQL. You can check all errors above STIF Report andchecking MESSAGES data set (check TurboTuneSQL-Messages Guide for moreinformation).

Note: TurboTuneSQL Batch Reports do not have the same behavior as Online Report. If SQL/Extractor could not extract SQL commands, batch reports do not show SQLs.


555

EXPLAIN limits

TurboTuneSQL explain module can not explain all types. Complex SQLs may be not be explained by TurboTuneSQL.Synonym for a table or view may work only few cases. Online Explain function the maximum length is 32k bytes. SQLs DELETE, INSERT and UPDATE with CURRENT OF sintax will not be explanned.

Others General Limitations

TurboTuneSQL ONLY processes SQL statements with a maximum length of 32768bytes, in general. When retrieving dynamic SQL statements from DB2 Performance trace, maximumlength of 5000 bytes.

Unpredictable results can occurs when you start TurboTuneSQL more than once in thesame TSO session.

There are other limits that depend on how much memory and disk storage is available.Please check Appendix TurboTuneSQL Profile Customization for more details. All batchjobs require a minimum of 24MB region size coded on the jobcard.

DDL Generator Utility has several limitations. For more information, check DDLGenerator Utility.

All TurboTuneSQL fields have a maximum length of 31 digits in packed format.Therefore, any information shown by the product will have this restriction.


556

Appendix F. Plan Table Description

Several TurboTuneSQL Reports show the results of DB2 Explain output. The results arestored into TurboTuneSQL Plan Tables (SRC_EXP_FUNC_TB, SRC_EXP_PLAN_TABLE andSRC_EXP_STMT_TABLE). These tables have more fields than IBM Plan Tables.

Here you will find a short description of TurboTuneSQL Plan Tables and IBM Plan Tables.

For more information or complete reference, please refer to IBM DB2 documentation.

SRC_EXP_PLAN_TABLE OR PLAN TABLE )

PROGRAM: Program name

STMT_NUM: Statement number (original)

STMT_NUM_UNIQUE: Statement number (unique)

QUERYNO: This represents a number given to identify the statement being explained.

QBLOCKNO: This represents the position number of the query in the statement being explained.

APPLNAME: This represents the name of the application plan for the row.

PROGNAME: This represents the name of the program or package that this statement being explained belongs to.

TBTYPE: Values are for internal use only.

PLANNO: This represents the number of the step in which the query indicated in QBLOCKNO was processed.

CREATOR: This is the creator of the new table which was accessed in this step.For METHOD 3 this field is blank

TNAME: This is the name of the table:CreatedDeclared temporary tableMaterialized viewMaterialized expression

SEQUENTIAL: Values are for internal use only.

TABNO: Values are for internal use only.

ACCESSCREATOR: When ACCESSTYPE is equal to I, I1, N, MX or DX, this represents the creator of the index; Blank for other ACCESSTYPEs.

ACCESSNAME: When ACCESSTYPE is equal to I, I1, N, DX or MX, this represents the name of the index; Blank for other ACCESSTYPEs.

METHOD: This number represents the join method used for the step:Values:


557

0 First table accessed1 Nested loop join. 2 Merge scan join. 3 Sorts needed.4 Hybrid join.

ACCESSTYPE: This field represents the method of Accessing type:Accessed by:I Index AcessI1 Index Scan, one-fetchN Index Scan, only when the matching predicate has the IN keywordR Table Space scanM Multiple index scan (check MX,MI,MU)MX Index scanMI Intersection of multiple indexesMU Union of multiple indexesT - Space Index (star join works file).DI - Intersection of DOCID DU - Union of DOCID DX - XML Index Scan E - Direct row access P - Dynamic pair-wise ix scan RW - Work file scan MQT V - By Buffer INSERT within SELECT blank- Not applicable.

MATCHCOLS: This represents the number of index keys in an INDEX SCAN for the following ACCESSTYPEs: I, I1, N, DX, or MX. INDEXONLY: When access to an index alone is enough to satisfy the request for thestep (or the data must be accessed too).

Values: Y=YES N=NO

SORTN_U: When new table is sorted to have duplicate rows removedY=Yes; N=No.

SORTN_JOIN: For join METHOD 2 or 4 when new table is sortedY=Yes; N=No.

SORTN_ORDERBY: For ORDER BY when new table is sorted Y=Yes; N=No.

SORTN_GBY: For GROUP BY when new table is sortedY=Yes; N=No.

SORTC_U: To remove duplicate rows when the composite table is sorted.Y=Yes; N=No.

SORTC_JOIN: For join method 1,2 or 4, when the composite table is sorted.Y=Yes; N=No.

SORTC_ORDERBY: For an ORDER BY when the composite table is sorted (or a quantified predicate).

Y=Yes; N=No.

SORTC_GBY: For a GROUP BY clause when the composite table is sorted.


558

Y=Yes; N=No.

TSLOCKM: This is the indication of the mode of lock. Values: IS Intent share lock IX Intent exclusive lock S Share lock U Update lock X Exclusive lock SIX Share with intent exclusive lock N UR isolation; no lock

PREFETCH: When data pages are to be read in advance by prefetch.Values:S - Pure sequential.L - through a page list.

D – Dynamic prefetchblank - Unknown or no prefetch at all.

COL_FN_EVA: This represents the evaluation for a SQL column function.Values:R = during the time the data is being read from the table or index;S = during the time it is performing a sort to satisfy a GROUP BY c

clause;blank = after any type of sort and after data retrieval.

QBLOCK_TYP: This represents the type of SQL operation for each query block

MIXOPSQ: In a multiple index operation this represents the number of the sequenceof the step.

ACCESS_PID: This represents an identifier of the parallel group when accessing the new table.

ACCESS_DEGREE: This represents the number of operations activated by a query orthe parallel tasks.

COLLID_EXPL: This represents the DB2 COLLECTION ID for the package.

JOIN_DG: For the new table this represents the number of tasks used in joining composite table or the number of parallel operations.

JOIN_PGRP_ID: For the new table this represents the identifier of the parallel group for joining the composite table.

SORTC_PGRP_ID: This represents the parallel group identifier for the parallel sort ofthe composite table.

SORTN_PGID: For the new table this represents the parallel group identifier for the parallel sort.PARAL_M: This represents the type of parallelism:

Values: I Query I/O parallelism C Query CP parallelism X Sysplex query parallelism

MERGE_JOIN_C: This represents (for METHOD 2) the number of columns which are joined during a merge scan join.


559

PAGE_RANGE: This field indicates whether the table qualifies for page range scanning.

Values:Y = Yesblank = No.

CORRELATION: For the statement being explained, this represents the correlation name of a table or view.

JOIN_TP: This represents the type of join operation:Values:L LEFT OUTER JOINF FULL OUTER JOINS STAR JOINBlank INNER JOIN or no join

GROUP_MEMBER: This represents the member name of the DB2 which executed EXPLAIN.

WHEN_OPTIMIZE: This represents the access path when it was determined:Values: B, R or Blank

PARENT_QBLOCKNO: This represents the number of the QBLOCKNO of the parent query block.

TABLE_TYPE: This represents the type of new table:Values:T TableW Work file F Table function Q Temporary intermediate result table (not materialized)

OPTHINT: This represents a string used for identification of this row as an optimization hint for DB2.

HINT_USED: This represents an identifier that DB2 puts when it chooses one of youroptimization hints.

PRIM_ACCESSTYPE: This represents whether DB2 will attempt first to use a direct row access.

Values:D DB2 will try to use direct row access. blank DB2 will not try to use direct row access.

BIND_TM: This represents the bind time which the package or plan for this statement or query block.

TIMESTAMP: Normally, this represents the time at which the row is processed.

SRC_EXP_STMT OR DSN_STATEMNT_TABLE

PROGRAM: Program name

STMT_NUM: Statement number (original)

STMT_NUM_UNIQUE: Statement number (unique)

QUERYNO: This represents a number given to identify the statement being explained.


560

STMT_TYPE: The type of statement being explained.

APPLNAME: This represents the name of the application plan for the row.

PROGNAME: This is the name of the program or package that this statement being explained belongs to.

SEQUENTIAL: Values are for internal use only.

FLAG_CAST: Indicates type of cast.Values:Y - Original FormatN - No Mismatches.C – Copy from Plan Table

TBTYPE: Values are for internal use only.

COLLID_EXPLAIN: Values are for internal use only.

PROCMS: The estimated processor cost, in milliseconds, for the SQL statement.

PROCSU: The estimated processor cost, in service units, for the SQL statement.

GROUP_MEMBER: This represents the member name of the DB2 which executed EXPLAIN.

COST_CATEGORY: This represents the indication if DB2 was forced to use default values when making its estimates. Values:

A DB2 did not use default values to make a cost estimateB DB2 used default values due to existing conditions.


561

Appendix G. JCL Description

JCL Description Several TurboTuneSQL functions result in JCL generation. The following screen is just asample and may vary depending on function being used.


562


563

------------------------------ Create Jobs ------------------------------------Option ===> HIT "ENTER" WHEN READY More: + Create Jobs Profile : IVP DB2 SSID : DB9G Inform PDS to receive JCLs: PLEASE.PUT.A.PDS.NAME.HERE

JOB Cards: (Recommended region size is 24M or 0M) //JSADV01A JOB 'IVP-TEST',MSGCLASS=A,CLASS=D,NOTIFY=&SYSUID, // REGION=0M //* //* //* Generate all JCLs in one single job: N Y/N. If Y was choosen, PDS member name: increase region size OR Execute several JCLs: J000ILOG J000INIT J700EXPL

HLQ work files: T.WORK.IVPV9 Prefix work data sets F1=Help F2=Split F3=Exit F4=LSTREQ F5=FILTER F6=SAVE F7=Up F8=Down F9=Swap Nex F10=Left F11=Right F12=Quit

Here is a short explanation of all JCL generated by TurboTuneSQL (using default name),ordered by member name.

Note: TurboTuneSQL always uses NOCOPYPEND as a parameter in Load Utility. Forrecovery purposes, you must always backup all TurboTuneSQL tables before executingany TurboTuneSQL batch process.

Member Description Type

----------- ---------------------------------------------------- --------------J000ILOG Creates Log data sets General Use

(ddnames MESSAGES and TOTALS)

J000INIT Initialize temporary data sets General Use

J000TCDT Start DB2 Traces Utility

J100CACE Load DB2 Traces (from CACHE) Load data

J100GTFE Load DB2 Traces (from GTF and CACHE) Load data

J100SMFE Load DB2 Traces (from SMF and CACHE) Load data

J100SGFE Load DB2 Traces (from SMF/GTF and CACHE) Load data

J150CSPK Copy SQLs from another DB2 Utility

J200DBRM Load SQLs from the DBRMLIB Load data

J200SPKS Load SQLs from DB2 Catalog Load data

J200STXT Load SQLs from sequential data set Load data

J300STMT Load DB2 traces Load data

J400OBJS Prepare to Load DB2 table Definition Load data

J500HIST Load DB2 table Definition Load data

J600SRCE Load SQLs and others information Load data

J700COPY Copy/Backup Explain Data Utility

J700EXPL Executes massive Explain Utility

J900IXAD Generate sequential data set with SQLs Utility

J900REPW Run TurboTuneSQL Batch Reports Report

J910GDDL Generate DDL syntax Utility

J918**** Copy Utilities Utility

J930GSTA Copy DB2 Table Statistics Utility

J940DSTB Create SQL Cross Reference Utility

J970IXAD Index Recommendation (all jobs) Utility


564

J970FREQ Index Recommendation Utility

J970IXRE Index Recommendation - create actions Utility

J990CLRN Clear TurboTuneSQL Repository Utility

J991UHIS Update TurboTuneSQL Repository (Tables Definition) Utility

J960SRMC Compare Plan Tables Utility

Restart Points

TurboTuneSQL has implemented JCL Restart Points. This allows you to restart batchjobs when needed.

To restart a batch job you must immediately execute the JCL step before the prior onehas stopped with the following comment out: '//* JCL RESTART POINT'.

Don't forget that TurboTuneSQL always generates JCL with option DB2 LOAD optionLOG NO, RESUME and NOCOPYPEND. Therefore, in some case you will need to executeDB2 RECOVER utility.


565

Appendix H. TurboTuneSQL CHANGES

TurboTuneSQL CHANGE is a set of software corrections (Fix) available to modify productlibraries, like panels, skeletons, modules, etc.


566

Appendix I. Numerical and Time formats.

This appendix describe TurboTuneSQL Numerical and Time formats used byTurboTuneSQL Products.

TurboTuneSQL Numerical Formats Numeric fields are show using this one of this format:

● 999,999,999 (Decimal Format) ● 999,999 MB (MegaByte Format) ● 999,999 GB (GigaByte Format)

TurboTuneSQL Time Formats

Fields like CPU, Elapsed and Wait time are show using this one of this format:

● hhhhhh:mm:ss.ttt (Normal Format) ● h:mm:ss.tttttt (Average Format)● hhhhhh:mm:ss.tttttt (Full Format)


567

Appendix J. TIPs

DROPPING AN INDEX

Before executing drop command, you may take the following actions:

–Check if all dynamic SQLs was captured by TurboTuneSQL and Explain utility wasproperly executed.

–If RTS is up and running, check last used date (SYSINDEXSPACESTATS.LASTUSED).Updates occurs once in a 24 hours period and updated once in a 24 hour period.

–RTS service task updates at 1st externalization interval (set by STATSINT) after 12PM.

–if the index is used by DB2, update occurs. If the index was not used, no update.

–Maintain your DB2 up-to-date with the most current APARs.–LASTUSED field from SYSINDEXSPACESTATS is checked automatically (DB2 V10and UP) and showned on online REPORT TI00 and batch REPORTs TI00 and HI00.

–Check if this index is the CLUSTER index (explicity or implicity).

Also, if you are dropping an index because there is an identical or similar index, beaware that indexes with small number of columns may have less getpages whencompared to bigger indexes.


568

Appendix K. How to apply fixes to TurboTuneSQL

TurboTuneSQL CHANGE is a set of software corrections (Fix) available to modify productlibraries, like panels, skeletons, modules, etc.

The TurboTuneSQL CHANGE has the following name conventions:YMMNN, where:– Y: Letter indicating the year. i.e.: I=2008, J=2009, and so on

Also, letter indicates if this is a Permanently or a Temporary Change– MM: Sequential number. Normally it will contain a 2 digits for the month when it

was originally created. Examples: 03 (March), 06 (June)– NN: Sequential number.

We strongly recommend you to apply corrections at least each 6 months to maintainyour product up to date.

What is a TurboTuneSQL FIX?Every TurboTuneSQL CHANGE is composed by several unique corrections.TurboTuneSQL FIX is the name of each correction.

Each FIX has a short description of the problem being fixed. A FIX may need one ormore actions. Examples of Actions:– Rebind a package– Re-create a JCL– Create a new DB2 Index– Etc

Each FIX in a CHANGE uses the following name convention: FIXNN, where:– NN: Sequential number. This is just a sequential number to create an unique

identifier for each FIX inside a CHANGE

You can only order TurboTuneSQL CHANGES to your local representative. You cannotask for a specific FIXes.

What is a TEMPORARY CHANGE?TEMPORARY CHANGES is a temporary correction to fix a high severity problem.

A TEMPORARY FIX is always made in pairs. When a temporary change is created, aPERMANENT will be created at same time with same MMNN (Sequential number, aspreviously explained.

The follow standard will be used:

YEAR PERMANENT CHANGES TEMPORARY CHANGE2008 IMMNN * exception (not available)2009 JMMNN KMMNN2010 LMMNN MMMNN2011 NMMNN OMMNN2012 PMMNN QMMNN2013 RMMNN SMMNN2014 TMMNN UMMNN2019 VMMNN XMMNN


569

How to apply CHANGES

CHANGEs are normally sent by e-mail or CD. It could be a compressed file (in zipformat) and it will contain the following files:

● README.txt– Contain a short description of steps below as well CHANGE descriptions and

their required Actions● ALLOC.TXT

– Contain a sample JCL to allocate a XMIT data set before uploadingTurboTuneSQL CHANGE

– Note: Libraries using IBM XMIT must always use the following DCB: LRECL=80,BLKSIZE=3120,RECFM=FB

● ADVCHG.XMIT– These are the mainframe libraries in XMIT format. You must upload them

using binary mode to previous created data set (alloc.txt).● RECEIVE.TXT

– Contain a sample JCL to receive previous uploaded data set.

Please, read instruction inside README.TXT to check required Actions (BIND, DDLs, JCLgeneration, etc).

CHANGEs must ALWAYS be applied in sequential mode.

Example:– If you have CHANGEs: I0410, I0305, I0310 to be applied, you must apply this

changes in the following order you must apply using this sequence: I0305, I0310and I0410.

Very important: ALWAYS backup your TurboTuneSQL product libraries and producttables before applying any TurboTuneSQL CHANGE.

How to check which CHANGES are appliedUse Online command INFO.


570

Appendix L. TurboTuneSQL PASSWORD SETUP

In order to set up a new password for TurboTuneSQL products, CPU ID serial numbermust be send to your TurboTuneSQL local representative.

After you send the CPU ID, TurboTuneSQL license module will be sent to be applied toyour TurboTuneSQL product.

Send CPU ID serial number

You will have to send the machine CPU ID to your local representative.

The preferable method to get this information is the result of the “D M=CPU” MVSoperator command.

Example: D M=CPU

RESPONSE=MVSA IEE174I 22.10.58 DISPLAY M 909 PROCESSOR STATUS ID CPU SERIAL 0 + 09FFDD2064 1 - 2 - 3 - 4 - 5 - 6 - 7 -

Receive TurboTuneSQL license module (password key module)

After sending the CPU ID serial number, you will receive the TurboTuneSQL licensemodule (PWD.XMIT). This module is distributed using the IBM XMIT format.

Create XMIT data set

So, before you upload it to the mainframe, you must allocate a data set to receive it.Use the following JCL to allocate a data set before sending to Mainframe:

// JOBCARD//* //********************************************************* //* //* SAMPLE JCL TO ALLOCATE A XMIT DATA SET//* //* //* //* PLEASE, CHANGE:


571

//* //* <NEWTEMPHLQ> TO Temporary HLQ//* <UNIT> TO Temporary unit //* <TEMPORARY_DISK_VOLUME> TO Temporary Disk Volume//* //* //********************************************************* //* //STEP01 EXEC PGM=IEFBR14//DD1 DD DSN=<NEWTEMPHLQ>.LINKLIBP, // DISP=(NEW,CATLG),VOL=SER=<TEMPORARY_DISK_VOLUME>, // UNIT=<UNIT>,LRECL=80,BLKSIZE=3120,RECFM=FB,DSORG=PS,// SPACE=(CYL,(00001,1))

Upload to Mainframe Now, you can use FTP (or another communication software) to transfer theTurboTuneSQL license module (PWD.XMIT) to the above data set. Use binary transfermode.

Execute TSO RECEIVE command

Use the following JCL to receive the XMIT data set (you must receive it into yourTurboTuneSQL linklib data set):

// JOBCARD//* //********************************************************* //* //* JCL TO RECEIVE TurboTuneSQL PASSWORD //* //* NOTE : //* SUBSTITUTE <HLQSADV> TO TurboTuneSQL HLQ //* SUBSTITUTE <NEWTEMPHLQ> TO HLQ of PREVIOUS UPLOAD DATA SET //* //********************************************************* //* //********************************************************* //* //* RECEIVE PASSWORD XMIT DATA SET//* AND STORE INTO YOUR LINKLIB //* //********************************************************* //STEP2 EXEC PGM=IKJEFT01 //SYSLIST DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSLIST DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSTSIN DD * RECEIVE + INDSNAME('<NEWTEMPHLQ>.LINKLIBP') DATASET('<HLQSADV>.LINKLIB')


572

Appendix M. TurboTuneSQL Common Online Commands

INFOShows applied product FIXES (Changes) and some other general information.

FIELD DESCRIPTION

ReleaseCurrent product release (VnRn).

Profile data set This is the data set where profiles are stored. It must be LRECL=80. Profile This is the current active profile. DB2 SSID This is the DB2 SSID you are current connected.

Current Location DB2 Location, automatically obtained from connected DB2. Plan Name This is the Plan Name you are current connected. Customer Name This is the Customer Name. This name is taken from product password license. DB2 Version This is the DB2 Version specified in the current active profile.

Message data set This is the Message data set used by the current active profile.


573

TurboTuneSQL V120 ------------------- General information --------------- 07:44 Option ===> General Information Profile data set: TTUNESQL.PROFILE.DBBG Profile : DBBG DB2 SSID : DBBG NFM=Y Current Location: DALLASB Plan Name : PLANSADV Customer Name : CRITICAL PATH SOFTWARE 209702 DB2 Version: VB(1110**) Message data set: TWORK11.MESSAGES Qualifier : SADVQUAL Current Target : DEVQ.V900 Last Permanent Change: New Target : Last Temporary Change: ----- / X0560 ---------- Change Library (DEVQ.V900.INSTJOB )----------------- Changes ------- ******************************* Bottom of data ********************************

QualifierQualifier of product tables.

Current TargetThis is the target HLQ where TurboTuneSQL was installed. Last Permanent ChangeIndicates the last permanent TurboTuneSQL CHANGE applied according to field Change Library New Target Here you can change HLQ to check CHANGEs applied in a different TurboTuneSQL installation.

Last Temporary ChangeIndicates the last temporary TurboTuneSQL CHANGE applied according to field ChangeLibrary

Change LibraryThis data set tracks TurboTuneSQL CHANGE. The data set name is composed by<CurrentTarget>.instjob or <NewTarget.instjob> if New Target was parameter wasinformed.

ChangesList of all applied TurboTuneSQL CHANGES according to Change Library.


574


575

JCLThis command will show “Create JCL” panel to inform PDS data set to create JCL for aspecific function.

The following screen will be displayed:

Note: – For most panels, PF5 will activate the same function.– TurboTuneSQL products has implemented JCL Restart Points. So, if you receive a condition code not equal 0 or 4, you can restart the job using restart point indicated inside the job.– Attention: JCL is only allowed when TurboTuneSQL profile is in Edit Mode {E}.


576

------------------------------------- Create Jobs ----------------------- 07:48 Option ===> HIT "ENTER" WHEN READY Create Jobs Profile : DBBG DB2 SSID : DBBG Inform PDS to receive JCLs: TTUNESQL.JCL Inform PDS member for JCLs: (01) J000ILOG (06) J300STMT (02) J010RPLG (07) J400OBJS (03) J020INIT (08) J600SRCE (04) J100SMFE (09) J700EXPL (05) J200DBRM HLQ work files: TWORK Unit Names Work Datasets : UNIT=SYSDA Example: UNIT=SYSDA Sort Datasets : UNIT=SYSDA Volumes Work Datasets : Example: VOL=SER=(VVVVV1,VVVVV2), Sort Datasets : SMS DATACLAS WK: SMS STORCLAS WK: SMS DATACLAS ST: SMS STORCLAS ST: Delete Parms: Keep/Delete Individual Work Files at each step run: DISP=(OLD,DELETE) To delete work files use: DISP=(OLD,DELETE) To keep work file use: DISP=(OLD,KEEP) JOB Cards: (Recommended region size is 24M or 0M) //JREPO1 JOB 'NEW',MSGCLASS=A,CLASS=D,NOTIFY=IBMUSER, // REGION=0M //*

FIELD DESCRIPTIONS

Inform PDS To Receive JCL Enter a data set to receive all JCL members.User should have authority to update the PDS. See online command SECON/ SECOFF fordetails on how to turn on/off security.

JOB Cards Enter JOB Cards to be used in this run If you change this parameter, JCL needs to be re-created.

HLQ work files Data set High Level Qualifier for work, log and sort files.

Generate all JCL in one single job This parameter is optional (for TurboTuneSQL-VIRT, always use option N). If you choose Y, all JCL will be generated in one single job and for that, you need toinform the "PDS member name". If you intend to use this option, most of the time youwill need to increase the JCL region size to 24 or 32MB to avoid the JES Initiator Error(lack of memory).If you choose N, leave this parameter blank in the "PDS member name" field.

The following JCL will be Created (or Execute several JCL)Here you get all JCL that need to be submitted to attend your request. You may change each PDS member name by over typing it with new names but youcan not remove them. IMPORTANT: Please, submit these jobs in the same order as they are displayed.

SAVEAll active configurations are saved into current TurboTuneSQL Profile. Attention: SAVEis only allowed when profile is in Edit Mode {E}.

SECONTurn on security check for resources (data set update only). TurboTuneSQL will first check if the user is authorized to update/read any resource. Thesecurity will be turned on the next time the user starts a new session.

SECOFFTurn off security check for resources (data set update only). TurboTuneSQL will never check if the user is authorized to update/read any resource.For example, If the user turns off security while generating a JCL, a system abend S913my occur and TurboTuneSQL session may be terminated abnormally. The security willbe turned off the next time the user starts a new session.

SETUPShows “Product profile” panel.

TurboTuneSQL Profile controls all functions of TurboTuneSQL products. It containsparameters used by all TurboTuneSQL process (batch and online programs).TurboTuneSQL Profiles are members stored into PDS data sets. Another way to setup a Profile: at main screen choose option “Product profile”.


577


578

Contact

If you have any doubts or comments, please contact your local representative.


579