标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,772)
- DB2 (22)
- MySQL (77)
- Oracle (1,612)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (593)
- Oracle安装升级 (98)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (31)
- pdu工具 (6)
- PostgreSQL恢复 (10)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 由于空间满导致PostgreSQL数据库异常处理
- 一次非常幸运的ORA-600 16703(tab$被清空)故障恢复
- Oracle 19c 202507补丁(RUs+OJVM)-19.28
- 2025年的Oracle 8.0.5数据库恢复
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
年归档:2021
删除分区 oracle asm disk 恢复
接到一个朋友数据库故障请求case.大概操作是这样的:有一个39T的lun,通过parted分了15个分区,给oracle asm使用创建磁盘组data4,然后分了4个分区做成data5(由于ausize写错误了),删除掉磁盘组和这四个分区.然后重新分配了6个分区,并且使用最后5个分区创建了data5磁盘组.使用了一段时间之后,由于oracle空间不足,检查的时候误以为这个lun就前面15个分区使用,人工把后面的6个分区给删除了,并且创建了4个新分区,然后发现数据库crash了,发现误删除了在使用的分区.然后又把新创建的4个分区给删除了.接手该故障的时候,这个39T lun的分区信息如下
[root@node1 linux64]# parted /dev/mapper/36000d31003d39e000000000000000004 GNU Parted 2.1 Using /dev/mapper/36000d31003d39e000000000000000004 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Linux device-mapper (multipath) (dm) Disk /dev/mapper/36000d31003d39e000000000000000004: 39.6TB Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 2097kB 2000GB 2000GB asmdata4-1 2 2000GB 4000GB 2000GB asmdata4-2 3 4000GB 6000GB 2000GB asmdata4-3 4 6000GB 8000GB 2000GB asmdata4-4 5 8000GB 10.0TB 2000GB asmdata4-5 6 10.0TB 12.0TB 2000GB asmdata4-6 7 12.0TB 14.0TB 2000GB asmdata4-7 8 14.0TB 16.0TB 2000GB asmdata4-8 9 16.0TB 18.0TB 2000GB asmdata4-9 10 18.0TB 20.0TB 2000GB asmdata4-10 11 20.0TB 22.0TB 2000GB asmdata4-11 12 22.0TB 24.0TB 2000GB asmdata4-12 13 24.0TB 26.0TB 2000GB asmdata4-13 14 26.0TB 28.0TB 2000GB asmdata4-14 15 28.0TB 30.0TB 2000GB asmdata4-15
客户正常使用情况下,这个lun上面相关分区的asm disk信息
SQL> CREATE DISKGROUP DATA4 EXTERNAL REDUNDANCY DISK '/dev/mapper/36000d31003d39e000000000000000004p1' SIZE 1907346M , '/dev/mapper/36000d31003d39e000000000000000004p2' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p3' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p4' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p5' SIZE 1907350M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='8M' /* ASMCA */ SQL> ALTER DISKGROUP DATA4 ADD DISK '/dev/mapper/36000d31003d39e000000000000000004p10' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p6' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p7' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p8' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p9' SIZE 1907348M /* ASMCA */ SQL> ALTER DISKGROUP DATA4 ADD DISK '/dev/mapper/36000d31003d39e000000000000000004p11' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p12' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p13' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p14' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p15' SIZE 1907350M /* ASMCA */ SQL> CREATE DISKGROUP DATA5 EXTERNAL REDUNDANCY DISK '/dev/mapper/36000d31003d39e000000000000000004p17' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p18' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p19' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p20' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p21' SIZE 1621246M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='4M' /* ASMCA */
基于客户现在的情况,data4中的所有分区都正常,主要是要找出来data5中的5个分区的数据.因为客户不确定p16分区大小,导致后续的5个分区起始位置不好定位.从而使得恢复无法进行.通过shell脚本结合kfed尝试定位asm disk header信息
#!/bin/bash j=xxxxxxxxxxx for ((i=xxxxxx; i<=j; i++)) do echo "-----$i--------" >> /home/get_au1.txt kfed read /dev/mapper/36000d31003d39e000000000000000004 aun=$i | > grep "kfdhdb.dskname: DATA" >> /home/get_au.txt done
结果发现无法获取到结果,通过分析发现这里由于lun过大,导致aun值过大,从而使得kfed溢出无法读取到正常值.根据parted的特性,人工dd部分block进行分析
[root@node1 bak]# kfed read xifenfei.dd aun=134|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 3357988283 ; 0x00c: 0xc826d5bb kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 0 ; 0x024: 0x0000 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA5_0000 ; 0x028: length=10 kfdhdb.grpname: DATA5 ; 0x048: length=5 kfdhdb.fgname: DATA5_0000 ; 0x068: length=10 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33116450 ; 0x0a8: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5 kfdhdb.crestmp.lo: 477378560 ; 0x0ac: USEC=0x0 MSEC=0x10e SECS=0x7 MINS=0x7 kfdhdb.mntstmp.hi: 33116450 ; 0x0b0: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5 kfdhdb.mntstmp.lo: 486256640 ; 0x0b4: USEC=0x0 MSEC=0x2ec SECS=0xf MINS=0x7 kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000 kfdhdb.mfact: 454272 ; 0x0c0: 0x0006ee80 kfdhdb.dsksize: 429153 ; 0x0c4: 0x00068c61 kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
顺利找到了data5中的第一块磁盘,而且确定了起始位置,然后构造相关的dd语句把分区的数据dd到一个新磁盘中
dd if=/dev/mapper/36000d31003d39e000000000000000004 bs=4M skip=xxxxx count=429153 of=/dev/sdu
通过类似方法依次处理,最终把5块asm disk全部找到,并且顺利dd到新的磁盘中.尝试启动crs,并mount data5


