计算机专业文献翻译优调SQL过程

《计算机专业文献翻译优调SQL过程》由会员分享，可在线阅读，更多相关《计算机专业文献翻译优调SQL过程（18页珍藏版）》请在装配图网上搜索。

1、外文资料译文及原文院（系）：计算机学院专 业：计算机科学与技术班 级：2401102学 号：20023011059姓 名： 指导教师： 2005年6月简介有关如何调优数据库系统和应用程序的好的建议的来源有很多。比如OLTP应用程序的DB2调优技巧(以前在 IBM DB2 开发者园地上发表)之类的文章通过使用事务和数据并行性以及分析查询方案，给出了从表空间和索引设计到缓冲池的内存分配等方面的建议。这些方面的内容是性能调优的基础知识。 但是，有关如何组织存储过程自身中的逻辑并着眼于其性能的专门建议却并不多见。本文就提供了这样一种建议。尽管本文着重于介绍 SQL 过程，但是这里所提供的大多数信息同样

2、适用于用其它语言编写的在应用程序中或存储过程中嵌入的 SQL 逻辑。背景知识和术语在深入研究详细问题之前，让我们先想想DB2 中有关过程化 SQL 的一些基本术语和概念。过程化 SQL 构造（例如标量变量、IF 语句和 WHILE 循环）是在 DB2 Universal Database (UDB) V7 发行版中引入 DB2 的。以前的 DB2 发行版支持 C 和 Java 作为存储过程的语言。V7 引入了 SQL 存储过程，以及其它许多可以促进 OLTP 应用程序开发的特性（例如临时表、应用程序保存点和标识列）。当创建 SQL 过程时，DB2 将过程主体中的 SQL 查询与过程逻辑区分开来

3、。为了使性能最优，SQL 查询被静态地编译成包中的节。（对于静态编译的查询而言，节主要是由 DB2 优化器为该查询选择的存取方案构成的。包是节的集合。在过程的执行期间，每当控制从过程逻辑流向 SQL 语句时，在 DLL 和 DB2 引擎之间就存在“上下文切换”。（在 DB2 V8 中，SQL 过程是在“不受保护的方式”下运行的，即与 DB2 引擎在相同的寻址空间中。因此我们这里谈及的上下文切换并不是操作系统级别上的完全的上下文切换，而是指 DB2 中层的更换。）减少频繁调用的过程（例如 OLTP 应用程序中的过程）或者处理大量行的过程（例如执行数据清理的过程）中的上下文切换次数，对它们的性能有

4、显著的影响。本文中的几个技巧恰好旨在减少这些上下文切换。刚开始的时候（DB2 通用数据库 V7 GA），只允许在 SQL 过程中使用 SQL 过程语言（通常称为 SQL PL）。后来（在 DB2 UDB V7.2 中），在 SQL 函数和触发器主体中开始支持该语言的子集。SQL PL 的这个子集即所谓的 内联（inline）SQL PL。“内联”一词突出显示了它与完整语言的重要区别。SQL PL 过程是通过将其单独的 SQL 查询静态地编译成包中的节实现的，而内联 SQL PL 函数就象其名称所展示的，是通过将函数主体内联到使用它的查询中实现的。稍后我们将再看一下内联 SQL PL 及其用法的

5、一些示例。 从多个 SQL 语句到一个 SQL 表达式跟其它编程语言一样，SQL 语言提供了两类条件构造：过程型（IF 和 CASE 语句）和函数型（CASE 表达式）。在大多数环境中，可使用任何一种构造来表达计算，到底使用哪一种只是喜好问题。但是，使用 CASE 表达式编写的逻辑不但比使用 CASE 或 IF 语句编写的逻辑更紧凑，而且更有效。使用 SQL 的一次处理一个集合语义,诸如循环、赋值和游标之类的过程化构造允许我们表达那些只使用 SQL DML 语句是不可能表达的计算。但是，当我们拥有一些可以随意使用的过程语句时，即使我们手头的计算实际上仅使用 SQL DML 语句就可表达，但转换

6、成过程语句还是有风险的。正如我们以前提到的，过程计算的性能与使用 DML 语句表达的同一个计算的性能相比会慢几个数量级。在研究改进现有过程逻辑的性能时，为消除游标循环而花费的任何时间都可能是值得的。改进游标性能如果存储过程中的逻辑确实需要游标，那么要使性能最优，请牢记下面这些内容。首先，请确保不使用高于您所需的隔离级别。隔离级别决定了 DB2 对过程读取或更新的行应用的锁定的数量。隔离级别越高，DB2 将执行的锁定越多，因此为同一资源而竞争的应用程序之间的并发就越少。例如，使用可重复读（Repeatable Read，RR）隔离级别的过程将形成对其读取的任何行的共享锁，而使用游标稳定性（Cur

