Oracle RAC for aix 存储双控锁盘导致ASM控制文件损坏恢复实例
故障场景:AIX IBM存储更换存储控制器电源模块导致存储双控同时掉电,存储双控恢复供电后发生锁盘,IBM解盘后 RAC数据库无法正常启动,启动报错:ORA-00600: internal error code, arguments: [2131], [33], [32], [], [], [], [], [], [], [], [], []
恢复方案确定:由于损坏的数据库数据量巨大,有30T之多,并且要求尽快打开数据库,可以接受丢失部分数据, 数据库有备份。商议之下,使用备份控制文件恢复数据库,进行数据库的不一致性恢复。
恢复过程:
1、从磁带库拉取控制文件备份集并恢复到Oracle RAC数据库ASM存储中
--此时尝试启动数据库会遇到报错信息:
ORA-00600: internal error code, arguments: [3020], [718], [2828551], [3014338823], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 718, block# 2828551, file offset is unknown bytes)
2、生成Oracle的pfile并加入如下三个参数
_allow_resetlogs_corruption=true #跳过redo崩溃,允许resetlogs开库
undo_management=manual #将undo管理修改为手工管理
event="10513 trace name context forever,level 2" #开10513事件跳过一致性验证
*.cluster_database=false
--此时,尝试启动数据库会遇到报错信息:
ORA-00600: internal error code, arguments: [2662], [3735], [1979553782], [3735], [1979584838], [20971664], [], [], [], [], [], []
3、Oracle数据库使用备份控制文件恢复数据库后,需要推进控制文件的SCN
数据库当前的SCN= 3735.1979584838=(3735*4294967296)+1979584838=16043682435398
giga=16043682435398/1024/1024/1024=14941.843=14941
需要推进的新SCN=14942*1024*1024*1024=16043850334208
Oracle数据库10g控制文件推进可以在pfile中加入参数:_minimum_giga_scn;
ORACLE 11.2.0.4 SCN推进方法oradebug
本次数据库控制文件SCN推进步骤步骤
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [700000000019B70, 700000000019BA0) = 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 07000000 00019850
SQL> oradebug poke 0x700000000019B70 8 16043850334208
BEFORE: [700000000019B70, 700000000019B78) = 00000000 00000000
AFTER: [700000000019B70, 700000000019B78) = 00000E97 80000000
SQL> oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [700000000019B70, 700000000019BA0) = 00000E97 80000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 07000000 00019850
SQL>
--此时尝试启动数据库会遇到报错信息:
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
接下来ORA600[4193]的处理就是ORACLE rac的undo表空间的重建了,需要配合参数:undo_management 和_CORRUPTED_ROLLBACK_SEGMENTS。
4、处理完ORA600[4193]后,数据库能够启动并打开到open状态,此时最好进行全库备份,如果条件允许, 就重建数据库以逻辑的方式导出故障数据库导新环境。否则,后续的使用中会时不时遇到如下报错信息:
ORA600[6122]和ORA600[KDSGRP1],实质文件是索引逻辑坏块引起的,以drop和create重建相关的索引即可。
更多Oracle相关信息见Oracle 专题页面 https://www.linuxidc.com/topicnews.aspx?tid=12
- oracle 12c RMAN异机恢复还原RAC集群(ASM)为单实例库(文件系统)记录
- Oracle备份恢复之断电导致控制文件和日志文件损坏修复
- oracle之 RAC 11G ASM下控制文件多路复用
- oracle数据恢复案例 - 控制文件损坏,无备份
- oracle 日志文件和控制文件损坏的恢复
- oracle用户管理的完全恢复6:控制文件损坏(控制文件前后内容改变)
- oracle控制文件的损坏或完全丢失的恢复办法
- oracle之 RAC 11G ASM下控制文件多路复用
- oracle 10G控制文件因介质失败导致全部不可用的恢复
- Oracle使用RMAN恢复控制文件实例
- 控制文件损坏或者丢失的Oracle 10g数据库恢复控制文件一例
- oracle 控制文件损坏恢复笔记
- RAC环境ASM存储新增控制文件的方法
- Oracle 添加冗余控制文件 for RAC On Linux
- oracle 异机恢复 从asm到文件系统成功实例
- Oracle案例:损坏控制文件的恢复方法
- Oracle备份恢复-控制文件损坏的各种场景恢复专题
- oracle用户管理的完全恢复5:控制文件损坏(控制文件前后内容未改变)
- [案例]Oracle控制文件损坏导致数据库故障(转载)
- Oracle案例:损坏控制文件的恢复方法