Start of change

Populating query text for statement-level matching

You can increase the likelihood that DB2® can identify matching SQL statements when you use the BIND QUERY command to influence access path selection.

About this task

DB2 modifies the statement text that is used for matching at BIND or PREPARE time. For example, white space, SQL comments, and certain clauses such as EXPLAIN, are removed from the query text. These changes enable DB2 to match the parsed SQL statements during BIND and PREPARE processing.

The following application default values must be the same at BIND QUERY time as they are when static SQL statements are bound or dynamic SQL statements are prepared:

  • CCSID
  • DECIMAL POINT
  • STRING DELIMITER

Procedure

To enable successful matching of the statement text, use the following approaches:

  • For static SQL statements, and for dynamic statements that are prepared with the DYNAMICRULES(BIND) option, specify the following columns that specify package information for the statement in DSN_USERQUERY_TABLE:
    • PACKAGE
    • COLLECTION
    • VERSION

    These values are not strictly required. However, when these values are specified, DB2 uses parsing information from the SYSIBM.SYSPACKSTMT catalog table to modify the statement text. If the values are unspecified, or the matching package is not found during the BIND QUERY processing, DB2 uses the values that are specified in the application defaults module.

    As part of the BIND QUERY process, DB2 validates that the package if specified, contains matching statement text. If the statement text does not match, DB2 issues message DSNT281I and the BIND QUERY command fails.

    When multiple versions of the package exist, and you specify * for the value of the VERSION column. DB2 uses package information from the SYSIBM.SYSPACKSTMT catalog table that has the smallest value in the VERSION column to modify the statement text. If other versions of the package use different options, it is possible that for matching to fail for statements from the other versions.

    When the package context is not specified in DSN_USERQUERY_TABLE, DB2 uses the applications default module to modify the statement text. However, the statement text is not validated against statements in a particular package.

  • When you populate the QUERY_TEXT column in DSN_USERQUERY_TABLE, select the parsed query text from the following locations:
    • For static SQL statements, select the statement text from the DBRM or from the SYSIBM.SYSPACKSTMT catalog table.
    • For dynamic SQL statements, select the statement text from the dynamic statement cache. For statements that are eligible for replacement of literal values by the ampersand symbol (&), extract the statement text after DB2 replaces literal values.

    It is possible to specify the text directly in an INSERT statement (such as by copying from the source code for your application). However, that approach reduces the likelihood of successful matching of statements to the hint.

  • Ensure that object names and SQL keywords in the statement text are specified by uppercase characters, especially for dynamic SQL statements.
End of change