问题现象：

               建立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对应配置。导致更新失败。

解决方法：

               1、在linux环境下查看hostname。

                2、通过命令 vi /etc/hosts进入配置文件hosts并且添加对应的  IP  hostname。

问题现象：

               单表更新成功但是后台报错out of memory。

报错截图：

                查看%FineBI%\logs下的fanruan.log文件，看到报错：Out of memory  如下图所示：

原因分析：

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

解决方法：           

               1、检查mysqld配置my.conf，查看key_buffer_size、max_heap_table_size和 tmp_table_size三个参数。

               首先查看key_buffer_size参数的大小，使用sql语句:show status like 'key_read%';如下图所示：

               接着是max_heap_table_size和tmp_table_size参数。它们一起限制了内部内存表的大小。

               2、调整至合适的参数大小。         

               通过检查状态值Key_read_requests和Key_reads来判断key_buffer_size参数配置是否合理。使用的sql语句分别为:

               show global status like 'key_read%'; show global status like 'key_blocks_u%';

               这里给出一个参数参考：比例key_cache_miss_rate = Key_reads / Key_read_requests * 100%尽可能低，至少是1:100。如果参数key_cache_miss_rate在0.01%以下的话，说明key_buffer_size分配的过多，可以适当减少。

               max_heap_table_size和tmp_table_size两个参数最好的配置是 Created_tmp_disk_tables / Created_tmp_tables * 100% <= 25% 。

问题现象：

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

原因分析：

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

解决方法：         

              1、查询默认临时表空间：

　　         select * from database_properties where property_name='DEFAULT_TEMP_TABLESPACE'

　           2、查询临时表空间状态:

　　         select tablespace_name,file_name,bytes/1024/1024 file_size,autoextensible from dba_temp_files

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

　　          alter database tempfile ‘/u01/app/oracle/oradata/orcl/temp01.dbf’ resize100m

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

　　           alter database tempfile ‘/u01/app/oracle/oradata/orcl/temp01.dbf’ autoextend on next5mmaxsize unlimited

               具体可以参考解决方法。

问题现象：

               建立mysql数据连接，打开BI进入数据准备之后显示为空白。

报错截图：

               查看%FineBI%\logs下的fanruan.log文件，看到报错：Data too long for column 'id' at row 1  如下图所示：

原因分析：

               MySQL中varchar字段默认长度为255，表的字段超过数据库中默认最大长度。

解决方案：

                1、删除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(1024);（1024为MySQL主键最大长度）

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