7、sor Stability，CS）的过程只会锁定任何可更新游标的当前行。可以使用 DB2_SQLROUTINE_PREPOPTS 注册表变量来指定 SQL 过程的隔离级别。DB2 中缺省的隔离级别是游标稳定性。但是，当然了，为了保持应用程序的正确性，有时需要使用可重复读。还需记住一件重要的事情，一旦创建了需要可重复读的过程，必须将 DB2_SQLROUTINE_PREPOPTS 重新设置回较低的隔离级别。在尝试改进游标性能时需要牢记的一个相关问题是游标的可更新能力。如果游标涉及的行是可以使用 INSERT 或 DELETE 语句中的 WHERE CURRENT OF 子句进行更新或删除，那么它

8、就是 可删除的。当游标可删除时，DB2 必须获取行上的 互斥锁（与 共享锁相对），并且不能执行行分块。行上的互斥锁甚至可以防止其它应用程序读取该行（在互斥锁被释放之前，这些应用程序必须等待，除非它们的隔离级别是 UR），而行分块通过在一个操作中检索行块，从而减少了用于游标的数据库管理器开销。 只有不可删除的游标才可以进行行分块。这就是为什么让 DB2 了解将如何使用游标是很重要的原因。通过在 SELECT 语句中指定 FOR READ ONLY 子句，可以将游标显式地声明为不可删除，或者通过在 SELECT 语句中使用 FOR UPDATE 子句将其声明为可删除。根据该信息（并且还根据下面描述

9、的 BLOCKING 选项），DB2 将确定是否将行分块用于给定的游标。缺省情况下，对于那些使用 FOR READ ONLY 子句定义的游标，DB2 将始终使用行分块，除非指定了 BLOCKING NO 绑定选项。另一方面，如果使用了 BLOCKING ALL 绑定选项，那么对于含混游标（既不是定义成 FOR READ ONLY 也不是定义成 FOR UPDATE 的游标），DB2 将使用行分块。简而言之：如果可能，则在游标定义中使用 FOR READ ONLY 子句；如果您的过程包含含混游标，那么请使用 BLOCKING ALL 绑定选项。要设置 BLOCKING 绑定选项的值，我们还可以使

10、用 DB2_SQLROUTINE_PREPOPTS 注册表变量。在无副作用的情况下，请使用 SQL 函数。正如我们在简介中提及的，SQL 过程和 SQL 函数是使用不同技术实现的。SQL 过程中的查询是单独编译的，每个查询都成为包中的一个节。编译是在过程创建时进行的，直到重新创建过程或者直到重新绑定其相关的包时才重新编译这些查询。另一方面，SQL 函数中的查询是一起编译的，就好像函数体是一个查询一样。每当编译一条使用 SQL 函数的语句时，也会对 SQL 函数进行编译。与 SQL 过程中所发生的情况不同，SQL 函数中的过程语句与数据流语句是在同一个层中执行的。因此，每当控制从过程语句流向数据

11、流语句或相反时，并不发生上下文切换。因为存在这些区别，所以当给定的过程代码段作为函数实现时的执行速度通常比作为过程实现时要快。但是，当然了，有一个小问题。函数只能包含那些不会改变数据库状态的语句（例如 INSERT、UPDATE 或 DELETE 语句是不允许的）。并且只允许完整 SQL PL 语言的子集出现在 SQL 函数中（不能是 CALL 语句、游标和条件处理）。尽管有这些限制，但大多数 SQL 过程都可以在无副作用的情况下转换成 SQL 函数。因此，正如本节标题所展示的，当您只是从数据库抽取数据而不执行任何更改时，请考虑使用 SQL 函数而不是使用 SQL 过程。使用用于临时数据的临时

12、表在 V7 中，DB2 引入了临时表。对临时表的操作通常比对常规表的操作快。让我们看一些原因： 首先，临时表的创建不会涉及向目录中插入项，并且临时表的使用也不会涉及对目录的访问；因此，不会有目录争用问题。 因为临时表只能由创建它们的应用程序访问，因此在其操作中不会涉及锁定问题。 如果指定了 NOT LOGGED 选项，则不对临时表上的操作记录日志（当然，这样就不可能回滚更改）。因此，如果您的存储过程生成了大量临时数据，并只打算在数据库的一个会话中使用它们，那么请将这些数据存储进临时表，这样可以显著地改进性能。 在对 SQL 过程中的临时表进行任何应用之前，表定义在编译环境中必须是可用的。在执行

