Getting Startedwith pureQuery

D
Appendix D – Static SQL in DB2
D.1 What is static SQL?
Static SQL means different things to different database vendors. This appendix describes
static SQL and its benefits for DB2.
Whenever DB2 executes an SQL statement, the system creates an access plan describing
the steps it will take, and in what order, to perform the execution. For example, the system
might create a plan by analyzing table statistics to decide what indexes to use and which
columns to access first to perform a join.
When SQL is executed dynamically, the access plan is selected on the fly, at runtime, as
part of execution processing. As a result, dynamic execution of an SQL statement is
usually delayed by the creation of its access plan. Even though mechanisms such as
dynamic statement caching exist to improve this sequence of steps, in dynamic and
improvised workloads, generating access plans can be a key negative factor in the overall
system performance.
Static SQL is an alternative to this dynamic execution model. When SQL is executed
statically, it uses a precompiled version of the SQL statement, which means that the
access path was generated before the statement was executed (see the section on
“Precompile and Bind” for more information). As a result, when the SQL execution request
is sent to the database, the system already knows the access plan it will use to evaluate
the statement.
Figure D.5 compares the runtime processing required for dynamic vs. static SQL execution
modes.