标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,880)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
分类目录归档:Oracle备份恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
昨天中午接到一位朋友紧急求救电话,大概场景如下,asm data磁盘组一共把个asm disk,但是使用4个lun实现的(也就是说每个lun使用fdisk进行分区),该主机上还有一个lun是用来存放备份的挂载在/xifenfei目录.客户记得他们的/xifenfei目录是/dev/sdh1这个分区,上次主机重启之后,rac工作正常,但是/xifenfei这个目录对应的/dev/sdh1无法挂载上去(提示无法找到超级块).然后我这位朋友上去也不管三七二一直接执行了mkfs.ext4 /dev/sdh1.结果整个asm 磁盘组异常了.最后他通过fdisk命令一看发现完蛋了,以前的/dev/sdh 已经变为了/dev/sdc,而现在的/dev/sdh是以前的asm disk.也就是说,他把asm 磁盘组中的一个disk进行了格式化为ext4文件系统操作.
ext4文件系统大概结构
通过这里大概可以发现在格式化为ext4文件系统并非把所有的磁盘数据全部重写主要就是覆盖一些ext4必要的一些元数据信息,理论上没有覆盖部分的数据依旧可以恢复

fdisk 分析现在磁盘情况
[root@db3 ~]# fdisk -l Disk /dev/sda: 171.8 GB, 171798691840 bytes 255 heads, 63 sectors/track, 20886 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00055b12 Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 8223 65536000 82 Linux swap / Solaris /dev/sda3 8223 20887 101723136 8e Linux LVM Disk /dev/sdb: 751.6 GB, 751619276800 bytes 255 heads, 63 sectors/track, 91379 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00b6888f Device Boot Start End Blocks Id System /dev/sdb1 1 91379 734001786 5 Extended /dev/sdb5 1 15000 120487437 83 Linux Disk /dev/sdd: 1073 MB, 1073741824 bytes 34 heads, 61 sectors/track, 1011 cylinders Units = cylinders of 2074 * 512 = 1061888 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00083b68 Device Boot Start End Blocks Id System Disk /dev/sdf: 526.1 GB, 526133493760 bytes 255 heads, 63 sectors/track, 63965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000c10d8 Device Boot Start End Blocks Id System /dev/sdf1 1 13054 104856223+ 83 Linux /dev/sdf2 13055 63965 408942607+ 83 Linux Disk /dev/sde: 1073 MB, 1073741824 bytes 34 heads, 61 sectors/track, 1011 cylinders Units = cylinders of 2074 * 512 = 1061888 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000b120f Device Boot Start End Blocks Id System Disk /dev/sdc: 1795.3 GB, 1795296329728 bytes 255 heads, 63 sectors/track, 218265 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x78c377f7 Device Boot Start End Blocks Id System /dev/sdc1 1 218265 1753213581 83 Linux Disk /dev/sdg: 526.1 GB, 526133493760 bytes 255 heads, 63 sectors/track, 63965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000ee648 Device Boot Start End Blocks Id System /dev/sdg1 1 13054 104856223+ 83 Linux /dev/sdg2 13055 63965 408942607+ 83 Linux Disk /dev/sdi: 526.1 GB, 526133493760 bytes 255 heads, 63 sectors/track, 63965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00027e4b Device Boot Start End Blocks Id System /dev/sdi1 1 13054 104856223+ 83 Linux /dev/sdi2 13055 63965 408942607+ 83 Linux Disk /dev/sdh: 526.1 GB, 526133493760 bytes 255 heads, 63 sectors/track, 63965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000938dc Device Boot Start End Blocks Id System /dev/sdh1 1 13054 104856223+ 83 Linux /dev/sdh2 13055 63965 408942607+ 83 Linux Disk /dev/mapper/rootvg-rootfs: 31.7 GB, 31708938240 bytes 255 heads, 63 sectors/track, 3855 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 Disk /dev/mapper/rootvg-lv01: 32.2 GB, 32212254720 bytes 255 heads, 63 sectors/track, 3916 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000
通过asm alert日志确定asm disk信息
这里可以确定asm disk是VOL01-VOL08一共8个盘
SQL> CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK '/dev/oracleasm/disks/VOL01',
'/dev/oracleasm/disks/VOL02',
'/dev/oracleasm/disks/VOL03',
'/dev/oracleasm/disks/VOL04' ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */
SQL> ALTER DISKGROUP DATA ADD DISK '/dev/oracleasm/disks/VOL05' SIZE 399358M ,
'/dev/oracleasm/disks/VOL06' SIZE 399358M ,
'/dev/oracleasm/disks/VOL07' SIZE 399358M ,
'/dev/oracleasm/disks/VOL08' SIZE 399358M /* ASMCA */
SQL> ALTER DISKGROUP ALL MOUNT /* asm agent call crs *//* {0:0:2} */
NOTE: Diskgroup used for Voting files is:
DATA
Diskgroup with spfile:DATA
Diskgroup used for OCR is:DATA
NOTE: cache registered group DATA number=1 incarn=0x6f3f6eb8
NOTE: cache began mount (not first) of group DATA number=1 incarn=0x6f3f6eb8
NOTE: Assigning number (1,7) to disk (/dev/oracleasm/disks/VOL08)
NOTE: Assigning number (1,6) to disk (/dev/oracleasm/disks/VOL07)
NOTE: Assigning number (1,5) to disk (/dev/oracleasm/disks/VOL06)
NOTE: Assigning number (1,4) to disk (/dev/oracleasm/disks/VOL05)
NOTE: Assigning number (1,3) to disk (/dev/oracleasm/disks/VOL04)
NOTE: Assigning number (1,1) to disk (/dev/oracleasm/disks/VOL02)
NOTE: Assigning number (1,2) to disk (/dev/oracleasm/disks/VOL03)
NOTE: Assigning number (1,0) to disk (/dev/oracleasm/disks/VOL01)
GMON querying group 1 at 2 for pid 23, osid 32026
NOTE: cache opening disk 0 of grp 1: DATA_0000 path:/dev/oracleasm/disks/VOL01
NOTE: cache opening disk 1 of grp 1: DATA_0001 path:/dev/oracleasm/disks/VOL02
NOTE: cache opening disk 2 of grp 1: DATA_0002 path:/dev/oracleasm/disks/VOL03
NOTE: cache opening disk 3 of grp 1: DATA_0003 path:/dev/oracleasm/disks/VOL04
NOTE: cache opening disk 4 of grp 1: DATA_0004 path:/dev/oracleasm/disks/VOL05
NOTE: cache opening disk 5 of grp 1: DATA_0005 path:/dev/oracleasm/disks/VOL06
NOTE: cache opening disk 6 of grp 1: DATA_0006 path:/dev/oracleasm/disks/VOL07
NOTE: cache opening disk 7 of grp 1: DATA_0007 path:/dev/oracleasm/disks/VOL08
NOTE: cache mounting (not first) external redundancy group 1/0x6F3F6EB8 (DATA)
查询asm对应的disk信息
这部分信息,可以确定VOL03被格式化,而且应该就是朋友反馈的被他格式化成ext4的/dev/sdh1