13、了 CONNECT RESET 命令后，临时表将不复存在。在运行时，应用程序必须确保在执行使用临时表的首个查询之前该表是存在的。最后的这个观察引出了一个我们从未提及的要点：引用临时表的任何查询都将被动态地编译，即使该查询被写成静态的 SQL。跟其它任何动态查询一样，在编译该查询之后，它将以已编译的形式保留在包高速缓存中。在下一次执行相同的查询时，仅当无法在高速缓存发现它时，DB2 才重新编译它。如果您打算创建相对较大的临时表，并对这些表运行几个查询，请考虑定义索引并对它们运行 runstats（显然后者是填充了表后进行的）。有关在 SQL 过程中使用临时表的最后一个说明是：如果需要根据在同一个

14、过程中创建的临时表返回结果集，那么必须在嵌套的复合语句中定义结果集。必须在嵌套的复合语句中定义结果集的理由是，DECLARE GLOBAL TEMPORARY TABLE 是一个可执行语句，而可执行语句只能在声明语句（例如 DECLARE CURSOR）之后编写。如果我们在游标定义之后在外部作用域中声明表，那么当编译 DECLARE CURSOR 语句时，该表在编译环境中将不可用，因此编译会失败。关于作者Gustavo Arocena是 DB2 SQL 编译器方面的技术经理。他于 1998 年加入 IBM 多伦多实验室，目前负责 SQL 过程和 SQL 解析器的开发。Gustavo 拥有多伦多

15、大学计算机科学硕士学位，研究方向是数据库查询语言。 优调SQL过程资深软件开发人员, IBM Canada Ltd. 2005 年 2 月普通 SQL 过程如果您有 Microsoft SQL Server 或 Sybase 方面的背景知识，那么您就会很好地了解这些过程。除了一条 CALL 语句，这个范例的应用程序中将不存在任何 SQL。通过这个范例所认识到的好处有两个：首先是封装。例如，如果查询十分复杂，就不应重复查询多次，而是应该将它存储在某一个地方。 其次是缓存。存储过程中的代码是预先编译的。而应用程序中的代码通常是动态代码。 为了解决第一个问题，DB2 支持内联 SQL PL 的概念。

16、DB2 允许将简单逻辑或查询封装在 SQL 函数中。当从调用者执行该 SQL 函数时，其主体就是扩展到调用者中的宏。为了解决第二个问题，DB2 使用了包缓存。该缓存不仅记住最近执行的过程，还记住了以前执行的语句。因此，在第一次编译 SQL 语句之后，后来的调用只要继续执行相同的执行计划即可。真是令人印象深刻！仅仅通过使用内联 SQL PL 就使所监控代码的运行速度提高了三倍。甚至连不返回结果集的简单 SQL 过程也可以用 SQL 函数取代。对于返回不止一个参数的过程，可以使用 SQL 表函数，它返回一个包含一行的表 每个输出参数为一列。对于包含一个输出的过程，可以只使用一个标量 SQL 函数。

17、注意，DB2 V8.2 还支持在 SQL 表函数中包含 UPDATE、DELETE、INSERT 和 MERGE。这意味着您甚至可以使用内联 SQL PL 封装数据库更改。使用临时表SQL 术语来说，DECLARE 表示所定义对象的目录中将不包含条目。因此，它在定义上是私有的。与之相比，DB2 UDB for zOS 所支持的已创建的全局临时表（Created Global Temporary Table）是在目录中定义的。当然，虽然它们的内容是私有的，但其定义却不是私有的。具有声明对象的灵活性（只要用户临时表空间是立即可用的，DBA 就不会再关心该应用程序在做什么）也带来了一个不足：对于要进

18、行编译的语句来说，这个对象必须存在。如果连接失败，或者该表已删除，那么每次重新声明这个表时，都需要重新编译引用 DGTT 的任何语句。DECLARE 和 DROP 之间的 insert 语句每次都要重新进行编译，因为 DB2 无法知道该 DGTT 下次是否将具有相同的属性。实际上，DECLARE 和 DROP 之间有许多语句，都可用于处理该临时表结果集的格式，直到它最终满足要求为止。为了避免这种疯狂编译，将该临时表的声明移至一个单独过程中会更合适一些，该过程只在启动工作负载时执行一次。正如您可以在上面看到的，其结果是令人震惊的。但这里将有更多要了解的东西。请观察取代 DROP 语句的 DELE

