下载掌阅APP，畅读海量书库
立即打开
对于Java.NET和很多其他可以执行动态SQL语句的语言，DB2会在运行时（即准备语句时）确定该语句的访问路径（优化）。由于要在运行时优化，可能会使其性能比静态SQL语句的性能差。不过，如果一个应用经常执行相同的SQL语句，那么它可以使用动态SQL语句缓存来减少准备这些动态语句的次数。
一些工作室把动态SQL缓存设置为On（即打开动态SQL语句缓存），如果是这样，已准备好的语句优化会存储在系统缓存中，以后执行相同语句时可以使用（可能由同一个进程执行，也可能由另一个进程基于一个不同的值来执行）。不过，除了宿主变量中的值可以不同，要执行的所有后续SQL语句必须与缓存的SQL语句完全匹配。要记住，所有后续语句必须提供相同的用户ID。如果用户A和用户B都运行相同的SQL语句，第一次执行时它们会分别完成一个完整的准备（而不能使用另一个用户缓存的语句）。
所以，对于可以执行动态SQL语句的语言，要利用参数标记（?）准备SQL语句，这很重要。如果将值移入宿主变量，然后通过引用宿主变量来准备语句，就会使用具体值完成优化。在这种情况下，以后每次使用不同的值执行这个语句时，都会另外完成一次语句准备，因为每次语句都与之前有所不同。这样还会占满缓存，导致其他共享缓存的应用性能下降。
DB2 V10现在已经有所改进，即使缓存中的准备语句是使用硬编码直接量建立的，对于其他包含不同值的查询，DB2 V10现在也能重用缓存中的这个准备语句。V10把动态语句缓存称为直接量替换（literal replacement）。由于DB2能够识别出一个SQL与之前的SQL相同（只是直接量值有所不同），这样就能大大减少实现语句重用所需的工作。如果一个应用在SQL语句中使用了大量直接量，就可以采用很多方法来启用这个特性。
可以修改SQL PREPARE语句，在其中包含新的ATTRIBUTES子句，并指定CONCENTRATE STATEMENTS WITH LITERALS，如下例所示：
SET：HV1='CONCENTRATE STATEMENT WITH LITERALS'；
PREPARE STMT
ATTRIBUTES：HV1
FROM HV-SQL-TEXT；
接下来，修改JSS驱动程序来包含enableliteral-replacement=YES关键字（在数据源或连接属性中指定）。然后修改ODBC初始化文件，设置在z/OS中启用LITERAL REPLACEMENT，这会使得通过ODBC提交到DB2的所有SQL启用直接量替换。
通过使用参数标记，可以提供一个更高的动态语句缓存命中率，不过使用直接量通常能提供更好的访问路径。因此，是否使用这个方法要根据动态SQL调用的性能特性做出权衡。