在数据库恢复中,ORA-600 2662我想是很多人都非常熟悉的错误,下文是对于该错误的一些解释
ORA-600 2662解释说明
Format: ORA-600 [2662] [a] [b] 1 [d] [e]
versions 6.0 to 12.1
DESCRIPTION:
A data block SCN is ahead of the current SCN.
The ORA-600 [2662] occurs when an SCN is compared to the dependent SCN
stored in a UGA variable.
If the SCN is less than the dependent SCN then we signal the ORA-600 [2662]
internal error.
ARGUMENTS:
Current SCN WRAP
Current SCN BASE
dependent SCN WRAP
dependent SCN BASE
Where present this is the DBA where the dependent SCN came from.
出现ORA-600 2662可能的原因
(1) doing an open resetlogs with _ALLOW_RESETLOGS_CORRUPTION enabled
(2) a hardware problem, like a faulty controller, resulting in a failed
write to the control file or the redo logs
(3) restoring parts of the database from backup and not doing the
appropriate recovery
(4) restoring a control file and not doing a RECOVER DATABASE USING BACKUP
CONTROLFILE
(5) having _DISABLE_LOGGING set during crash recovery
(6) problems with the DLM in a parallel server environment
ORA-600 2662解决方法
(1) if the SCNs in the error are very close, attempting a startup several
times will bump up the dscn every time we open the database even if
open fails. The database will open when dscn=scn.
(2)You can bump the SCN either on open or while the database is open
using Event:ADJUST_SCN
Be aware that you should rebuild the database if you use this
有网友数据库启动报ORA-600 999错误,无法正常open,让我们介入分析,帮忙恢复其中部分数据
数据库启动报ORA-600 999
Sun Jul 31 23:09:36 2016
SMON: enabling cache recovery
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc
(incident=179779):
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_179779\orcl_smon_.trc
No Resource Manager plan active
Starting background process QMNC
Sun Jul 31 23:09:37 2016
QMNC started with pid=20, OS id=5068
ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (7, 1).
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc:
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Completed: alter database open
Sun Jul 31 23:09:38 2016
db_recovery_file_dest_size of 8680 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Trace dumping is performing id=[cdmp_39]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc
(incident=179785):
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
ORACLE Instance orcl (pid = 13) - Error 600 encountered while recovering transaction (7, 1).
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_3356.trc:
ORA-00600: internal error code, arguments: [999], [0x7FFAE748013], [], [], [], [], [], [], [], [], [], []
Sun Jul 31 23:09:41 2016
Starting background process CJQ0
Sun Jul 31 23:09:41 2016
CJQ0 started with pid=25, OS id=2572
Process debug not enabled via parameter _debug_enable
Trace dumping is performing id=[cdmp_42]
PMON (ospid: 3948): terminating the instance due to error 474
Sun Jul 31 23:09:48 2016
opiodr aborting process unknown ospid (2592) as a result of ORA-1092
Sun Jul 31 23:09:48 2016
ORA-1092 : opitsk aborting process
Sun Jul 31 23:09:52 2016
Instance terminated by PMON, pid = 3948
设置_offline_rollback_segments数据库启动正常
Sun Jul 31 23:18:13 2016
ALTER DATABASE OPEN
Thread 1 opened at log sequence 16
Current log# 1 seq# 16 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Successful open of redo thread 1
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 5.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc
(incident=182188):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_182188\orcl_smon_.trc
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 16, block 2945 to scn
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Trace dumping is performing id=[cdmp_15]
Block recovery stopped at EOT rba 16.2952.16
Block recovery completed at rba 16.2952.16, scn 0.
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Sun Jul 31 23:18:19 2016
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc
(incident=182189):
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_182189\orcl_smon_.trc
Starting background process QMNC
Sun Jul 31 23:18:19 2016
QMNC started with pid=20, OS id=4920
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 16, block 2945 to scn
Recovery of Online Redo Log: Thread 1 Group 1 Seq 16 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG
Block recovery completed at rba 16.2952.16, scn 0.
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_4372.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Starting background process SMCO
Sun Jul 31 23:18:19 2016
SMCO started with pid=21, OS id=3176
Sun Jul 31 23:18:20 2016
Trace dumping is performing id=[cdmp_20]
Completed: ALTER DATABASE OPEN
尝试删除异常回滚段
Sun Jul 31 23:15:07 2016
drop rollback segment &_SYSSMU7_$&
Sun Jul 31 23:15:07 2016
Corrupt Block Found
TSN = 2, TSNAME = UNDOTBS1
RFN = 3, BLK = 224, RDBA =
OBJN = -1, OBJD = -1, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_5300.trc
(incident=181035):
ORA-00600: 内部错误代码, 参数: [kdBlkCheckError], [3], [224], [38508], [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_181035\orcl_ora_.trc
Doing block recovery for file 3 block 224
Resuming block recovery (PMON) for file 3 block 224
Block recovery from logseq 14, block 8682 to scn
Recovery of Online Redo Log: Thread 1 Group 2 Seq 14 Reading mem 0
Mem# 0: D:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
Block recovery completed at rba 14.8688.16, scn 0.
ORA-607 signalled during: drop rollback segment &_SYSSMU7_$&...
Corrupt Block Found
TSN = 2, TSNAME = UNDOTBS1
RFN = 3, BLK = 224, RDBA =
OBJN = -1, OBJD = -1, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =
从这里看,我们可以确定file 3 block 224异常,导致删除回滚段异常.和mos官方给出来的案例类似,由于undo坏块导致数据库报ORA-600 999错误
mos中ORA-600 999报错信息
官方的益处ORA-600[999]报错,也是由于undo坏块引起和本文的报错基本上一致
因为只要部分数据,直接屏蔽回滚段,数据库不再crash,导出需要对象即可
我相信_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
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 t--
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
5. Oracle does not support the database after using this parameter for
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.
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.
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.
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
Action: Either apply more logs until the file is consistent or restore the
file from an older backup and repeat recovery.
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.
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.
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.
Verification that the data file status is not still in (0x10) MEDIA recovery
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
This left the file in an inconsistent state.
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.
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
使用_ALLOW_RESETLOGS_CORRUPTION 参数需谨慎,因为该参数可能导致数据库逻辑不一致,甚至可能把本来很简单的一个恢复弄的非常复杂甚至不可恢复的后果,建议在oracle support支持下使用.另外使用该参数resetlogs库之后,强烈建议通过逻辑方式重建库
, , , , , ,
有客户数据库由于某种原因无法open,请求我们技术支持.通过检查alert日志发现数据库是由于ORA-600 kccpb_sanity_check_2错误.并且他们已经重建控制文件,通过我们的
datafile 6 异常
通过这里我们发现datafile 6 数据文件头是干净的,而且对应的redo seq为5270,而其他文件头都是fuzzy,而且对应的redo为.这里怀疑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) , 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
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL& STARTUP NOMOUNT
ORACLE 例程已经启动。
Total System Global Area
Fixed Size
2011360 bytes
Variable Size
Database Buffers
Redo Buffers
SQL& CREATE CONTROLFILE REUSE DATABASE &LANDDB& NORESETLOGS
ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 3
MAXDATAFILES 100
MAXINSTANCES 8
MAXLOGHISTORY 292
GROUP 1 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_1_4JCM05KL_.LOG'
GROUP 2 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_2_4JCM064D_.LOG'
GROUP 3 'F:\ORADATA\LANDDB\ONLINELOG\O1_MF_3_4JCM06PG_.LOG'
'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSTEM_4JCLYY6T_.DBF',
'F:\ORADATA\LANDDB\DATAFILE\O1_MF_UNDOTBS1_4JCLYY8S_.DBF',
'F:\ORADATA\LANDDB\DATAFILE\O1_MF_SYSAUX_4JCLYY7B_.DBF',
'F:\ORADATA\LANDDB\DATAFILE\O1_MF_USERS_4JCLYY98_.DBF',
'F:\ORADATA\LANDDB\DATAFILE\FUJIAN',
'D:\data\sde.dbf'
CHARACTER SET ZHS16GBK
控制文件已创建。
完成介质恢复。
数据库已更改。
这个库比较幸运,客户发现异常之后,里面停止了有风险性的操作(比如使用_allow_resetlogs_corruption参数,resetlogs库等),使得数据完美恢复0丢失.如果条件允许最好使用老的控制文件来重建新控制文件,而不要通过人工去系统中找数据文件来实现恢复,这样很可能有遗落或者使用错误的数据文件
前段时间有多个朋友问我,在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) , 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$
--------------------------------------------------------------------------------
+DATA/ora10g/datafile/system.256.
+DATA/ora10g/datafile/undotbs1.258.
+DATA/ora10g/datafile/sysaux.257.
+DATA/ora10g/datafile/users.259.
SQL& create tablespace xifenfei
datafile '+data/xifenfei01.dbf' size 10M;
表空间已创建。
SQL& alter tablespace xifenfei add
datafile '+data/ora10g/datafile/xifenfei02.dbf' size 10m;
表空间已更改。
SQL& alter tablespace xifenfei add
datafile '+data/ora10g/xifenfei03.dbf' size 10m;
表空间已更改。
SQL& select name from v$
--------------------------------------------------------------------------------
+DATA/ora10g/datafile/system.256.
+DATA/ora10g/datafile/undotbs1.258.
+DATA/ora10g/datafile/sysaux.257.
+DATA/ora10g/datafile/users.259.
+DATA/xifenfei01.dbf
+DATA/ora10g/datafile/xifenfei02.dbf
+DATA/ora10g/xifenfei03.dbf
已选择7行。
分析磁盘组和别名信息
SQL& select name from v$asm_
------------------------------
SQL& select path from v$asm_
-----------------------------------------
H:\ASMDISK\ASMDISK1.DD
H:\ASMDISK\ASMDISK2.DD
SQL& SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS where file_number&&;
FILE_NUMBER
------------------------------ -----------
SYSTEM.256.
SYSAUX.257.
UNDOTBS1.258.
USERS.259.
XIFENFEI.266.
XIFENFEI.267.
xifenfei02.dbf
XIFENFEI.268.
Current.260.
group_1.261.
group_2.262.
group_3.263.
spfile.265.
spfileora10g.ora
xifenfei03.dbf
xifenfei01.dbf
已选择17行。
SQL& SELECT NAME,FILE_NUMBER FROM V$ASM_ALIAS;
FILE_NUMBER
------------------------------ -----------
SYSTEM.256.
SYSAUX.257.
UNDOTBS1.258.
USERS.259.
XIFENFEI.266.
XIFENFEI.267.
xifenfei02.dbf
XIFENFEI.268.
CONTROLFILE
Current.260.
group_1.261.
group_2.262.
group_3.263.
PARAMETERFILE
spfile.265.
spfileora10g.ora
xifenfei03.dbf
xifenfei01.dbf
已选择23行。
从sql查询,我们可以确定xifenfei0n.dbf对应的文件号分别为:xifenfei01.dbf==>266,xifenfei02.dbf==>267,xifenfei03.dbf==>268
通过kfed file 6所在位置
&kfed read H:\ASMDISK\ASMDISK1.DD |grep f1b1
kfdhdb.f1b1locn:
2 ; 0x0d4: 0x
kfdhdb.f1b1fcn.base:
0 ; 0x100: 0x
kfdhdb.f1b1fcn.wrap:
0 ; 0x104: 0x
&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:
; 0x4a8: 0xffffffff
kfffde[1].xptr.disk:
65535 ; 0x4ac: 0xffff
从这里我们可以确定别名的au只有一个位于disk 0, au 26(0x1a)的位置
通过kfed分析别名
&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:
; 0x00c: 0x5d3438e6
kfbh.fcn.base:
3461 ; 0x010: 0x00000d85
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
0 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
0 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0x7bfef17e
kfade[0].entry.refer.number:
1 ; 0x02c: 0x
kfade[0].entry.refer.incarn:
1 ; 0x030: A=1 NUMM=0x0
kfade[0].name:
ORA10G ; 0x034: length=6
kfade[0].fnum:
; 0x064: 0xffffffff
kfade[0].finc:
; 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:
; 0x074: 0xb7ee3331
kfade[1].entry.refer.number:
; 0x078: 0xffffffff
kfade[1].entry.refer.incarn:
0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:
xifenfei01. 0x080: length=14
kfade[1].fnum:
266 ; 0x0b0: 0x0000010a
kfade[1].finc:
; 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: 0x
kfade[2].entry.refer.number:
0 ; 0x0c4: 0x
kfade[2].entry.refer.incarn:
0 ; 0x0c8: A=0 NUMM=0x0
kfade[2].name:
0x0cc: length=0
kfade[2].fnum:
0 ; 0x0fc: 0x
kfade[2].finc:
0 ; 0x100: 0x
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
&kfed read H:\ASMDISK\ASMDISK1.DD aun=26 |grep name
kfade[0].name:
ORA10G ; 0x034: length=6
kfade[1].name:
xifenfei01. 0x080: length=14
kfade[2].name:
0x0cc: length=0
kfade[3].name:
0x118: length=0
kfade[4].name:
0x164: length=0
&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:
; 0x00c: 0x0e3edb95
kfbh.fcn.base:
3536 ; 0x010: 0x00000dd0
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
0 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
1 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0x2a59a799
kfade[0].entry.refer.number:
2 ; 0x02c: 0x
kfade[0].entry.refer.incarn:
1 ; 0x030: A=1 NUMM=0x0
kfade[0].name:
DATAFILE ; 0x034: length=8
kfade[0].fnum:
; 0x064: 0xffffffff
kfade[0].finc:
; 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:
; 0x074: 0xf198c1a8
kfade[1].entry.refer.number:
3 ; 0x078: 0x
kfade[1].entry.refer.incarn:
3 ; 0x07c: A=1 NUMM=0x1
kfade[1].name:
CONTROLFILE ; 0x080: length=11
kfade[1].fnum:
; 0x0b0: 0xffffffff
kfade[1].finc:
; 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:
; 0x0c0: 0xa719cb31
kfade[2].entry.refer.number:
4 ; 0x0c4: 0x
kfade[2].entry.refer.incarn:
1 ; 0x0c8: A=1 NUMM=0x0
kfade[2].name:
ONLINELOG ; 0x0cc: length=9
kfade[2].fnum:
; 0x0fc: 0xffffffff
kfade[2].finc:
; 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:
; 0x10c: 0xad2aeb3d
kfade[3].entry.refer.number:
5 ; 0x110: 0x
kfade[3].entry.refer.incarn:
1 ; 0x114: A=1 NUMM=0x0
kfade[3].name:
TEMPFILE ; 0x118: length=8
kfade[3].fnum:
; 0x148: 0xffffffff
kfade[3].finc:
; 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:
; 0x158: 0xc26bae71
kfade[4].entry.refer.number:
6 ; 0x15c: 0x
kfade[4].entry.refer.incarn:
1 ; 0x160: A=1 NUMM=0x0
kfade[4].name:
PARAMETERFILE ; 0x164: length=13
kfade[4].fnum:
; 0x194: 0xffffffff
kfade[4].finc:
; 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:
; 0x1a4: 0xc9151d6a
kfade[5].entry.refer.number:
; 0x1a8: 0xffffffff
kfade[5].entry.refer.incarn:
0 ; 0x1ac: A=0 NUMM=0x0
kfade[5].name:
spfileora10g. 0x1b0: length=16
kfade[5].fnum:
265 ; 0x1e0: 0x
kfade[5].finc:
; 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:
; 0x1f0: 0xedf4c53e
kfade[6].entry.refer.number:
; 0x1f4: 0xffffffff
kfade[6].entry.refer.incarn:
0 ; 0x1f8: A=0 NUMM=0x0
kfade[6].name:
xifenfei03. 0x1fc: length=14
kfade[6].fnum:
268 ; 0x22c: 0x0000010c
kfade[6].finc:
; 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: 0x
kfade[7].entry.refer.number:
0 ; 0x240: 0x
kfade[7].entry.refer.incarn:
0 ; 0x244: A=0 NUMM=0x0
kfade[7].name:
0x248: length=0
kfade[7].fnum:
0 ; 0x278: 0x
kfade[7].finc:
0 ; 0x27c: 0x
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
&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. 0x1b0: length=16
kfade[6].name:
xifenfei03. 0x1fc: length=14
kfade[7].name:
0x248: length=0
kfade[8].name:
0x294: length=0
&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:
; 0x00c: 0xeaaaa711
kfbh.fcn.base:
3535 ; 0x010: 0x00000dcf
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
1 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
2 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0x540f60be
kfade[0].entry.refer.number:
; 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: 0x
kfade[0].finc:
; 0x068: 0x
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:
; 0x074: 0x3eba2539
kfade[1].entry.refer.number:
; 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: 0x
kfade[1].finc:
; 0x0b4: 0x
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:
; 0x0c0: 0x8b8b5f04
kfade[2].entry.refer.number:
; 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: 0x
kfade[2].finc:
; 0x100: 0x
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:
; 0x10c: 0x0121b29d
kfade[3].entry.refer.number:
; 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: 0x
kfade[3].finc:
; 0x14c: 0x
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:
; 0x158: 0x16a42835
kfade[4].entry.refer.number:
; 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:
; 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:
; 0x1a4: 0x350b3f03
kfade[5].entry.refer.number:
; 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:
; 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:
; 0x1f0: 0xcba817a9
kfade[6].entry.refer.number:
; 0x1f4: 0xffffffff
kfade[6].entry.refer.incarn:
0 ; 0x1f8: A=0 NUMM=0x0
kfade[6].name:
xifenfei02. 0x1fc: length=14
kfade[6].fnum:
267 ; 0x22c: 0x0000010b
kfade[6].finc:
; 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:
; 0x23c: 0xbec59fc8
kfade[7].entry.refer.number:
; 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:
; 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
&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. 0x1fc: length=14
kfade[7].name:
XIFENFEI ; 0x248: length=8
kfade[8].name:
0x294: length=0
&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:
; 0x00c: 0x159e2418
kfbh.fcn.base:
1938 ; 0x010: 0x
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
3 ; 0x000: A=1 NUMM=0x1
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
1 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
3 ; 0x01c: 0x
kffdnd.fstblk.incarn:
3 ; 0x020: A=1 NUMM=0x1
kfade[0].entry.incarn:
3 ; 0x024: A=1 NUMM=0x1
kfade[0].entry.hash:
; 0x028: 0xafeaf704
kfade[0].entry.refer.number:
; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:
0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:
C 0x034: length=7
kfade[0].fnum:
260 ; 0x064: 0x
kfade[0].finc:
; 0x068: 0x
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: 0x
kfade[1].entry.refer.number:
0 ; 0x078: 0x
kfade[1].entry.refer.incarn:
0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:
0x080: length=0
kfade[1].fnum:
0 ; 0x0b0: 0x
kfade[1].finc:
0 ; 0x0b4: 0x
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
&kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=3|grep name
kfade[0].name:
C 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
&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:
; 0x00c: 0xd5790a69
kfbh.fcn.base:
2167 ; 0x010: 0x
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
1 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
4 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0x3caabafe
kfade[0].entry.refer.number:
; 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: 0x
kfade[0].finc:
; 0x068: 0x
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:
; 0x074: 0x5d9837a1
kfade[1].entry.refer.number:
; 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: 0x
kfade[1].finc:
; 0x0b4: 0x
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:
; 0x0c0: 0x09666df2
kfade[2].entry.refer.number:
; 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: 0x
kfade[2].finc:
; 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: 0x
kfade[3].entry.refer.number:
0 ; 0x110: 0x
kfade[3].entry.refer.incarn:
0 ; 0x114: A=0 NUMM=0x0
kfade[3].name:
0x118: length=0
kfade[3].fnum:
0 ; 0x148: 0x
kfade[3].finc:
0 ; 0x14c: 0x
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
&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
&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:
; 0x00c: 0x44bf1137
kfbh.fcn.base:
2212 ; 0x010: 0x
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
1 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
5 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0xdc809375
kfade[0].entry.refer.number:
; 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: 0x
kfade[0].finc:
; 0x068: 0x
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: 0x
kfade[1].entry.refer.number:
0 ; 0x078: 0x
kfade[1].entry.refer.incarn:
0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:
0x080: length=0
kfade[1].fnum:
0 ; 0x0b0: 0x
kfade[1].finc:
0 ; 0x0b4: 0x
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
&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
&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:
; 0x00c: 0x
kfbh.fcn.base:
2267 ; 0x010: 0x000008db
kfbh.fcn.wrap:
0 ; 0x014: 0x
kfbh.spare1:
0 ; 0x018: 0x
kfbh.spare2:
0 ; 0x01c: 0x
kffdnd.bnode.incarn:
1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number:
; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn:
0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number:
; 0x00c: 0xffffffff
kffdnd.overfl.incarn:
0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number:
1 ; 0x014: 0x
kffdnd.parent.incarn:
1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number:
6 ; 0x01c: 0x
kffdnd.fstblk.incarn:
1 ; 0x020: A=1 NUMM=0x0
kfade[0].entry.incarn:
1 ; 0x024: A=1 NUMM=0x0
kfade[0].entry.hash:
; 0x028: 0xe8479169
kfade[0].entry.refer.number:
; 0x02c: 0xffffffff
kfade[0].entry.refer.incarn:
0 ; 0x030: A=0 NUMM=0x0
kfade[0].name:
0x034: length=6
kfade[0].fnum:
265 ; 0x064: 0x
kfade[0].finc:
; 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: 0x
kfade[1].entry.refer.number:
0 ; 0x078: 0x
kfade[1].entry.refer.incarn:
0 ; 0x07c: A=0 NUMM=0x0
kfade[1].name:
0x080: length=0
kfade[1].fnum:
0 ; 0x0b0: 0x
kfade[1].finc:
0 ; 0x0b4: 0x
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
&kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blkn=6|grep name
kfade[0].name:
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
&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++ ))
kfed read H:\ASMDISK\ASMDISK1.DD aun=26 blknum=$i
\|egrep 'name|fnum'|grep -v length=0 |grep -v 0x &&asm_file.out
注意需要按照file 6的au依次处理,否则会不全,更加简单的方法,直接通过dul扫描磁盘获取相关file number
加我微信(xifenfei88)
WP Cumulus Flash tag cloud by
9 or better.}