神马文学网对话大型机上的 DB2，SQL 篇
来源：百度文库 编辑：神马文学网 时间：2024/04/23 14:30:00
三种语言
大型机上的 DB2 数据库（DB2 for z/OS）作为数据库家族中的元老，数据库应该掌握的几种语言（即交互方式，见表 1），它当然是很在行的。
表 1. DB2 的交互方式
SQL ：世界语
SQL 的全称是结构化查询语言（Structured Query Language），最早的是 IBM 的 San Jose 实验室为关系数据库管理系统 SYSTEM R 开发的一种查询语言，SYSTEM R 就是 DB2 的前身。自从 IBM 公司 1981 年推出以来，SQL 语言得到了广泛的应用。如今无论是像 Oracle、Sybase、SQL Server 这些数据库管理系统，还是像 Visual FoxPro，PowerBuilder 这些微机上常用的数据库开发系统，都支持 SQL 语言作为标准的查询语言。
Command ：普通话
Command 是数据库提供给 DBA 们控制和调用各种数据库对象（Object）的利器，它有一套标准的格式（见图 1），有了它 DBA 可以很方便的了解数据库的各种状态，并加以调整。
图 1. Command 的格式
图 2. 执行‘DIS DB2(DSNDB04)’的实例
Utility ：方言
Utility 是 DB2 for z/OS 上特定的一组工具，它可以帮助 DB2 for z/OS 方便的完成 COPY CHECK INDEX, RUNSTATS 等众多日常的工作。Utility 分两种类型：online utilities 和 stand-alone utilities。online utilities 必须在 DB2 处于运行状态时才能执行，而 stand-alone utilities 则没有这个限制。Utility 是 DB2 for z/OS 自己的”方言”，它要靠 JCL（Job Control Language）作业去执行（见清单 1）。
清单 1. 运行 CHECK INDEX 的 JCL
//CHIWC55 JOB MSGLEVEL=(1,1),REGION=0M, // CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID //* - - - - - - - - - - - - - - - - - - - - - //CHECK EXEC PGM=DSNUTILB,PARM='DSN7,CHIWC55' //SYSPRINT DD SYSOUT=* //UTPRINT DD SYSOUT=* //SYSUT1 DD SPACE=(4096,(10000,10000)) //SORTOUT DD SPACE=(4096,(10000,10000)) //SYSIN DD * CHECK INDEX (ALL) TABLESPACE WC55DB1.ACACTGRP /*
回页首
走自己的路
两种 SQL
SQL 根据其使用的方式分为两种类型：静态 SQL 和动态 SQL（见表 2）。
表 2. SQL 的类型
运行嵌入式 SQL 的程序
图 3. “编译”嵌入式 SQL 程序
在 DB2 for z/OS 运行一个嵌入式 SQL 的应用程序总共有 4 步。
- Precompile
- Compile/Link-edit
- Bind
- Run (Execution)
DB2 for z/OS 是通过 JCL 作业来运行一个嵌入式程序的（以 COBOL 程序为例，见清单 2）。
清单 2. 运行嵌入式 SQL 程序的 JCL
//************************************************************** //* STEP1: PRECOMPILE THE SQL IN COBOL PROGRAM //************************************************************** //PC EXEC PGM=DSNHPC,PARM='HOST(COB2)',REGION=4096K ... //************************************************************** //* STEP2:COMPILE THE COBOL PROGRAM IF STEP1 IS OK //************************************************************** //COB EXEC PGM=IGYCRCTL,COND=(4,LT,PC), // PARM='DYNAM,LIB,OBJECT,RENT,APOST,MAP,XREF,LIST,DBCS' //* CICS(''COBOL3,SP'')' ... //************************************************************** //* STEP2: LINKEDIT IF THE PRECOMPILE AND COMPILE //* RETURN CODES ARE 4 OR LESS //************************************************************** //LKED EXEC PGM=IEWL,PARM='XREF,AMODE(31),RMODE(ANY)', // COND=((4,LT,COB),(4,LT,PC)) ... //************************************************************** //* STEP 3: BIND PROGRAMS //************************************************************** //PH02CS04 EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT) ... //SYSTSIN DD * DSN SYSTEM(SSID) BIND PLAN (TESTPLAN) MEMBER(PGM01) ISO(CS) QUALIFIER(ABC) VALIDATE(BIND) END //* //************************************************************** //* STEP 4: RUN //************************************************************** //RUNPGM01 JOB CLASS=A,MSGLEVEL=(1,1),NOTIFY=&SYSUID,MSGCLASS=H ... //SYSTSIN DD * DSN SYSTEM(SSID) RUN PROGRAM(PGM01) PLAN(TESTPLAN) END /* 执行动态 SQL
图 4. 执行动态 SQL 的工具
SPUFI（SQL Processing Using File Input）是 DB2 for z/OS 中最常用的执行动态 SQL 的工具。
图 5. SPUFI 运行的界面
请回顾一下表 2 中描述的动态 SQL 的特点，其实图 4 所示的这些工具就是正在运行的程序，它们都是通过宿主变量把 SQL 传给 DB2 for z/OS，然后再通过 PREPARE 决定这一次的存取数据方法和路径，最后通过 EXECUTE 执行这条 SQL 并返回结果。
以图 5 中执行的 SQL 为例：
CREATE TABLE TTEST (A VARCHAR(512));
SPUFI 会先把这串字符放到一个宿主变量 (STMTBUFF) 中：MOVE ‘CREATE TABLE TTEST (A VARCHAR(512))’ TO STMTBUFF
接着执行：PREPARE S1 FROM: STMTBUFF
最后执行：EXECUTE S1
回页首
你错了还是我错了
在与 DB2 for z/OS 对话的过程中，也经常会有’沟通不畅’的问题，这时 DB2 for z/OS 就会通过各种错误信息来告诉你，所以看明白 SQL 运行中出现的错误信息（见表 3），对于分析这些问题是至关重要的。
表 3. SQL 相关的错误信息
导致错误的原因可能是用户使用错误也可能是软件的 Bug，DB2 for z/OS 技术支持人员也是通过分析上述错误信息来诊断问题的。
Sqlcode
Sqlcode 是在执行 SQL 时最常见的一种错误。碰到这种问题时，完整的 SQLCA 对于辅助分析问题是很重要的
图 6. SQL Output
图 7. SQLCA
在 SQLCA 中有三部分信息是需要被关注的（见表 4）。
表 4. SQLCA 中关注的信息
① SQLCODE = -601 参考 DB2 UDB for z/OS V8 Codes，可以看到详细的问题描述以及基本的处理措施。 ② SQLERRP = DSNXISB2 这部分信息告诉大家是 DB2 for z/OS 哪个 Module 抛出的这个错误信息 ③ SQLERRD = 100 这部分信息显示位置标识符，它能够唯一标识 Module 中出错的位置
结合上述三部分信息，可以作出如下判断 :
SQLCODE -601 是 DSNXISB2 这个 Module 在位置 100 抛出的，原因是与所要创建的对象（TTABLE）重名。参考 DB2 UDB for z/OS V8 Codes 的相应章节，发现通过 DROP TABLE TTABLE 或者取另一个 Table 名可以解决这个问题。
注：如果是软件 Bug 导致错误地抛出了 SQLCODE，DB2 for z/OS 技术支持人员会根据上述 SQLCA 中的三部分信息 , 定位到出错的代码，进而根据代码上下文中的各种情况分析并找出问题的根源。
Abend (Abnormal end of Program)
顾名思义，Abend 会导致程序非正常结束。通常 Abend 信息会被记录到 EREP (DB2 for z/OS 的信息日志，见图 8），而且为了便于详细的分析导致异常的具体原因，DB2 for z/OS 常常会把系统异常时内存的实时信息存到叫 DUMP 的文件中。
图 8. EREP
在 Abend Description 中有三部分信息是需要被关注的（见表 5）:
表 5. Abend Description 中关注的信息
① CSECT NAME : DSNHXLTR 指出了出现异常的 Module ② ABEND CODE : 004E 指出了 Abend 类型。Abend 通常可分为两种类型：一种是 DB2 for z/OS 异常 , 如 04E; 另一种是操作系统异常 , 如 0C4。 ③ REASON CODE : 00C89014 参考 DB2 UDB for z/OS V8 Codes，可以看到 REASON CODE 的详细描述，以及相应的处理措施。
结合上述三部分信息，可以作出如下判断 :
Abend 是由于 DB2 for z/OS 的 Module DSNHXLTR 在运行过程中发现严重的错误，从而导致程序异常结束。通过参考 DB2 UDB for z/OS V8 Codes 的相应章节（见清单 3），可以知道 Abend 是程序在 precompiler 时做一致性检查发现错误所致。
注：如果 Abend 是软件 Bug 导致的，DB2 for z/OS 技术支持人员会根据 DUMP 中的信息找出发生错误时 Module 中各个变量以及结构的内容，进而找到导致错误的变量或结构 , 并结合代码分析并找出问题的根源。
清单 3. 00C8901x
3.6.1 00C8901x 00C8901x Explanation: An internal precompiler/parser consistency check failed. An S04E abend is generated. The error type and reason code are found in register 15 of the dump. In the reason code, x is one of the following:... …. 4. Error in pointer structures. …. System Programmer Response: Obtain the SVC dump and a copy of the application program source…
Incorrout (Incorrect output)
Incorrout 通常是指在执行 SQL 时，正确的结果应该是 DB2 for z/OS 返回记录 N，但却返回了记录 M。 Incorrout 多数是由于 SQL 的 Access Plan（即表 2中提到的 SQL 到数据库中存取数据的方法和路径）改变所致的。Visual Explain for DB2 for z/OS 是 IBM 提供的一个帮助客户图形化 Access Plan 的工具，请参见参考资源。
通过 Visual Explain 可以产生 SQL 对应的 Access Plan（见图 9）
图 9. Visual Explain
Access Plan 是 DB2 for z/OS 根据 Catalog Statistics 计算出来的，所以当遇到 Incorrout 问题时可以通过运行 RUNSTATS utility 获得最新的 Catalog Statistics，从而产生正确的 Access Plan。
注：如果 Incorrout 是软件 Bug 导致的，由于它没有出错信息 , 程序也没有异常结束，因此错误可能发生 DB2 for z/OS 决定 Access Plan 过程中的任一环节。对于这种问题，DB2 for z/OS 技术支持人员会先在 IBM 标准的 DB2 for z/OS 环境中重现这样的问题，然后再结合 Visual Explain 产生的 Access Plan，通过 DEBUG 工具分析产生这种 Access Plan 过程中涉及到的 Module，进而找出问题的根源。