问题现象：

               建立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 og 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、参考如何使用第三方管理软件连接内置hsql数据库finedb连接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即可。如下图：