历史版本10 :数据更新报错 返回文档
编辑时间: 内容长度:图片数:目录数: 修改原因:

目录:

1. ORA-01555:snapshot too old编辑

1.1 问题现象

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

bn.png

1.2 原因分析

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

1.3 解决方案

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

2. Got timeout reading communication packets编辑

2.1 问题现象

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

vb.png

2.2 原因分析

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

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

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

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

2.3 解决方案

1)在 MySQL 数据库中查看wait_timeoutinteractive_timeout 参数,执行 SQL 语句:show global variables like '%timeout%';,如下图所示:

v.png

2)修改至合适的参数大小,执行 SQL 语句:set global wait_timeout=xxxx;  set global interactive_timeout=xxxx;       

3. Name or service not known编辑

3.1 问题现象

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

untitled.png 

3.2 原因分析

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

3.3 解决方法

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

 896.png

4. Out of memory编辑

4.1 问题现象

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

6.png

4.2 原因分析

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

4.3 解决方案           

检查 MySQL 中的key_buffer_size、max_heap_table_sizetmp_table_size三个参数,调整至合适的大小。可以参考:out of memory解决方法

5. ORA-01652: 无法通过128(在表空间 TEMP 中)扩展 temp 段编辑

5.1 问题现象

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

5.2 原因分析

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

5.3 解决方案       

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

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

具体可以参考:解决方法

6. data too long for column 'id' at row xxx编辑

6.1 问题现象

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

6.2 原因分析

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

6.3 解决方案

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

1)连接 FineDB 数据库,删除数据库的表fine_conf_entityfine_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 即可。

7. Futures timed out after [300 seconds]编辑

7.1 问题现象

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

7.2 解决方案

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

41.png

8. com.fr.transaction.ConfigException: java.lang.NullPointerException编辑

8.1 报错现象

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

8.2 原因分析

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

8.3 解决方案

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

9. 表异常标红编辑

9.1 报错现象

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

9.2 原因分析

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

9.3 解决方案

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

26.png

10. no such file or directory and file info编辑

10.1 问题现象

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

10.2 原因分析

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

10.3 解决方法

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

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