<< Click to Display Table of Contents >> 当前位置:  附录  错误码 复制链接

1. 模块错误码

错误码的前两位为模块码，代表错误所属的功能模块。

2.详细错误码

2.1 数据连接

2.1.1 120000003

问题描述：无法连接到数据库。

排查方法：检查数据库驱动版本。

问题原因：驱动版本过低导致，产品自带驱动和使用的数据库版本不对应。

解决方案：自定义上传新版本的驱动。        

2.1.2 120000016

问题描述：连接报错g5.util.GRTException: 数据库驱动没有找到请验证驱动名称是否正确。

排查方法：

1)到产品部署目录vividime\jdbcDriver\Default中查看是否存在默认驱动。

2)添加数据源页面，点击去”驱动管理”，查看上传的自定义驱动是否存在。

问题原因：

1)没有找到默认驱动。

2)没有上传自定义驱动或自定义驱动失效。

解决方案：添加数据源页面，重新上传自定义驱动。

2.1.3 120000043

问题描述：数据库连接报错Communications link failure。

排查方法：

1)检查URL，查看是否包含useSSL=false。

问题原因：客户本地使用的cenos8系统，可能会涉及到安全升级的原因

解决方案：数据库连接URL后面拼接&useSSL=false

2)先通过Ping命令、Telnet命令，测试是否可以和数据库通信；排查防火墙是否处于关闭状态；使用数据库连接工具，测试能否连接成功；排查产品日志，查看对应的报错信息。

问题原因：产品存在属性conn.create.timeout=30000，默认尝试连接数据库的时间为30秒，超过30秒没连上就会弹出超时提示。

解决方案：将属性conn.create.timeout的值改为较长时间，如2分钟（120000ms），重启产品后，再次尝试测试连接。

2.2 数据集

2.2.1 130000218

可能的情景：

•在ORACLE数据库中写了一个存储过程，报错：

问题原因：sql语句中存储过程名称不需要用引号进行标识。

解决方案：是否需要标识存在差异，请查阅数据库相关手册。

•入集市load数据时，数据库出现问题返回报错。

问题原因：由于数据库出行问题导致load数据出错，如：数据库连接太多导致本次连接失败。

解决方案：根据数据库返回错误信息，搜索相关解决方案，如更改数据库连接限制等，或者修改sql解决。

2.2.1 130000034

问题描述：预览数据集或者报告，不给参数传值，会报错。

排查方法：首先确认在sql数据集中自定义sql语句时是否引用参数，例如：select * from table where ID > ?{param1}，在执行数据时是不是未给参数传值。

问题原因：未给参数传值导致的。

解决方案：如果确认当前场景就是要不给参数传值，则去修改sql的写法为：select * from table <param1> where ID > ?{param1} <param1>，详情可参考数据集中使用参数中的第一点。

2.3 数据执行

2.3.1  140000004

•数据集报列不存在

通常是自服务数据集报列不存在，排查步骤如下：

1) 从end节点往前检查，找到最先报列不存在的节点。

2)查看元数据中是否存在报错的这一列（记得看一下隐藏列），如果确实不存在，报列不存在是正确的，如果存在这一列，继续下面的步骤。

3)看这一节点是否有计算列或过滤，逐个隐藏，排查是哪一个计算列或者过滤条件报的列不存在。

4)编辑计算列，查看计算列中col的写法是否正确，前后是否多了空格，有空格的话会跟列名匹配不上，报列不存在是正确的，调整计算列即可。

5)如果列都匹配的上仍报列不存在，大概率是bug，可以提流程。

•报告中报列不存在

与数据集中报列不存在的排查步骤类似。

1)首先确认是哪一个组件报的列不存在，可以通过日志查看，如下图，日志中会显示出报错的组件名称。

2)删除无关的组件，排除其它组件的影响。

3)查看元数据中是否存在报错的这一列（记得看一下隐藏列），如果确实不存在，报列不存在是正确的，如果存在这一列，继续下面的步骤。

4)看报告中是否有计算列，逐个绑定，排查是哪一个计算列报的列不存在。

5)编辑计算列，检查计算列中col的写法是否正确，前后是否多了空格，有空格的话会跟列名匹配不上，报列不存在是正确的，调整计算列即可。

6)如果列都匹配的上仍报列不存在，可能是bug，可以提流程。

总结：列不存在的问题通常跟计算列有关，计算列多层嵌套、数据集多层嵌套或者计算列引用的原始列改了别名，会导致找不到列报列不存在，排查的时候注意看客户是否做了这些操作。

2.4 数据集市

2.4.1 110000057

问题原因：不同名但列相同的数据集同时增量导入同一个集市文件夹，但是数据集上有列的数据类型不一致

解决方案：调整数据列类型一致即可。

2.4.2 210000162

问题原因：

原因1：join过程中通过link交换到磁盘中导致磁盘空间不足，磁盘空间不足会触发程序去删除一些交换文件，以保证程序正常运行。

解决方案：增大磁盘空间。

原因2：多线程问题

解决方案：提供报错时间段的bi日志，转售后跟踪。

原因3：空指针导致的入集市失败，需要分析的有两段堆栈日志。

解决方案：提供包含报错堆栈的bi.log转售后分析。如果异常堆栈未打印，需要在jvm参数中增加  -XX:-OmitStackTraceInFastThrow ，保证异常栈打印出来。

2.4.3 210000120

排查步骤：

1) 单M节点是否有宕机；多M节点下检查其中是否有M节点宕机，发送map任务失败的zb是不是存于宕机的M节点上；

2)检查map任务失败的zb文件在监控系统-集市文件夹信息统计，找到对应的集市文件夹，查看具体的zb文件是否存在，并且分布机IP是正常的。

3) 以上检查后都正常，那么就需要提供bi.log查看map任务失败后的堆栈，才能定位到具体是由于什么问题导致的map任务失败。

处理：需要提供日志中的报错堆栈才能定位具体问题。

2.5 系统管理

2.5.1 190000206

数据库系统同步时出现此报错，具体原因报packet for query is too large时：

原因：数据库默认的max_allowed_packet属性值比实际上传时候的数据要小，

解决方法：需要去数据库里面设置max_allowed_packet。

示例：set global max_allowed_packet = 10*1024*1024*10。

2.5.2 190000080

License不合法时，排查以下：

1)排查license中是否带有\，如果有去掉\后重试

2)查询mac，前往官网的授权验证页面校验license是否合法以及合法时间。

3）校验安装包的合法性：安装包是否正常，版本是否匹配。