Getting Startedwith pureQuery

Appendix D – Static SQL in DB2 349
Once the optimal plan is identified it can be locked in for the static SQL statement. This
means that for static SQL, performance can be maximized and then locked-in via a fixed
access plan. For certain applications it is essential to understand and lock in performance
behavior before a production system is rolled out.
Dynamic SQL can approach the benefits of a predetermined access plan by using a
dynamic statement cache. With a dynamic statement cache, the access plan is calculated
the first time a dynamic statement is executed. The plan for the dynamic SQL string is
cached by the database and reused the next time the same statement is executed. For
certain applications and environments that have high dynamic statement cache hit ratios,
it’s possible to approach the database performance of static SQL, by limiting the number of
times access plans are calculated at runtime. However, these dynamic applications must
be coded to produce maximum cache hits, and the dynamic cache environment must be
well tuned, in order to get a similar advantage using a dynamic cache to the one obtained
with static SQL. Static SQL is the only way to completely lock in the access plan ahead of
execution time for every statement.
D.3.2 Package level security
In addition to a locked-in access plan, static SQL provides a different SQL security model
using package level privileges. Because static SQL statements are known ahead of time,
users can be given authorization only for a specific set of SQL statements. These
statements are combined into a unit called a package. Static SQL statements can be
logically grouped into packages according to the needs of the security model. Users are
only granted permission to execute packages containing SQL that matches their access
level. With package level privileges, users cannot execute any SQL statements unless the
statements are contained in the packages the users have been granted the privilege to
execute.
This provides an important alternative to table-based privileges, which is the common
security model for dynamic SQL. With dynamic SQL, privileges are granted for specific
table operations, such as read or update on a table. The risk with granting table privileges
is they do not limit users to executing specific SQL statements. Users could potentially
execute any query or any update SQL statement on a table, once they have been granted
read or update privileges on the table. Even though a user’s application may be hardcoded
with a specific SQL string, a malicious user could potentially use table privileges to
execute dynamic SQL that is not contained within their application. Dynamic SQL injection
is one form of malicious behavior that takes advantage of this fact. Static SQL, with a
previously designed fix set of packages, and package level privileges, prevents this
unwanted behavior. Only the package owner, not each user, needs to be granted table
level privileges for static SQL. The package owner is usually the administrator who binds
the packages. Therefore good static package design can eliminate the risk of a user
maliciously executing unwanted SQL.