目录:
1、ORA-01555:snapshot too old编辑
问题现象:
建立oracle数据连接,更新一张9000万数据量的sql表失败。查看%FineBI%\logs下的fanruan.log文件,有报错:ORA-01555:snapshot too old,如下图:
原因分析:
SQL语句执行时间太长,或者UNDO表空间过小,或者事务量过大,或者过于频繁的提交,导致执行SQL过程中进行一致性读时,数据库回滚段占满,SQL执行后修改的前镜像(即UNDO数据)在UNDO表空间中已经被覆盖,不能构造一致性读块。
解决方法:
增加UNDO表空间大小,可以添加undo表空间的数据文件或者切换undo表空间,参考Oracle undo 表空间管理。
2、Got timeout reading communication packets编辑
问题现象:
单机部署的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;
3、Name or service not known编辑
问题现象:
linux系统下,BI全局更新卡住了,单个业务包更新失败。
报错截图:
查看后台报错如下图:
原因分析:
在linux环境下执行hostname,发现hostname为DISDB1,查看etc/hosts配置文件,文件中没有hostname对应配置。导致更新失败。
解决方法:
在配置文件hosts中添加对应的 IP hostname。
4、Out of memory编辑
问题现象:
单表更新成功但是后台报错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% 。
5、ORA-01652: 无法通过128(在表空间 TEMP 中)扩展temp段编辑
问题现象:
建立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
具体可以参考解决方法。
6、data too long for column 'id' at row xxx编辑
问题现象:
建立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即可。