问题现象：

               建立oracle数据连接，更新一张9000万数据量的sql表失败。

报错截图：

              查看%FineBI%\logs下的fanruan.log文件，看到如下报错：

原因分析：

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

解决方法：

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

问题现象：

               单机部署的FineBI业务包更新失败、单表更新失败。

报错截图：  

               查看%FineBI%\logs下的fanruan.log文件，看到如下报错：

原因分析：

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

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

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

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

解决方法：

                在mysql数据库中查看wait_timeout和interactive_timeout 参数：show global variables like '%timeout%'

                修改至合适的参数大小：set global wait_timeout=xxxx; set global interactive_timeout=xxxx;

问题现象：

                linux系统下，BI全局更新卡住了，单个业务包更新失败。

报错截图：

                查看后台报错如下图：

原因分析：

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

解决方法：

               在配置文件hosts中添加对应的  IP  hostname。

问题现象：

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

报错截图：

原因分析：

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

解决方法：           

               检查mysqld配置my.conf，查看key_buffer_size, max_heap_table_size, tmp_table_size参数，并调整至合适的参数大小。

               key_buffer_size：通过检查状态值Key_read_requests和Key_reads：show global status like 'key_read%' 

show global status like 'key_blocks_u%'可以知道key_buffer_size（ 通过show status like 'key_read%'语句查看）设置是否合理。比例key_cache_miss_rate = Key_reads / Key_read_requests * 100%尽可能低，至少是1:100，1:1000更好（上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得）；如果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进入数据准备之后显示为空白。

报错截图：

原因分析：

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

解决方案：

                删除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主键最大长度）

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