19、TE 语句。它将总是因用户引起的错误而失败，然后，将由一个 continue 处理程序解决这个错误。这里发生了什么事？为了提高速度，需要优化临时表，因此，当插入行时，DB2 不用费心在临时表中寻找空闲空间，而是将表行为替换为 APPEND ONLY。虽然常规的 DELETE 将删除这些行，但是它不会真正让 DB2 回收这些空间。应用程序将继续消费越来越多的用户临时表空间。实际上，另外一个因素在这里提供了帮助。那就是，所有 DGTT 都被声明为 NOT LOGGED。毕竟，您可以相当容易地重新构建临时表的内容。如果 NOT LOGGED 表在执行数据修改语句期间碰到了执行错误，那么对于 DB2

20、来说，就只有一个选择：清空（truncate）该表。而这就是 DELETE 语句所进行的工作。条件处理程序计算机语言有两种处理错误的常用方法。第一种方法要求程序在在进行每一个重大操作之后，检查错误。在 DB2 中编写 C-UDF 或 C 存储过程的开发人员已经学会在其代码的每条 EXEC SQL 语句之后检查 SQLCA。第二种方法就是具有专用的处理程序，“捕捉”各条语句所“抛出”的任何或特定错误条件。Java 和 C+ 编程人员都熟悉这一概念。SQL/PSM 标准为 SQL 过程语言定义了使用处理程序的第二种方法。然而，通常当从 Sybase 或 Microsoft SQL 服务器移植 TS

21、QL 过程时，或当仅仅对 SQL PL 应用 C 技巧时，都可以避免更现代的处理程序方法，而支持更为传统的错误检查方法。这些情况下要做的事情就是定义一个通用的“万能（catch-all）”处理程序，用于在局部变量中保存所有错误信息。然后，使用过程体中的显式错误处理代码进行错误处理。具有讽刺意味的是，在许多情况下，程序甚至可能不在乎检查 SELECT INTO 的结果是什么，因此，条件处理程序的工作是徒劳的。本例中，将完成以下几件事。首先，可以显式地检查 NOT FOUND 警告（如果想这样做的话），而不必在局部变量中保存 SQLCODE 和 SQLSTATE。事实的确如此，因为该警告可用于 S

22、QL 过程中的下一条语句。其次，所有错误或意想不到的警告实际上应该由异常处理程序来处理。除了按照发明者所计划的方式来使用该语言之外，这样做可避免复制和重新设置局部变量。IntroductionThere are many sources of advice available on how to tune database systems and applications. Articles like DB2 Tuning Tips for OLTP Applications, previously published on the IBM DB2 Developer Domain, prov

23、ide advice on topics ranging from tablespace and index design to memory allocation for buffer pools, exploiting transaction and data parallelism and analyzing query plans. These topics are the ABCs of performance tuning.However, specific advice on how to organize the logic in the stored procedures t

24、hemselves with an eye on performance is not that common. That is the kind of advice I provide in this article. Even though the article focuses on SQL procedures, most of the information provided here is applicable to SQL logic embedded in applications or in stored procedures written in other languag

25、esBackground and terminologyBefore going into the details, lets first review some basic terminology and concepts related to procedural SQL in DB2. Procedural SQL constructs (such as scalar variables, IF statements and WHILE loops) were introduced in DB2 with the release of DB2 Universal DatabaseTM (

26、UDB) Version 7. Prior releases of DB2 supported C and JavaTM as languages for stored procedures. Version 7 introduced SQL stored procedures. When an SQL procedure is created, DB2 separates the SQL queries in the procedure body from the procedural logic. To maximize performance, the SQL queries are s

27、tatically compiled into sections in a package. (For a statically compiled query, a section consists mainly of the access plan selected by the DB2 optimizer for that query. A package is a collection of sections. For more information on packages and sections, please refer to the DB2 SQL Reference,Volu

28、me1.) On the other hand, the procedural logic is compiled into a DLL (dynamically linked library).During the execution of a procedure, every time control flows from the procedural logic to an SQL statement, there is a context switch between the DLL and the DB2 engine. (In DB2 V8, SQL procedures run

29、in unfenced mode, i.e., in the same addressing space as the DB2 engine. Therefore the context switch we refer to here is not a full context switch at the operating system level, but rather a change of layer within DB2.) Reducing the number of context switches in procedures that are invoked very ofte

