你通过添加--logLevel=debug和--logFile来收集详细日志的思路完全正确，这是定位这类Schema生成失败问题最直接有效的方法。接下来可以从以下几个方向去分析生成的/tmp/res.log日志：

1. 先查Schema权限是否足够 #

• 确认执行命令的数据库用户USER对失败的Schema拥有足够的权限：比如能SELECT该Schema下所有表、视图，同时有权访问DB2的系统目录表（比如SYSCAT.TABLES、SYSCAT.COLUMNS这些）——Liquibase生成变更日志时必须读取这些系统表来获取元数据。
• 如果日志里出现SQLCODE=-551这类错误，基本就是权限不足，找DBA给用户补对应权限就行。

2. 排查Schema里的特殊数据库对象 #

Liquibase 3.8.0对某些DB2对象类型的支持可能存在局限，比如：

• 自定义数据类型（UDT）
• 触发器、存储过程或用户定义函数（UDF）
• 大对象（LOB）字段
• 分区表、临时表
• 带有循环依赖外键、复杂检查约束的表

你可以在日志里找失败前最后处理的对象，定位到具体是哪个对象拖了后腿，然后试试：

• 先暂时排除这个对象，单独对其他对象执行generateChangeLog验证是否正常
• 查一下Liquibase 3.8.0的官方文档，确认是否支持该对象类型，或者有没有额外配置项需要开启

3. 验证DB2驱动与版本的兼容性 #

你用的是DB2 9.7.2的db2jcc4.jar，结合Liquibase 3.8.0的话要注意：

• 确保驱动版本和DB2服务器版本匹配（你连接的服务器也是9.7.x吧？）
• 可以试试替换成更高版本的db2jcc4.jar（比如10.5或11.1版本），旧驱动可能对某些Schema元数据的读取存在bug

4. 细化日志的关键词搜索 #

在/tmp/res.log里重点搜这些关键词，能快速定位问题：

• ERROR或Exception：直接找异常堆栈，看具体抛出了什么错误
• Failed to read：看Liquibase尝试读取哪个对象的时候挂了
• SQLCODE：DB2的错误码，查DB2官方文档就能知道具体原因

另外，你还可以尝试给命令加上--schemaName参数，明确指定要生成日志的Schema，避免Liquibase扫描其他Schema时出现干扰：

./liquibase --logLevel=debug --logFile=/tmp/res.log --driver=com.ibm.db2.jcc.DB2Driver --classpath=/opt/db2/9.7.2/java/db2jcc4.jar --changeLogFile=/tmp/db.changelog.xml --url="jdbc:db2://00.00.000.000:50001/base" --username=USER --password=PASSWORD --schemaName=你的失败Schema名称 generateChangeLog

如果日志里的错误信息还是不够明确，也可以考虑升级Liquibase到较新的版本（比如3.10.x或者4.x分支），新版本对DB2的兼容性更好，大概率已经修复了你遇到的这类bug。

内容的提问来源于stack exchange，提问作者CBJ