SQL COMMAND ANALYSIS User's Guide

1,110 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,110
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
70
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SQL COMMAND ANALYSIS User's Guide

  1. 1. SQL COMMAND ANALYSIS User's Guide © Copyright Software Product Research 2000 All other product names, mentioned in this manual, are trademarks owned by International Business Machines Corporation, Armonk, NY.
  2. 2. 1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Statement extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 SQL EXPLAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.1 Statement text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.2 Statement Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2.3 Statement Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.4 Statement Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.5 Statement Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.6 Explain Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Text analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Object lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5 Object notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6 Analysis summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.7 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.2 SQL/CA help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.3 Explain tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.7.4 DB2 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.8 SQL/CA - SQL/MF integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.9 DB2 data modelling facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 SQL/CA Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1 Software Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Pre-installation tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Prepare a VSE library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.2 Update LIBDEF and Standard Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3 Prepare the SQL/CA Report Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Installing SQL/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.3.1 Preliminary Note ................................................... 12 2.3.2 Issue SETPARM for SPRLIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3 Upload the SQL/CA software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.4 Link SQL/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5 Upload the SQLCA OPTIONS file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.6 Define the SQL/CA Report Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.7 Define the SQL/CA components to CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.8 Update the CICS FCT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.9 Install SQL/CA in a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.10 Update the VSE startup stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.3.11 Update the VSE standard labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.12 Upload the SQLCASRV startup sample job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3 Using SQL/CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1 Using the SQL/CA interactive menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Analyze a VSE library member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3 Analyze an ICCF library member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4 Analyze a VOLLIE library member . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5 Analyze a DB2 package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 Analyze a QMF query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.7 Analyze an ISQL query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.8 Analyze an interactive query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.9 SQL/CA Librarian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.9.1 Searching the SQL/CA Report Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.9.2 Processing the Report selection list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.9.3 Processing the analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.9.4 Displaying the SQL/CA Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.10 Invoking SQL/CA from a batch job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 The SQL/CA Server
  3. 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1 Starting the SQL/CA server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.2 Stopping the SQL/CA server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 5 Interpreting the analysis report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.1 Statement Execution Structure by block and parent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.2 Structure of Referential Constraint Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5.3 Statement Cost Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.4 Statement Plan Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.5 Statement Execution Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.6 Statement Execution Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.6.1 Plan Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.6.2 Column Reference Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.7 Predicate Analysis Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6 SQL/CA data modelling facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7 SQL/CA Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8 SQL/CA analysis warning messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9 SQL/CA object notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 10 Predicate evaluation tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.1 Datatype evaluation table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.2 Decimal precision evaluation table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 10.3 Predicate operator evaluation table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 10.4 Default filter factor table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 11 SQL/CA messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 12 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
  4. 4. SQL Command Analysis Page 1 1 Functional description SQL Command Analysis (‘SQL/CA’) is a software tool for DB2/VSE (previously known as SQL/DS). Its primary purpose is to assist SQL programmers in producing efficient and well performing SQL applications, by providing analysis services during program development. SQL/CA encourages SQL developers to systematically analyze their applications in view of optimal SQL coding. This approach will detect poorly designed SQL at an early stage and prevent many performance problems, that otherwise would appear only when the program is moved into production. SQL/CA examines the source text of the program, and therefore is able to signal SQL performance deviations that cannot be detected by means of the traditional DB2 tuning procedures. SQL/CA presents its findings in the form of an analysis report. The report is easy to read: it does not require a highly technical background to be understood. SQL/CA operates in the DB2/VSE environment and is capable of analysing: - Assembler, Cobol, Fortran or PL/1 source programs, residing in a VSE, an ICCF or a VOLLIE library - ISQL routines and QMF procedures - Files containing SQL statements in DB2 Database Services format - Designated DB2 packages in the currently connected database Except when analyzing DB2 packages, SQL/CA operates on the text of the source program. DB2 packages are not referenced during statement analysis: application programs need not to be prepped in order to be analyzed. However, the SQL statements must have correct syntax and the DB2 objects (tables etc.) used by the application, must exist in the database connected during analysis.
  5. 5. Page 2 SQL Command Analysis When analyzing a program, SQL/CA extracts the SQL statements, invokes DB2 EXPLAIN and performs text analysis. 1.1 Statement extraction All SQL statements that can be explained and the related host variable specifications are extracted from the program source text or from the unloaded DB2 package. SQL statements that can be explained are: SELECT, INSERT, UPDATE, DELETE and DECLARE CURSOR FOR SELECT | INSERT. 1.2 SQL EXPLAIN The SQL EXPLAIN statement is issued for all the extracted SQL statements and the resulting SQL explain table data are converted from their encoded and numeric format into a textual and easily readable analysis report. This report is stored in the SQL/CA Report Library with a 2-part reportname (creator | packagename for packages filename | filetype for sources in a library). The analysis library is processed online, using the SQL/CA Librarian which runs as a CICS transaction. For each SQL statement, the analysis report provides following data obtained from the SQL Explain tables: 1.2.1 Statement text Prints the SQL statement in a manner that reflects the logical execution tree structure. If the statement contains subqueries, they are formatted by statement block and calling block. The indention level used when printing a given subquery, corresponds to the nesting level of the query within the logical execution tree. 1.2.2 Statement Cost Reports the cost of statement execution, as estimated by DB2. If the statement consists of multiple queries, a number of calculations are carried out in the Cost paragraph, in order to show the cost associated with each subquery, taking into account its execution characteristics within the logical execution tree. SQL/CA will also indicate the subquery with the highest cost.
  6. 6. SQL Command Analysis Page 3 1.2.3 Statement Structure Reports: - from which query block a dependent block is called, if the statement contains embedded queries - the estimated number of rows processed - the estimated number of execution iterations If the statement consists of multiple queries, the Structure paragraph will compute the projected execution properties of each subquery, taking into account the execution properties of all its logical predecessors within the execution tree. 1.2.4 Statement Plans Reports: - whether the statement is executed - by DBspace scan - by index-only scan - by fully-qualified index scan - by selective or non-selective index scan - by view materialization - the name of the plan index, if any - the number of matching index-key columns - the join method if the statement implies joining - the number of rows in the inner and outer join table - whether sort operations will be performed If the statement is executed by DBspace scan, the Plan paragraph will compute the DBspace scan productivity as the estimated percentage of table data accessed during the relational scan. If indexed access is used, the column definitions of the index and its characteristics (first or not, clustered or not, unique or not) are shown. 1.2.5 Statement Reference Reports: - the column names appearing in the WHERE or UPDATE SET clauses - the selectivity (filter factor) of those columns - the columns appearing in a sargable predicate - the columns used during a join - the columns used for ORDER or GROUP BY - the columns updated by the statement The Reference paragraph shows the explain column numbers as names. If a view is being explained, the base table name and column names from explain are related to the corresponding viewname and view column names, as used in the application.
  7. 7. Page 4 SQL Command Analysis 1.2.6 Explain Warnings In addition, an SQL statement will be flagged with the warning character > and a warning message code: - if it is executed by DBspace scan - if it is executed by a non-selective index scan - if data pages must be accessed to resolve the predicate conditions - if no indexes exist for the table - if no highly clustered indexes or unique indexes exist for the table - if view materialization occurs - if all rows of the table are being accessed - if a subquery is executed at each invocation of its parent block - if the outer join table is larger than the inner join table A severity code 1, 2 or 3 is associated with each of the warnings and printed as 1, 2 or 3 > signs. The highest severity code 3 is assigned to conditions that are assumed to increase database I/O during statement execution. Note If the statement contains view references, SQL EXPLAIN operates using the underlying real tables. Therefore, SQL/CA expands such statements by inserting the view definition(s) until the resulting statement contains real table references only. The original and the expanded statements are printed and the expanded statement is used for SQL/CA text analysis.1 1 If the original statement is a SELECT *, the * is not expanded, due to the maximal statement length restrictions.
  8. 8. SQL Command Analysis Page 5 1.3 Text analysis SQL/CA text analysis examines the application program for adherence to the SQL coding and performance rules described in the IBM "performance tuning" manual and detects statement specifications that lead to suboptimal performance. Text analysis will specifically warn the following performance exposures: - Indexing columns are being updated by the statement. - Table indexes do exist, but the statement predicate does not contain index column references. - Table indexes do exist, but the statement predicate contains incomplete index column references, that is, one or more indexing columns are not specified for the plan index (the index that is effectively used during execution). - The predicate uses indexing columns in expressions such as "BALANCE*2 > 1000". This may disqualify index use. - The datatype compatibility rules are violated in a combination of two syntactical elements. For example: the datatype of a host variable is not compatible with the datatype of the corresponding table column. See “Datatype evaluation table” on page 85. Moreover, when the column is DECIMAL and the host variable DECIMAL, INTEGER or SMALLINT, the scale compatibility rules must be observed, as described on page 85. - The data length compatibility rules are being violated for non-decimal columns. The lengths of the syntactical elements A and B are considered compatible when length(A) >= length(B), except for VARCHAR columns with length < 254 and VARGRAPHIC columns with length < 127, which are compatible with all character values, fixed or variable of any length. - The data precision compatibility rules are being violated for decimal columns. The precisions of the decimal elements A and B are considered compatible when precision(A) >= precision(B). - The data scale compatibility rules are being violated for decimal columns. The scales of the decimal elements A and B are considered compatible when scale(A) = scale(B) when B is not a constant. When B is a constant the compatibility rule is scale(A) >= scale(B). - SQL predicate operators used in the statement are no index keymatching candidates, that means, the key values cannot be used to directly fetch an index entry. For instance: an = operator is key-matching, a ^= operator is not. For a complete list of index keymatching operators, see the table on page 86. - The statement predicate specifications are not "sargable", that is, they cause the predicate to be evaluated by RDS (the DB2 Relational Data System) and not by DBSS (the DB2 Database Subsystem). This involves additional CPU time consumption. A number of statement operators is not sargable. For a list of them, see the table on page 86. - The predicate is not sargable because an indicator variable is used with a host variable in an EQUALS predicate for a column that does not permit nulls.
  9. 9. Page 6 SQL Command Analysis - The left and right hand expressions of the predicate refer to columns of the same table (T1.COL1=T1.COL2). Such predicates are not sargable and not keymatching. - The statement contains suboptimal SQL verbs such as "OR" or "NOT". - The entire statement predicate has become non-sargable, due to a non-sargable predicate connected by OR. - The default filter factor is used for range operators (such as > , LIKE or BETWEEN) because the predicate contains host variables. Due to the default selectivity rules applied by the DB2 optimizer, such specifications may lead to index disqualification. The default filter factor used for the predicate is shown: it depends on both the range operator type and the number of distinct column values. For more information, see the table on page 87. - Range predicates such as >, >=, <, <= are used. These are less selective than BETWEEN. - A predicates uses indicator variables. Such predicates are neither key-matching or sargable. - A join predicate violates the datatype and data length rules. Contrarily to normal predicates (which must be compatible), join predicates require that the datatypes, lengths, precisions and scales of the join columns be identical. - A join statement omits necessary search conditions. If, in addition to the join predicate, the statement states more "local" predicates, the latter should normally be stated for both join columns. The DB2 optimizer will automatically add a missing "local" condition, but this will be done only for an equijoin and when the local condition is sargable. Many of the above conditions disqualify selective index use, that is, DB2 may decide to read the entire table, using either an index scan or a DBspace scan (in the latter case, all tables in the DBspace are scanned). For each of the above conditions, a specific warning message is inserted in the report. These warning message can be searched by code in the SQL/CA Glossary, while examining the analysis report on the screen. The Glossary describes the detected performance exposure in full detail and suggests corrective action. It contains a number of tables that illustrate the rules followed by DB2 in evaluating the statement predicate. The Glossary can be found on page 43 of this publication. A severity code is associated with each warning issued, to indicate its importance. For warnings involving predicate columns, a distinction is made between indexing and non-indexing columns. Since a performance exposure concerning an indexing column will have a more considerable performance impact, a severity 3 code is signalled. For a non-indexing column, a severity code 1 is associated with the warning.
  10. 10. SQL Command Analysis Page 7 1.4 Object lists Following the analysis report, lists are produced to describe the physical characteristics of the tables, table columns and indexes used by the program. These characteristics and statistical data are taken from the DB2 catalogs. If no statistics are available for a table (no UPDATE STATISTICS statement executed), the corresponding statistic values are unknown and displayed as ? (a question mark). The table section shows for each table accessed by the application: - the name of the table's DBspace - the average rowlength - the number of table rows - the effective number of rows per DBspace page, taking into account the effective freespace class - the number of table pages - the percentage of DBspace pages occupied by the table - the number of dependent and parent tables in a referential integrity environment The index section shows for all indexes defined on all tables in the table section: - the "clustered" attribute - the clustering ratio - the "first" attribute - the "unique" attribute - the first key count - the full key count - the number of leaf pages in the index - the number of levels in the index The index column section shows for all columns of all indexes appearing in the index section: - the percentage of distinct column values - the first eight bytes of the second lowest value in the column. - the first eight bytes of the second highest value in the column. - the value of the column at the 10th percentile2 - the value of the column at the 50th percentile - the value of the column at the 90th percentile - the most frequent column value and its percent frequency - the second most frequent column value and its percent frequency 2 If a table has N rows and all N values of the column are arranged in ascending order, the value shown is at position 0.1*N (for the 10th percentile), 0.5*N (for the 50th percentile) or 0.9*N (for the 90th percentile).
  11. 11. Page 8 SQL Command Analysis 1.5 Object notes SQL/CA analyses each DBspace, table or index used by the application and (if applicable) issues following notes at the end of the analysis report: - the freespace in a DBspace may not be used during insert activity - a small DBspace does not have the "row" locklevel - the DBspace is located in the same storage pool as the DB2 catalogs - a table has more than 10% overflow rows - a small table has indexes other than those required for referential integrity or primary keys (small tables are best processed by DBspace scan) - VARCHAR or VARGRAPHIC columns are part of an index definition: such indexes will never be used for an index-only scan - the first column of a composite index is not the most selective one 1.6 Analysis summary At the end of the report, a summary is printed that shows the highest SQL cost value encountered in the program, the number of DBspace and index scans and the number of SQL/CA warnings, by warning severity.
  12. 12. SQL Command Analysis Page 9 1.7 Operation 1.7.1 User interface SQL/CA analysis requests are usually issued from the CICS transaction $CAM. However, the analysis request can also be issued from a batch partition (e.g. a compile procedure), as described on page 25 Analysis itself is performed in a batch partition by the SQL/CA Analysis Server. The analysis reports must be examined online, using the$CAM transaction. After submitting an analysis request, the user has the option of waiting interactively on the analysis report. 1.7.2 SQL/CA help Online help is provided at all levels of the SQL/CA user interface. The product provides an online Glossary that explains the messages issued during analysis and defines most of the DB2 technical terminology and the SQL/CA specific terms. This glossary can be displayed by function key while the analysis report is being examined. 1.7.3 Explain tables The SQL/CA explain DBspace and tables are created during product installation under the ownership of “SQLCA” which is the userid under which the SQL/CA server connects to DB2. Before starting an analysis, the server deletes all rows in the explain tables. No indexes are provided on the explain tables. 1.7.4 DB2 Connections Analysis is always executed under the DB2 userid of the SQL/CA server “SQLCA”, which should have DBA authority. When submitting an analyis request, the user must specify the name of the DB2/VSE database where analysis should be performed. If the statements to be analyzed contain unqualified table names, a default creator name can be supplied in the user interface. SQL/CA will automatically use this default creator with unqualified table names. 1.8 SQL/CA - SQL/MF integration If our SQL/MF monitor program product has been installed, real-time execution statistics will be included for each analyzed application. This allows to compare the execution cost estimated by DB2, with the effective execution cost. To achieve this, the SQL/CA server should have access (as DBA) to the SQL/MF tables.
  13. 13. Page 10 SQL Command Analysis 1.9 DB2 data modelling facility It is desirable that development databases resemble the production databases as much as possible. This ensures that access paths chosen by DB2 for the test programs are identical to those in the production system. However, completely replicating the operational data in the test database usually is not practical or feasible. In fact, it is not necessary : DB2/VSE allows database administrators to modify certain columns in the catalog tables, in order to create a model of a production database on a test system. SQL statements in the test system are then executed using the access path that would have been chosen in the production system. Manually modelling the catalogs is time-consuming and requires knowledge about DB2 internals. Therefore, SQL/CA offers the utility program SQLCADMF that can be used to quickly copy the catalog statistics from one system to another.
  14. 14. SQL Command Analysis Page 11 2 SQL/CA Installation 2.1 Software Prerequisites - VSE/ESA Version 2 Release 2 and later - DB2/VSE Version 3.5 and later 2.2 Pre-installation tasks 2.2.1 Prepare a VSE library If you did install another SPR product previously, SQL/CA should be stored in the same library as the other SPR product and you can skip the remainder of this paragraph. Otherwise, define the VSE library where SQL/CA will be catalogued, by submitting the following jobstream: // EXEC LIBR DEFINE SUBLIB=xxxxx.xxxx /* Notes - The SQL/CA material requires about 5000 library blocks. - If you have other SPR products installed, install SQL/CA in that library. All SPR products must reside in the same library and sublibrary. 2.2.2 Update LIBDEF and Standard Labels - Add the SQL/CA library to the PHASE and OBJ SEARCH LIBDEF in your LIBDEF.PROC. - Submit the updated LIBDEFs to the system before continuing installation. The installation procedures expect that the SQL/CA library is in the current chain. - Ensure that the standard labels have a DLBL for the DB2 files SQLBIND, SQLGLOB and BINDWKF, as suggested by the DB2 installation guide. Submit the updated label definitions before continuing installation. 2.2.3 Prepare the SQL/CA Report Library The SQL/CA analysis reports are stored in a VSAM cluster. These reports are managed by the SQL/CA users from the online SQL/CA application. Analysis reports are never deleted by SQL/CA. This is a user responsability. An installation may decide to keep the analysis reports in the library, as part of the application’s documentation. The space needed for the VSAM cluster depends on the number of active reports, the number of SQL statements in the applications and the number of SQL/CA warnings issued. SQL/CA compresses the text of the report by dropping leading, trailing and interspersed blanks. The SQL/CA library blocks are 16K long and in the average, a block will hold 3 to 4 analyzed SQL statements.
  15. 15. Page 12 SQL Command Analysis 2.3 Installing SQL/CA The SQL/CA software is delivered as a PC file in ZIP format. Place the ZIP file in a dedicated directory (e.g. SQLCA) and unzip the file. Following files should now be present in the SQLCA directory: INSTALL.BAT installation procedure for Windows SEND2RDR.BAT installation procedure for Windows SQLCA.PCF SQL/CA software SQLCASCF.PCF software key SQLCA.OPTIONS upload the OPTIONS file SQLCAI0.VSEJOB setparm SPRLIB SQLCAI1.VSEJOB linkedit SQL/CA SQLCAI2.VSEJOB define the SQL/CA report library SQLCAI3.VSEJOB define the SQL/CA components to CICS SQLCAI4.VSEJOB install SQL/CA in a database SQLCASRV.VSEJOB job to start the SQL/CA server SQLCA.BKS bookshelf for IBM Library Reader SQLCA.BOO SQL/CA User’s Guide in IBM Library Reader format 2.3.1 Preliminary Note The INSTALL.BAT and SEND2RDR.BAT installation procedures use the “SEND.EXE” to upload the PC files to the POWER reader queue. Ensure that your 3270 emulator supports SEND (some emulators don’t) and that the EXE is on your active path. If you cannot use the SEND.EXE, use the upload facilities of your emulator to perform the equivalent of the SEND commands contained in the BAT files, that is: for the INSTALL.BAT: SEND SQLCASCF.PCF (FILE=RDR BINARY LRECL=80 NOUC SEND SQLCA.PCF (FILE=RDR BINARY LRECL=80 NOUC for the SEND2RDR.BAT: SEND <filename> (FILE=RDR
  16. 16. SQL Command Analysis Page 13 2.3.2 Issue SETPARM for SPRLIB Skip this step when running a VSE/ESA version lower than 2.4. The job submits a SETPARM SYSTEM statement that is not accepted in older VSE versions. - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Edit the file SQLCAI0.VSEJOB and insert the name of the target library on the SETPARM SPRLIB statement. The SETPARM statement remains active until the next VSE IPL. If you installed another SPR product previously into the SPRLIB, insert the name of that library on the SETPARM statement. - Drag and drop the file SQLCAI0.VSEJOB on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - Check the output listing for errors. 2.3.3 Upload the SQL/CA software - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Execute the INSTALL.BAT by clicking. This will upload 2 jobs to the POWER/VSE reader queue with DISP D and class 0. The jobs catalog all SQL/CA components into the VSE library chosen as SQL/CA residence. - Both jobs contain a // PAUSE statement. This allows to enter a // SETPARM SPRLIB=’...’. If running VSE/ESA 2.4 or higher, ignore the PAUSE statement, as the SETPARM has been submitted by the SQLCAI0.VSEJOB, described above. If running a version older than 2.4, issue the SETPARM statement. - After job completion, check the DISP=H listing for any errors. 2.3.4 Link SQL/CA - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - In the file SQLCAI1.VSEJOB, assign the SETPARM symbol SPRLIB, specifying the library where SQL/CA has been uploaded. This is required for VSE versions lower than 2.4. If running 2.4 or higher, you can delete the SETPARM statement, as it has been submitted by the SQLCAI0.VSEJOB, described above. - Drag and drop the file SQLCAI1.VSEJOB on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - Check the output listing for errors. 2.3.5 Upload the SQLCA OPTIONS file - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Edit the file SQLCA.OPTIONS. If needed, change the POWERCLASS statement, which indicates the class where analysis jobs should run. - Drag and drop the file SQLCA.OPTIONS on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - Check the output listing for errors.
  17. 17. Page 14 SQL Command Analysis 2.3.6 Define the SQL/CA Report Library - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Edit the file SQLCAI2.VSEJOB and assign the following SETPARM symbols to define the cluster SQLCA.REPORT.LIBRARY: - CAT the name of the VSAM catalog for the cluster - VOLUME the VOLUME parameter - PALLOC the primary space allocation value as a number of records (16K long) - SALLOC the secondary space allocation value as a number of records (16K long) - Drag and drop the file SQLCAI2.VSEJOB on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - Check the output listing for errors. 2.3.7 Define the SQL/CA components to CICS - The SQLCAI3.VSEJOB assumes that the CICS.CSD cluster is in the VSESPUC user catalog. If this not not the case, re-assign the CAT symbol in the SQLCAI3.VSEJOB file. - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Drag and drop the file SQLCAI3.VSEJOB on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - The job starts a DFHCSDUP run that defines the interactive SQL/CA components to CICS, using the group SQLCA. - Check the output listing for errors. 2.3.8 Update the CICS FCT - The CICS FCT must have an entry for the SQLCA.REPORT.LIBRARY. - Copy the member SQLCAFCT.A in your DFHFCT and re-assemble it.
  18. 18. SQL Command Analysis Page 15 2.3.9 Install SQL/CA in a database This installation step should be executed in all databases where SQL/CA will be used. Following functions will be performed in the target database: - Define the userid SQLCA - Load the SQL/CA packages - Create the SQL/CA Explain tables Edit the PC file SQLCAI4.VSEJOB and assign the following SETPARM symbols CAT the VSAM catalog for a SAM ESDS workfile (default is VSESPUC) DB The name of the target database. DBAPASS The password of user SQLDBA in that database. CAPASS The password to be assigned to user SQLCA in that database. The SQLCA userid is granted DBA authority by SQLCAI4. The CAPASS value is stored (in encrypted format) into a member of the SPRLIB, for retrieval by the SQL/CA components. The CAPASS value should be the same in all databases where SQL/CA is installed. POOL The storage pool number for the SQL/CA explain DBspace. PAGES The number of pages for the SQL/CA explain tables (minimal size of 128 pages is sufficient). Submit the SQLCAI4.VSEJOB as follows: - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Drag and drop the file SQLCAI4.VSEJOB on the SEND2RDR.BAT. This will send and start the job in class 0 and DISP D. The output listing is in DISP H. - Check the output listing for errors. 2.3.10 Update the VSE startup stream If you installed the SPR product SQL/MF previously, skip this section. If you are running VSE/ESA 2.4 or higher, insert a // SETPARM SYSTEM,SPRLIB=’library_name’ in the $0JCL or USERBG procedure, where ‘library_name’ is the library where SQL/CA has been catalogued. The SPRLIB variable is needed by several SQL/CA components during execution. VSE versions lower than 2.4 do not provide the SETPARM SYSTEM statement and the SPR library name will be obtained using a component provided by SQL/CA. The SETPARM SYSTEM statement will ensure better performance, as it allows to determine the library name without accessing the library.
  19. 19. Page 16 SQL Command Analysis 2.3.11 Update the VSE standard labels In your standard labels procedure, insert the following DLBL for the SQL/CA report library: // DLBL SQLCLIB,’SQLCA.REPORT.LIBRARY’,,VSAM,CAT=....,DISP=(OLD,KEEP) 2.3.12 Upload the SQLCASRV startup sample job - The SQLCASRV VSEJOB starts the SQL/CA server partition. - Examine the SQLCASRV.VSEJOB and modify the CLASS operand, if needed. - Start ICCF PC file transfer (fast path 386) in 3270 emulator session A. - Drag and drop the file SQLCASRV.VSEJOB on the SEND2RDR.BAT. This will store the job in the POWER reader queue, with DISP L.
  20. 20. SQL Command Analysis Page 17 3 Using SQL/CA 3.1 Using the SQL/CA interactive menu In a CICS session, enter $CAM. This will display the main SQL/CA menu. Enter one of the following function codes or select the function by positioning the cursor on the function description: 1 Invoke the SQL/CA Librarian (see page 20) 2 Analyze a source program residing in a VSE library (see page 17) 3 Analyze a source program residing in an ICCF library (see page 17) 4 Analyze a source program residing in a VOLLIE library (see page 18) 5 Analyze a DB2/VSE package (see page 18) 6 Analyze a QMF query (see page 18) 7 Analyze an ISQL query (see page 18) 8 Analyze a query entered on the terminal (see page 19) 3.2 Analyze a VSE library member Supply following panel fields: - the name of the VSE library - the name of the VSE sublibrary - the name of the VSE library member - the type of the VSE library - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function. 3.3 Analyze an ICCF library member Supply following panel fields: - your ICCF userid - the ICCF library number - the name of the ICCF library member - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function.
  21. 21. Page 18 SQL Command Analysis 3.4 Analyze a VOLLIE library member Supply following panel fields: - the name of the VOLLIE library member - the type of the VOLLIE library member - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function. 3.5 Analyze a DB2 package Supply following panel fields: - the creator of the package - the name of the package - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function. 3.6 Analyze a QMF query Supply following panel fields: - the creator of the query - the name of the query - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function. 3.7 Analyze an ISQL query Supply following panel fields: - the creator of the ISQL ROUTINE table containing the query - the name of the query - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references Your input is saved in global variables and restored as default on the next invocation of this function.
  22. 22. SQL Command Analysis Page 19 3.8 Analyze an interactive query Supply following panel fields: - the name of the database where analysis must be performed - optionally, the table creator to be used for unqualified table name references - the text of the SQL statement to be analyzed, with a maximum length of 10 terminal lines)
  23. 23. Page 20 SQL Command Analysis 3.9 SQL/CA Librarian 3.9.1 Searching the SQL/CA Report Library SQL/CA analysis reports are identified in the library by: - the CICS userid that requested analysis - a reportname - a report timestamp (to allow multiple analysis reports for the same source) The report name is the name of the analysis source, that is - the VSE membername and the membertype - the ICCF membername and library number - the package creator and package name - the query creator and query name - the string “Interact Query” for interactive statement analysis To search your reports in the library, enter following panel fields - your userid (or leave the default CICS id) - the 2-part reportname Generic search arguments can be indicated by a trailing asterisk sign. The argument may consist of a single asterisk. Examples - to list all your reports, enter your userid and 2 asterisks for the reportname - to list the analysis reports for all DB2 packagenames starting with ‘AB’, enter your userid, an asterisk for the creator and AB* as the packagename
  24. 24. SQL Command Analysis Page 21 3.9.2 Processing the Report selection list Process the list of the selected analyis reports by using following PF key functions: PF1 Display the SQL/CA help file. PF2 Refresh the list from the report library. PF3 Exit from this panel. PF6 Display first page of the list. PF7 Display previous page of the list. PF8 Display next page of the list. PF9 Display last page of the list. PF10 Display the report under the cursor by invoking the SQL/CA report editor. PF11 Print the report under the cursor. The function is not executed online but the request is transmitted to the batch SQL/CA analysis server. The report is printed to the POWER/VSE queue with an LDEST that specifies your CICS userid. PF12 Delete the report under the cursor. The function is not executed online but the request is transmitted to the batch SQL/CA analysis server. ENTER Makes the report under the cursor “current” (and highlights the line).
  25. 25. Page 22 SQL Command Analysis 3.9.3 Processing the analysis report After invoking the report editor (PF10 on the previous screen), the report is read from the library into a storage list and the first page of the report is shown. Process the analyis report by using following PF key functions: PF1 Display the SQL/CA help file. PF2 Searches a text string in the report. On the search panel, specify the string to be located and the search direction as > (forward) or < (backward). Searching is case insensitive and proceeds from the current line + 1. The first line located becomes the current line. PF3 Terminate the report editor. PF4 Display the SQL/CA glossary. The glossary contains - a detailed description of the warning messages issued during analyis - suggestions for corrective action - a description of the DB2 and SQL/CA terminology - tables that describe some rules applied by the DB2 Optimizer If the cursor is on an SQL/CA warning (“AWxx”) when pressing PF4, the Glossary is positioned to the description of that warning. PF5 Locates the next SQL/CA warning message. PF6 Display first page of the list. PF7 Display previous page of the list. PF8 Display next page of the list. PF9 Display last page of the list. PF10 Displays the previous SQL statement in the report.
  26. 26. SQL Command Analysis Page 23 PF11 Displays the next SQL statement in the report. PF12 Displays all warning issued for the current SQL statement on a single screen. The SQL/CA Glossary can be called for each warning in this list, using PF4. ENTER Places the report line under the cursor on top of the screen and highlights the line.
  27. 27. Page 24 SQL Command Analysis 3.9.4 Displaying the SQL/CA Glossary Browse the Glossary by using following PF key functions: PF2 Searches a text string in the glossary. On the search panel, specify the string to be located and the search direction as > (forward) or < (backward). Searching is case insensitive and proceeds from the current line + 1. The first line located becomes the current line. PF3 Terminate the report editor. PF6 Display first page of the list. PF7 Display previous page of the list. PF8 Display next page of the list. PF9 Display last page of the list. ENTER Places the line under the cursor on top of the screen and highlights it.
  28. 28. SQL Command Analysis Page 25 3.10 Invoking SQL/CA from a batch job SQL/CA analysis can be requested from batch, by submitting following JCL: // JOB // LIBDEF PROC,SEARCH=&SPRLIB // EXEC SQLCA,SIZE=SQLCA (1) control_statement_1 (2) control_statement_2 (3) control_statement_3 (4) source text to be analyzed /* /& Notes (1) The first control statement specifies the name of the database where analysis should be performed. An optional default creator can be specified as the second word on this statement, if the SQL statements to be analyzed use unqualified tablenames. (2) Specify an 8-character userid under which the analysis report should be stored in the SQL/CA report library. No checking is done on the validity of this userid and it is used solely as part of the report key. This userid should be used to search the report library after analysis. (3) Identifies the source for analysis. The first word on the record is the sourcetype. The following words depend on the sourcetype used, as follows Source word 2 word 3 word 4 word 5 type VSE library sublibrary member member name name name type ICCF library member number name PACKAGE creator packagename QMF creator queryname ISQL creator queryname * (4) If the source is in a library, use the * $$ SLI statement to insert it here. With sourcetype *, insert the text of the SQL statement. No data is expected when analyzing a package, a QMF query or an ISQL routine. (5) By default, the report resulting from the batch analysis is stored in the SQL/CA Report Library. The report should be consulted using the $CAM CICS transaction. However, if the PARM=’PRINT’ option is included on the // EXEC SQLCA statement, the analysis report will be printed to the POWER list queue only. The PARM=’PRINTKEEP’ option will print the report to the POWER queue and store the report in the Report Library.
  29. 29. Page 26 SQL Command Analysis Example // JOB SQLCA // LIBDEF PROC,SEARCH=<SPRLIB> // EXEC SQLCA,SIZE=SQLCA SPRDB2 USER1 PACKAGE SQLDBA DRD10 /* /&
  30. 30. SQL Command Analysis Page 27 4 The SQL/CA Server 4.1 Starting the SQL/CA server The server is started with a PRELEASE RDR,SQLCASRV. This command should be in the system startup stream. The online SQL/CA interface sends analysis requests to the server using XPCC messages to - perform analysis - print a named analysis report - delete a named analysis report On reception of an analysis request, SQLCASRV builds an SQL/CA jobstream and transmits it to POWER/VSE with the class specified as POWERCLASS in the SQLCA OPTIONS file. If no POWERCLASS statement is found, class Z is used. After the job has been sent, analysis is performed asynchronously and the server is free to accept a new request. The analysis program itself (SQLCA) serializes the analysis facility, using a VSE lock request. This is necessary because SQLCA has only one set of explain tables. This method of operation will also reduce system load resulting from explain and predicate analysis. 4.2 Stopping the SQL/CA server The stop the analysis server, issue a VSE MSG to the partition. No MSG data is expected.
  31. 31. Page 28 SQL Command Analysis
  32. 32. SQL Command Analysis Page 29 5 Interpreting the analysis report For each SQL statement in the application program, following paragraphs are printed in the analysis report. 5.1 Statement Execution Structure by block and parent SQL/CA formats the SQL statement in such a way, that the execution structure for a multiple query statement becomes apparent. Each subquery is indented according to its nesting level within the execution tree. The outer (first) query is printed at indent level 1; a subquery called from the outer query is printed at indent level 2; a subquery called by another subquery is printed at the indent level following that of its parent query. For each subquery, the query blocnumber (BLK) and the number of the invoking parent block (Par) is provided. Note that the execution hierarchy is derived by SQL/CA from the explain tables and that in some cases the actual execution structure may differ from the source statement structure. The DB2 optimizer may effectively execute some subqueries earlier, at the opening of an ancestor block, when there is no correlation to the tables in the intermediate query block. 5.2 Structure of Referential Constraint Statements A statement modifying a table that is a member of a referential integrity constraint, generates additional statements that enforce the integrity. A delete on a parent table for instance, will generate delete or update statements for all its dependent tables. The execution structure of these internal statements is provided by SQL/CA in separate paragraphs that are titled Structure of referential constraint statement, followed by the internal statement number (1 to N). The text of the internal statement is derived from the EXPLAIN data.
  33. 33. Page 30 SQL Command Analysis 5.3 Statement Cost Summary The cost paragraph applies to the statement as a whole. For a single query statement, 2 cost estimates are provided: - Total Statement Cost The query cost estimate from the explain table. The value is zero for INSERT statements. - ISQL like Cost (total_statement_cost / 1000) + 1. Interactive SQL systems such as ISQL present the Query Cost Estimate in this format. For a multiple query statement, following values are computed: - Single_Cost The cost of a single execution of the query block, not including the cost of the dependent and the ancestor blocks. - Exec_Times The estimated number of invocations of a query from all its parent blocks. Eventual multiple parents as well as their "ATOPEN" attribute are taken into account. (The ATOPEN flag tells whether the subquery is executed once or multiple times by its immediate parent block). - Multi_Cost Single_Cost multiplied by Exec_Times. - SQL_Cost The cost from the DB2 explain table i.e. the cost of the query plus the cost of all its dependent blocks. - Highest_Subquery_Cost The highest Multi_Cost found for a subquery in the statement. Performance tuning should concentrate on this subquery. If our SQL/MF monitor program product has been installed and if the monitor tables are accessible during analysis3, following execution-time program statistics are included: N_Rows number of rows processed DBSScall number of calls to the DBSS component Buflook number of buffer lookups performed Tot_IO number of I/O's or dataspace transfers performed SQL_Cost effective statement cost as TOT_IO + (DBSSCALL/3) These statistics were recorded during the last execution of the application. They can be used to compare the cost estimated by DB2/VSE with the real execution cost. 3 See SQL/MF Integration on page 9.
  34. 34. SQL Command Analysis Page 31 5.4 Statement Plan Summary If the analyzed statement has more than one row in the plan table, the plan summary is printed. For each entry in the plan table, following data is provided: - the query number starting from 1 up to the number of nested queries in the statement - the plan number within the query (1 to N) - the access descriptor for the plan entry For primary plan entries, one of the following access descriptors is provided: - scan of DBspace N for table N - selective index[-only] scan of table N - non-selective index[-only] scan of table N - fully qualified index[-only] scan of table N - literal based index[-only] scan of table N For secondary plan entries, one of the following access descriptors is provided: - nested loop join - merge scan join - sort at end of query For join plans, the access path taken during join is also shown, using one of the primary plan descriptors. For example: "Nested loop join using selective index scan of table N". Each plan is described in full detail in the Statement execution detail paragraph.
  35. 35. Page 32 SQL Command Analysis 5.5 Statement Execution Structure The paragraph is printed for each subquery in the SQL statement and provides following data obtained from the DB2 explain tables: Estimated number of rows processed ... out of ... The ROWCOUNT column from the EXPLAIN table. It indicates the estimated number of rows returned for the table(s) used in this statement. SQL/CA computes the total number of table rows from which the estimated number of rows is selected and prints this number following out of. For join statements, this total counts the rows for all tables participating in the join. Estimated global statement filter factor Represents the fraction of table rows estimated to satisfy the statement predicate as (estimated number of satisfying rows) / (sum of all rows of all tables accessed) The filter value ranges from 0 to 1. The lower the value, the better the selectivity of the statement. Estimated times predicate conditions satisfied The TIMES column from the EXPLAIN table. It estimates the probability that the predicate conditions of the statement will be true. It also shows how many times eventual dependent blocks will be executed. If the estimated value equals the number of table rows, SQL/CA assumes a sequential table scan and issues a warning. Estimated execution iteration by ancestor blocks Using the TIMES column from the EXPLAIN Structure table for all parent blocks, SQL/CA computes the total number of times this query block will actually be executed. The ATOPEN attribute of each ancestor block is also taken into account. (The ATOPEN flag tells whether the subquery is executed once or multiple times by its immediate parent block). Block executed ... times by parent block .. The TIMES column from the EXPLAIN Structure table. It estimates the number of times the subquery is invoked by its immediate parent, which is represented by its blocknumber.
  36. 36. SQL Command Analysis Page 33 5.6 Statement Execution Detail The following information is printed for each plan in the query. JOIN queries or statements requesting a sort operation, will have more than one plan. 5.6.1 Plan Detail The execution plan is detailled by providing the following items: METHOD The information is available for JOIN and sort plans only. It takes following values: Merge scan JOIN DB2 merges the response set obtained thus far with the new table to be joined in the order of the join column and joins rows with matching columns. A sort operation may be necessary to access the table to be merged in the required order. A merge scan join may require work dataspace. Nested loop JOIN For each row of the response set obtained thus far, the new table to be joined is searched for matching rows and the matching rows are joined. An index may be used to access the new table. Additional sort at end of query block The plan executes a final sort operation in order to satisfy ORDER, GROUP or DISTINCT statement clauses.
  37. 37. Page 34 SQL Command Analysis ACCESS Using scan of DBspace Rows are accessed by scanning the named DBspace. Data belonging to other tables in the same DBspace will also be scanned. SQL/CA adds the following informations: DBspace pages scanned Provides the number of active pages in the scanned DBspace, that is the number of pages that actually will be read. DBspace scan productivity If multiple tables share the scanned DBspace, the productivity value shows the percentage of DBspace data scanned belonging to the table accessed in the plan. For critical tables productivity should normally be 100%, that is, the table should have its dedicated DBspace. Otherwise, a DBspace scan will imply unnecessary I/O by reading pages of other tables and unproductive locks on pages that contain rows belonging to other tables. Fully-qualified index scan The table will be accessed using all columns of the named unique index. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Fully-qualified index-only scan The table will be accessed using all columns the named unique index. Moreover, all selected data will be retrieved using the index, that is, data pages will not be accessed. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Fully-qualified index scan The table will be accessed using all columns of the named unique index. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique.
  38. 38. SQL Command Analysis Page 35 Literal based index scan The table will be accessed using the named index and literal values from an IN list. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Literal based index-only scan The table will be accessed using the named index and with values from an IN list. Moreover, all selected data will be retrieved using the index, that is, data pages will not be accessed. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Non-selective index only scan The table will be accessed using the named index without key values, which means that a sequential index scan will be performed. However, all selected data will be retrieved using the index, that is, data pages will not be accessed. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Selective index scan The table will be accessed using the named index with specific key values. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Non-selective index scan The table will be accessed using the named index without key values, which means that a sequential index scan will be performed. Data pages may be accessed if the predicate references columns that are not available in the index. The name of the index and its columns are printed. The characteristics of the index are specified as first or non-first, highly clustered or weakly clustered, unique or not unique. Materialization of view View materialization is a technique used by DB2 version 3 in order to remove restrictions on the processing of views. The feature implies storing of intermediate select results in internal tables. To access these intermediate results, indexed access is never used by DB2. Hence the possibly negative performance implications of view materialization.
  39. 39. Page 36 SQL Command Analysis Score The access score is a value computed by SQL/CA in order to represent the efficiency of the DB2 access path chosen. The higher the score, the better the path. One point is added to the score each time one of the following conditions is true: - index access is being performed - fully-qualified index access is being performed - index-only access is being performed - selective index access is being performed - index access is using a highly-clustered index - index access is using a unique index The highest score is achieved when all the above conditions are true. The highest score is 6. The lowest score is 0 and indicates a DBspace scan. AW91 Data pages accessed for predicate and data Data pages must be accessed to resolve the predicate and to retrieve data. If the warning is not provided and the access is index-only, both predicate and data are resolved using the index only. If the warning is not provided and the access is not index-only, the predicate is resolved using the index and data pages are accessed to retrieve data and predicate columns not available in the index. Key-matching index columns: n out of m The number of index keys (n) that have key-matching predicates used in an index scan. The number of columns in the index is provided by m. If n < m, warning AW92 is inserted. No indexes for table No indexes have been defined for the named table. No highly clustered first index for table Indexes do exist for the table, but none of them is highly clustered. No unique indexes for table The table has no unique indexes. This is a warning only, since the structure of the data may be such that non-unique indexes are acceptable. No indexes found created using current DB2 release All indexes for the table were created using a backlevel DB2 release.
  40. 40. SQL Command Analysis Page 37 SORT New table [not] sorted The new table4 accessed in this statement plan needs [does not need] to be sorted. New table sorted and duplicates removed The new table accessed in this statement plan needs to be sorted and duplicates to be removed, for instance, in order to satisfy a DISTINCT request. New table sorted for JOIN purposes The new table accessed in this statement plan needs to be sorted as part of a JOIN plan. New table sorted due to ORDER BY The new table accessed in this statement plan needs to be sorted to satisfy the statement's ORDER BY clause. New table sorted due to GROUP BY The new table accessed in this statement plan needs to be sorted to satisfy the statement's GROUP BY clause. Composite [not] sorted When a statement is performed in several steps, the DB2 term "composite" refers to the response set obtained thus far, as the result of execution in previous steps. For a join operation it is the "input" table. The composite had [not] to be sorted at the initiation of the plan, for example, to prepare the composite for a merge scan join. Composite sorted and duplicates removed The composite has to be sorted and duplicates removed. Composite sorted for JOIN purposes The composite table accessed in this statement plan needs to be sorted as part of a JOIN plan. 4 See the Glossary on page 43 for a definition of "new table".
  41. 41. Page 38 SQL Command Analysis Composite sorted due to ORDER BY The composite table accessed in this statement plan needs to be sorted to satisfy the statement's ORDER BY clause. Composite sorted due to GROUP BY The composite table accessed in this statement plan needs to be sorted to satisfy the statement's GROUP BY clause. Additional information provided for a JOIN Number of rows in inner table: the number of rows in the table from which rows are joined in the current plan (the new table). Not available if no statistics exist for the table. Number of rows in outer table: the number of rows in the table to which the join is done (the composite table). Not available if no statistics exist for the table. The above number of rows represents the effective tablesize during the join, that is, local non-join predicates are applied when computing the value.
  42. 42. SQL Command Analysis Page 39 5.6.2 Column Reference Details The table and columns intervening in the current statement execution plan are obtained from the DB2 EXPLAIN Reference table. For each column, following items are reported: Filtering factor For each column referenced in the statement predicate, DB2 determines a filter factor, which represents the fraction of table rows estimated to satisfy the predicate as: estimated_number_of_rows / number_of_table_rows The filter is a value between 0.0 and 1.0. The lower the value, the better the column's selectivity. A filter factor of 1 means the column has no selectivity at all. The filter factor depends on the distribution of data values for the column. A column having a high number of unique values within the table, will have a good selectivity, that is, a small filter factor. If an SQL statement supplies a search value for such a column, the DB2 optimizer then knows that only a few number of rows will meet the condition and that the response set will be small, which in turn affects the statement execution cost. Estimated table rows filtered This value is obtained by multiplying the number of table rows by the above filter factor. It shows how many table rows are estimated to be filtered through this column. Sargable predicate associated with column A sargable predicate is associated with this column. To receive the qualification: - the column must be in a predicate that is connected by AND to the rest of the WHERE clause, or be the only WHERE predicate - the predicate in which the column appears must be in the format: "column operator expression" Sargable equi-JOIN predicate associated with column The column appears in a join predicate using the = operator and the join predicate is sargable. Appears in ORDER BY clause on position .. The column is used on position .. of an ORDER BY clause. Appears in GROUP BY clause on position .. The column is used on position .. of a GROUP BY clause.
  43. 43. Page 40 SQL Command Analysis Updated by literal expression The column appears in the SET clause of an UPDATE statement that updates the column with a constant value. Updated by column or expression The column appears in the SET clause of an UPDATE statement that updates the column with a column value or an expression Resolved using index page The column occurs in the plan index and is fixed-length. No data page must be accessed when fetching this column. Resolved using index and data page The column occurs in the plan index but is VARCHAR or VARGRAPHIC. A data page must be accessed when fetching this column. Resolved using data page The column is not in the plan index. A data page must be accessed when fetching this column. 5.7 Predicate Analysis Warnings Predicate analysis warnings are issued by the Text Analysis component of SQL/CA. They all have a message number starting with AW followed by a message code. Please refer to page 53 for a detailled description of the warning messages. Unless the warning applies to the SQL statement as a whole, the warning will be preceded by the part of the statement predicate that is causing the warning.
  44. 44. SQL Command Analysis Page 41 6 SQL/CA data modelling facility The SQLCADMF utility programs copies catalog information for a named DBspace between databases. The utility is invoked as follows: // EXEC SQLCADMF INSTALL source_database Dbspacename TO target_databasename /* Where Source_database Designates the database from which catalog modelling is performed. Dbspace name Is required and designates the PUBLIC DBspace for which statistical data should be stored in the extract file; a generic name, containing the % pattern character can be used to obtain data for several Dbspaces. Target_database Designates the database into which catalog modelling is performed. The utility copies following catalog columns from source to target: - SYSDBSPACES - NACTIVE - NPAGES - SYSCATALOG - ROWCOUNT - AVGROWLEN - SYSCOLUMNS - COLCOUNT - AVGCOLLEN - SYSCOLSTATS - FREQ1PCT - FREQ2PCT - SYSINDEXES - FULLKEYCOUNT - FIRSTKEYCOUNT - NLEAF - NLEVELS - CLUSTER - CLUSTERRATIO
  45. 45. Page 42 SQL Command Analysis
  46. 46. SQL Command Analysis Page 43 7 SQL/CA Glossary ACCESS DB2 has following ways of accessing a table: 1 DBSPACE SCAN (also termed RELATIONAL SCAN) The entire DBspace containing the table is scanned. This will also read (and lock) pages of other tables residing in the same DBspace. In most cases, a DBspace scan is a problem. However, for small tables residing in a dedicated DBspace, a DBspace scan may be the most appropriate access strategy. 2 SELECTIVE INDEX SCAN Selected rows of the table can be accessed using an index and specific key values, because the statement predicate specifies a string that can be used to directly access an index page. Data pages will be accessed selectively during predicate resolution, when the predicate contains search conditions on columns that are not in the search index, or when the search index has VARCHAR or VARGRAPHIC columns. 3 NON-SELECTIVE INDEX SCAN The table is accessed using an index without specific key values, because because the statement predicate specifies a string that cannot be used to directly access an index page. This happens: - when the predicate operator does not allow direct index access (such operators are called non key-matching; they are listed in the table Predicate operator evaluation on page 86), for example : WHERE C1 IS NOT NULL - when the predicate omits leading columns in a composite index, for example : WHERE C2 = x (and the index is on C1,C2) - when there is some other coding inefficiency in the predicate, such as: WHERE C1=:HOSTVAR+10 or WHERE C1=:HOSTVAR (and the datatype of hostvar is not compatible with that of C1)
  47. 47. Page 44 SQL Command Analysis A non-selective index scan accesses all the pages of the index. It will also access table data pages: - when the predicate contains search conditions on columns not available in the search index - when a column of the search index has the VARCHAR or VARGRAPHIC datatype An index scan may be chosen by DB2 as an alternative for a DBspace scan, for example, when the relational scan productivity is low (many pages not belonging to the table would be scanned because the table's SYSCATALOG.PCTPAGES value is low). A true DBspace scan might be performed under different circumstances, for instance when the table gets larger or when less tables share the same DBspace. In some cases, a non-selective index scan may be worse than a DBspace scan, since both index and data pages must be accessed, whereas a DBspace scan accesses data pages only. 4 SELECTIVE OR NON-SELECTIVE INDEX-ONLY SCAN All columns in the SELECT list and in the predicate are indexing columns and can be retrieved without accessing the data pages. A selective index-only scan is the most efficient access path. 5 FULLY-QUALIFIED INDEX SCAN All columns of a unique index can be used for the index scan. ADDITIONAL SORT DB2 performs an additional sort at the end of the query block. This may be caused by ORDER BY, GROUP BY or SELECT DISTINCT clauses. Note that a small number of rows will be sorted by DB2 in storage with no I/O involved. Larger response sets will be sorted using internal DBspaces. ATOPEN A dependent block may be executed once when the corresponding parent block is initiated (ATOPEN=YES) or it may be executed for each iteration in the parent block (ATOPEN=NO). In the latter case, the iteration count of the dependent block is the product of its own estimated iteration and that of its parent(s). If a block has multiple ancestors and each invocation has ATOPEN=NO, the iteration count and the execution cost may become very high. Therefore SQL/CA will issue a warning. However, high iteration rates may exist, even with an ATOPEN=YES block, because DB2 may save the result of the dependent block in internal DBspaces and iteratively search these Dbspaces, instead of executing the dependent query. This situation is not visible in the EXPLAIN results. In any case, you should try to keep the number of matching subquery rows as low as possible. Using a correlated subquery may reduce the size of the subquery result. CHILD BLOCK The opposite of parent block. See PARENT BLOCK.
  48. 48. SQL Command Analysis Page 45 CLUSTERED INDEX An index is clustered if the sequence of its entries reflects the physical ordering of the table rows. The clustering attribute of a given index is stored in SYSINDEXES as a flag and as a clustering ratio. The latter is a value ranging from 0 to 10000 and represents the degree of clustering, where 10000 is the optimal clustering ratio. An index is termed "weak" by SQL/CA, if the SYSINDEXES flag says so, or if the clustering ratio drops below 6000. The clusterratio on the SQL/CA index report equals the DB2 clusterratio divided by 100. Statement COST SUMMARY The cost value from the DB2 explain cost table indicates for a given query block the total execution cost estimate. This estimate includes the cost of eventual dependent blocks. For statements containing multiple queries, SQL/CA provides a more refined cost computation method. For each query block, following values are computed: Single_Cost The cost of the query block, not including the cost of the dependent and the ancestor blocks. Exec_Times The estimated number of invocations from all parent blocks. The number of invocations of the parent blocks themselves and the ATOPEN flags are taken into account. Multi_Cost Single_Cost multiplied by Exec_Times. SQL_Cost The cost from the DB2 explain table i.e. the statement cost plus the cost of all its dependent blocks. Highest_Subquery_Cost The highest Multi_Cost found for a subquery in the statement. For both single and multiple query statements, following cost information is provided: Total Statement Cost The cost estimate associated by DB2 with the statement as a whole. ISQL-like Cost (total_statement_cost / 1000) + 1. Interactive SQL systems such as ISQL present the Query Cost Estimate in this format.
  49. 49. Page 46 SQL Command Analysis COMPOSITE When a statement is performed in several steps, the DB2 term "composite" refers to the response set obtained thus far, as the result of execution in previous steps. In joins, the composite is also termed the outer table. DBSPACE SCAN A synonym of RELATIONAL SCAN. Refer to the keyword ACCESS. DBSPACE SCAN PRODUCTIVITY A value computed by SQL/CA to estimate the percentage of table data actually accessed during a DBspace scan. The value is taken from the PCTPAGES column in the SYSCATALOG row for the table. For critical, operational tables productivity should normally be 100%, that is, the table should have its dedicated DBspace. Otherwise, a DBspace scan will imply unnecessary I/O by reading pages of other tables and unproductive locks on pages that contain rows belonging to other tables. DEFAULT FILTER FACTOR The DB2 Optimizer may not be able to use significant filter factors during path selection. Default filter factors are then adopted. This will be the case when: - no catalog statistics are available to compute the filter factor - the predicate contains host variables (which do not have a value when the access strategy is determined during program preprocessing) - the predicate contains expressions - disjunctive predicates are used, by means of the OR connector When no catalog statistics are available, the default filter factor is as follows: - for the = operator 0.040 ( 4% qualifying rows) - for LIKE and BETWEEN 0.100 (10% qualifying rows) - for all other operators 0.333 (30% qualifying rows) - for the <> operator 0.960 (96% qualifying rows) When statistics are available, the default filter is as follows: - for the = operator 1/COLCOUNT (where COLCOUNT is the estimated number of distinct values in the column) - for all other operators see the default filter factor table on page 87.
  50. 50. SQL Command Analysis Page 47 ESTIMATED GLOBAL Statement FILTER FACTOR Represents the fraction of table rows estimated to satisfy the statement predicate as (estimated number of satisfying rows) / (sum of all rows of all tables accessed) The filter value ranges from 0 to 1. The lower the value, the better the selectivity of the statement predicate. ESTIMATED EXECUTION ITERATION BY ANCESTOR BLOCKS Using the TIMES column for all ancestor ("parent") blocks, SQL/CA computes the total number of times this query block will actually be executed. The ATOPEN attribute of each ancestor block is also taken into account. ESTIMATED NUMBER OF ROWS PROCESSED The ROWCOUNT column from the EXPLAIN Structure table. It indicates the estimated number of rows returned for the table(s) used in this statement. The filtering factors associated with the columns referenced in the statement predicate, intervene in estimating the size of the response set. The ROWCOUNT column may be zero for small response sets. SQL/CA computes the total number of table rows out of which the estimated number of rows is selected. For join statements, the total counts the rows for all tables participating in the join. If the estimated value equals the number of table rows, SQL/CA assumes a sequential table scan and issues a warning. ESTIMATED TIMES PREDICATE CONDITIONS MET The TIMES column from the EXPLAIN Structure table. It estimates the probability that the predicate conditions of the statement will be true. It also shows how many times eventual dependent blocks will be executed.
  51. 51. Page 48 SQL Command Analysis FILTER FACTOR For each column reference in the statement predicate, DB2 determines a filter factor, which represents the fraction of table rows estimated to satisfy the predicate as: estimated_number_of_rows / number_of_table_rows. The filter is a value between 0.0 and 1.0. The lower the value, the better the column's selectivity. A filter factor of 1 means the column has no selectivity at all. The filter factor depends on the distribution of data values for the column. A column having a high number of unique values within the table, will have a good selectivity, that is, a small filter factor. If an SQL statement supplies a search value for such a column, the Optimizer knows that only a few number of rows will meet the condition and that the response set will be small. This will reduce the statement execution cost and determine the access strategy. A column with a small filter is also a good index candidate. The filter factor chosen depends on the predicate operator used, as shown on page 86. FULLY-QUALIFIED INDEX SCAN Refer to the keyword ACCESS. INDEX DISQUALIFIED An index is present but not used by the optimizer, because the application statement specifications are inhibiting it. The optimizer will use a DBspace scan or an index scan (scanning the entire table using the index). Whether a DBspace or an index scan is chosen, depends on factors such as the index clustering ratio, the percentage of table pages in the DBspace etc. INDEX SCAN Refer to the keyword ACCESS.
  52. 52. SQL Command Analysis Page 49 INDEX-ONLY SCAN Refer to the keyword ACCESS. KEYMATCHING A predicate is called keymatching, when the columns used in the predicate can be formed into a string that matches existing entries of the table index. Such a predicate allows direct retrieval of a qualifying key and row. To be a candidate for keymatchinq, the predicate must be sargable. Examples of key-matching predicates: C1 = 1 C1 > 1 Examples of non key-matching predicates: C1 <> 1 C2 NOT LIKE :VAR Given a composite index on (C1,C2): C1 = 1 is key-matching C2 = 1 is not key-matching MATERIALIZATION View materialization is a technique used by DB2 version 3 in order to remove restrictions on the processing of views. The feature implies storing of intermediate select results in internal tables. To access these intermediate results, indexed access is never used by DB2. Hence the possibly negative performance implications of view materialization. MERGE SCAN JOIN DB2 scans the composite and the new table in the order of the join column and joins rows with matching columns. A sort operation may be necessary to access the new table and or the composite in the required order and additional work dataspace (internal DBspaces) may be required. Therefore, a merge scan join is usually less performant than a nested loop join. METHOD Represents the action performed by DB2 for a given plan: a merge scan join, a nested loop join, an additional sort plan or a view materialization. NESTED LOOP JOIN For each row of the composite, matching rows of the new table are located and joined. An index may be used to access the new table.
  53. 53. Page 50 SQL Command Analysis NEW TABLE When a join is being executed, this DB2 term refers to the new table that is being accessed in the current step (plan) and joined to the data resulting from previous steps (the composite table). The new table is also called the inner join table. NO EXPLICIT SORT PLAN The ordering clause requested by the statement can be satisfied using the index order without requiring a specific sort operation. NON-SELECTIVE INDEX SCAN Refer to the keyword ACCESS. PARENT BLOCK In a multiple query structure, a parent or ancestor block is the subquery that initiates another subquery, which in turn is called a child or dependent block. PLAN An SQL statement may be executed in several steps. Each step is called a plan by SQL EXPLAIN and receives a plan number, representing the order in which the statement's plans are executed. There are specific plans for join, sort and view materialization operations. PREDICATE The search condition in the WHERE clause of an SQL statement. There are four types of predicates. They are, in decreasing order of performance: Keymatching A predicate is keymatching, when it can be applied against an index for direct retrieval of qualifying keys. The predicate is applied by the DB2 Database Subsystem (DBSS). Index sarg An index sarg is a predicate that can by applied by the DB2 Database Subsystem (DBSS) against keys in index leaf pages. Data sarg A data sarg is a predicate that can by applied by the DB2 Database Subsystem (DBSS) against column values in data pages. Residual A residual predicate cannot be applied by the DB2 Database Subsystem (DBSS), but is evaluated by the DB2 Relational Data System (RDS). This implies that DBSS must obtain all rows that are to be evaluated by RDS.
  54. 54. SQL Command Analysis Page 51 RANGE PREDICATE A range predicate contains the SQL verbs LIKE or BETWEEN or one of the range operators >, >=, <, <=. A DEFAULT FILTER FACTOR is used for a range predicate, when it has the format: - Column range_operator Host variable - Column range_operator Column - Column LIKE expression - Column BETWEEN expression AND expression RESIDUAL The opposite of SARGABLE. See SARGABLE. SARGABLE An expression is sargable if it can be evaluated by the DB2/VSE Database Subsystem (DBSS), that is, while data is being retrieved from the I/O system. If the expression is not sargable (also called a RESIDUAL expression) it is evaluated by the DB2/VSE Relational Data System (RDS) after calling the Database Subsystem to obtain data. Filtering the data (testing whether they satisfy the predicate specifications) at the RDS level causes additional DBSS calls and increases the processing overhead. Only sargable expressions are keymatching candidates. A predicate containing residual expressions only, is resolved using an index or dbspace scan. SCORE An attempt to measure the efficiency of the DB2 access path. The higher the score, the better the path. One "point" is added to the score each time one of the following conditions is true: - index access is being performed - fully-qualified index access is being performed - index-only access is being performed - selective index access is being performed - index access uses a highly-clustered index - index access uses a unique index The highest score is achieved, when all the above conditions are true. The highest score is 6. The lowest score 0 indicates a DBspace scan. SELECTIVE INDEX SCAN Refer to the keyword ACCESS.

×