本篇内容介绍了“怎么处理Oracle ORA-03113 ORA-600故障”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
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 = 37842.故障分析
# 出了问题，通过询问现场人员，服务器有掉电、重启等操作，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=<initsid.ora>;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 immediate9.启动到mount状态
startup mount10.修改参数
alter system set undo_tablespace =’UNDOTBS2’ scope=spfile;11.关闭实例
shutdown immediate12.正常启动数据库
startup“怎么处理Oracle ORA-03113 ORA-600故障”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！