data5 磁盘组mount成功之后,数据库顺利启动,实现lun中删除分区之后,asm磁盘组数据完美恢复

这次运气还不错,仅仅是对lun的分区使用了parted进行了删除和创建等操作,没有格式化文件系统和做成新的asm disk,不然数据会有一部分丢失.对于有部分破坏的分区,需要通过底层碎片的方法进行最大限度抢救数据.参考类似文档:
asm disk被加入vg恢复
又一例asm格式化文件系统恢复
文件系统损坏导致数据文件异常恢复
一次完美的asm disk被格式化ntfs恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
再一起asm disk被格式化成ext3文件系统故障恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例
drop tablesapce 数据恢复
有客户执行了drop tablespace xxx including contents and datafiles,虽然删除命令返回错误,但是该表空间中大量对象被删除,文件没有被从系统层面删除
Tue Jun 29 14:38:26 2021 DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS Tue Jun 29 14:38:32 2021 Thread 1 advanced to log sequence 975 (LGWR switch) Current log# 3 seq# 975 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO03.LOG ORA-604 signalled during: DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS... Tue Jun 29 14:40:44 2021 ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF' AUTOEXTEND ON NEXT 50M Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF' AUTOEXTEND ON NEXT 50M ALTER TABLESPACE "XFF" DROP DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF' WARNING: Cannot delete file D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF Errors in file d:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_2528.trc: ORA-01265: 无法删除 DATA D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF ORA-27056: 无法删除文件 OSD-04024: 无法删除文件。 O/S-Error: (OS 32) 另一个程序正在使用此文件,进程无法访问。 Completed: ALTER TABLESPACE "XFF" DROP DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF' Tue Jun 29 14:58:51 2021 ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF' AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF' AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED
通过工具获取obj$字典信息,结合user$,判断业务用户表数据基本上全部删除
对于这类情况,常规方法无法恢复,只能按照表被drop的思路进行恢复.参考文章:dul恢复drop表测试,通过结合客户提供的表结构和一些特殊方法恢复出来所有对象的obj#,dataobj#信息,快速的恢复了客户数据,得到客户认可

