DB2 Universal Database: SQL 语句的生命周期
热 荐
【字体：小 大】
DB2 Universal Database: SQL 语句的生命周期
作者：－ 文章来源：－ 点击数：1455 更新时间：2006-4-22 
Paul Bird
摘自：IDUG Journal
2003 年 12 月 本文深入研究了 DB2 UDB 的一些内部构件，以及在对 SQL 语句进行处理的不同阶段（从向 DB2 UDB 提供语句的初始表示，到语句的编译，最后到语句的执行）这些内部构件之间如何交互。
对于很多 Unix、NT 和 OS/2 下的 DB2 Universal Database (UDB) 的用户来说，有关 DB2 如何分析和处理 SQL 语句这样的细节还是一个谜。本文深入研究了 DB2 UDB 的一些内部构件，以及在对 SQL 语句进行处理的不同阶段 —— 从向 DB2 UDB 提供语句的初始表示，到语句的编译，再到语句的执行 —— 这些内部构件之间如何交互。这里给出的基本信息同时适用于静态和动态 SQL 语句，因为这两种 SQL 语句都可以在 Unix、NT 和 OS/2 下的 DB2 UDB 中进行处理。
贯穿全文，术语“SQL 请求”将作为一个通称术语，用于指代与 SQL 语句相关的任何应用程序请求。在 DB2 UDB 的内部，对语句的处理实际上是按照 SQL 请求而不是 SQL 语句进行的。
基本概念
要理解 DB2 UDB 如何处理 SQL 语句，需清楚一个基本概念，那就是每一条单独的 SQL 请求都将被映射到 DB2 UDB 内一个特定的包。换句话说，为了处理一条 SQL 语句，请求者必须将该语句与一个特定的 DB2 UDB 包关联起来。对于与 SQL 语句有关的所有应用程序请求，例如 PREPARE、FETCH 和 CLOSE 来说，都是如此。命令行处理器(CLP）和 Call Level Interface（CLI）之类的接口对用户隐藏了这一事实，这些接口将在幕后执行必要的对包的管理。
什么是包？
包是一个信息群集，它控制着任何静态 SQL 语句的编译，同时还部分地控制着任何动态 SQL 语句的编译，而且，包还会影响在其作用域内发出的任何 SQL 请求的执行。包信息包括一些项，例如编译期间所使用的优化级别、在执行期间是否为合格的游标使用块（blocking）。所有这些信息都存储在 SYSCAT.PACKAGES 编目表（catalog table）中，作为表示这个包的一个条目。对于静态 SQL 语句，包还针对每一条语句有一个与其自身相关联的段（section）。段是 SQL 语句的 DB2 UDB 可执行版本。DB2 UDB 使用包作为一个基本授权控制点。为允许某人执行或维护包，可以针对包为之授予或撤消一定的特权（privilege）。这种信息反映在 SYSCAT.PACKAGEAUTH 中。
什么是段条目？
既然一个应用程序可能有很多不同的 SQL 语句（这些语句可能是静态的，也可能是动态的），那么应用程序就可以有一个包。为了使各条 SQL 语句的上下文清晰明了，同时也为了避免对于每一条请求都必须提供这种信息，DB2 UDB 将一个包细分成一些更小的单元，这些单元就叫做段条目（section entry）。段条目包含了有关 SQL 语句自身的信息（如果有的话）以及有关该 SQL 语句在应用程序中所处的上下文的信息。例如，对于一个游标，段条目包含该游标的名称、它是否是 WITH HOLD 游标以及该游标是否被定义为 FOR UPDATE。在执行期间，段条目包含关于与其相关的任何段的当前状态的信息。对于动态 SQL 语句，与一个包一起存储的段条目是空的，这里只是用来作为一个“书签”。
对于应用程序中的每一条惟一的 PREPARE、DECLARE CURSORS 请求或静态 SQL，都有一个惟一的段条目。当在应用程序中发现一条 EXECUTE IMMEDIATE 请求时，也会添加一个惟一的段条目。这个条目由同一应用程序中的所有其他 EXECUTE IMMEDIATE 请求共享。
该图是一个应用程序的内容与一个包中的段条目之间的对应关系的一个例子。我们可以看到，第一条静态 INSERT 语句与段条目 #1 相关联。接下来的两条 PREPARE 请求各自针对一条 SQL 语句（即 S1 和 S2），它们分别与段条目 #2 和段条目 #3 相关联。DECLARE CURSOR 语句所定义的静态游标与段条目 #4 相关联。接下来是两条连续的 EXECUTE IMMEDIATE 请求，这两条请求都与段条目 #5 相关联。最后，还有另一条对于 S2 的 PREPARE 请求。由于它不是一条惟一的语句，因此该请求跟先前的 PREPARE S2 请求一样与同一个段条目（即段条目 #3）相关联。
更精确的基本概念
现在我们已经有了关于一个包的内部格式的更多信息，因而可以重新表述起初的基本概念。关于 DB2 UDB 如何处理 SQL 请求的一个更准确的描述是：在 DB2 UDB 中，每一条请求都被映射为一个特定包中的一个特定段条目。
为什么需要包？
我们需要包的实际原因是，这些包允许 DB2 UDB 支持在同一个包内具有静态和动态 SQL 的任何混合形式。我们可以使用纯静态 SQL，也可以使用静态和动态 SQL 的混合形式，或者使用纯动态 SQL，来编写应用程序。DB2 UDB 通过使用包为所有这些方法提供了支持。通过使用包带来的另一大好处就是，开发人员在开发嵌入式 SQL 应用程序时，同样可以使用应用程序开发中用到的模块化编程技术。他们可以安排来自应用程序不同部分的 SQL 请求，以拥有不同的包，进而拥有不同的 SQL 上下文。有了包，就可以对应用程序采取更细粒度的授权控制。可以使用包授权来控制哪个用户可以执行整个的应用程序，或执行应用程序的一部分。而且，通过使用静态 SQL 语句，用户就可以执行一些特殊的请求（通过临时地采用包绑定者（binder）的特权不能执行这些请求），但这只适用于包的上下文中。
什么是段？
段是一条 SQL 语句的可执行的真实化身。它包含 DB2 UDB 在产生指定结果时所需的逻辑和数据访问方法。一个段由一系列的操作符和任何相关的操作数组成，这些操作符和操作数勾画出了数据访问的执行顺序以及最合适的操作。操作符对应于低级的访问和操纵数据的 DB2 UDB 函数。操作数代表数据元素（例如行、表、索引等）以及控制结构。段是 SQL 语句编译后的最终结果。SQL 编译器决定最有效的执行步骤以满足 SQL 语句，并产生一个段来实现这一计划。