30、n (such as procedures in an OLTP application) or that process large numbers of rows (for example, procedures that perform data cleansing) can have a noticeable impact on their performance. Several of the tips in this article aim precisely at reducing these context switches.The SQL procedural languag

31、e (commonly referred to as SQL PL) was first allowed only in SQL procedures (DB2 Universal Database V7 GA). Later on (DB2 UDB V7.2), a subset of the language started to be supported in SQL functions and trigger bodies. This subset of SQL PL is known as inline SQL PL. The word inline highlights an im

32、portant difference with the full language. Whereas an SQL PL procedure is implemented by statically compiling its individual SQL queries into sections in a package, an inline SQL PL function is implemented, as the name suggests, by inlining the body of the function into the query that uses it. Well

33、revisit inline SQL PL later on, along with examples of its use.From multiple SQL statements to a single SQL expressionLike other programming languages, the SQL language provides two types of conditional constructs: procedural (IF and CASE statements) and functional (CASE expressions). In most circum

34、stances where either type can be used to express a computation, using one or the other is a matter of taste. However, logic written using CASE expressions is not only more compact, but also more efficient than logic written using CASE or IF statementsExploit the set-at-a-time semantics of SQL,Proced

35、ural constructs such as loops, assignment and cursors allow us to express computations that would not be possible to express using just SQL DML statements. But when we have procedural statements at our disposal, there is a risk that we could turn to them even when the computation at hand can, in fac

36、t, be expressed using just SQL DML statements. As weve mentioned earlier, the performance of a procedural computation can be orders of magnitude slower than the performance of an equivalent computation expressed using DML statements. When looking at improving the performance of existing procedural l

37、ogic, any time spent in eliminating cursor loops will likely pay off.Improve cursor performance.If the logic in your stored procedures does require cursors, here are a few things to keep in mind to maximize their performance.First of all, make sure you dont use an isolation level higher than what yo

38、u need. The isolation level determines the amount of locking that DB2 applies on the rows that the procedure reads or updates. The higher the isolation level, the more locking DB2 will perform, and therefore, the less concurrency between applications competing for the same resources. For instance, a

39、 procedure using Repeatable Read (RR) isolation level will cause share locks on any row it reads, whereas a procedure using Cursor Stability (CS) will only lock the current row of any updatable cursor. The isolation level for SQL procedures can be specified with the DB2_SQLROUTINE_PREPOPTS registry

40、variable.The default isolation level in DB2 is Cursor Stability. But of course, to preserve the correctness of an application, it is sometimes necessary to use Repeatable Read. What is important to remember is to revert DB2_SQLROUTINE_PREPOPTS back to a lower isolation level once procedures requirin

41、g Repeatable Read are created.The query above will execute with isolation level UR regardless the isolation level specified in DB2_SQLROUTINE_PREPOPTS.A related issue to keep in mind when trying to improve cursor performance is cursor updatability. A cursor is deletable if the rows it ranges over ca

42、n be updated or deleted using the WHERE CURRENT OF clause in UPDATE or DELETE statements. When a cursor is deletable, DB2 has to obtain exclusive locks (as opposed to share locks) on rows, and cannot perform row blocking. An exclusive lock on a row prevents other applications from even reading the r

43、ow (they have to wait until the lock is released, unless their isolation level is UR), whereas row blocking reduces database manager overhead for cursors by retrieving a block of rows in a single operation.Row blocking can only happen for non-deletable cursors. That is why it is important to let DB2

44、 know how a cursor is going to be used. Cursors can be explicitly declared as non-deletable by specifying the FOR READ ONLY clause in the SELECT statement, or as deletable by using the FOR UPDATE clause in the SELECT statement. Based on this information (and also on the BLOCKING option described bel

45、ow), DB2 will decide whether to use row blocking for a given cursor or not.By default, DB2 will always use row blocking for cursors defined using the FOR READ ONLY clause, unless the BLOCKING NO bind option has been specified. On the other hand, DB2 will use row blocking for ambiguous cursors (curso

46、rs that are not defined as either FOR READ ONLY or FOR UPDATE) if the BLOCKING ALL bind option is used.To make a long story short: when possible, use the FOR READ ONLY clause in your cursor definitions; if your procedures contain ambiguous cursors, use the BLOCKING ALL bind option. To set the value

47、of the BLOCKING bind option, we also use the DB2_SQLROUTINE_PREPOPTS registry variable.In the absence of side-effects, use SQL functions.As we mentioned in the introduction, SQL procedures and SQL functions are implemented using different technologies. Queries in an SQL procedure are compiled indivi

