数据更新报错

问题现象

建立 Oracle 数据连接，更新一张 9000 万数据量的 SQL 表失败，查看%FineBI%\logs下的 fanruan.log 文件，报错如下图所示：

原因分析

SQL 语句执行时间太长，或者 UNDO 表空间过小，或者事务量过大，或者过于频繁的提交，导致执行 SQL 过程中进行一致性读时，数据库回滚段占满，SQL 执行后修改的前镜像（即 UNDO 数据）在 UNDO 表空间中已经被覆盖，不能构造一致性读块。

解决方案

增加 UNDO 表空间大小，可以添加 undo 表空间的数据文件或者切换 undo 表空间，可以参考：Oracle undo 表空间管理。

问题现象

单机部署的 FineBI 业务包更新失败、单表更新失败。查看%FineBI%\logs下的 fanruan.log 文件，看到报错：错误代码:62400001Got timeout reading communication packets如下图所示：

原因分析

在 MySQL 通讯协议建立连接之后，此时客户端连接的时间受 wait_timeout和interactive_timeout参数控制。

interactive_timeout：指服务器关闭交互式连接前等待活动的秒数。

wait_timeout：指服务器关闭非交互连接之前等待活动的秒数。

两者生效取决于：客户端是交互或者非交互的连接。在交互模式下，interactive_timeout才生效；在非交互模式下，wait_timeout生效。出现更新问题是由于由于参数过小而导致连接超时，从而使得数据更新失败。

解决方案

1）在 MySQL 数据库中查看wait_timeout和interactive_timeout 参数，执行 SQL 语句：show global variables like '%timeout%';，如下图所示：

2）修改至合适的参数大小，执行 SQL 语句：set global wait_timeout=xxxx;  set global interactive_timeout=xxxx;       

问题现象

Linux 系统下，BI 全局更新卡住了，单个业务包更新失败。查看%FineBI%\logs下的fanruan.log文件，看到报错：DISDB1:DISDB1:Name or service not known，如下图所示： 

原因分析

在 Linux 环境下执行 hostname，发现hostname为DISDB1，查看etc/hosts配置文件，文件中没有hostname对应配置。导致更新失败。

解决方法

通过命令 vi /etc/hosts进入配置文件hosts并且添加对应的  IP  hostname，如下图所示：

问题现象

单表更新成功但是后台报错out of memory。查看%FineBI%\logs下的fanruan.log文件，看到报错：Out of memory  如下图所示：

原因分析

报错out of memory是需要看数据库的当时的状态和内存使用情况，可能是由于数据库不稳定引起的。

解决方案           

检查 MySQL 中的key_buffer_size、max_heap_table_size和 tmp_table_size三个参数，调整至合适的大小。可以参考：out of memory解决方法。

问题现象

建立 Oracle 数据连接并创建 SQL 数据集，预览和保存失败。查看后台出现此报错 ORA-01652: 无法通过 128 (在表空间 TEMP 中) 扩展 temp段

原因分析

临时表空间主要用途是在数据库进行排序运算、管理索引、访问视图等操作时提供临时的运算空间，当运算完成之后系统会自动清理。当临时表空间不足时，表现为运算速度异常的慢，并且临时表空间迅速增长到最大空间（扩展的极限），一般不会自动清理。如果临时表空间没有设置为自动扩展，则临时表空间不够时事务执行将会报ora-01652无法扩展临时段的错误。

解决方案       

方法一：增大临时文件大小。

方法二：将临时数据文件设为自动扩展。

具体可以参考：解决方法

问题现象

进行资源迁移后，打开BI进入数据准备之后显示为空白。查看%FineBI%\logs下的fanruan.log文件，看到报错：Data too long for column 'id' at row 1  如下图所示： 

原因分析

由于资源迁移前后两个系统下数据库字段默认长度设置不一致，某表中的'id'字段为业务包+表+字段名，比较长，当该'id'字段长度超过资源导入对应系统的数据库中默认的最大长度，则会出现此问题。

解决方案

修改需要资源导入的系统使用的数据库的字段默认长度即可。以FineBI内置的数据库findb为例：

1）连接 FineDB 数据库，删除数据库的表fine_conf_entity与fine_conf_classname中的'id'字段索引，重建该字段并修改长度。依次执行如下语句：

alter table fine_conf_entity drop primary key;
alter table fine_conf_entity add key(id);
alter table fine_conf_entity modify column id varchar(xxxx);  xxxx可以根据相应数据库字符长度设置合适大小。

2）对 classname 也进行此操作,然后重启 BI 即可。

问题现象

定时自动更新业务包时，后台出现报错Futures timed out after [300 seconds]。查看%FineBI%\logs下fanruan.log文件，看到报错:java.until.concurrent.TimeoutException:Futures timed out after [300 seconds],如下图所示：

解决方案

在finedb数据库中找到表fine_conf_entity，并增加参数（ID)DistributedOptimizationConfig.spiderConfig.spark_sql_broadcastTimeout，将VALUE值设为 12000 即可。如下图所示：

报错现象

日志报错：ERROR [standard] java.lang.NullPointerException  com.fr.transaction.ConfigException: java.lang.NullPointerException，所有数据集突然更新失败。