[root@db3 disks]# ls VOL01 VOL02 VOL04 VOL05 VOL06 VOL07 VOL08 [root@db3 disks]# oracleasm querydisk -p 'VOL01' Disk "VOL01" is a valid ASM disk /dev/sdf1: LABEL="VOL01" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL02' Disk "VOL02" is a valid ASM disk /dev/sdg1: LABEL="VOL02" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL03' Disk "VOL03" does not exist or is not instantiated [root@db3 disks]# oracleasm querydisk -p 'VOL04' Disk "VOL04" is a valid ASM disk /dev/sdi1: LABEL="VOL04" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL05' Disk "VOL05" is a valid ASM disk /dev/sdf2: LABEL="VOL05" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL06' Disk "VOL06" is a valid ASM disk /dev/sdg2: LABEL="VOL06" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL07' Disk "VOL07" is a valid ASM disk /dev/sdh2: LABEL="VOL07" TYPE="oracleasm" [root@db3 disks]# oracleasm querydisk -p 'VOL08' Disk "VOL08" is a valid ASM disk /dev/sdi2: LABEL="VOL08" TYPE="oracleasm"
通过kfed分析被格式化成ext4的磁盘信息
[grid@db3 ~]$ kfed read /dev/sdh1 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 0 ; 0x008: file=0 kfbh.check: 810307429 ; 0x00c: 0x304c4f65 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 000000000 00000000 00000000 00000000 304C4F65 [............eOL0] 000000010 00000000 00000000 00000000 00000000 [................] 000000020 4C43524F 44524C43 00000000 00000000 [ORCLCLRD........] 000000030 00000000 00000000 00000000 00000000 [................] Repeat 252 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] [grid@db3 ~]$ kfed read /dev/sdh1 aun=1 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 129 ; 0x001: 0x81 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 98560 ; 0x004: blk=98560 kfbh.block.obj: 164096 ; 0x008: file=164096 kfbh.check: 229632 ; 0x00c: 0x00038100 kfbh.fcn.base: 295168 ; 0x010: 0x00048100 kfbh.fcn.wrap: 819456 ; 0x014: 0x000c8100 kfbh.spare1: 884992 ; 0x018: 0x000d8100 kfbh.spare2: 1605888 ; 0x01c: 0x00188100 000100000 00008100 00018100 00028100 00038100 [................] 000100010 00048100 000C8100 000D8100 00188100 [................] 000100020 00288100 003E8100 00798100 00AB8100 [..(...>...y.....] 000100030 01388100 016C8100 00000000 00000000 [..8...l.........] 000100040 00000000 00000000 00000000 00000000 [................] Repeat 251 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] [grid@db3 ~]$ kfed read /dev/sdh1 aun=1 blkn=254 kfbh.endian: 254 ; 0x000: 0xfe kfbh.hard: 129 ; 0x001: 0x81 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 98814 ; 0x004: blk=98814 kfbh.block.obj: 164350 ; 0x008: file=164350 kfbh.check: 229886 ; 0x00c: 0x000381fe kfbh.fcn.base: 295422 ; 0x010: 0x000481fe kfbh.fcn.wrap: 819710 ; 0x014: 0x000c81fe kfbh.spare1: 885246 ; 0x018: 0x000d81fe kfbh.spare2: 1606142 ; 0x01c: 0x001881fe 0001FE000 000081FE 000181FE 000281FE 000381FE [................] 0001FE010 000481FE 000C81FE 000D81FE 001881FE [................] 0001FE020 002881FE 003E81FE 007981FE 00AB81FE [..(...>...y.....] 0001FE030 013881FE 016C81FE 00000000 00000000 [..8...l.........] 0001FE040 00000000 00000000 00000000 00000000 [................] Repeat 251 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] [grid@db3 ~]$ kfed read /dev/sdh1 aun=9 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 0 ; 0x008: file=0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 000900000 00000000 00000000 00000000 00000000 [................] Repeat 255 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
从这里可以看出来该asm的元数据信息大量被破坏(asm 备份的磁盘头也损坏),直接修复的可能性基本上为0,现在为了最大限度的恢复数据,通过底层扫描asm au结合数据库block信息,进行重组出来数据文件(这次的恢复有点难度,因为该asm磁盘组中有两个数据库,需要通过结合asm file+datafile来区分文件)
恢复出来两套库的数据文件信息
/orabak/xifenfei/oradb/1.dbf /orabak/xifenfei/oradb/2.dbf /orabak/xifenfei/oradb/3.dbf /orabak/xifenfei/oradb/4.dbf /orabak/xifenfei/oradb/5.dbf /orabak/xifenfei/oradb/6.dbf /orabak/xifenfei/oradb/7.dbf /orabak/xifenfei/oradb/8.dbf /orabak/xifenfei/oradb/9.dbf /orabak/xifenfei/oradb/10.dbf /orabak/xifenfei/oradb/11.dbf /orabak/xifenfei/oradb/12.dbf /orabak/xifenfei/oradb/13.dbf /orabak/xifenfei/oradb/14.dbf /orabak/xifenfei/oradb/15.dbf /orabak/xifenfei/oradb/16.dbf /orabak/xifenfei/oradb/17.dbf /orabak/xifenfei/oradb/18.dbf /orabak/xifenfei/oradb/19.dbf /orabak/xifenfei/xgdb/1.dbf /orabak/xifenfei/xgdb/2.dbf /orabak/xifenfei/xgdb/3.dbf /orabak/xifenfei/xgdb/4.dbf /orabak/xifenfei/xgdb/5.dbf /orabak/xifenfei/xgdb/6.dbf /orabak/xifenfei/xgdb/7.dbf /orabak/xifenfei/xgdb/8.dbf /orabak/xifenfei/xgdb/9.dbf /orabak/xifenfei/xgdb/10.dbf /orabak/xifenfei/xgdb/11.dbf /orabak/xifenfei/xgdb/12.dbf /orabak/xifenfei/xgdb/13.dbf /orabak/xifenfei/xgdb/14.dbf /orabak/xifenfei/xgdb/15.dbf /orabak/xifenfei/xgdb/16.dbf
然后使用工具拷贝出来redo信息,最后通过重建控制文件.其中一套库完美直接open,另外一套库system中的c_obj$被覆盖,不过使用一个多月以前的备份的system文件强制打开库成功,数据基本上完美导出,实现完美恢复.由于在格式化为ext4的时候,会在磁盘中部分位置写入一些
数据文件恢复参考:asm disk header 彻底损坏恢复
另外有一次win平台类似恢复经历:asm disk格式化为ntfs恢复
如果您遇到此类情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
oracle dul 11 正式发布
千呼万唤oracle dul 11终于发布了,迫不及待的下载来测试,现在版本号为dul 11.2.0.0.1,目前只发布了for linux,其他版本估计要等等.期待该版本有引进新功能
oracle dul 11发布


