在IBM DB2数据库中进行包的重绑定

重绑定是对先前已经与数据库进行了绑定的应用程序重新生成包(Package)的过程 当应用程序对应的包 被标记为不合法(Invalid)或不可 *** 作(Inoperative)的时候 用户必须对它进行重绑定 有的情况下 包虽然依然合法 但是用户为了提高程序的运行性能 如利用新的索引 或者在运行完RUNSTATS命令后利用新的系统优化数据 用户也会进行包的重绑定

如果应用程序的包依赖于某些数据对象 如表 触发器等 当这些数据对象被删除时 包将会被设置为不合法(Invalid) 不合法的包在下一次被执行的时候 会被数据库管理器自动执行重绑定的 *** 作 用户必须注意的是 如果系统自动执行重绑定失败 则程序在执行的时候会产生不可预料的错误 这时候也许程序的语句并没有错误 错误是由重绑定 *** 作失败造成的

但是如果用户的包依赖的数据对象有用户自定义函数(UDF) 则当该UDF被删除后 包会被设置为不可 *** 作(Inoperative) 被设置为不可 *** 作的包 必须要用户手动进行重绑定

另外当用户希望修改绑定过程的参数时 也需要重新执行绑定命令

lishixinzhi/Article/program/DB2/201311/11222

今天所做的程序最后封版，封版前觉得程序有一个地方让我很不爽，于是就进行了一下修改，改动其实很小，只是在if里面增加了一个判断条件，结果程序运行的时候开始报数据库系统错误，错误内容如下：

[DB2/NT] SQL0805N 找不到程序包 "NULLID.SYSLH203 0X5359534C564C3031"。 SQLSTATE=51002

到网上查找错误的原因，结果关于这方面的内容少之又少，Google中只找到两个网页，里面倒是提供了解决方案，不过原因不是很详细。继续搜索，最后在IBM官方网站上找到一个还算清楚的解释：

Solution

Depending on the type of statement you are executing, DB2 will use a particular package on the server. By default, DB2 creates three packages for each type of package. In this case NULLID.SYSLH2yy is reserved for statements with CURSORHOLD on and isolation level Cursor Stability. The package SYSLH203 means that DB2 is looking for the 4th package (200 is first, 201 is second, etc) of this type, but it does not exist. You can create more packages on the server by connecting to the database and issuing the following bind command from the /sqllib/bnd directory:

db2 bind @db2cli.lst blocking all grant public sqlerror continue CLIPKG 5

Note: CLIPKG 5 will create 5 large packages, and will give you the package that your application is looking for, as well as one more in this case.

源文档 <http://www-1.ibm.com/support/docview.wss?uid=swg21208123>

大致的意思是说DB2在执行SQL语句的时候会使用内部定义的包(package)来保持不同级别的游标的稳定性，包的名字就是“NULLID.SYSLH2XX”。DB2里面默认的时候会创建3个这样的包即SYSLH200, SYSLH201, SYSLH202，而当你的程序报“找不到程序包”的错误，并且程序包的名字的序号大于SYSLH202，也就说明DB2默认的包不够用了，DB2要求使用更多的包，但是这些包在DB2中并没有创建，因此DB2抛出了异常。

要解决这个错误有两种方法：一是执行上面的英文段中的粗体部分的命令，把DB2的包的个数扩大到5个，这样DB2就可以找到它需要的包；二是调整你的程序，优化结构，使得DB2不会用到多于3个的包，当然，这将会使你经历一个非常艰难的调试时刻。

至于我吗，由于是在封版时刻，自然选择最简单的处理方式——把错误的地方再改回来，虽然有点取巧，但是至少不会产生对数据库修改的需求 :-)

---