原因分析

内置数据库锁住（可能关闭工程的时候没杀干净，或者用第三方工具连过 finedb）

解决方案

在 %FineBI%/webapps/webroot/WEB-INF/embed/finedb 目录下删除 db.lck 文件或迁移数据库。

报错现象

表更新失败，且更新界面显示：com.fr.engine.bi.config.exception.IllegalTableMarkedException: 表异常标红

原因分析

数据库中的表字段产生了变化，与之前该表抽取到 FineBI 的数据不一样了。

解决方案

点击「编辑」按钮，「取消勾选」标红的字段。

问题现象

Linux 环境下，连接数据库后无法更新。

原因分析

Linux 中存储数据的文件夹没有读写权限。存储的文件夹和路径可在「数据准备>更新设置」中看到，详细请参见：数据更新与存放

解决方法

给存储更新数据的文件夹读写权限。

例如：存储数据的文件夹路径为/home/update data，那么 chmod -R 777 /home/update data  即可给该文件夹读写权限。

解决办法

排查集群环境的每个节点的WEB-INF/classes/com/，是否都放了 class 文件。

原因分析

数据库密码过期。

解决办法

修改数据库密码，并修改数据连接的密码。

解决办法

检查一下客户的报表模板是不是有表做错了

原因分析

两个环境共享了一个ZK。相同的表同一时间更新才会出现这个问题。

解决办法

修改zk路径。在fine_conf_entity中参数名：DistributedOptimizationConfig.spiderConfig.spider_zookeeper_lock_root_path

参数默认值：/DISTRIBUTED_LOCK_MANAGERTEST

原因分析

内存化参数设置为10000，实际值为40573，需要调大内存化参数。内存化指的是将表数据全部加载到内存中进行计算。

解决办法

调大内存化参数。参见文档：BI/Spider参数

解决办法

看一下分析表的父表，是否更新成功过（看数据占用空间是否为0kb）。（T_XXXX一般为父表的数据文件）

解决办法

1）删除定时更新任务的触发记录，删除finedb中的QRTZ开头的表中的所有数据，后重启BI；

2）重新修改一下之前的定时任务，保存。

原因分析

tomcat 重复启动，有多个进程。

解决方案

关掉tomcat后重新启动。

解决办法

查看更新的表所用数据（基础表或者数据库表）是否变化

原因分析

BI申请资源超过spark 系统资源；BI端防火墙未开放，需要确认防火墙的状态

解决方案

修改bi端spark资源相关配置，spark_executor_memory；spark_executor_cores；spark_cores_max，如果资源配置正常，则查看是否存在遗留进程占用资源；关闭bi端防火墙，或者允许bi应用通过防火墙。

解决方案

参考文档：Linux最大打开文件数

原因分析

作用于该组件的关联关系字段不唯一导致的

解决办法

排查关联关系是否符合1:1/1:N/N:1

解决方案

去数据库中查看该表是否还存在

原因分析

数据库方言权限相关问题

解决方案

重新设置数据库相关权限

原因分析

61300108的报错主要是alluxio服务和block id的问题
解决方案

alluxio组件增加个参数配置，alluxio.network.netty.heartbeat.timeout.ms=1800000

原因分析

1）分析表与基础表的字段类型不一致； 2）基础表和数据库字段类型不一致

解决方案

1）将用到的基础表删除后重新添加后更新；2）将基础表重新编辑保存；

问题现象

nested exception is java.lang.NoClassDefFoundError

原因分析

jar包冲突问题，是由于hive-jdbc-1.1.0-cdh5.13.0-standalone.jar里面的jackson的包冲突了导致，和bi本身冲突

解决方案

把上面冲突的jar从lib里面删除即可。

原因分析

数据库的报错，非更新bug，jdbc不支持

解决办法

字段设置那里编辑后重新保存下就可以了。

原因分析

 linux文件数设置过小。

解决方案

linux打开文件数问题。

解决办法

排查集群环境的每个节点的WEB-INF/classes/com/，是否都放了class文件

原因分析

数据库字段增加，增量删除报错了。

解决方案

重新编辑字段，全量更新一下。

解决办法

调大数据库的临时表空间的大小。

原因分析

在更新的过程中同时看仪表板了；没更新完，报错取不到锁是正常现象。

原因分析

客户没有迁移数据库，可能有多个工程连接了finedb，或者用第三方工具连接了finedb导致启动加载时连接被锁住

解决办法

迁移数据库

问题现象

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of 'net_write_timeout' on the server.

原因分析

数据库写操作超时

解决方法

1）可以调小一下基础表更新线程的并发：设置该参数DistributedOptimizationConfig.spiderConfig.spider_base_update_thread_proportion，默认为30，可以设为20或25；

2）修改并发参数tableLoadThreadPoolNum，由默认20改为10；

3）调大net_write_timeout参数值：连接数据库，执行show global variables like '%timeout%'，再执行 SET GLOBAL net_write_timeout = XXX（默认60，需要调大一点）

解决方法

更换lic文件

原因分析

任务在更新中，此时重启环境会认为更新中的更新失败并报错。

513 上报错信息会优化成：重启BI后清理正在更新中的更新任务为失败