48、dually, each of them becoming a section in a package. The compilation occurs when the procedure is created, and the queries are not recompiled until the procedure is recreated or until its associated package is rebound.On the other hand, queries in SQL functions are compiled together, as if the func

49、tion body were a single query. The compilation occurs every time a statement that uses the function is compiled.Unlike what happens in SQL procedures, procedural statements in SQL functions are not executed in a different layer than dataflow statements. Therefore, there is no context switch every ti

50、me control flows from a procedural to a dataflow statement or vice versa.As a result of these differences, a given piece of procedural code will usually execute much faster when implemented as a function than when implemented as a procedure. But of course, there is a catch. Functions can only contai

51、n statements that do not alter the state of the database (for example, INSERT, UPDATE or DELETE statements are not allowed). And also only a subset of the full SQL PL language is allowed in SQL functions (no CALL statements, no cursors, no condition handling).Despite these restrictions, most SQL pro

52、cedures with no side-effects can be converted into SQL functions.So, as the title of this section indicates, consider using SQL functions instead of SQL procedures when youre just extracting data from the database without performing any changes.Use temporary tables for temporary dataIn Version 7, DB

53、2 introduced temporary tables. Operations on temporary tables are usually much faster than operations on regular tables. Lets look at some of the reasons:To begin with, the creation of a temporary table does not involve the insertion of entries in the catalogs, and use of the temporary table does no

54、t involve access to the catalogs either; therefore, there is no catalog contention. Because temporary tables are only accessible to the application that created them, there is no locking involved in their manipulation. If the NOT LOGGED option is specified, operations on temporary tables are not log

55、ged (at the expense, of course, of the possibility of rolling back changes). Therefore, if your stored procedures generate large amounts of temporary data that are only meant to be used within a session with the database, storing those data in temporary tables can result in significant performance g

56、ains.Before any use of a temporary table in an SQL procedure, the table definition must be available in the compilation environment.After the CONNECT RESET command, the temporary table will no longer exist. At runtime, the application will have to ensure that the table exists before the first query

57、that uses it is executed. This last observation brings up an important point we havent mentioned yet: any query that references a temporary table will be compiled dynamically, even if the query is written as static SQL. Like any other dynamic query, after the query is compiled, it will stay in compi

58、led form in the package cache. The next time the same query is executed, DB2 will recompile it only if it is not found in the cache.If you plan to create relatively big temporary tables and run several queries on them, consider defining indexes and running runstats on them (the latter obviously afte

59、r the table has been populated).One last comment on using temporary tables in SQL procedures: if you need to return a result set based on a temporary table that is created in the same procedure, the result set must be defined in a nested compound statement.The reason the result set must be defined i

60、n a nested compound statement is that the DECLARE GLOBAL TEMPORARY TABLE is an executable statement, and executable statements can only be written after declaration statements such as DECLARE CURSOR. If we declared the table in the outer scope after the cursor definition, the table would not be avai

61、lable in the compilation environment when the DECLARE CURSOR statement is compiled, and therefore the compilation would fail.Keep the DB2 optimizer informed. When a procedure is created, its individual SQL queries are compiled into sections in a package. The DB2 optimizer chooses an execution plan f

62、or a query based, among other things, on table statistics (for example, table sizes or the relative frequency of data values in a column) and indexes available at the time the query is compiled. When tables suffer significant changes, it may be a good idea to let DB2 collect statistics on these tabl

63、es again. And when statistics are updated, or when new indexes are created it may also be a good idea to rebind the packages associated with SQL procedures that use the tables, to let DB2 create plans that exploit the latest stats and indexes.Table statistics can be updated using the RUNSTATS comman

64、d. To rebind the package associated with an SQL procedure, you can use the REBIND_ROUTINE_PACKAGE built-in procedure (available in DB2 Version 8). About the authorGustavo Arocena is a technical manager in the DB2 SQL Compiler area. He joined the IBM Toronto Lab in 1998 and is currently responsible f

65、or SQL Procedures and SQL Parser development. Gustavo holds a Masters degree in Computer Science from the University of Toronto in the area of database query languages.Senior Software Developer, IBM Canada Ltd. 27 Jan 2005The trivial SQL ProcedureIf you have a Microsoft SQL Server or Sybase background, you know these procedures very well. The paradigm is to not have any SQL in the application other than a CALL statement. The perceived benefit of this paradigm is