SQL/MX Programming Manual for C and COBOL (G06.24+, H06.03+)

Name Resolution, Similarity Checks, and Automatic
Recompilation
HP NonStop SQL/MX Programming Manual for C and COBOL—523627-004
8-9
Similarity Check
recompile the SQL plan. For more information, see Automatic Recompilation on
page 8-12.
Causes of a Similarity Check
When enabled, a similarity check occurs for these reasons:
•
Changed DEFINEs or PROTOTYPE Host Variables on page 8-9
•
Failed Timestamp Check on page 8-9
Similarity checks are performed regardless of the method chosen to refer to tables in
the source code: hard-coded Guardian or logical names, class map DEFINEs, or
PROTOTYPE host variables. For more information, see Name Resolution on page 8-1.
Changed DEFINEs or PROTOTYPE Host Variables
The SQL/MX executor performs a similarity check if a statement that was compiled for
one table, specified by either a class map DEFINE or a PROTOTYPE host variable,
will now be executed to process a different table specified by a new DEFINE or host
variable value, respectively. For more information, see Late Name Resolution on
page 8-6.
If the value of a DEFINE or a PROTOTYPE host variable changes, the SQL/MX
executor initiates a similarity check, comparing the compile-time table to the run-time
table, to determine if the query execution plan is still operable. See Similarity Check
Criteria on page 8-10.
Failed Timestamp Check
The SQL/MX executor performs a similarity check if a timestamp check fails, which
occurs if the table’s redefinition timestamp has changed since the referencing
statement was compiled. The SQL/MX executor performs a timestamp check for each
table referenced in an SQL statement at table open time (the first time the table is
opened). The timestamp check ensures that the current execution plan of an SQL
statement uses a valid definition of each table.
After the SQL/MX compiler has prepared the query execution plan of a statement,
changes to the tables that the plan processes can occur. For example, an index can be
added or removed, or a partition added. Changes of this nature can render the plan
inoperable. These types of changes to a table also change the redefinition timestamp
of the table.
Each table contains a redefinition timestamp in its file label. At compile time, the
timestamp of each table accessed by an SQL statement is stored with the compiled
plan of the statement in a module. When executing a plan, the SQL/MX executor
compares the current timestamp in the table’s file label with the compile-time
timestamp of the same table in the query execution plan. If the timestamps differ, the
SQL/MX executor initiates a similarity check, comparing the compile-time version to
the run-time version of the table, to determine if the query execution plan is still
operable. See Similarity Check Criteria on page 8-10.