记一次异常断电导致ora-600、ORA-25153的处理经过

朋友突然联系我说,他们项目的数据库宕机起不来了,报错全是600,请我帮他处理下,现在记录处理过程如下:

首先看下报错日志:

alter database mount 
ORA-1100 signalled during: alter database mount ...
Fri Oct 25 08:53:37 2019
alter database open 
Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Started redo scan
Completed redo scan
 read 258 KB redo, 35 data blocks need recovery
Errors in file c:\app\administrator\diag\rdbms\xdyy\xdyy\trace\xdyy_ora_3068.trc  (incident=19794):
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4757], [69495], [69667], [], [], [], [], [], [], []
Incident details in: c:\app\administrator\diag\rdbms\xdyy\xdyy\incident\incdir_19794\xdyy_ora_3068_i19794.trc
Aborting crash recovery due to error 600
Errors in file c:\app\administrator\diag\rdbms\xdyy\xdyy\trace\xdyy_ora_3068.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4757], [69495], [69667], [], [], [], [], [], [], []
Errors in file c:\app\administrator\diag\rdbms\xdyy\xdyy\trace\xdyy_ora_3068.trc:
ORA-00600: 内部错误代码, 参数: [kcratr_nab_less_than_odr], [1], [4757], [69495], [69667], [], [], [], [], [], [], []
ORA-600 signalled during: alter database open ...
Fri Oct 25 08:53:39 2019
Trace dumping is performing id=[cdmp_20191025085339]
Fri Oct 25 08:53:40 2019
Sweep [inc][19794]: completed
Sweep [inc2][19794]: completed
Fri Oct 25 08:55:45 2019
alter database mount 
ORA-1100 signalled during: alter database mount ...
Fri Oct 25 08:57:02 2019
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
License high water mark = 8
All dispatchers and shared servers shutdown
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
ALTER DATABASE DISMOUNT
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Archive process shutdown avoided: 0 active
Fri Oct 25 08:57:07 2019
Stopping background process VKTM: 
Fri Oct 25 08:57:09 2019
Instance shutdown complete

还有一段报错:

Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Errors in file c:\app\administrator\diag\rdbms\xdyy\xdyy\trace\xdyy_smon_7552.trc  (incident=22155):
ORA-00600: ??????, ??: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: c:\app\administrator\diag\rdbms\xdyy\xdyy\incident\incdir_22155\xdyy_smon_7552_i22155.trc
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file c:\app\administrator\diag\rdbms\xdyy\xdyy\trace\xdyy_ora_684.trc  (incident=22203):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: c:\app\administrator\diag\rdbms\xdyy\xdyy\incident\incdir_22203\xdyy_ora_684_i22203.trc
Doing block recovery for file 3 block 1567

简单看了下报错内容,初步判断是undo和控制文件损坏了。他用的windows系统,数据库装在了c盘,不开归档也没备过份,如果是数据文件也损坏了那就无力回天了。

一,修复控制文件

1,进入数据库

sqlplus / as sysdba

  将数据库打开到mount状态

startup mount;

2,备份控制文件到c盘

ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'C:/1.TXT';,

3,打开1.txt将如下这段复制出来

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "XDYY" NORESETLOGS  NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
LOGFILE
  GROUP 1 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE

DATAFILE
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\SYSTEM01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\SYSAUX01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\UNDOTBS01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\USERS01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\TSP_TEST.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\OBJECTS_TABLESPACE.DBF'
CHARACTER SET ZHS16GBK
;

4,重建控制文件,在数据库执行:

CREATE CONTROLFILE REUSE DATABASE "XDYY" NORESETLOGS  NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2920
LOGFILE
  GROUP 1 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\REDO03.LOG'  SIZE 50M BLOCKSIZE 512

DATAFILE
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\SYSTEM01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\SYSAUX01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\UNDOTBS01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\USERS01.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\TSP_TEST.DBF',
  'C:\APP\ADMINISTRATOR\ORADATA\XDYY\OBJECTS_TABLESPACE.DBF'
CHARACTER SET ZHS16GBK
;

 

5,介质恢复一下
RECOVER DATABASE ;

6,开启数据库:
ALTER DATABASE OPEN;

不出所料继续报600错位,序号4194

二,重建undo表空间

看下现在使用的undo

1,show parameter undo_tablespace;

2,在mount状态无法创建undo表空间,只能修改spfile文件,使用system表空间暂时替代

create pfile='C:/pfile.txt' from spfile;

编辑pfile.txt

*.undo_tablespace='UNDOTBS1'
*.undo_management='AUTO'

改成

#*.undo_tablespace='UNDOTBS1'
#*.undo_management='AUTO'

*.undo_tablespace='SYSTEM'
*.undo_management='MANUAL'

3,使用修改好的pfile启动数据库

startup pfile='C:/pfile.txt';

 

 4,删除原来的undo表空间

drop tablespace undotbs1 including CONTENTS;

create undo tablespace UNDOTBS1 datafile 'C:\app\Administrator\oradata\XDYY\UNDOTBS01.DBF' size 500M REUSE auto extend on maxsize  unlimited;

5,重启数据库,修改pfile中undo参数

#*.undo_tablespace='UNDOTBS1'
#*.undo_management='AUTO'

*.undo_tablespace='SYSTEM'
*.undo_management='MANUAL'

改回去

*.undo_tablespace='UNDOTBS1'
*.undo_management='AUTO'

6,重启数据库到nomount

startup nomount pfile='C:/pfile.txt';

create spfile from pfile='C:/pfile.txt';

7,重启数据库

SHUTDOWN IMMEDIATE;

STARTUP;

到此undo修复完成了,数据库也正常启动了

不过在导出或者order by 时又报临时表空间错误了,那就继续修复临时表空间

三,修复临时表空间

ORA-25153 临时表空间为空

1,新建临时表空间

CREATE TEMPORARY TABLESPACE TMP TEMPFILE 'C:\APP\ADMINISTRATOR\ORADATA\XDYY\TMP02.dbf'  SIZE 2G AUTOEXTEND ON;

2,将默认表空间设置成新建的tmp

alter database default temporary tablespace tmp;

3,删除原来的临时表空间

drop tablespace temp including contents and datafiles; 

4,重启下数据库(随意,不必要)

庆祝一下,到此修复全部完成。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章