本篇内容介绍了“怎么处理Oracle ORA-03113 ORA-600故障”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

1.故障现象(1)启动现象

SQL>startup;ORA-03113end-of-fileoncommunicationchannelSQL>startupnomount;#可以nomount成功SQL>alterdatabasemount;ORA-03113end-of-fileoncommunicationchannel

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

(2)alert日志现象

WedJul2910:17:072020ALTERDATABASEMOUNTUSER(ospid:3784):terminatingtheinstanceSystemstatedumprequestedby(instance=1,osid=3784),summary=[abnormalinstancetermination].SystemStatedumpedtotracefileE:\APP\ADMINISTRATOR\diag\rdbms\dzwl\dzwl\trace\dzwl_diag_2708.trcDumpingdiagnosticdataindirectory=[cdmp_20200729101712],requestedby(instance=1,osid=3784),summary=[abnormalinstancetermination].InstanceterminatedbyUSER,pid=37842.故障分析

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

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

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

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

# 排查步骤：

10046追踪

PARSINGINCURSOR#79065416len=20dep=0uid=0oct=35lid=0tim=8397179226hv=1913505115ad='7ff8f1ab3f40'sqlid='fr02x8dt0vjav'alterdatabasemountENDOFSTMT...WAIT#79065416:nam='controlfilesequentialread'ela=147file#=0block#=16blocks=1obj#=-1tim=8401282794Error:kccpb_sanity_check_2Controlfilesequencenumbermismatch!fhcsq:3714bhcsq:3717cfn0...3.故障解决(1)尝试有没有好的控制文件

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

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

编辑创建控制文件语句:

CREATECONTROLFILEREUSEDATABASE"DZWL"NORESETLOGSNOARCHIVELOGMAXLOGFILES16MAXDATAFILES100MAXINSTANCES2MAXLOGHISTORY453LOGFILEGROUP1'E:\app\Administrator\oradata\DZWL\REDO01.LOG'SIZE50M,GROUP2'E:\app\Administrator\oradata\DZWL\REDO02.LOG'SIZE50M,GROUP3'E:\app\Administrator\oradata\DZWL\REDO03.LOG'SIZE50MDATAFILE'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'CHARACTERSETZHS16GBK;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文件

createpfile='E:\pfile.txt'fromspfile;

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

2.关闭实例

shutdownimmediate;

3.编辑pfile文件加入参数

undo_management=manualevent='10513tracenamecontextforever,level2'#将禁止smon进程执行事务回滚操作，以便顺利打开数据库，跳过回滚步骤

4.用pfile启动数据库

startuprestrictpfile=<initsid.ora>;

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

selecttablespace_name,status,segment_namefromdba_rollback_segswherestatus!='OFFLINE';

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

createundotablespaceUNDOTBS2datafile‘D:\oradata\undo02’size2000M;

7.删除旧的UNDO表空间

droptablespaceUNDOTBS1includingcontentsanddatafiles;

8.关闭实例

shutdownimmediate

9.启动到mount状态

startupmount

10.修改参数

altersystemsetundo_tablespace=’UNDOTBS2’scope=spfile;

11.关闭实例

shutdownimmediate

12.正常启动数据库

startup

“怎么处理Oracle ORA-03113 ORA-600故障”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！