Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-37
Recompiling or Execution-Time Name Resolution for
Data Definition Changes
Without Similarity Checks
Without similarity checks, the entire SQL program would be invalidated, requiring
complete SQL recompilation or automatic recompilation of all SQL statements at
execution time.
With Similarity Checks
With similarity checks, you have the options of recompiling or automatically recompiling
only those statements that fail the similarity checks. Thus, logical changes such as
adding a column to a table or adding an index would likely pass the similarity checks
allowing the program to continue uninterrupted. Physical changes such as dropping an
index might cause the corresponding execution plans to fail the similarity check, but
only those plans need be automatically recompiled, allowing the program to continue
executing with minimal reduction in performance. Alternatively, you can recompile the
program with SQL to avoid any loss of performance while using similarity checks to
minimize the recompilation time.
Refer to Using the Similarity Check on page 10-30 for an overview of the options
available.
Example Use of Similarity Checks to Endure DDL Changes
Figure 10-7 on page 10-38 shows the steps involved in preparing a SQL program so
that it can later endure DDL changes without downtime.
The similarity check on the execution plans is enabled by compiling the program with
SQL in the development phase with the CHECK INOPERABLE PLANS compile option
set. The similarity check must also be set for the affected SQL object if that object is an
SQL table or protection view; this is done using the ALTER TABLE statement. Once
these options are set, there is no need to bring down the application in order to make a
DDL change.
If you are adding the similarity check to an application that is already executing on a
production system, then you must recompile the program. By recompiling on the
development system then installing the upgraded program on the production system
using the REGISTERONLY ON option, you minimize application downtime due to the
recompilation. You can install an SQL program using the REGISTERONLY ON option
in a much shorter time than you can recompile the same program.
For a brand new application, the REGISTERONLY ON option is unnecessary because
there is no existing application to bring down while the recompilation takes place.