dul 11 测试恢复oracle 12c版本
[root@ora1221 dul11]# ./dul
Data UnLoader: 11.2.0.0.1 - Internal Only - on Mon Jun 13 00:04:50 2016
with 64-bit io functions
Copyright (c) 1994 2016 Bernard van Duijnen All rights reserved.
Strictly Oracle Internal Use Only
DUL: Warning: Recreating file "dul.log"
Found db_id = 1414800805
Found db_name = ORCL
DUL> bootstrap;
Probing file = 1, block = 520
. unloading table BOOTSTRAP$
DUL: Warning: block number is non zero but marked deferred trying to process it anyhow
60 rows unloaded
DUL: Warning: Dictionary cache DC_BOOTSTRAP is empty
Reading BOOTSTRAP.dat 60 entries loaded
Parsing Bootstrap$ contents
DUL: Warning: Recreating file "dict.ddl"
Generating dict.ddl for version 12
OBJ$: segobjno 18, file 1 block 240
TAB$: segobjno 2, tabno 1, file 1 block 144
COL$: segobjno 2, tabno 5, file 1 block 144
USER$: segobjno 10, tabno 1, file 1 block 208
Running generated file "@dict.ddl" to unload the dictionary tables
. unloading table OBJ$ 72547 rows unloaded
. unloading table TAB$ 2137 rows unloaded
. unloading table COL$ 115645 rows unloaded
. unloading table USER$ 129 rows unloaded
Reading USER.dat 129 entries loaded
Reading OBJ.dat
DUL: FATAL Error: File OBJ.dat, line 22094: identifier too long
dul 11 恢复oracle 12c 报错分析
看报错OBJ.dat报错数据,从定义上判断是长度过长
[root@ora1221 dul11]# vi OBJ.dat 22091 "22435" "" "0" "JVMFCB" "" "9" "" 22092 "22436" "" "0" "JVMFCB" "" "11" "" 22093 "22437" "56417" "0" "JAVA$CBOBJ$" "" "2" "" ---- 22094 "22439" "" "0" "sun/util/xml/PlatformXmlPropertiesProvider$Resolver" "" "29" "" 22095 "22440" "" "0" "sun/util/xml/PlatformXmlPropertiesProvider$EH" "" "29" "" 22096 "22441" "" "0" "sun/util/xml/PlatformXmlPropertiesProvider$1" "" "29" "" 22097 "22442" "" "0" "sun/util/resources/LocaleNamesBundle" "" "29" ""
对象名长度分析
[oracle@ora1221 ~]$ ss
SQL*Plus: Release 12.2.0.0.3 Production on Fri Aug 7 02:50:35 2015
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.0.3 - 64bit Production
SQL> select length(object_name) from dba_objects
2 where object_name='sun/util/xml/PlatformXmlPropertiesProvider$Resolver';
LENGTH(OBJECT_NAME)
-------------------
51
SQL> select max(length(object_name)) from dba_objects;
MAX(LENGTH(OBJECT_NAME))
------------------------
123
SQL> desc dba_objects
Name Null? Type
----------------------------------------- -------- ----------------------------
OWNER VARCHAR2(128)
OBJECT_NAME VARCHAR2(128)
SUBOBJECT_NAME VARCHAR2(128)
OBJECT_ID NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(23)
CREATED DATE
LAST_DDL_TIME DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)
NAMESPACE NUMBER
EDITION_NAME VARCHAR2(128)
SHARING VARCHAR2(18)
EDITIONABLE VARCHAR2(1)
ORACLE_MAINTAINED VARCHAR2(1)
APPLICATION VARCHAR2(1)
DEFAULT_COLLATION VARCHAR2(100)
DUPLICATED VARCHAR2(1)
SHARDED VARCHAR2(1)
CREATED_APPID NUMBER
CREATED_VSNID NUMBER
MODIFIED_APPID NUMBER
MODIFIED_VSNID NUMBER
在oracle 12c中对象名长度已经变为128,但是dul依旧不能支持列长度,既然作者已经在init.dul的Compatible参数曾增加了对12c的支持,那对这样明显的bug应该在不久的将来即可修复。当然这个问题,可以通过一些人工技巧绕过去
ORA-01555 ORA-600 kdiulk:kcbz_objdchk ORA-600 kdBlkCheckError等错误恢复
数据库启动ORA-00704,0RA-00604,ORA-01555导致数据库无法启动
Tue May 31 17:32:42 2016 SMON: enabling cache recovery SUCCESS: diskgroup RECOVERY was mounted ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0004.3af84bee): select ctime, mtime, stime from obj$ where obj# = :1 Archived Log entry 5 added for thread 1 sequence 10 ID 0x86a261e7 dest 1: Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_12779.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_1592079335$" too small Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_12779.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7_1592079335$" too small Error 704 happened during db open, shutting down database USER (ospid: 12779): terminating the instance due to error 704
通过bbed修改事务之后启动数据库
Tue May 31 17:35:49 2016
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
This condition can occur when a backup controlfile has
been restored. It may be necessary to add files to these
tablespaces. That can be done using the SQL statement:
ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
Alternatively, if these temporary tablespaces are no longer
needed, then they can be dropped.
Empty temporary tablespace: TEMP
*********************************************************************
Updating character set in controlfile to AL32UTF8
Tue May 31 17:35:50 2016
Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p021_13862.trc (incident=166002):
ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []
Tue May 31 17:35:50 2016
Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p010_13818.trc (incident=165914):
ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []
Tue May 31 17:35:50 2016
Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p004_13794.trc (incident=165866):
ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []
Tue May 31 17:35:50 2016
Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p011_13822.trc (incident=165922):
ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []
Tue May 31 17:35:50 2016
Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p016_13842.trc (incident=165962):
ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], []
ORA-600 [kdiulk:kcbz_objdchk] trace文件
*** SESSION ID:(3.5) 2016-05-31 17:35:50.068 OBJD MISMATCH typ=6, seg.obj=-2, diskobj=222225, dsflg=0, dsobj=285890, tid=285890, cls=1 ORA-00600: 内部错误代码, 参数: [kdiulk:kcbz_objdchk], [0], [0], [1], [], [], [], [], [], [], [], [] Parallel Transaction recovery server caught exception 600 begin Parallel Recovery Context Dump nsi: 48, nsactive: 48 , nirsi: 1, nidti: 1, ndt: 1, rescan: 0, ptrs: 48 [ktprsi] wdone: 50 [ktpritp 378651b8] ktprsi: 37903b60 37903b78 37903b90 37903ba8 37903bc0 37903bd8 37903bf0 37903c08 37903c20 37903c38 37903c50 37903c68 37903c80 37903c98 37903cb0 37903cc8 37903ce0 37903cf8 37903d10 37903d28 37903d40 37903d58 37903d70 37903d88 37903da0 37903db8 37903dd0 37903de8 37903e00 37903e18 37903e30 37903e48 37903e60 37903e78 37903e90 37903ea8 37903ec0 37903ed8 37903ef0 37903f08 37903f20 37903f38 37903f50 37903f68 37903f80 37903f98 37903fb0 37903fc8 [ktprht] nhb: 47, nfl: 20247, flg: 2 *** 2016-05-31 17:36:08.584 [ktprhb] nfl: 1, nelem: 97, flg: 0, sqn: 1 flist: 37698940 nhe: [ktprhe 32] sqn: -1297235803 [kturur] uoff: -1797708320, sqn: 4 uba: 0x098004cd.07e4.0b *----------------------------- * Rec #0xb slt: 0x07 objn: 123986(0x0001e452) objd: 285891 tblspc: 10(0x0000000a) * Layer: 10 (Index) opc: 22 rci 0x0a Undo type: Regular undo Last buffer split: No Temp Object: No Tablespace Undo: No rdba: 0x00000000
这里基本上可以确定是由于undo index中的dataobj#和block中的dataobj# 不匹配.在数据库undo回滚之时出现该错误.可以通过跳过undo回滚,然后重建对象
Tue May 31 17:36:06 2016 Simulated error on redo application. Block recovery from logseq 12, block 959 to scn 20401094719 Recovery of Online Redo Log: Thread 1 Group 3 Seq 12 Reading mem 0 Mem# 0: +DATA/xifenfei/onlinelog/group_3.263.802446627 Block recovery completed at rba 12.1012.16, scn 4.3221225536 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Simulated error for redo application done. Errors in file /opt/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_p009_13814.trc (incident=165906): ORA-00600: 内部错误代码, 参数: [kdBlkCheckError], [26], [950417], [18025], [], [], [], [], [], [], [], []
这些错误是由于数据库block逻辑异常导致,错过参数含义
在10g中ORA-600 kddummy_blkchk 在11g中ORA-600 kdBlkCheckError
ARGUMENTS: Arg [a] Absolute file number Arg [b] Bock number Arg 1 Internal error code returned from kcbchk() which indicates the problem encountered. See Note 46389.1 for details of block check codes.
根据QREF kddummy_blkchk / kdBlkCheckError Check Codes Listing (Full) (Doc ID 1264040.1)分析
这里的18025是代码的KCBTEMAP_EC_START + KTS4_EC_SBFREE部分异常,主要表现在Incorrect firstfree or nfree 可以通过设置一些参数进行屏蔽
在恢复过程中还有其他错误
ORA-600 encountered when generating server alert SMG-4128 ORA-00600: internal error code, arguments: [ktcpoptx:!cmt top lvl], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4406], [0x1026B65348], [0x000000000], [2], [6215], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [ktcpoptx:!cmt top lvl], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] ORACLE Instance xifenfei (pid = 15) - Error 600 encountered while recovering transaction (10, 7) on object 123986. ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [kturbleurec1], [], [], [], [], [], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [kewrose_1], [600], [ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], [] Non-fatal internal error happenned while SMON was doing logging scn->time mapping.
通过整体分析错误主要是由于undo异常导致,通过设置_corrupted_rollback_segments设置db_block_checking等相关参数,清理SMON_SCN_TIME等操作数据库没有其他异常报错,让其通过逻辑方式重建库

加我微信(17813235971)
加我QQ(107644445)

