标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 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-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)
- 操作系统 (100)
- 数据库 (1,597)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (17)
- PostgreSQL恢复 (5)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
月归档:七月 2016
_ALLOW_RESETLOGS_CORRUPTION
我相信_ALLOW_RESETLOGS_CORRUPTION 这个参数一定很多人都熟悉,是redo异常恢复的杀手锏之一,以下文章是来自官方的解释
DB_Parameter _ALLOW_RESETLOGS_CORRUPTION ======================================== This documentation has been prepared avoiding the mention of the complex structures from the code and to simply give an insight to the 'damage it could cause'. The usage of this parameter leads to an in-consistent Database with no other alternative but to rebuild the complete Database. This parameter could be used when we realize that there are no stardard options available and are convinced that the customer understands the implications of using the Oracle's secret parameter. The factors to be considered are ;-- 1. Customer does not have a good backup. 2. A lot of time and money has been invested after the last good backup and there is no possibility for reproduction of the lost data. 3. The customer has to be ready to export the full database and import it back after creating a new one. 4. There is no 100% guarantee that by using this parameter the database would come up. 5. Oracle does not support the database after using this parameter for recovery. 6. ALL OPTIONS including the ones mentioned in the action part of the error message have been tried. By setting _ALLOW_RESETLOGS_CORRUPTION=TRUE, certain consistency checks are SKIPPED during database open stage. This basically means it does not check the datafile headers as to what the status was before the shutdown and how it was shutdown. The following cases mention few of the checks that were skipped. Case-I ------ Verification that the datafile present has not been restored from a BACKUP taken before the database was opened successfully by using RESETLOGS. ORA-01190: control file or data file %s is from before the last RESETLOGS Cause: Attempting to use a data file when the log reset information in the file does not match the control file. Either the data file or the control file is a backup that was made before the most recent ALTER DATABASE OPEN RESETLOGS. Action: Restore file from a more recent backup. Case-II ------- Verification that the status bit of the datafile is not in a FUZZY state. The datafile could be in this state due to the database going down when the - Datafile was on-line and open - Datafile was not closed cleanly (maybe due to OS). ORA-01194: file %s needs more recovery to be consistent Cause: An incomplete recover session was started, but an insufficient number of logs were applied to make the file consistent. The reported file was not closed cleanly when it was last opened by the database. It must be recovered to a time when it was not being updated. The most likely cause of this error is forgetting to restore the file from a backup before doing incomplete recovery. Action: Either apply more logs until the file is consistent or restore the file from an older backup and repeat recovery. Case-III -------- Verification that the COMPLETE recover strategies have been applied for recovering the datafile and not any of the INCOMPLETE recovery options. Basically because the complete recovery is one in which we even apply the ON-LINE redo log files and open the DB without reseting the logs. ORA-01113: file '%s' needs media recovery starting at log sequence # %s Cause: An attempt was made to open a database file that is in need of media recovery. Action: First apply media recovery to the file. Case-IV ------- Verification that the datafile has been recovered through an END BACKUP if the control file indicates that it was in backup mode. This is useful when the DB has crashed while in hot backup mode and we lost all log files in DB version's less than V7.2. ORA-01195: on-line backup of file %s needs more recovery to be consistent" Cause: An incomplete recovery session was started, but an insufficient number of logs were applied to make the file consistent. The reported file is an on-line backup which must be recovered to the time the backup ended. Action: Either apply more logs until the file is consistent or resotre the database files from an older backup and repeat recovery. In version 7.2, we could simply issue the ALTER DATABASE DATAFILE xxxx END BACKUP statement and proceed with the recovery. But again to issue this statement, we need to have the ON-LINE redo logs or else we still are forced to use this parameter. Case-V ------ Verification that the data file status is not still in (0x10) MEDIA recovery FUZZY. When recovery is started, a flag is set in the datafile header status flag to indicate that the file is presently in media recovery. This is reset when recovery is completed and at times when it has not been reset we are forced to use this paramter. ORA-01196: file %s is inconsistent due to a failed media recovery session Cause: The file was being recovered but the recovery did not terminate normally. This left the file in an inconsistent state. No more recovery was successfully completed on this file. Action: Either apply more logs until the file is consistent or restore the backup again and repeat recovery. Case-VI ------- Verification that the datafile has been restored form a proper backup to correspond with the log files. This situation could happen when we have decided that the data file is invalid since its SCN is ahead of the last applied logs SCN but it has not failed on one of the ABOVE CHECKS. ORA-01152: file '%s' was not restored from a sufficientluy old backup" Cause: A manual recovery session was started, but an insufficient number of logs were applied to make the database consistent. This file is still in the future of the last log applied. Note that this mistake can not always be caught. Action: Either apply more logs until the database is consistent or restore the database file from an older backup and repeat recovery.
使用_ALLOW_RESETLOGS_CORRUPTION 参数需谨慎,因为该参数可能导致数据库逻辑不一致,甚至可能把本来很简单的一个恢复弄的非常复杂甚至不可恢复的后果,建议在oracle support支持下使用.另外使用该参数resetlogs库之后,强烈建议通过逻辑方式重建库
发表在 Oracle备份恢复
标签为 ORA-01113, ORA-01152, ORA-01190, ORA-01194, ORA-01195, ORA-01196, _ALLOW_RESETLOGS_CORRUPTION
评论关闭
数据库恢复的敏感性—重建控制文件使用不合适数据文件
有客户数据库由于某种原因无法open,请求我们技术支持.通过检查alert日志发现数据库是由于ORA-600 kccpb_sanity_check_2错误.并且他们已经重建控制文件,通过我们的Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)
datafile 6 异常
通过这里我们发现datafile 6 数据文件头是干净的,而且对应的redo seq为5270,而其他文件头都是fuzzy,而且对应的redo为295902613.这里怀疑datafile 6 可能是错误的.当然对于这样scn相距比较大的情况,我们可以通过隐含参数,修改scn等方法强制让该库起来(或者该文件online),但是从现在看到的情况,文件很可能异常,这样强制恢复,可能没有实际意义.
分析alert日志
这个里面可以发现是先删除了sde表空间,然后创建了同一个表空间,只是数据文件路径不一样了.而且正好在seq为5270的地方操作的.现在出现datafile 6异常的原因已经清楚,就是创建数据控制文件的时候,使用了错误的数据文件导致.
完美恢复数据库
D:\>sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 7月 30 16:31:01 2016 Copyright (c) 1982, 2005, Oracle. All rights reserved. 连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production With the Partitioning, OLAP and Data Mining options SQL> shutdown immediate; ORA-01109: 数据库未打开 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> STARTUP NOMOUNT ORACLE 例程已经启动。 Total System Global Area 5133828096 bytes Fixed Size 2011360 bytes Variable Size 2382368544 bytes Database Buffers 2734686208 bytes Redo Buffers 14761984 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "LANDDB" NORESETLOGS ARCHIVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 292 7 LOGFILE 8 GROUP 1 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_1_4JCM05KL_.LOG' SIZE 50M, 9 GROUP 2 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_2_4JCM064D_.LOG' SIZE 50M, 10 GROUP 3 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_3_4JCM06PG_.LOG' SIZE 50M 11 DATAFILE 12 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSTEM_4JCLYY6T_.DBF', 13 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_UNDOTBS1_4JCLYY8S_.DBF', 14 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSAUX_4JCLYY7B_.DBF', 15 'F:\ORADATA\LANDDB\DATAFILE\O1_MF_USERS_4JCLYY98_.DBF', 16 'F:\ORADATA\LANDDB\DATAFILE\FUJIAN', 17 'D:\data\sde.dbf' 18 CHARACTER SET ZHS16GBK 19 ; 控制文件已创建。 SQL> recover database; 完成介质恢复。 SQL> alter database open; 数据库已更改。 SQL>
这个库比较幸运,客户发现异常之后,里面停止了有风险性的操作(比如使用_allow_resetlogs_corruption参数,resetlogs库等),使得数据完美恢复0丢失.如果条件允许最好使用老的控制文件来重建新控制文件,而不要通过人工去系统中找数据文件来实现恢复,这样很可能有遗落或者使用错误的数据文件
kfed找出来asm 磁盘组中数据文件别名对应的文件号—amdu恢复
前段时间有多个朋友问我,在amdu中,如果数据文件命名不是omf的方式,该如何找出来数据文件的asm file_number,从而实现通过amdu对不能mount的磁盘组中的数据文件进行恢复,这里通过测试给出来处理方法.根据我们对asm的理解,asm file_number 6为asm file的别名文件记录所在地,我们通过分析kfed这些au中的记录即可获得相关数据文件的别名对应的asm文件号
模拟各种别名
D:\app\product\10.2.0\db_1\bin>sqlplus / as sysdba SQL*Plus: Release 10.2.0.3.0 - Production on 星期三 7月 27 22:48:48 2016 Copyright (c) 1982, 2006, Oracle. All Rights Reserved. 连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production With the Partitioning, OLAP and Data Mining options SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- +DATA/ora10g/datafile/system.256.914797317 +DATA/ora10g/datafile/undotbs1.258.914797317 +DATA/ora10g/datafile/sysaux.257.914797317 +DATA/ora10g/datafile/users.259.914797317 SQL> create tablespace xifenfei 2 datafile '+data/xifenfei01.dbf' size 10M; 表空间已创建。 SQL> alter tablespace xifenfei add 2 datafile '+data/ora10g/datafile/xifenfei02.dbf' size 10m; 表空间已更改。 SQL> alter tablespace xifenfei add 2 datafile '+data/ora10g/xifenfei03.dbf' size 10m; 表空间已更改。 SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- +DATA/ora10g/datafile/system.256.914797317 +DATA/ora10g/datafile/undotbs1.258.914797317 +DATA/ora10g/datafile/sysaux.257.914797317 +DATA/ora10g/datafile/users.259.914797317 +DATA/xifenfei01.dbf +DATA/ora10g/datafile/xifenfei02.dbf +DATA/ora10g/xifenfei03.dbf 已选择7行。
分析磁盘组和别名信息
SQL> select name from v$asm_disk; NAME ------------------------------ DATA_0000 DATA_0001 SQL> select path from v$asm_disk; PATH ----------------------------------------- H:\ASMDISK\ASMDISK1.DD H:\ASMDISK\ASMDISK2.DD SQL> SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS where file_number<>4294967295; NAME FILE_NUMBER ------------------------------ ----------- SYSTEM.256.914797317 256 SYSAUX.257.914797317 257 UNDOTBS1.258.914797317 258 USERS.259.914797317 259 XIFENFEI.266.918341361 266 XIFENFEI.267.918341389 267 xifenfei02.dbf 267 XIFENFEI.268.918341409 268 Current.260.914797381 260 group_1.261.914797385 261 group_2.262.914797385 262 group_3.263.914797387 263 TEMP.264.914797393 264 spfile.265.914797421 265 spfileora10g.ora 265 xifenfei03.dbf 268 xifenfei01.dbf 266 已选择17行。 SQL> SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS; NAME FILE_NUMBER ------------------------------ ----------- ORA10G 4294967295 DATAFILE 4294967295 SYSTEM.256.914797317 256 SYSAUX.257.914797317 257 UNDOTBS1.258.914797317 258 USERS.259.914797317 259 XIFENFEI.266.918341361 266 XIFENFEI.267.918341389 267 xifenfei02.dbf 267 XIFENFEI.268.918341409 268 CONTROLFILE 4294967295 Current.260.914797381 260 ONLINELOG 4294967295 group_1.261.914797385 261 group_2.262.914797385 262 group_3.263.914797387 263 TEMPFILE 4294967295 TEMP.264.914797393 264 PARAMETERFILE 4294967295 spfile.265.914797421 265 spfileora10g.ora 265 xifenfei03.dbf 268 xifenfei01.dbf 266 已选择23行。
从sql查询,我们可以确定xifenfei0n.dbf对应的文件号分别为:xifenfei01.dbf==>266,xifenfei02.dbf==>267,xifenfei03.dbf==>268
通过kfed file 6所在位置
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD |grep f1b1 kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 kfdhdb.f1b1fcn.base: 0 ; 0x100: 0x00000000 kfdhdb.f1b1fcn.wrap: 0 ; 0x104: 0x00000000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=2 blkn=6|grep kfffde|more kfffde[0].xptr.au: 26 ; 0x4a0: 0x0000001a kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000 kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0 kfffde[0].xptr.chk: 48 ; 0x4a7: 0x30 kfffde[1].xptr.au: 4294967295 ; 0x4a8: 0xffffffff kfffde[1].xptr.disk: 65535 ; 0x4ac: 0xffff
从这里我们可以确定别名的au只有一个位于disk 0, au 26(0x1a)的位置
通过kfed分析别名
www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 |more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 1563703526 ; 0x00c: 0x5d3438e6 kfbh.fcn.base: 3461 ; 0x010: 0x00000d85 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 0 ; 0x014: 0x00000000 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 0 ; 0x01c: 0x00000000 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 2080305534 ; 0x028: 0x7bfef17e kfade[0].entry.refer.number: 1 ; 0x02c: 0x00000001 kfade[0].entry.refer.incarn: 1 ; 0x030: A=1 NUMM=0x0 kfade[0].name: ORA10G ; 0x034: length=6 kfade[0].fnum: 4294967295 ; 0x064: 0xffffffff kfade[0].finc: 4294967295 ; 0x068: 0xffffffff kfade[0].flags: 4 ; 0x06c: U=0 S=0 S=1 U=0 F=0 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 1 ; 0x070: A=1 NUMM=0x0 kfade[1].entry.hash: 3085841201 ; 0x074: 0xb7ee3331 kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: xifenfei01.dbf ; 0x080: length=14 kfade[1].fnum: 266 ; 0x0b0: 0x0000010a kfade[1].finc: 918341361 ; 0x0b4: 0x36bcc6f1 kfade[1].flags: 17 ; 0x0b8: U=1 S=0 S=0 U=0 F=1 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 kfade[2].entry.incarn: 0 ; 0x0bc: A=0 NUMM=0x0 kfade[2].entry.hash: 0 ; 0x0c0: 0x00000000 kfade[2].entry.refer.number: 0 ; 0x0c4: 0x00000000 kfade[2].entry.refer.incarn: 0 ; 0x0c8: A=0 NUMM=0x0 kfade[2].name: ; 0x0cc: length=0 kfade[2].fnum: 0 ; 0x0fc: 0x00000000 kfade[2].finc: 0 ; 0x100: 0x00000000 kfade[2].flags: 0 ; 0x104: U=0 S=0 S=0 U=0 F=0 kfade[2].ub1spare: 0 ; 0x105: 0x00 kfade[2].freeblock: 0 ; 0x106: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 |grep name kfade[0].name: ORA10G ; 0x034: length=6 kfade[1].name: xifenfei01.dbf ; 0x080: length=14 kfade[2].name: ; 0x0cc: length=0 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=1|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 1 ; 0x004: blk=1 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 239000469 ; 0x00c: 0x0e3edb95 kfbh.fcn.base: 3536 ; 0x010: 0x00000dd0 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 0 ; 0x014: 0x00000000 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 1 ; 0x01c: 0x00000001 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 710518681 ; 0x028: 0x2a59a799 kfade[0].entry.refer.number: 2 ; 0x02c: 0x00000002 kfade[0].entry.refer.incarn: 1 ; 0x030: A=1 NUMM=0x0 kfade[0].name: DATAFILE ; 0x034: length=8 kfade[0].fnum: 4294967295 ; 0x064: 0xffffffff kfade[0].finc: 4294967295 ; 0x068: 0xffffffff kfade[0].flags: 4 ; 0x06c: U=0 S=0 S=1 U=0 F=0 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 3 ; 0x070: A=1 NUMM=0x1 kfade[1].entry.hash: 4053320104 ; 0x074: 0xf198c1a8 kfade[1].entry.refer.number: 3 ; 0x078: 0x00000003 kfade[1].entry.refer.incarn: 3 ; 0x07c: A=1 NUMM=0x1 kfade[1].name: CONTROLFILE ; 0x080: length=11 kfade[1].fnum: 4294967295 ; 0x0b0: 0xffffffff kfade[1].finc: 4294967295 ; 0x0b4: 0xffffffff kfade[1].flags: 4 ; 0x0b8: U=0 S=0 S=1 U=0 F=0 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 kfade[2].entry.incarn: 1 ; 0x0bc: A=1 NUMM=0x0 kfade[2].entry.hash: 2803485489 ; 0x0c0: 0xa719cb31 kfade[2].entry.refer.number: 4 ; 0x0c4: 0x00000004 kfade[2].entry.refer.incarn: 1 ; 0x0c8: A=1 NUMM=0x0 kfade[2].name: ONLINELOG ; 0x0cc: length=9 kfade[2].fnum: 4294967295 ; 0x0fc: 0xffffffff kfade[2].finc: 4294967295 ; 0x100: 0xffffffff kfade[2].flags: 4 ; 0x104: U=0 S=0 S=1 U=0 F=0 kfade[2].ub1spare: 0 ; 0x105: 0x00 kfade[2].freeblock: 0 ; 0x106: 0x0000 kfade[3].entry.incarn: 1 ; 0x108: A=1 NUMM=0x0 kfade[3].entry.hash: 2905271101 ; 0x10c: 0xad2aeb3d kfade[3].entry.refer.number: 5 ; 0x110: 0x00000005 kfade[3].entry.refer.incarn: 1 ; 0x114: A=1 NUMM=0x0 kfade[3].name: TEMPFILE ; 0x118: length=8 kfade[3].fnum: 4294967295 ; 0x148: 0xffffffff kfade[3].finc: 4294967295 ; 0x14c: 0xffffffff kfade[3].flags: 4 ; 0x150: U=0 S=0 S=1 U=0 F=0 kfade[3].ub1spare: 0 ; 0x151: 0x00 kfade[3].freeblock: 0 ; 0x152: 0x0000 kfade[4].entry.incarn: 1 ; 0x154: A=1 NUMM=0x0 kfade[4].entry.hash: 3261836913 ; 0x158: 0xc26bae71 kfade[4].entry.refer.number: 6 ; 0x15c: 0x00000006 kfade[4].entry.refer.incarn: 1 ; 0x160: A=1 NUMM=0x0 kfade[4].name: PARAMETERFILE ; 0x164: length=13 kfade[4].fnum: 4294967295 ; 0x194: 0xffffffff kfade[4].finc: 4294967295 ; 0x198: 0xffffffff kfade[4].flags: 4 ; 0x19c: U=0 S=0 S=1 U=0 F=0 kfade[4].ub1spare: 0 ; 0x19d: 0x00 kfade[4].freeblock: 0 ; 0x19e: 0x0000 kfade[5].entry.incarn: 1 ; 0x1a0: A=1 NUMM=0x0 kfade[5].entry.hash: 3373604202 ; 0x1a4: 0xc9151d6a kfade[5].entry.refer.number: 4294967295 ; 0x1a8: 0xffffffff kfade[5].entry.refer.incarn: 0 ; 0x1ac: A=0 NUMM=0x0 kfade[5].name: spfileora10g.ora ; 0x1b0: length=16 kfade[5].fnum: 265 ; 0x1e0: 0x00000109 kfade[5].finc: 914797421 ; 0x1e4: 0x3686b36d kfade[5].flags: 17 ; 0x1e8: U=1 S=0 S=0 U=0 F=1 kfade[5].ub1spare: 0 ; 0x1e9: 0x00 kfade[5].freeblock: 0 ; 0x1ea: 0x0000 kfade[6].entry.incarn: 1 ; 0x1ec: A=1 NUMM=0x0 kfade[6].entry.hash: 3992241470 ; 0x1f0: 0xedf4c53e kfade[6].entry.refer.number: 4294967295 ; 0x1f4: 0xffffffff kfade[6].entry.refer.incarn: 0 ; 0x1f8: A=0 NUMM=0x0 kfade[6].name: xifenfei03.dbf ; 0x1fc: length=14 kfade[6].fnum: 268 ; 0x22c: 0x0000010c kfade[6].finc: 918341409 ; 0x230: 0x36bcc721 kfade[6].flags: 17 ; 0x234: U=1 S=0 S=0 U=0 F=1 kfade[6].ub1spare: 0 ; 0x235: 0x00 kfade[6].freeblock: 0 ; 0x236: 0x0000 kfade[7].entry.incarn: 0 ; 0x238: A=0 NUMM=0x0 kfade[7].entry.hash: 0 ; 0x23c: 0x00000000 kfade[7].entry.refer.number: 0 ; 0x240: 0x00000000 kfade[7].entry.refer.incarn: 0 ; 0x244: A=0 NUMM=0x0 kfade[7].name: ; 0x248: length=0 kfade[7].fnum: 0 ; 0x278: 0x00000000 kfade[7].finc: 0 ; 0x27c: 0x00000000 kfade[7].flags: 0 ; 0x280: U=0 S=0 S=0 U=0 F=0 kfade[7].ub1spare: 0 ; 0x281: 0x00 kfade[7].freeblock: 0 ; 0x282: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=1|grep name kfade[0].name: DATAFILE ; 0x034: length=8 kfade[1].name: CONTROLFILE ; 0x080: length=11 kfade[2].name: ONLINELOG ; 0x0cc: length=9 kfade[3].name: TEMPFILE ; 0x118: length=8 kfade[4].name: PARAMETERFILE ; 0x164: length=13 kfade[5].name: spfileora10g.ora ; 0x1b0: length=16 kfade[6].name: xifenfei03.dbf ; 0x1fc: length=14 kfade[7].name: ; 0x248: length=0 kfade[8].name: ; 0x294: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=2 kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 2 ; 0x004: blk=2 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 3937052433 ; 0x00c: 0xeaaaa711 kfbh.fcn.base: 3535 ; 0x010: 0x00000dcf kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 1 ; 0x014: 0x00000001 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 2 ; 0x01c: 0x00000002 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 1410293950 ; 0x028: 0x540f60be kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfade[0].name: SYSTEM ; 0x034: length=6 kfade[0].fnum: 256 ; 0x064: 0x00000100 kfade[0].finc: 914797317 ; 0x068: 0x3686b305 kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 1 ; 0x070: A=1 NUMM=0x0 kfade[1].entry.hash: 1052386617 ; 0x074: 0x3eba2539 kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: SYSAUX ; 0x080: length=6 kfade[1].fnum: 257 ; 0x0b0: 0x00000101 kfade[1].finc: 914797317 ; 0x0b4: 0x3686b305 kfade[1].flags: 18 ; 0x0b8: U=0 S=1 S=0 U=0 F=1 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 kfade[2].entry.incarn: 1 ; 0x0bc: A=1 NUMM=0x0 kfade[2].entry.hash: 2341166852 ; 0x0c0: 0x8b8b5f04 kfade[2].entry.refer.number: 4294967295 ; 0x0c4: 0xffffffff kfade[2].entry.refer.incarn: 0 ; 0x0c8: A=0 NUMM=0x0 kfade[2].name: UNDOTBS1 ; 0x0cc: length=8 kfade[2].fnum: 258 ; 0x0fc: 0x00000102 kfade[2].finc: 914797317 ; 0x100: 0x3686b305 kfade[2].flags: 18 ; 0x104: U=0 S=1 S=0 U=0 F=1 kfade[2].ub1spare: 0 ; 0x105: 0x00 kfade[2].freeblock: 0 ; 0x106: 0x0000 kfade[3].entry.incarn: 1 ; 0x108: A=1 NUMM=0x0 kfade[3].entry.hash: 18985629 ; 0x10c: 0x0121b29d kfade[3].entry.refer.number: 4294967295 ; 0x110: 0xffffffff kfade[3].entry.refer.incarn: 0 ; 0x114: A=0 NUMM=0x0 kfade[3].name: USERS ; 0x118: length=5 kfade[3].fnum: 259 ; 0x148: 0x00000103 kfade[3].finc: 914797317 ; 0x14c: 0x3686b305 kfade[3].flags: 18 ; 0x150: U=0 S=1 S=0 U=0 F=1 kfade[3].ub1spare: 0 ; 0x151: 0x00 kfade[3].freeblock: 0 ; 0x152: 0x0000 kfade[4].entry.incarn: 1 ; 0x154: A=1 NUMM=0x0 kfade[4].entry.hash: 379856949 ; 0x158: 0x16a42835 kfade[4].entry.refer.number: 4294967295 ; 0x15c: 0xffffffff kfade[4].entry.refer.incarn: 0 ; 0x160: A=0 NUMM=0x0 kfade[4].name: XIFENFEI ; 0x164: length=8 kfade[4].fnum: 266 ; 0x194: 0x0000010a kfade[4].finc: 918341361 ; 0x198: 0x36bcc6f1 kfade[4].flags: 18 ; 0x19c: U=0 S=1 S=0 U=0 F=1 kfade[4].ub1spare: 0 ; 0x19d: 0x00 kfade[4].freeblock: 0 ; 0x19e: 0x0000 kfade[5].entry.incarn: 1 ; 0x1a0: A=1 NUMM=0x0 kfade[5].entry.hash: 889929475 ; 0x1a4: 0x350b3f03 kfade[5].entry.refer.number: 4294967295 ; 0x1a8: 0xffffffff kfade[5].entry.refer.incarn: 0 ; 0x1ac: A=0 NUMM=0x0 kfade[5].name: XIFENFEI ; 0x1b0: length=8 kfade[5].fnum: 267 ; 0x1e0: 0x0000010b kfade[5].finc: 918341389 ; 0x1e4: 0x36bcc70d kfade[5].flags: 18 ; 0x1e8: U=0 S=1 S=0 U=0 F=1 kfade[5].ub1spare: 0 ; 0x1e9: 0x00 kfade[5].freeblock: 0 ; 0x1ea: 0x0000 kfade[6].entry.incarn: 1 ; 0x1ec: A=1 NUMM=0x0 kfade[6].entry.hash: 3416790953 ; 0x1f0: 0xcba817a9 kfade[6].entry.refer.number: 4294967295 ; 0x1f4: 0xffffffff kfade[6].entry.refer.incarn: 0 ; 0x1f8: A=0 NUMM=0x0 kfade[6].name: xifenfei02.dbf ; 0x1fc: length=14 kfade[6].fnum: 267 ; 0x22c: 0x0000010b kfade[6].finc: 918341389 ; 0x230: 0x36bcc70d kfade[6].flags: 17 ; 0x234: U=1 S=0 S=0 U=0 F=1 kfade[6].ub1spare: 0 ; 0x235: 0x00 kfade[6].freeblock: 0 ; 0x236: 0x0000 kfade[7].entry.incarn: 1 ; 0x238: A=1 NUMM=0x0 kfade[7].entry.hash: 3200622536 ; 0x23c: 0xbec59fc8 kfade[7].entry.refer.number: 4294967295 ; 0x240: 0xffffffff kfade[7].entry.refer.incarn: 0 ; 0x244: A=0 NUMM=0x0 kfade[7].name: XIFENFEI ; 0x248: length=8 kfade[7].fnum: 268 ; 0x278: 0x0000010c kfade[7].finc: 918341409 ; 0x27c: 0x36bcc721 kfade[7].flags: 18 ; 0x280: U=0 S=1 S=0 U=0 F=1 kfade[7].ub1spare: 0 ; 0x281: 0x00 kfade[7].freeblock: 0 ; 0x282: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=2|grep name kfade[0].name: SYSTEM ; 0x034: length=6 kfade[1].name: SYSAUX ; 0x080: length=6 kfade[2].name: UNDOTBS1 ; 0x0cc: length=8 kfade[3].name: USERS ; 0x118: length=5 kfade[4].name: XIFENFEI ; 0x164: length=8 kfade[5].name: XIFENFEI ; 0x1b0: length=8 kfade[6].name: xifenfei02.dbf ; 0x1fc: length=14 kfade[7].name: XIFENFEI ; 0x248: length=8 kfade[8].name: ; 0x294: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=3 kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 3 ; 0x004: blk=3 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 362685464 ; 0x00c: 0x159e2418 kfbh.fcn.base: 1938 ; 0x010: 0x00000792 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 3 ; 0x000: A=1 NUMM=0x1 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 1 ; 0x014: 0x00000001 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 3 ; 0x01c: 0x00000003 kffdnd.fstblk.incarn: 3 ; 0x020: A=1 NUMM=0x1 kfade[0].entry.incarn: 3 ; 0x024: A=1 NUMM=0x1 kfade[0].entry.hash: 2951411460 ; 0x028: 0xafeaf704 kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfade[0].name: Current ; 0x034: length=7 kfade[0].fnum: 260 ; 0x064: 0x00000104 kfade[0].finc: 914797381 ; 0x068: 0x3686b345 kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 0 ; 0x070: A=0 NUMM=0x0 kfade[1].entry.hash: 0 ; 0x074: 0x00000000 kfade[1].entry.refer.number: 0 ; 0x078: 0x00000000 kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: ; 0x080: length=0 kfade[1].fnum: 0 ; 0x0b0: 0x00000000 kfade[1].finc: 0 ; 0x0b4: 0x00000000 kfade[1].flags: 0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=3|grep name kfade[0].name: Current ; 0x034: length=7 kfade[1].name: ; 0x080: length=0 kfade[2].name: ; 0x0cc: length=0 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=4|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 4 ; 0x004: blk=4 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 3581479529 ; 0x00c: 0xd5790a69 kfbh.fcn.base: 2167 ; 0x010: 0x00000877 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 1 ; 0x014: 0x00000001 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 4 ; 0x01c: 0x00000004 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 1017821950 ; 0x028: 0x3caabafe kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfade[0].name: group_1 ; 0x034: length=7 kfade[0].fnum: 261 ; 0x064: 0x00000105 kfade[0].finc: 914797385 ; 0x068: 0x3686b349 kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 1 ; 0x070: A=1 NUMM=0x0 kfade[1].entry.hash: 1570256801 ; 0x074: 0x5d9837a1 kfade[1].entry.refer.number: 4294967295 ; 0x078: 0xffffffff kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: group_2 ; 0x080: length=7 kfade[1].fnum: 262 ; 0x0b0: 0x00000106 kfade[1].finc: 914797385 ; 0x0b4: 0x3686b349 kfade[1].flags: 18 ; 0x0b8: U=0 S=1 S=0 U=0 F=1 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 kfade[2].entry.incarn: 1 ; 0x0bc: A=1 NUMM=0x0 kfade[2].entry.hash: 157707762 ; 0x0c0: 0x09666df2 kfade[2].entry.refer.number: 4294967295 ; 0x0c4: 0xffffffff kfade[2].entry.refer.incarn: 0 ; 0x0c8: A=0 NUMM=0x0 kfade[2].name: group_3 ; 0x0cc: length=7 kfade[2].fnum: 263 ; 0x0fc: 0x00000107 kfade[2].finc: 914797387 ; 0x100: 0x3686b34b kfade[2].flags: 18 ; 0x104: U=0 S=1 S=0 U=0 F=1 kfade[2].ub1spare: 0 ; 0x105: 0x00 kfade[2].freeblock: 0 ; 0x106: 0x0000 kfade[3].entry.incarn: 0 ; 0x108: A=0 NUMM=0x0 kfade[3].entry.hash: 0 ; 0x10c: 0x00000000 kfade[3].entry.refer.number: 0 ; 0x110: 0x00000000 kfade[3].entry.refer.incarn: 0 ; 0x114: A=0 NUMM=0x0 kfade[3].name: ; 0x118: length=0 kfade[3].fnum: 0 ; 0x148: 0x00000000 kfade[3].finc: 0 ; 0x14c: 0x00000000 kfade[3].flags: 0 ; 0x150: U=0 S=0 S=0 U=0 F=0 kfade[3].ub1spare: 0 ; 0x151: 0x00 kfade[3].freeblock: 0 ; 0x152: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=4|grep name kfade[0].name: group_1 ; 0x034: length=7 kfade[1].name: group_2 ; 0x080: length=7 kfade[2].name: group_3 ; 0x0cc: length=7 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 kfade[5].name: ; 0x1b0: length=0 kfade[6].name: ; 0x1fc: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=5|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 5 ; 0x004: blk=5 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 1153372471 ; 0x00c: 0x44bf1137 kfbh.fcn.base: 2212 ; 0x010: 0x000008a4 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 1 ; 0x014: 0x00000001 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 5 ; 0x01c: 0x00000005 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 3699413877 ; 0x028: 0xdc809375 kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfade[0].name: TEMP ; 0x034: length=4 kfade[0].fnum: 264 ; 0x064: 0x00000108 kfade[0].finc: 914797393 ; 0x068: 0x3686b351 kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 0 ; 0x070: A=0 NUMM=0x0 kfade[1].entry.hash: 0 ; 0x074: 0x00000000 kfade[1].entry.refer.number: 0 ; 0x078: 0x00000000 kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: ; 0x080: length=0 kfade[1].fnum: 0 ; 0x0b0: 0x00000000 kfade[1].finc: 0 ; 0x0b4: 0x00000000 kfade[1].flags: 0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=5|grep name kfade[0].name: TEMP ; 0x034: length=4 kfade[1].name: ; 0x080: length=0 kfade[2].name: ; 0x0cc: length=0 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=6|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 11 ; 0x002: KFBTYP_ALIASDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 6 ; 0x004: blk=6 kfbh.block.obj: 6 ; 0x008: file=6 kfbh.check: 1230193442 ; 0x00c: 0x49534322 kfbh.fcn.base: 2267 ; 0x010: 0x000008db kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 1 ; 0x014: 0x00000001 kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0 kffdnd.fstblk.number: 6 ; 0x01c: 0x00000006 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfade[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfade[0].entry.hash: 3897004393 ; 0x028: 0xe8479169 kfade[0].entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfade[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfade[0].name: spfile ; 0x034: length=6 kfade[0].fnum: 265 ; 0x064: 0x00000109 kfade[0].finc: 914797421 ; 0x068: 0x3686b36d kfade[0].flags: 18 ; 0x06c: U=0 S=1 S=0 U=0 F=1 kfade[0].ub1spare: 0 ; 0x06d: 0x00 kfade[0].freeblock: 0 ; 0x06e: 0x0000 kfade[1].entry.incarn: 0 ; 0x070: A=0 NUMM=0x0 kfade[1].entry.hash: 0 ; 0x074: 0x00000000 kfade[1].entry.refer.number: 0 ; 0x078: 0x00000000 kfade[1].entry.refer.incarn: 0 ; 0x07c: A=0 NUMM=0x0 kfade[1].name: ; 0x080: length=0 kfade[1].fnum: 0 ; 0x0b0: 0x00000000 kfade[1].finc: 0 ; 0x0b4: 0x00000000 kfade[1].flags: 0 ; 0x0b8: U=0 S=0 S=0 U=0 F=0 kfade[1].ub1spare: 0 ; 0x0b9: 0x00 kfade[1].freeblock: 0 ; 0x0ba: 0x0000 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=6|grep name kfade[0].name: spfile ; 0x034: length=6 kfade[1].name: ; 0x080: length=0 kfade[2].name: ; 0x0cc: length=0 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 www.xifenfei.com>kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=7|grep name kfade[0].name: ; 0x034: length=0 kfade[1].name: ; 0x080: length=0 kfade[2].name: ; 0x0cc: length=0 kfade[3].name: ; 0x118: length=0 kfade[4].name: ; 0x164: length=0 kfade[5].name: ; 0x1b0: length=0 kfade[6].name: ; 0x1fc: length=0
通过上述分析我们发现目前数据主要分布在au=26,block in(0-6)的几个block中,通过kfed已经找出来了所有的asm中文件的file_number
非win平台脚本实现
for (( i=0; i<255; i++ )) do kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blknum=$i \|egrep 'name|fnum'|grep -v length=0 |grep -v 0x00000000 >>asm_file.out done
注意需要按照file 6的au依次处理,否则会不全,更加简单的方法,直接通过dul扫描磁盘获取相关file number