内行看门道,外行品味道
摘要:
浪擎对山东枣矿医院数据库故障分析和处理的报告 这篇纯技术帖是浪擎科技研发部主管在解决客户山东枣矿医院数据库故障后对该次技术支持服务所做的一份总结报告,在我们非技术人员看来,那就是四个字不明觉厉!看点点拨:内行,自然是看门道,欢迎业内行家参与
——浪擎对山东枣矿医院数据库故障分析和处理的报告
这篇纯技术帖是浪擎科技研发部主管在解决客户山东枣矿医院数据库故障后对该次技术支持服务所做的一份总结报告,在我们非技术人员看来,那就是四个字——不明觉厉!看点点拨:内行,自然是看门道,欢迎业内行家参与技术交流;外行,当然不是看热闹了,而是要品味浪擎的技术人员专业负责的态度和条理清晰的逻辑,以及浪擎售后服务支持体系的规范化。闲言少叙——
PART 1:数据库故障现象
主机重启后,数据库无法启动,通过offline datafile 15使得数据库正常open,但是ZSF 表空间数据无法访问,而且当时在该数据文件中还有事务,也就是说数据库除了datafile 15 offline不能访问外,还有可能crash 掉。
ALTER DATABASE RECOVER datafile 15
Tue Oct 28 14:38:23 2014
Media Recovery Datafile: 15
Media Recovery Start
Media Recovery Log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 245110 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG
Media Recovery failed with error 1115
ORA-283 signalled during: ALTER DATABASE RECOVER datafile 15 ...
Tue Oct 28 14:40:18 2014
alter database datafile 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF' offline drop
Tue Oct 28 14:40:18 2014
Completed: alter database datafile 'D:\ORACLE\ORADATA\ORCL\ZS
Tue Oct 28 14:40:25 2014
alter database open
ORA-1113 signalled during: alter database open
...
Tue Oct 28 14:40:32 2014
ALTER DATABASE RECOVER database
Media Recovery Start
Media Recovery Log
Recovery of Online Redo Log: Thread 1 Group 1 Seq 245110 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG
Media Recovery Complete
Completed: ALTER DATABASE RECOVER database
Tue Oct 28 14:40:41 2014
alter database open
Beginning crash recovery of 1 threads
Tue Oct 28 14:40:42 2014
Thread recovery: start rolling forward thread 1
Recovery of Online Redo Log: Thread 1 Group 3 Seq 245109 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO01.LOG
Recovery of Online Redo Log: Thread 1 Group 1 Seq 245110 Reading mem 0
Mem# 0 errs 0: D:\ORACLE\ORADATA\ORCL\REDO03.LOG
Tue Oct 28 14:40:42 2014
Thread recovery: finish rolling forward thread 1
Thread recovery: 0 data blocks read, 0 data blocks written, 2209 redo blocks read
Crash recovery completed successfully
Tue Oct 28 14:40:42 2014
Thread 1 advanced to log sequence 245111
Thread 1 opened at log sequence 245111
Current log# 2 seq# 245111 mem# 0: D:\ORACLE\ORADATA\ORCL\REDO02.LOG
Successful open of redo thread 1.
Tue Oct 28 14:40:43 2014
SMON: enabling cache recovery
SMON: enabling tx recovery
ORACLE Instance orcl (pid = 6) - Error 376 encountered while recovering transaction(7, 73) on object 25169.
Tue Oct 28 14:40:43 2014
Errors in file D:\oracle\admin\ORCL\bdump\orclSMON.TRC:
ORA-00376: file 15 cannot be read at this time
ORA-01110: data file 15: 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF'
尝试恢复datafile 15
SQL> recover datafile 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF';
ORA-00283: 恢复会话因错误而取消
ORA-01115: 从文件15 读取块时出现IO 错误(块# 1030071)
ORA-01110: 数据文件15: 'D:\ORACLE\ORADATA\ORCL\ZSF_DATA.DBF'
ORA-27069: skgfdisp: 尝试在文件范围外执行I/O
OSD-04026: 无效的参数经过. (OS 1030071)
PART 2:数据库故障原因
该错误原因是由于15 号文件大小超过了系统限制,读到block 1030071 进行恢复之时,由于系统限制,导致无法进行,从而使得恢复中止,datafile 15 无法正常恢复,也就无法online成功,从而也就无法访问ZSF 中数据。
故障原因总结:因数据文件写入数据高水位线到达8G,由于操作系统或者老版本Oracle限制,使得数据库重启后,无法在实例恢复之时读到8G 之外的数据,从而使得实例恢复失败,数据库无法正常启动。
PART 3:数据库故障解决思路
屏蔽datafile 15 利用redo 恢复,直接online 起来数据文件(该方法是没有办法中的办法,最大限度抢救该数据文件中数据)。
PART 4:数据库故障解决方法
1. Shutdown abort 数据库,为了能够进行不完全恢复。
2. 进行不完全恢复,并指定当前redo 路径,确保除datafile 15 之外,其他文件正常恢复完全。
3. 配置隐含参数_allow_resetlogs_corruption 和_minimum_giga_scn(屏蔽redo 恢复,和推scn),确保数据库所有数据文件scn一致。
4. 然后resetlogs 数据库,恢复完成。
PART 5:数据库故障解决的后续问题
后面由于datafile 15 里面数据文件中写入的数据已经超过了8G,但是接下来继续写入新数据,还是在原extent 中写入,但是由于超出了操作系统对该文件的控制限制,因此出现detail表无法插入数据。
PART 6:数据库故障解决的后续问题处理
1. 查询出来那些对象在报异常block 之后
SQL> col segment_name for a20
SQL> SELECT distinct OWNER, SEGMENT_NAME, SEGMENT_TYPE, A.PARTITION_NAME
2 FROM DBA_EXTENTS A
3 WHERE FILE_ID = 15
4 AND 1030071 <= BLOCK_ID;
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ -------------------- ------------------
PARTITION_NAME
------------------------------
ZSF DETAIL TABLE
ZSF DETAIL1 INDEX
ZSF DETAIL2 INDEX
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ -------------------- ------------------
PARTITION_NAME
------------------------------
ZSF DETAIL3 INDEX
ZSF DETAIL4 INDEX
ZSF FK_RECI_ORD INDEX
OWNER SEGMENT_NAME SEGMENT_TYPE
------------------------------ -------------------- ------------------
PARTITION_NAME
------------------------------
ZSF PREPAY1 INDEX
ZSF RECEDETAIL1 INDEX
2. 创建新表空间
Create tablespace zsf_new datafile
'D:\ORACLE\ORADATA\ORCL\ZSF_DATA_new01.dbf' size 4096m;
alter tablespace zsf_new add datafile
'D:\ORACLE\ORADATA\ORCL\ZSF_DATA_new02.dbf' size 128m autoextend on next 128M
maxsize 4096m;
3. 迁移异常对象到新表空间
alter table ZSF.DETAIL move tablespace ZSF_new;
alter index ZSF.DETAIL1 rebuild tablespace ZSF_new;
alter index ZSF.DETAIL2 rebuild tablespace ZSF_new;
alter index ZSF.DETAIL3 rebuild tablespace ZSF_new;
alter index ZSF.DETAIL4 rebuild tablespace ZSF_new;
alter index ZSF.FK_RECI_ORD rebuild tablespace ZSF_new;
alter index ZSF.PREPAY1 rebuild tablespace ZSF_new online;
alter index ZSF.RECEDETAIL1 rebuild tablespace ZSF_new;
本次创建index 慢,主要原因有:
1. 数据库版本为8i无法充分利用系统资源(内存和cpu)。
2. 8i的数据库版本,本身在设计上,无法满足现在高性能主机,大数据量的要求,执行本身就相对较慢。
补充说明:由于redo 太小,导致创建index 和move 操作太慢,增加redo 大小
alter database add logfile group 4 ('D:\ORACLE\ORADATA\ORCL\redo04.log') size
512m;
alter database add logfile group 5 ('D:\ORACLE\ORADATA\ORCL\redo05.log') size
512m;
alter database add logfile group 6 ('D:\ORACLE\ORADATA\ORCL\redo06.log') size
512m;
PART 7:事后的思考
由于数据库是8i,早就过了oracle 支持期限,而且当年的设计未考虑到现在的数据量,所以各个方面考虑不周,比如:
1. Win 上oracle 8i 只有32 位版本,标准支持内存不能超过1.7G,对于现在大内存主机无法充分利用资源。
2. Oracle 8i 因为没有Oracle 的进一步支持,出现bug 无法修复。
3. Oracle 8i 的在管理和维护方面,相比现在的Oracle 版本,已经太过于落后,不便于管理和维护。
本次遇到的故障,针对文件大小限制问题,升级到后续高版本就无该问题;针对创建index 效率低下问题,升级到高版本也会明显改善,建议升级数据库。