bug现场谜之报错也识趣-客户一上班报错就消失了！

1. bug现场情况

部署的是Java应用，容器中间件使用的是IBM WebSphere，数据库使用的是IBM DB2，数据源使用的是容器中间件提供的JNDI数据源服务。

程序在上班前的一段时间点击报错mybatis查询失败(sqlcode=-774 sqlstate=2D522)，上班之后就恢复正常了。生产环境的日志没有有效的信息，全是-774的报错，而把报错的sql拿出来在数据库执行没有问题，并且同样的sql在客户上班后系统中执行没有问题。

粗略在网上查一下，DB2数据库sqlcode=-774的含义是：Explanation: Statement cannot be executed within a compound SQL statement.，意思是“语句不能在复合sql中执行”；sqlstate=2D522的含义是： “ATOMIC 复合语句中不允许 COMMIT 和 ROLLBACK”。初步的判断可能和数据库的事务相关。

2. 尝试破案

日志中没有有效的报错信息，只能先观察程序表象。发现，报错的现象在中午13:00之后是能够稳定复现的，在14:30之后就稳定消失。问题出现的时候，随意刷新页面就会报错，具体后台就是-774，也就是mybatis执行sql不成功。而14:30之后，随便刷新页面都不会出现问题，即使客户端并发多个请求造成响应慢但是也不会出现报错-774。如果在报错这段时间重启了应用程序，则报错就会消失。

从以上信息，大概估计，问题应该是出现在了数据库连接池上。在某个时刻，程序用数据库连接池中的连接执行了某些操作，该数据库连接就处于了“异常”状态，其他任何功能用到该“异常”数据库连接执行sql时，就会报错，不是数据库有什么问题，而是连接数据库的数据库连接有问题。这样设想也解释了两点，第一：为什么同样的sql、同一时刻在程序中执行就会报错，而拿出来到数据库客户端中执行就没有问题；第二：程序报错的时候重启，重启后为什么就正常了。原因都是报错来自于用到了数据库连接池中“异常”的数据库连接。

那具体是什么样的操作造成了数据库连接池连接的异常呢？正常在日志中应该有所体现才对，生产环境IBM Websphere的日志太不方便看了，并且也没法设置参数重启进行监控。研究决定将生产环境迁移出来一份作为测试环境。原来容器中间件为IBM WebSphere迁移到Tomcat上。

迁移完成后程序运行一段时间后查看日志，发现最先开始报错的日志有如下内容：Processing was cancelled ... SQLSTATE=57014，日志显示在执行一个存储过程的时候，由于某种原因（可能是时间过长）客户端主动取消了。后来在网上查到了IBM官方的一个帖子：www.ibm.com/support/pag…。心里一下子豁然开朗了，这不就是DB2的一个bug吗？

IBM官方帖子说：“在DB2版本9上有一个bug，如果你在一个数据库连接中执行一个存储过程，因为某种原因客户端取消了，这时候在这个连接上执行的任何sql都会报错-774”。官方还提供了bug的补丁包。果然，找到报错的存储过程，处理之后，后续程序就没有出现过问题了。

这下找到了是什么样的操作导致数据库连接池中的连接“异常”了，就是DB2数据库的一个bug（存储过程被客户端取消后，使用同一连接执行sql都会报错-774），DB2在后续高版本上解决了这个bug。

3. 破案绊脚石

3.1 Tomcat JNDI容器数据源的配置

1). 配置server.xml中Resource。在GlobalNamingResources节点下增加节点Resource：

  </GlobalNamingResources>
    ...
    <Resource name="jdbc/court" global="jdbc/court"
        auth="Container"
        type="javax.sql.DataSource"
        driverClassName="com.ibm.db2.jcc.DB2Driver"
        url="jdbc:db2://xxx.xxx.xxx.xxx:50000/xxx:currentSchema=xxx;currentFunctionPath=xxx;"
        username=""
        password=""
        maxActive="20"
        initialSize="0"
        minIdle="0"
        maxIdle="8"
        maxWait="10000"
        timeBetweenEvictionRunsMills="30000"
        minEvictableIdleTimeMillis="60000"
        testWhileIdle="true"
        validationQuery="select current date from sysibm.sysdummy1"
        maxAge="600000"
        rollbackOnReturn="true"
        factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"/>
    ...
  </GlobalNamingResources>

2). 配置context.xml。在Context节点下增加节点ResourceLink：

<Context>
  <ResourceLink global="jdbc/court" name="jdbc/court" auth="Container" type="javax.sql.DataSource" />
</Context>

3). 配置数据源applicationContext.xml：

<bean id="datasource" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName">
        <value>java:comp/env/jdbc/court</value>
    </property>
</bean>

3.2 项目字符编码配置

由于解决问题的项目是10年前的老项目，因此项目的字符编码使用的是GBK。在迁移项目的过程中本地启动项目发现乱码，于是就尝试将xml文件的编码从GBK改为utf8。但是xml文件太多了，没有有效的工具能批量将GBK编码改为utf8编码。

实际上这个解决编码问题的思路方向走错了，如果原来项目使用的是GBK编码，那么迁移过也要使用GBK编码，而不是尝试将原来文本文件的字符编码进行修改。JVM参数指定项目字符编码的参数是：-Dfileencoding=GBK。

3.3 DB2数据库迁移

DB2数据库之前没有接触过，迁移一个DB2数据库到新的服务器上也没有什么经验。走了一些弯路，主要问题是迁移表缺失、数据量不匹配。需要注意的问题是：

db2lookup生成的迁移sql在目标db2服务上执行时，如果缺失表空间等元信息可能就会报错；一些sql语句可能在不同配置的环境上执行不了。关键是要验证表是否完整的迁移了，这一步是基础工作，非常重要。
一些表因为触发器、外键约束等的存在直接使用db2move命令迁移数据可能会不成功，这些表需要做单独的处理。

3.4 第一次听说currentFunctionPath这玩意

之前知道一些数据库的jdbcurl上支持配置一个currentSchema，表示默认查询的模式名，如果在jdbcurl配置上默认的schema，在程序中的sql可以省去查询语句表名前的schema。

迁移的程序启动后报错一个function找不到，但实际上数据库中该函数是存在的，将sql中函数前面加上模式名就可以调用成功。如果要将一个个函数都加上模式名实在太傻太累了，实际上这个方法是走偏了，应该上官网上找一找DB2的jdbcurl支持的参数，还真有currentFunctionPath这样的参数。有时候需要限定问题真正出现的范围，往这个范围查找。不然不从根本上解决问题会带来更多的问题或者非常大的工作量。

4. 总结

再着急的工作也一定要有个整体的方案，一些基础性的工作（例如数据迁移）是着急不来的，反而越着急，越会出问题，越影响整个进度。做整体方案的时候，那些脑海中一闪而过的担忧要仔细分析，不能心存侥幸心理、或者说后面再说。有些事情前期做成本很小，到了后期再做就会走非常多的弯路。
对于自己不熟悉的技术，一定要好好看看官网解释，不要随便找到一个网络上的命令就直接用，你们的场景可能是不太一样的，所需要的参数可能也是不同的，最好弄懂每个命令/参数的含义，不能着急，否则做了也会是有问题的。
问题一定是有原因的，可以暂时不去追根溯源，但要坚信肯定不是玄学。利用自己的知识将原因锁定在一定的范围内，大胆猜测、查资料、排查。
解决问题不能只解决表象，只解决表象可能还有大量问题等着你，实际上还是没有找到解决问题的途径。稳住参照3揪出来问题的元凶，就舒服了。