大型机上的 DB2 数据库(DB2 for z/OS)作为数据库家族中的元老,数据库应该掌握的几种语言(即交互方式,见表 1),它当然是很在行的。 表 1. DB2 的交互方式
SQL 的全称是结构化查询语言(Structured Query Language),最早的是 IBM 的 San Jose 实验室为关系数据库管理系统 SYSTEM R 开发的一种查询语言,SYSTEM R 就是 DB2 的前身。自从 IBM 公司 1981 年推出以来,SQL 语言得到了广泛的应用。如今无论是像 Oracle、Sybase、SQL Server 这些数据库管理系统,还是像 Visual FoxPro,PowerBuilder 这些微机上常用的数据库开发系统,都支持 SQL 语言作为标准的查询语言。 Command 是数据库提供给 DBA 们控制和调用各种数据库对象(Object)的利器,它有一套标准的格式(见图 1),有了它 DBA 可以很方便的了解数据库的各种状态,并加以调整。 图 1. Command 的格式 图 2. 执行‘DIS DB2(DSNDB04)’的实例 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
SQL 根据其使用的方式分为两种类型:静态 SQL 和动态 SQL(见表 2)。 表 2. SQL 的类型
图 3. “编译”嵌入式 SQL 程序 在 DB2 for z/OS 运行一个嵌入式 SQL 的应用程序总共有 4 步。
DB2 for z/OS 是通过 JCL 作业来运行一个嵌入式程序的(以 COBOL 程序为例,见清单 2)。 清单 2. 运行嵌入式 SQL 程序的 JCL
图 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 是在执行 SQL 时最常见的一种错误。碰到这种问题时,完整的 SQLCA 对于辅助分析问题是很重要的 图 6. SQL Output 图 7. SQLCA 在 SQLCA 中有三部分信息是需要被关注的(见表 4)。 表 4. SQLCA 中关注的信息
结合上述三部分信息,可以作出如下判断 : 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 中关注的信息
结合上述三部分信息,可以作出如下判断 : 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
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,进而找出问题的根源。 |
|