bug现场谜之报错也识趣-客户一上班报错就消失了！
内容提要
文章讨论了在使用IBM WebSphere和DB2数据库的Java应用中遇到的mybatis查询失败问题，错误代码-774与数据库连接池异常有关，分析发现是DB2的一个bug导致的。迁移到Tomcat后，问题得到解决，同时提到迁移过程中遇到的字符编码和数据库函数调用问题。
延伸解读
问题根源：DB2连接状态异常
文章指出，报错-774并非SQL本身问题，而是数据库连接池中的某个连接因DB2的bug进入异常状态。该bug表现为：存储过程被客户端取消后，同一连接上执行任何SQL都会报错-774。这解释了为何同一SQL在数据库客户端正常，而在应用中报错，以及重启应用后问题消失。
迁移验证与官方补丁
为排查问题，作者将应用从WebSphere迁移到Tomcat，从而捕获到关键日志“Processing was cancelled ... SQLSTATE=57014”，并找到IBM官方帖子确认这是DB2版本9的已知bug。官方提供了补丁包，处理报错的存储过程后问题不再出现。这提示在遇到类似连接级异常时，可查阅官方bug库并考虑升级或打补丁。
迁移中的编码与配置要点
迁移老项目时，若原项目使用GBK编码，应通过JVM参数-Dfileencoding=GBK保持编码一致，而非批量转换文件编码。配置Tomcat JNDI数据源需在server.xml和context.xml中正确设置Resource和ResourceLink。对于DB2，可在JDBC URL中使用currentSchema和currentFunctionPath参数指定默认模式与函数路径，避免在SQL中硬编码模式名。
Q&A
在使用IBM DB2时，错误代码-774表示什么？
错误代码-774表示语句不能在复合SQL中执行，sqlstate=2D522表示ATOMIC复合语句中不允许COMMIT和ROLLBACK。
为什么在特定时间段内mybatis查询会失败？
在中午13:00后，数据库连接池中的连接可能处于异常状态，导致mybatis查询失败，14:30后问题消失可能与连接恢复正常有关。
如何解决DB2数据库连接池异常的问题？
迁移到Tomcat后，需配置server.xml和context.xml，确保数据库连接正常，并处理DB2的bug。
迁移项目时字符编码应如何处理？
迁移项目时应继续使用GBK编码，而不是尝试转换为UTF-8，以避免乱码问题。
在迁移DB2数据库时需要注意哪些问题？
需要注意表缺失和数据量不匹配，使用jdbcurl的currentSchema和currentFunctionPath参数可简化查询。
DB2数据库的bug是什么，如何影响查询？
DB2的bug导致存储过程被客户端取消后，使用同一连接执行SQL会报错-774，影响查询的正常执行。
