内容简介:联系:标题:作者:
联系: 手机/微信(+86 13429648788) QQ(107644445)
作者: 惜分飞 ©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
数据库启动报ORA-600 kokasgi1错误
SMON: enabling tx recovery Database Characterset is WE8ISO8859P1 Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_10056.trc (incident=269259): ORA-00600: internal error code, arguments: [kokasgi1], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/incident/incdir_269259/xifenfei1_ora_10056_i269259.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_10056.trc: ORA-00600: internal error code, arguments: [kokasgi1], [], [], [], [], [], [], [], [], [], [], [] Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei1/trace/xifenfei1_ora_10056.trc: ORA-00600: internal error code, arguments: [kokasgi1], [], [], [], [], [], [], [], [], [], [], [] Error 600 happened during db open, shutting down database USER (ospid: 10056): terminating the instance due to error 600 Instance terminated by USER, pid = 10056 ORA-1092 signalled during: alter database open resetlogs... opiodr aborting process unknown ospid (10056) as a result of ORA-1092 Sat May 25 09:40:21 2019 ORA-1092 : opitsk aborting process
该错误在mos上没有查询出来明确的解决方案,但是在google中有人删除user$模拟出该故障
数据库启动10046跟踪
PARSING IN CURSOR #140185422046848 len=189 dep=1 uid=0 oct=3 lid=0 tim=1558756188092143 hv=186852205 ad='390983730' sqlid='2tkw12w5k68vd' select user#,password,datats#,tempts#,type#,defrole,resource$, ptime,decode(defschclass,NULL, 'DEFAULT_CONSUMER_GROUP',defschclass),spare1,spare4,ext_username,spare2 from user$ where name=:1 END OF STMT PARSE #140185422046848:c=0,e=784,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1558756188092141 BINDS #140185422046848: Bind#0 oacdty=01 mxl=32(03) mxlc=00 mal=00 scl=00 pre=00 oacflg=18 fl2=0001 frm=01 csi=31 siz=32 off=0 kxsbbbfp=7f7f7648a230 bln=32 avl=03 flg=05 value="SYS" EXEC #140185422046848:c=1000,e=1432,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=1457651150,tim=1558756188093835 WAIT #140185422046848: nam='db file sequential read' ela= 5226 file#=1 block#=417 blocks=1 obj#=46 tim=1558756188099198 FETCH #140185422046848:c=1000,e=5465,p=1,cr=1,cu=0,mis=0,r=0,dep=1,og=4,plh=1457651150,tim=1558756188099349 STAT #140185422046848 id=1 cnt=0 pid=0 pos=1 obj=22 op='TABLE ACCESS BY INDEX ROWID USER$ (cr=1 pr=1 pw=0 time=5463 us)' STAT #140185422046848 id=2 cnt=0 pid=1 pos=1 obj=46 op='INDEX UNIQUE SCAN I_USER1 (cr=1 pr=1 pw=0 time=5461 us)' CLOSE #140185422046848:c=0,e=10,dep=1,type=0,tim=1558756188099578 ORA-00600: internal error code, arguments: [kokasgi1], [], [], [], [], [], [], [], [], [], [], []
这里比较明显数据库在查询user$中的SYS用户的时候,无法查询数据从而出现ORA-00600: internal error code, arguments: [kokasgi1]错误.通过进一步对USER$表进行分析发现,sys和system被人重命名
SQL> select name from user$ WHERE NAME LIKE 'SYS%'; NAME ------------------------------ SYSDW SYSMAN SYSTEMDW
定位到具体问题,解决比较简单,在oracle的open过程中,通过对user$表进行修复,实现数据库完美恢复.
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 记一次 Kafka 集群的故障恢复
- Hadoop 使用SecondaryNameNode进行故障恢复
- 数据库故障恢复机制的前世今生
- Elasticsearch 最佳实践系列之分片恢复并发故障
- Windows故障转移群集(WSFC)的备份和恢复
- 数据库ORA-01196故障-归档日志丢失恢复详解
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。