Oracle日志报03113,OracleORA-03113 ORA-600 [4193]故障处理

背景

有台服务器由于掉电导致数据库无法打开，处理过程如下。

1.故障现象

(1)启动现象

SQL> startup;

ORA-03113 end-of-file on communication channel

SQL> startup nomount;  # 可以nomount成功

SQL> alter database mount;

ORA-03113 end-of-file on communication channel

# 从上面现象根据数据库启动过程知道，基本定位在控制文件有问题。

(2)alert日志现象

Wed Jul 29 10:17:07 2020

ALTER DATABASE   MOUNT

USER (ospid: 3784): terminating the instance

System state dump requested by (instance=1, osid=3784), summary=[abnormal instance termination].

System State dumped to trace file E:\APP\ADMINISTRATOR\diag\rdbms\dzwl\dzwl\trace\dzwl_diag_2708.trc

Dumping diagnostic data in directory=[cdmp_20200729101712], requested by (instance=1, osid=3784), summary=[abnormal instance termination].

Instance terminated by USER, pid = 3784

2.故障分析

# 出了问题，通过询问现场人员，服务器有掉电、重启等操作，trace文件大多没有明确信息，

# alert日志中前一天有mmon进程的trm追踪文件的metadata元数据由于掉电损坏的记录，

# 但是跟此次故障无关，但是也可以看出确实由于掉电有文件损坏，紧接着使用10046 trace启动过程，

# 果然发现控制文件内容file header记录的seq号与推测为控制文件block header记录的bhcsq不一致。

# 排查步骤：

10046追踪

PARSING IN CURSOR #79065416 len=20 dep=0 uid=0 oct=35 lid=0 tim=8397179226 hv=1913505115 ad='7ff8f1ab3f40' sqlid='fr02x8dt0vjav'

alter database mount

END OF STMT

...

WAIT #79065416: nam='control file sequential read' ela= 147 file#=0 block#=16 blocks=1 obj#=-1 tim=8401282794

Error: kccpb_sanity_check_2

Control file sequence number mismatch!

fhcsq: 3714 bhcsq: 3717 cfn 0

...

3.故障解决

(1)尝试有没有好的控制文件

由于配制了闪回去，使用闪回区控制文件与数据文件目录控制文件依次尝试是否有完好的控制文件，发现控制文件均有问题。

(2)没有备份，只能重建控制文件

编辑创建控制文件语句:

CREATE CONTROLFILE REUSE DATABASE "DZWL" NORESETLOGS NOARCHIVELOG

MAXLOGFILES 16

MAXDATAFILES 100

MAXINSTANCES 2

MAXLOGHISTORY 453

LOGFILE

GROUP 1'E:\app\Administrator\oradata\DZWL\REDO01.LOG' SIZE 50M,

GROUP 2'E:\app\Administrator\oradata\DZWL\REDO02.LOG' SIZE 50M,

GROUP 3'E:\app\Administrator\oradata\DZWL\REDO03.LOG' SIZE 50M

DATAFILE

'E:\app\Administrator\oradata\DZWL\DATASYN01.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2019A.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2019B.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2020A.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2020B.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2021A_01.DBF',

'E:\app\Administrator\oradata\DZWL\DZWL2021B_01.DBF',

'E:\app\Administrator\oradata\DZWL\EXAMPLE01.DBF',

'E:\app\Administrator\oradata\DZWL\MT01.DBF',

'E:\app\Administrator\oradata\DZWL\SYSAUX01.DBF',

'E:\app\Administrator\oradata\DZWL\SYSTEM01.DBF',

'E:\app\Administrator\oradata\DZWL\UNDOTBS01.DBF',

'E:\app\Administrator\oradata\DZWL\USERS01.DBF'

CHARACTER SET ZHS16GBK;

4.正常mount，open再次报错ORA-600 [4193]

数据库可以正常mount，open阶段，报错ORA-600 [4193]，undo表空间有问题。

通过如下Mos文档解决：

ORA-600 [4193]错误解决方案

此解决方法适用于Version 9.2.0.1 to 11.2.0.3 [Release 9.2 to 11.2]，没有平台限制。

原因：

1， 可能是同一个UNDO块用于2个不同事务所引起的内部错误。

2， ORA-600 [4193] / ORA-600 [4194] for new transactions

3， ORA-600 [4137] for a transaction rollback

解决方案：

创建一个新的UNDO表空间，并且检查段是否有未回滚。

1.创建一个pfile文件

create pfile='E:\pfile.txt' from spfile;

windows平台默认是在database下，linux是在dbs下

2.关闭实例

shutdown immediate;

3.编辑pfile文件加入参数

undo_management = manual

event = '10513 trace name context forever, level 2'    # 将禁止smon进程执行事务回滚操作，以便顺利打开数据库，跳过回滚步骤

4.用pfile启动数据库

startup restrict pfile=;

5.检查是否所有的UNDO段都是offline状态，system段必须在线

select tablespace_name,status, segment_name from dba_rollback_segs where status != 'OFFLINE';

6.创建一个新的UNDO表空间

create undo tablespace UNDOTBS2 datafile ‘D:\oradata\undo02’ size 2000M;

7.删除旧的UNDO表空间

drop tablespace UNDOTBS1 including contents and datafiles;

8.关闭实例

shutdown immediate

9.启动到mount状态

startup mount

10.修改参数

alter system set undo_tablespace =’UNDOTBS2’  scope=spfile;

11.关闭实例

shutdown immediate

12.正常启动数据库

startup

此文档还适用  ORA-600 4194 4197

(6)总结

比较幸运，undo中没有事务，重新创建undo之后，并没有报错内部不一致，如果undo中有未提交事务，需要回滚，则还需要

继续特殊处理，才可以正常。