ORA-15335: ASM metadata corruption detected in disk group ‘DATA’
asm磁盘组增加磁盘进行扩容之后报ORA-15335: ASM metadata corruption detected in disk group ‘DATA’和ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479],磁盘组dismount,然后mount之后立马dismount掉.
Tue Jun 29 09:19:09 2021 SQL> ALTER DISKGROUP DATA ADD DISK '/dev/raw/raw5' SIZE 102400M /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region NOTE: Assigning number (2,1) to disk (/dev/raw/raw5) NOTE: requesting all-instance membership refresh for group=2 NOTE: initializing header on grp 2 disk DATA_0001 NOTE: requesting all-instance disk validation for group=2 Tue Jun 29 09:19:11 2021 NOTE: skipping rediscovery for group 2/0xb0c845ce (DATA) on local instance. NOTE: requesting all-instance disk validation for group=2 NOTE: skipping rediscovery for group 2/0xb0c845ce (DATA) on local instance. NOTE: initiating PST update: grp = 2 Tue Jun 29 09:19:16 2021 GMON updating group 2 at 7 for pid 27, osid 25020 NOTE: PST update grp = 2 completed successfully NOTE: membership refresh pending for group 2/0xb0c845ce (DATA) GMON querying group 2 at 8 for pid 18, osid 3852 NOTE: cache opening disk 1 of grp 2: DATA_0001 path:/dev/raw/raw5 NOTE: Attempting voting file refresh on diskgroup DATA NOTE: Refresh completed on diskgroup DATA. No voting file found. GMON querying group 2 at 9 for pid 18, osid 3852 SUCCESS: refreshed membership for 2/0xb0c845ce (DATA) Tue Jun 29 09:19:20 2021 SUCCESS: ALTER DISKGROUP DATA ADD DISK '/dev/raw/raw5' SIZE 102400M /* ASMCA */ NOTE: starting rebalance of group 2/0xb0c845ce (DATA) at power 1 Starting background process ARB0 Tue Jun 29 09:19:21 2021 ARB0 started with pid=33, OS id=25176 NOTE: assigning ARB0 to group 2/0xb0c845ce (DATA) with 1 parallel I/O cellip.ora not found. Tue Jun 29 09:19:24 2021 NOTE: Attempting voting file refresh on diskgroup DATA NOTE: Refresh completed on diskgroup DATA. No voting file found. Tue Jun 29 09:19:46 2021 WARNING: cache read a corrupt block: group=2(DATA) dsk=0 blk=7 disk=0 (DATA_0000) incarn=3915953476 au=0 blk=7 count=1 Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_25176.trc: ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] NOTE: a corrupted block from group DATA was dumped to /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_25176.trc Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_25176.trc: ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] ERROR: cache failed to read group=2(DATA) dsk=0 blk=7 from disk(s): 0(DATA_0000) ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] NOTE: cache initiating offline of disk 0 group DATA NOTE: process _arb0_+asm1 (25176) initiating offline of disk 0.3915953476 (DATA_0000) with mask 0x7e in group 2 NOTE: initiating PST update: grp = 2, dsk = 0/0xe968b544, mask = 0x6a, op = clear Tue Jun 29 09:19:46 2021 GMON updating disk modes for group 2 at 10 for pid 33, osid 25176 ERROR: Disk 0 cannot be offlined, since diskgroup has external redundancy. ERROR: too many offline disks in PST (grp 2) Tue Jun 29 09:19:46 2021 NOTE: cache dismounting (not clean) group 2/0xB0C845CE (DATA) NOTE: messaging CKPT to quiesce pins Unix process pid: 25395, image: oracle@frsrac1 (B000) Tue Jun 29 09:19:46 2021 NOTE: halting all I/Os to diskgroup 2 (DATA) Tue Jun 29 09:19:46 2021 NOTE: LGWR doing non-clean dismount of group 2 (DATA) NOTE: LGWR sync ABA=11.10715 last written ABA 11.10715 WARNING: Offline for disk DATA_0000 in mode 0x7f failed. Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_25176.trc (incident=54665): ORA-15335: ASM metadata corruption detected in disk group 'DATA' ORA-15130: diskgroup "DATA" is being dismounted ORA-15066: offlining disk "DATA_0000" in group "DATA" may result in a data loss ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] Incident details in: /u01/app/grid/diag/asm/+asm/+ASM1/incident/incdir_54665/+ASM1_arb0_25176_i54665.trc Tue Jun 29 09:19:46 2021 kjbdomdet send to inst 2 detach from dom 2, sending detach message to inst 2 Tue Jun 29 09:19:46 2021 List of instances: 1 2 Dirty detach reconfiguration started (new ddet inc 1, cluster inc 24) Global Resource Directory partially frozen for dirty detach * dirty detach - domain 2 invalid = TRUE 796 GCS resources traversed, 0 cancelled Dirty Detach Reconfiguration complete Tue Jun 29 09:19:46 2021 WARNING: dirty detached from domain 2 NOTE: cache dismounted group 2/0xB0C845CE (DATA) SQL> alter diskgroup DATA dismount force /* ASM SERVER:2965915086 */ Tue Jun 29 09:19:47 2021 ERROR: ORA-15130 thrown in ARB0 for group number 2 Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_arb0_25176.trc: ORA-15130: diskgroup "DATA" is being dismounted ORA-15335: ASM metadata corruption detected in disk group 'DATA' ORA-15130: diskgroup "DATA" is being dismounted ORA-15066: offlining disk "DATA_0000" in group "DATA" may result in a data loss ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] ORA-15196: invalid ASM block header [kfc.c:26368] [check_kfbh] [2147483648] [7] [2183628676 != 686982479] Tue Jun 29 09:19:47 2021 NOTE: stopping process ARB0 Tue Jun 29 09:19:47 2021 Sweep [inc][54665]: completed Tue Jun 29 09:19:47 2021 Sweep [inc2][54665]: completed NOTE: cache deleting context for group DATA 2/0xb0c845ce Errors in file /u01/app/grid/diag/asm/+asm/+ASM1/trace/+ASM1_rbal_3852.trc: ORA-15130: diskgroup "DATA" is being dismounted GMON dismounting group 2 at 11 for pid 27, osid 25395 NOTE: Disk DATA_0000 in mode 0x7f marked for de-assignment NOTE: Disk DATA_0001 in mode 0x7f marked for de-assignment SUCCESS: diskgroup DATA was dismounted SUCCESS: alter diskgroup DATA dismount force /* ASM SERVER:2965915086 */
通过kfed分析报错block,确认错误
kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 7 ; 0x004: blk=7 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 2183628676 ; 0x00c: 0x82278784 <<======该值错误,应该为:686982479 kfbh.fcn.base: 3430 ; 0x010: 0x00000d66 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdatb.aunum: 2240 ; 0x000: 0x000008c0 kfdatb.shrink: 448 ; 0x004: 0x01c0 kfdatb.ub2pad: 0 ; 0x006: 0x0000
通过修复该错误,并且禁止reblance操作[增加磁盘数据需要重新分布],mount磁盘组,然后open库,发现redo已经被覆盖(非归档),强制打开库报错
SQL> alter database open resetlogs; alter database open resetlogs * ERROR at line 1: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [0], [2691201882], [0], [2691227745], [12583040], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [0], [2691201881], [0], [2691227745], [12583040], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [0], [2691201879], [0], [2691227745], [12583040], [], [], [], [], [], [] Process ID: 25110 Session ID: 287 Serial number: 3
通过对scn进行处理,数据库顺利open
SQL> startup mount pfile='/tmp/pfile'; ORACLE instance started. Total System Global Area 5044088832 bytes Fixed Size 2261928 bytes Variable Size 1442843736 bytes Database Buffers 3590324224 bytes Redo Buffers 8658944 bytes Database mounted. SQL> alter database open; Database altered.