Oracle ASM和VxCFS的比较

2015/03/21 by Leave a Comment
关于VxCFS和ASM
 
 
ASM的主要优点在于 成本的优势：
1.ASM是免费的存储解决方案； 
2.磁盘管理与自动IO负载均衡，可以免除手动进行IO调优；
3.ASM功能绑定在Oracle内核中，无需依靠安装HACMP或第三方HA软件；(注10g中可能仍需要ha来存放OCR和Votedisk)
4.自动重组数据,较稳定的保持负载均衡
5.动态添加移除磁盘，对oracle数据库几乎透明；
6.性能上ASM接近于使用裸设备
 
虽然ORACLE 10g的早期版本，ASM很不稳定，而且在PSU 10.2.0.4.4发布时，其中修复的ASM bug数仍达到了8个，但在PSU 10.2.0.4.5及其之后，没有发现有修复ASM bug的情况，所以可以相信在PSU 10.2.0.4.4之后，ASM功能已趋于稳定(注: 在PSU 10.2.0.5.6发布时修复了1个ASM bug；在PSU 11.2.0.3.1发布时修复了6个bug)
 
缺点是：ASM的内部结构较为黑盒，当出现例如ASM header丢失时，需要ASM相关专业人员负责修复。
 
 
Veritas Cluster File System VxCFS的优势是管理方便，较ASM在技术上更透明，一旦发生故障可以更快地定位问题。
 
目前国内 VxCFS在电信业有一些核心库使用的例子， 而 ASM在银行、政府机构等行业已经有了广泛的使用，部分银行用户已部署多达上百套RAC+ASM库。
Filed Under: Oracle, Oracle ASM

Oracle ASM ACFS 安装失败问题

2015/03/19 by 1 Comment

Oracle ASM ACFS 安装失败问题

 

[client(10813644)]CRS-10001:29-Sep-13 14:07 ACFS-9200: Supported
[client(7798872)]CRS-10001:29-Sep-13 14:07 ACFS-9300: ADVM/ACFS distribution files found.
[client(7798880)]CRS-10001:29-Sep-13 14:07 ACFS-9312: Existing ADVM/ACFS installation detected.
[client(7798888)]CRS-10001:29-Sep-13 14:07 ACFS-9314: Removing previous ADVM/ACFS installation.
[client(7798896)]CRS-10001:29-Sep-13 14:07 ACFS-9361: Removing device ‘acfsctl’ failed with error code ‘5888’.
[client(7798898)]CRS-10001:29-Sep-13 14:07 ACFS-9307: Installing requested ADVM/ACFS software.
[client(7143672)]CRS-10001:29-Sep-13 14:07 ACFS-9308: Loading installed ADVM/ACFS drivers.
[client(7143678)]CRS-10001:29-Sep-13 14:07 ACFS-9154: Loading ‘oracleadvm.ext’ driver.
[client(7143430)]CRS-10001:29-Sep-13 14:07 ACFS-9154: Loading ‘oracleacfs.ext’ driver.
[client(7143438)]CRS-10001:29-Sep-13 14:07 ACFS-9109: oracleacfs.ext driver failed to load.
[client(7143440)]CRS-10001:29-Sep-13 14:07 ACFS-9310: ADVM/ACFS installation failed.
[client(7143442)]CRS-10001:29-Sep-13 14:07 ACFS-9311: not all components were detected after the installation.
 
 
 
以上ACFS 安装失败问题，与 ACFS-9109: [oracleacfs.ext driver failed to load] Error During 11.2.0.3 RAC Grid Infrastructure Installation (On AIX). (Doc ID 1541476.1) 描述的较为一致。
 
请收集一下  ls -l /dev/   的信息 
 
 

1) Brand New 11.2.0.3 RAC Grid Infrastructure Installation (on AIX) is reporting the following errors during the “root.sh” script execution:

[client(7274562)]CRS-10001:23-Mar-13 01:14 ACFS-9314: Removing previous ADVM/ACFS installation.
[client(7274570)]CRS-10001:23-Mar-13 01:14 ACFS-9361: Removing device ‘acfsctl’ failed with error code ‘5888’.
[client(7274572)]CRS-10001:23-Mar-13 01:14 ACFS-9307: Installing requested ADVM/ACFS software.
[client(9568274)]CRS-10001:23-Mar-13 01:14 ACFS-9308: Loading installed ADVM/ACFS drivers.
[client(10551446)]CRS-10001:23-Mar-13 01:14 ACFS-9109: oracleacfs.ext driver failed to load.
[client(10551448)]CRS-10001:23-Mar-13 01:14 ACFS-9310: ADVM/ACFS installation failed.
[client(10551450)]CRS-10001:23-Mar-13 01:14 ACFS-9311: not all components were detected after the installation.
[client(7274634)]CRS-10001:23-Mar-13 01:21 ACFS-9300: ADVM/ACFS distribution files found.
[client(7274646)]CRS-10001:23-Mar-13 01:21 ACFS-9307: Installing requested ADVM/ACFS software.
[client(7274660)]CRS-10001:23-Mar-13 01:21 ACFS-9308: Loading installed ADVM/ACFS drivers.
[client(7274678)]CRS-10001:23-Mar-13 01:21 ACFS-9109: oracleacfs.ext driver failed to load.
[client(7274680)]CRS-10001:23-Mar-13 01:21 ACFS-9310: ADVM/ACFS installation failed.
[client(7274682)]CRS-10001:23-Mar-13 01:21 ACFS-9311: not all components were detected after the installation.

 
2) An attempt to manually install the ACFS/ADVM layer could isolated the problem and reported the next errors (ACFS-11053):

asmhost1[/u01/grid/bin]#./acfsroot install
ACFS-9300: ADVM/ACFS distribution files found.
ACFS-9312: Existing ADVM/ACFS installation detected.
ACFS-9314: Removing previous ADVM/ACFS installation.
This may take several minutes. Please wait …
(udefacfsctl): ACFS-11053: failed to release major number for device ofsctl
(udefacfsctl): ACFS-11055: failed to remove device special file /dev/ofsctl, errno 2 (No such file or directory)
ACFS-9361: Removing device ‘acfsctl’ failed with error code ‘14848’.
ACFS-9307: Installing requested ADVM/ACFS software.
ACFS-9308: Loading installed ADVM/ACFS drivers.
(cfgacfsctl): ACFS-11022: failed to configure device ofsctl, errno 22 (Invalid argument)
(cfgacfsctl): ACFS-11041: trying to clean up after encountering an error
ACFS-9109: oracleacfs.ext driver failed to load.
ACFS-9310: ADVM/ACFS installation failed.
ACFS-9311: not all components were detected after the installation.

 

CAUSE

 

The “[ACFS-11053: failed to release major number for device ofsctl]” error indicates a conflict between the “/dev/ofsctl” & “/dev/dlmadrv” devices since both have the same major and minor numbers:

 

# cd  /dev

# ls -l dlmadrv  

crw——-    1 root     system       37,  0 Feb  1 14:34 dlmadrv  
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# ls -l ofsctl

crw——-    1 root     system       37,  0 Mar  1 10:15 ofsctl


Filed Under: Oracle, Oracle ASM

Oracle ASM架构图

2015/01/29 by Leave a Comment

Oracle ASM架构图Oracle ASM架构图

Filed Under: Oracle, Oracle ASM

ORA-15042 ORA-15040 ORA-15032 ASM add disk加盘

2015/01/29 by Leave a Comment

存在这种可能性，即ORACLE ASM在add disk扩盘时add disk操作正常完成，disk group的rebalance其实还没有开始，但是由于新加入的disk存在硬件故障，导致add disk后写入到disk header的所有metadata元数据全部丢失，且由于diskgroup是外部冗余即EXTERNAL REdundancy所以该diskgroup由于已经加入了一个DISK，而该DISK上的metadata全部丢失的缘故，所以该diskgroup 将无法正常MOUNT。

且由于新加入的disk上的所有metadata都丢失了，而不仅仅是丢失了disk header的KFBTYP_DISKHEAD，所以还不能是仅仅将KFBTYP_DISKHEAD的信息通过kfed merge其他的disk信息并做修改来还原，其需要通过特殊的手工处理才能绕过该问题。

如下面的例子:

 

SUCCESS: diskgroup TESTDG03 was created
NOTE: cache deleting context for group TESTDG03 1/0x86485c30
NOTE: cache registered group TESTDG03 number=1 incarn=0xab385c36
NOTE: cache began mount (first) of group TESTDG03 number=1 incarn=0xab385c36
NOTE: Assigning number (1,3) to disk (/oracleasm/asm-disk04)
NOTE: Assigning number (1,2) to disk (/oracleasm/asm-disk03)
NOTE: Assigning number (1,1) to disk (/oracleasm/asm-disk02)
NOTE: Assigning number (1,0) to disk (/oracleasm/asm-disk01)
Thu Jan 29 08:21:07 2015
NOTE: GMON heartbeating for grp 1
GMON querying group 1 at 92 for pid 20, osid 20176
Thu Jan 29 08:21:07 2015
NOTE: cache opening disk 0 of grp 1: TESTDG03_0000 path:/oracleasm/asm-disk01
NOTE: F1X0 found on disk 0 au 2 fcn 0.0
NOTE: cache opening disk 1 of grp 1: TESTDG03_0001 path:/oracleasm/asm-disk02
NOTE: cache opening disk 2 of grp 1: TESTDG03_0002 path:/oracleasm/asm-disk03
NOTE: cache opening disk 3 of grp 1: TESTDG03_0003 path:/oracleasm/asm-disk04
NOTE: cache mounting (first) external redundancy group 1/0xAB385C36 (TESTDG03)
NOTE: cache recovered group 1 to fcn 0.0
NOTE: redo buffer size is 256 blocks (1053184 bytes)
Thu Jan 29 08:21:07 2015
NOTE: LGWR attempting to mount thread 1 for diskgroup 1 (TESTDG03)
NOTE: LGWR found thread 1 closed at ABA 0.10750
NOTE: LGWR mounted thread 1 for diskgroup 1 (TESTDG03)
NOTE: LGWR opening thread 1 at fcn 0.0 ABA 2.0
NOTE: setting 11.2 start ABA for group TESTDG03 thread 1 to 2.0
NOTE: cache mounting group 1/0xAB385C36 (TESTDG03) succeeded
NOTE: cache ending mount (success) of group TESTDG03 number=1 incarn=0xab385c36
GMON querying group 1 at 93 for pid 13, osid 4612
Thu Jan 29 08:21:07 2015
NOTE: Instance updated compatible.asm to 11.2.0.0.0 for grp 1
SUCCESS: diskgroup TESTDG03 was mounted
SUCCESS: CREATE DISKGROUP TESTDG03 EXTERNAL REDUNDANCY  DISK '/oracleasm/asm-disk01' SIZE 129500M ,
'/oracleasm/asm-disk02' SIZE 128800M ,
'/oracleasm/asm-disk03' SIZE 129200M ,
'/oracleasm/asm-disk04' SIZE 128800M  ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='1M' /* ASMCA */
Thu Jan 29 08:21:07 2015
NOTE: diskgroup resource ora.TESTDG03.dg is online
NOTE: diskgroup resource ora.TESTDG03.dg is updated
Thu Jan 29 08:21:23 2015
SQL> alter diskgroup testdg03  add disk '/oracleasm/asm-disk06' 
ORA-15032: not all alterations performed
ORA-15260: permission denied on ASM disk group
ERROR: alter diskgroup testdg03  add disk '/oracleasm/asm-disk06'
Thu Jan 29 08:21:31 2015
SQL> alter diskgroup testdg03  add disk '/oracleasm/asm-disk06' 
NOTE: Assigning number (1,4) to disk (/oracleasm/asm-disk06)
NOTE: requesting all-instance membership refresh for group=1
NOTE: initializing header on grp 1 disk TESTDG03_0004
NOTE: requesting all-instance disk validation for group=1
Thu Jan 29 08:21:32 2015
NOTE: skipping rediscovery for group 1/0xab385c36 (TESTDG03) on local instance.
NOTE: requesting all-instance disk validation for group=1
NOTE: skipping rediscovery for group 1/0xab385c36 (TESTDG03) on local instance.
NOTE: initiating PST update: grp = 1
Thu Jan 29 08:21:32 2015
GMON updating group 1 at 94 for pid 21, osid 22706
NOTE: PST update grp = 1 completed successfully 
NOTE: membership refresh pending for group 1/0xab385c36 (TESTDG03)
GMON querying group 1 at 95 for pid 13, osid 4612
NOTE: cache opening disk 4 of grp 1: TESTDG03_0004 path:/oracleasm/asm-disk06
GMON querying group 1 at 96 for pid 13, osid 4612
SUCCESS: refreshed membership for 1/0xab385c36 (TESTDG03)
SUCCESS: alter diskgroup testdg03  add disk '/oracleasm/asm-disk06'
NOTE: Attempting voting file refresh on diskgroup TESTDG03
Thu Jan 29 08:22:09 2015
SQL> alter diskgroup testdg03 dismount 
NOTE: cache dismounting (clean) group 1/0xAB385C36 (TESTDG03) 
NOTE: messaging CKPT to quiesce pins Unix process pid: 22730, image: oracle@mlab2.oracle.com (TNS V1-V3)
Thu Jan 29 08:22:10 2015
NOTE: LGWR doing clean dismount of group 1 (TESTDG03)
NOTE: LGWR closing thread 1 of diskgroup 1 (TESTDG03) at ABA 2.15
NOTE: cache dismounted group 1/0xAB385C36 (TESTDG03) 
Thu Jan 29 08:22:10 2015
GMON dismounting group 1 at 97 for pid 21, osid 22730
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
SUCCESS: diskgroup TESTDG03 was dismounted
NOTE: cache deleting context for group TESTDG03 1/0xab385c36
Thu Jan 29 08:22:10 2015
NOTE: diskgroup resource ora.TESTDG03.dg is offline
SUCCESS: alter diskgroup testdg03 dismount
NOTE: diskgroup resource ora.TESTDG03.dg is updated
SQL> alter diskgroup testdg03 mount 
NOTE: cache registered group TESTDG03 number=1 incarn=0x83f85c5f
NOTE: cache began mount (first) of group TESTDG03 number=1 incarn=0x83f85c5f
NOTE: Assigning number (1,3) to disk (/oracleasm/asm-disk04)
NOTE: Assigning number (1,2) to disk (/oracleasm/asm-disk03)
NOTE: Assigning number (1,1) to disk (/oracleasm/asm-disk02)
NOTE: Assigning number (1,0) to disk (/oracleasm/asm-disk01)
Thu Jan 29 08:22:22 2015
NOTE: GMON heartbeating for grp 1
GMON querying group 1 at 100 for pid 21, osid 22730
Thu Jan 29 08:22:22 2015
NOTE: Assigning number (1,4) to disk ()
GMON querying group 1 at 101 for pid 21, osid 22730
NOTE: cache dismounting (clean) group 1/0x83F85C5F (TESTDG03) 
NOTE: messaging CKPT to quiesce pins Unix process pid: 22730, image: oracle@mlab2.oracle.com (TNS V1-V3)
NOTE: dbwr not being msg'd to dismount
NOTE: lgwr not being msg'd to dismount
NOTE: cache dismounted group 1/0x83F85C5F (TESTDG03) 
NOTE: cache ending mount (fail) of group TESTDG03 number=1 incarn=0x83f85c5f
NOTE: cache deleting context for group TESTDG03 1/0x83f85c5f
GMON dismounting group 1 at 102 for pid 21, osid 22730
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
NOTE: Disk  in mode 0x8 marked for de-assignment
ERROR: diskgroup TESTDG03 was not mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "4" is missing from group number "1" 
ERROR: alter diskgroup testdg03 mount
Thu Jan 29 08:27:37 2015
SQL> alter diskgroup testdg03 mount 
NOTE: cache registered group TESTDG03 number=1 incarn=0x56985c64
NOTE: cache began mount (first) of group TESTDG03 number=1 incarn=0x56985c64
NOTE: Assigning number (1,3) to disk (/oracleasm/asm-disk04)
NOTE: Assigning number (1,2) to disk (/oracleasm/asm-disk03)
NOTE: Assigning number (1,1) to disk (/oracleasm/asm-disk02)
NOTE: Assigning number (1,0) to disk (/oracleasm/asm-disk01)
Thu Jan 29 08:27:43 2015
NOTE: GMON heartbeating for grp 1
GMON querying group 1 at 105 for pid 21, osid 23017
NOTE: cache opening disk 0 of grp 1: TESTDG03_0000 path:/oracleasm/asm-disk01
NOTE: F1X0 found on disk 0 au 2 fcn 0.0
NOTE: cache opening disk 1 of grp 1: TESTDG03_0001 path:/oracleasm/asm-disk02
NOTE: cache opening disk 2 of grp 1: TESTDG03_0002 path:/oracleasm/asm-disk03
NOTE: cache opening disk 3 of grp 1: TESTDG03_0003 path:/oracleasm/asm-disk04
NOTE: cache mounting (first) external redundancy group 1/0x56985C64 (TESTDG03)
NOTE: cache recovered group 1 to fcn 0.609
NOTE: redo buffer size is 256 blocks (1053184 bytes)
Thu Jan 29 08:27:43 2015
NOTE: LGWR attempting to mount thread 1 for diskgroup 1 (TESTDG03)
NOTE: LGWR found thread 1 closed at ABA 2.15
NOTE: LGWR mounted thread 1 for diskgroup 1 (TESTDG03)
NOTE: LGWR opening thread 1 at fcn 0.609 ABA 3.16
NOTE: cache mounting group 1/0x56985C64 (TESTDG03) succeeded
NOTE: cache ending mount (success) of group TESTDG03 number=1 incarn=0x56985c64
GMON querying group 1 at 106 for pid 13, osid 4612
Thu Jan 29 08:27:43 2015
NOTE: Instance updated compatible.asm to 11.2.0.0.0 for grp 1
SUCCESS: diskgroup TESTDG03 was mounted
SUCCESS: alter diskgroup testdg03 mount
Thu Jan 29 08:27:43 2015
NOTE: diskgroup resource ora.TESTDG03.dg is online
NOTE: diskgroup resource ora.TESTDG03.dg is updated
Thu Jan 29 08:33:52 2015
SQL> alter diskgroup testdg03 check all norepair 
NOTE: starting check of diskgroup TESTDG03
Thu Jan 29 08:33:52 2015
GMON checking disk 0 for group 1 at 107 for pid 21, osid 23017
GMON checking disk 1 for group 1 at 108 for pid 21, osid 23017
GMON checking disk 2 for group 1 at 109 for pid 21, osid 23017
GMON checking disk 3 for group 1 at 110 for pid 21, osid 23017
ERROR: no kfdsk for  (4)
ERROR: check of diskgroup TESTDG03 found 1 total errors
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ORA-15032: not all alterations performed
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ERROR: alter diskgroup testdg03 check all norepair
Thu Jan 29 08:34:07 2015
SQL> alter diskgroup testdg03 check all 
NOTE: starting check of diskgroup TESTDG03
Thu Jan 29 08:34:07 2015
GMON checking disk 0 for group 1 at 111 for pid 21, osid 23017
GMON checking disk 1 for group 1 at 112 for pid 21, osid 23017
GMON checking disk 2 for group 1 at 113 for pid 21, osid 23017
GMON checking disk 3 for group 1 at 114 for pid 21, osid 23017
ERROR: no kfdsk for  (4)
ERROR: check of diskgroup TESTDG03 found 1 total errors
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ORA-15032: not all alterations performed
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ERROR: alter diskgroup testdg03 check all
SQL> alter diskgroup testdg03 check all repair 
NOTE: starting check of diskgroup TESTDG03
GMON checking disk 0 for group 1 at 115 for pid 21, osid 23017
GMON checking disk 1 for group 1 at 116 for pid 21, osid 23017
GMON checking disk 2 for group 1 at 117 for pid 21, osid 23017
GMON checking disk 3 for group 1 at 118 for pid 21, osid 23017
ERROR: no kfdsk for  (4)
ERROR: check of diskgroup TESTDG03 found 1 total errors
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ORA-15032: not all alterations performed
ORA-15049: diskgroup "TESTDG03" contains 1 error(s)
ERROR: alter diskgroup testdg03 check all repair

[oracle@mlab2 oracleasm]$ oerr ora 15042
15042, 00000, “ASM disk \”%s\” is missing from group number \”%s\” ”
// *Cause:  The specified disk, which is a necessary part of a diskgroup,
//          could not be found on the system.
// *Action: Check the hardware configuration.
//

ORA-15042错误正是因为add disk的磁盘上的metadata全部丢失了，但搞笑的时候新加入的盘上可能因为还没有开始rebalance而没有一点真正有意义的数据，但因为ASM认为该disk已经add进来了，所以必须要该disk可用才能mount diskgroup。 而且用户甚至无法强制DROP这个DISK，原因是需要DISKGROUP在MOUNT状态下才可以drop disk， 这就变成了鸡生蛋 蛋生鸡的死循环， 要DROP这个disk必须MOUNT DISKGROUP，但要MOUNT DISKGROUP要先DROP该DISK。

 

对于此问题一般需要诗檀软件工程师手动修改ASM metadata来绕过问题，或者如果有之前的ASM metadata也可以采用。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

Filed Under: Oracle, Oracle ASM, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: , ,

ASM kfed repair到底干点啥？

2015/01/29 by 2 Comments

官方对于kfed repair命令的描述比较简单:Recover the disk header from the redundant copy of it maintained on an unused portion of the disk. 其主要用来disk header的头4096 bytes的KFBTYP_DISKHEAD结构，这个恢复是基于10.2.0.5以后的Disk Header自动备份机制的。其在PST即AU=1的最后第二个数据块中(Read from PST(AU 1)’s penultimate Block)自动备份了KFBTYP_DISKHEAD。

 

如:

[oracle@mlab2 oracleasm]$ kfed read asm-disk04 aun=1 blkn=254|less
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483651 ; 0x008: disk=3
kfbh.check:                    98849704 ; 0x00c: 0x05e453a8
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum:                        3 ; 0x024: 0x0003
kfdhdb.grptyp:                        3 ; 0x026: KFDGTP_HIGH
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:              DATA1_0003 ; 0x028: length=10
kfdhdb.grpname:                   DATA1 ; 0x048: length=5
kfdhdb.fgname:               DATA1_0003 ; 0x068: length=10
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             33006980 ; 0x0a8: HOUR=0x4 DAYS=0xc MNTH=0x9 YEAR=0x7de
kfdhdb.crestmp.lo:           2555232256 ; 0x0ac: USEC=0x0 MSEC=0x370 SECS=0x4 MINS=0x26
kfdhdb.mntstmp.hi:             33008247 ; 0x0b0: HOUR=0x17 DAYS=0x13 MNTH=0xa YEAR=0x7de
kfdhdb.mntstmp.lo:           3341018112 ; 0x0b4: USEC=0x0 MSEC=0xf9 SECS=0x32 MINS=0x31
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize:                  128800 ; 0x0c4: 0x0001f720
kfdhdb.pmcnt:                         3 ; 0x0c8: 0x00000003
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
:

由于ASM 有这个备份，所以kfed repair可以自动修复ASM disk header的最开始的4096 bytes，但又由于这个备份只备份4096字节的metadata，所以它不能应对整体metadata(除掉KFBTYP_DISKHEAD外）还有大量的其他必须的metadata元数据。

之前在用户现场发现kfed repair也能修复PST KFBTYP_PST_META中的部分逻辑讹误/损坏，但一直无法在自己的环境中重现。

 

具体STRACE了下 kfed repair的处理过程：

 

[oracle@mlab2 oracleasm]$ dd if=/dev/zero of=asm-disk04 bs=4096 count=1 conv=notrunc
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 6.9811e-05 seconds, 58.7 MB/s
[oracle@mlab2 oracleasm]$ 
[oracle@mlab2 oracleasm]$ kfed read asm-disk04
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
7F70E2F06400 00000000 00000000 00000000 00000000  [................]
  Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

[oracle@mlab2 oracleasm]$ 
[oracle@mlab2 oracleasm]$ 
[oracle@mlab2 oracleasm]$ www.askmac.cn
[oracle@mlab2 oracleasm]$ 
[oracle@mlab2 oracleasm]$ strace -o  kfed1.log kfed repair asm-disk04

munmap(0x7fd80aa2d000, 143360)          = 0
stat("asm-disk04", {st_mode=S_IFREG|0644, st_size=135056588800, ...}) = 0
access("asm-disk04", F_OK)              = 0
statfs("asm-disk04", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=961422084, f_bfree=454635689, f_bavail=405808746, f_files=244187136, f_ffree=24
4182184, f_fsid={-138681668, -1790432782}, f_namelen=255, f_frsize=4096}) = 0
open("asm-disk04", O_RDWR)              = 7
lseek(7, 2088960, SEEK_SET)             = 2088960
read(7, "\1\202\1\1\0\0\0\0\3\0\0\200\250S\344\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
lseek(7, 0, SEEK_SET)                   = 0
read(7, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
lseek(7, 0, SEEK_SET)                   = 0
write(7, "\1\202\1\1\0\0\0\0\3\0\0\200\250S\344\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 4096
close(7)

在以上场景中未重现KFED 修复KFBTYP_PST_META的元数据，其仅仅读取了偏移量为2088960的（2088960/4096=510=255+255 即AUN=1的最后第二个块）的4096字节，并写入到OFFSET=0的地方。

 

 

具体查看了以下KFED的源代码 ， 也并未发现其会修复其他地方metadata的线索：

 



#define KFEDOP_REPAIR ((kfedop)13)      /* Repair ASM disk header            */
www.askmac.cn

  case KFEDOP_REPAIR:
    /* Read from PST(AU 1)'s penultimate Block */
    cx->aunum_kfedcx  = (ub4)1;
    cx->blknum_kfedcx = (ub4)(bfact - 2);

    if (!kfedReadBlk(cx))
      goto done;

    /* Validate the Disk Header block read from PST */
    if(!kfedValidateBlk(cx, KFBTYP_DISKHEAD))
      goto done;

    /* Fix the block number and checksum in the buffer */
    if (!kfedFixBackupHeader(cx)) www.askmac.cn
      goto done;

    /* Write to Disk Header(AU 0 and Block 0) */
    cx->aunum_kfedcx  = (ub4)0;
    cx->blknum_kfedcx = (ub4)0;

    if (!kfedWriteBlk(cx))
      goto done;

    break;

以上代码可以理解为，KFEDOP_REPAIR操作读取PST(AU 1)’s penultimate Block即AUN=1的最后第二个块，若无法读取则直接报错，若可以读取则验证从PST中读取的DISK header的block,并FIX其中的block number以及checksum值，之后写出到disk header即AUN=0 BLKN=0的地方。

 

总之，如果确实遇到了此类ASM的问题，那么在充分备份DISK HEADER后（备份前200MB是必要的），在有DISK HEADER自动备份的情况下，尝试KFED REPAIR一下吧，如果不能成功那么后续会有一堆的诊断metadata和手动修复工作等着我们呢。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

 

诗檀软件专业数据库修复团队

 

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。

欢迎下载使用ORACLE PRM。 下载地址：http://parnassusdata.com/sites/default/files/ParnassusData_PRMForOracle_3206.zip

PRM用户使用手册。http://www.parnassusdata.com/sites/default/files/ParnassusData%20Recovery%20Manager%20For%20Oracle%20Database%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%20v0.3.pdf

 

 

 

Filed Under: Oracle, Oracle ASM, Oracle数据恢复、数据库恢复、灾难恢复 Tagged With: ,

深入了解Oracle ASM(二):ASM File number 1 文件目录

2014/12/14 by 4 Comments

ASM file number 1 – the File Directory

 

ASM文件目录File Directory针对本Disk Group中的每一个文件包含一条记录。该记录指向该文件的前60个数据盘区extents，必要时还包括间接盘区indirect extents。该文件目录在必要容纳更多文件数目时会自动增长。每一个文件目录记录保持更新以下文件信息：

 

  • 文件大小
  • 该文件的块大小
  • 文件种类，例如：数据文件，ASM元数据文件，在线日志，归档日志，控制文件等等
  • 文件冗余度：外部、2路或者3路镜像
  • 条带化配置，coarse or fine
  • 到前60个extent的直接盘区指针(direct extent pointer)
  • 300个间接盘区指针(indirect extent pointers)
  • 创建时间戳
  • 最后修改或更新时间戳
  • 指向别名目录中的用户别名和文件名

ASM 1号文件 file number 1

文件号file number是文件目录中找到对应文件记录的重要索引键。 其中第一条记录是该文件目录自身。为了找出过期的文件号，所以在每个文件创建时都生成了一个唯一的32 bit的识别号incarnation number。由此，disk group的ID+ file number + 该incarnation number 可以做到唯一识别某个指定文件。

 

请注意，约定俗成地将ASM文件的第一个block称为0号块–block zero。 0号块通常包含十分重要的接口信息。

 

文件目录file directory 的位置 

 

为了找出file directory所在AU的位置，我们需要使用kfed工具浏览ASM disk header磁盘头部0号AU中的kfdhdb.f1b1locn信息，例如我们使用kfed查看asm disk /dev/asm-diski上的信息：

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski  aun=0 |less

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483650 ; 0x008: disk=2
kfbh.check:                  2593903300 ; 0x00c: 0x9a9bd2c4
kfbh.fcn.base:                      217 ; 0x010: 0x000000d9
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        2 ; 0x024: 0x0002
kfdhdb.grptyp:                        3 ; 0x026: KFDGTP_HIGH
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:           SYSTEMDG_0002 ; 0x028: length=13
kfdhdb.grpname:                SYSTEMDG ; 0x048: length=8
kfdhdb.fgname:            SYSTEMDG_0002 ; 0x068: length=13
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32982958 ; 0x0a8: HOUR=0xe DAYS=0x1d MNTH=0x1 YEAR=0x7dd
kfdhdb.crestmp.lo:           3878604800 ; 0x0ac: USEC=0x0 MSEC=0x3b4 SECS=0x32 MINS=0x39
kfdhdb.mntstmp.hi:             32983461 ; 0x0b0: HOUR=0x5 DAYS=0xd MNTH=0x2 YEAR=0x7dd
kfdhdb.mntstmp.lo:            474934272 ; 0x0b4: USEC=0x0 MSEC=0x3bb SECS=0x4 MINS=0x7
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize:                    3072 ; 0x0c4: 0x00000c00
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000
kfdhdb.dbcompat:              168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi:             32982958 ; 0x0e4: HOUR=0xe DAYS=0x1d MNTH=0x1 YEAR=0x7dd
kfdhdb.grpstmp.lo:           3878197248 ; 0x0e8: USEC=0x0 MSEC=0x226 SECS=0x32 MINS=0x39
kfdhdb.vfstart:                       0 ; 0x0ec: 0x00000000
kfdhdb.vfend:                         0 ; 0x0f0: 0x00000000
kfdhdb.spfile:                       38 ; 0x0f4: 0x00000026
kfdhdb.spfflg:                        1 ; 0x0f8: 0x00000001

//也可以通过查询X$KFFXP视图找出该FILE NUMBER=1的文件的Allocation Units

select disk_kffxp, AU_kffxp, xnum_kffxp
  from x$kffxp
 where group_kffxp = 3 -- Diskgroup 3 (GROUPB)
   and number_kffxp = 1 -- File 1 (file directory)
   /

DISK_KFFXP   AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
         0          2          0
         1          2          0
         2          2          0
         2         46          1
         3         44          1
         0         46          1

 

 

 

上面显示的结果显示 在disk number =0 的ASM Disk 上的allocation units 2属于file number=1的file directory， 同理 在disk number =0 的ASM Disk 上的allocation units 46也属于file number=1的file directory。

在1MB allocation units大小，4k ASM block大小的前提下，第一个allocation unit可以存放255个目录记录(256*4k=1MB)。 由于前255个文件是为ASM元数据保留的，所以第一个allocation unit仅记录ASM元数据文件第一到第六个。剩下的allocation unit(46)则存放接下来的255个ASM文件。

 

文件目录结构

 

Allocation unit=2 的block 1描述了该ASM 1号文件file directory自身。该块的前部分包含了标准的头部信息，并显示该块的类型为KFBTYP_FILEDIR。 在该kfffdb结构之后，该file directory的每一个block包含描述文件物理属性和盘区指针的信息， 以及指向所有间接盘区的指针。

以下是aun=2 block=1的file directory信息：

 

 

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski aun=2 blkn=1  > block.log
[grid@localhost ~]$ vi block.log 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: blk=1
kfbh.block.obj:                       1 ; 0x008: file=1
kfbh.check:                  3254018873 ; 0x00c: 0xc1f46339
kfbh.fcn.base:                      493 ; 0x010: 0x000001ed
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfffdb.node.incarn:                   1 ; 0x000: A=1 NUMM=0x0
kfffdb.node.frlist.number:   4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:                 2097152 ; 0x010: 0x00200000
kfffdb.xtntcnt:                       6 ; 0x014: 0x00000006
kfffdb.xtnteof:                       6 ; 0x018: 0x00000006
kfffdb.blkSize:                    4096 ; 0x01c: 0x00001000
kfffdb.flags:                         1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfffdb.fileType:                     15 ; 0x021: 0x0f
kfffdb.dXrs:                         19 ; 0x022: SCHE=0x1 NUMB=0x3
kfffdb.iXrs:                         19 ; 0x023: SCHE=0x1 NUMB=0x3
kfffdb.dXsiz[0]:             4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]:                      0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]:                      0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]:             4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]:                      0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]:                      0 ; 0x038: 0x00000000
kfffdb.xtntblk:                       6 ; 0x03c: 0x0006
kfffdb.break:                        60 ; 0x03e: 0x003c
kfffdb.priZn:                         0 ; 0x040: KFDZN_COLD
kfffdb.secZn:                         0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare:                      0 ; 0x042: 0x0000

 

 

其中字段的含义：

 

 

KFBTYP_FILEDIR // block type = file directory block
kfffdb.node.incarn: File incarnation information
kfffdb.hibytes File size (high bytes)
kfffdb.lobyte 2097152 ; 0x010: 0x00200000 File size (low bytes) 2097152 ==》2MB大小
kfffdb.xtntcnt: 6 ; 0x014: 0x00000006 // 6 extents for this file
kfffdb.xtnteof: 6 ; 0x018: 0x00000006 // 6 extents before eof
kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 // 标准ASM block大小
kfffdb.flags: 1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0
// Flag definitions
O – File is original, not snapshot
S – File is striped
S – Strict allocation policy
D – File is damaged
C – File creation is committed
I – File has empty indirect block
R – File has known at-risk value
A – The at-risk value itsefl

 

接下来看一个ASM metadata 文件的实际目录记录，我们就查看aun=2的 blkn=4

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski aun=2 blkn=4|less

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       4 ; 0x004: blk=4
kfbh.block.obj:                       1 ; 0x008: file=1
kfbh.check:                  3786097185 ; 0x00c: 0xe1ab4221
kfbh.fcn.base:                      206 ; 0x010: 0x000000ce
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfffdb.node.incarn:                   1 ; 0x000: A=1 NUMM=0x0
kfffdb.node.frlist.number:   4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:                 8331264 ; 0x010: 0x007f2000
kfffdb.xtntcnt:                      24 ; 0x014: 0x00000018
kfffdb.xtnteof:                      24 ; 0x018: 0x00000018
kfffdb.blkSize:                    4096 ; 0x01c: 0x00001000
kfffdb.flags:                         1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfffdb.fileType:                     15 ; 0x021: 0x0f
kfffdb.dXrs:                         19 ; 0x022: SCHE=0x1 NUMB=0x3
kfffdb.iXrs:                         19 ; 0x023: SCHE=0x1 NUMB=0x3
kfffdb.dXsiz[0]:             4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]:                      0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]:                      0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]:             4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]:                      0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]:                      0 ; 0x038: 0x00000000
kfffdb.xtntblk:                      24 ; 0x03c: 0x0018
kfffdb.break:                        60 ; 0x03e: 0x003c
kfffdb.priZn:                         0 ; 0x040: KFDZN_COLD
kfffdb.secZn:                         0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare:                      0 ; 0x042: 0x0000
kfffdb.alias[0]:             4294967295 ; 0x044: 0xffffffff
kfffdb.alias[1]:             4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth:                      0 ; 0x04c: 0x00
kfffdb.strpsz:                        0 ; 0x04d: 0x00
kfffdb.usmsz:                         0 ; 0x04e: 0x0000
kfffdb.crets.hi:               32982958 ; 0x050: HOUR=0xe DAYS=0x1d MNTH=0x1 YEAR=0x7dd
kfffdb.crets.lo:             3878730752 ; 0x054: USEC=0x0 MSEC=0x2f SECS=0x33 MINS=0x39
kfffdb.modts.hi:               32982958 ; 0x058: HOUR=0xe DAYS=0x1d MNTH=0x1 YEAR=0x7dd
kfffdb.modts.lo:             3878730752 ; 0x05c: USEC=0x0 MSEC=0x2f SECS=0x33 MINS=0x39
kfffdb.dasz[0]:                       0 ; 0x060: 0x00
kfffdb.dasz[1]:                       0 ; 0x061: 0x00
kfffdb.dasz[2]:                       0 ; 0x062: 0x00
kfffdb.dasz[3]:                       0 ; 0x063: 0x00
kfffdb.permissn:                      0 ; 0x064: 0x00
kfffdb.ub1spar1:                      0 ; 0x065: 0x00
kfffdb.ub2spar2:                      0 ; 0x066: 0x0000
kfffdb.user.entnum:                   0 ; 0x068: 0x0000
kfffdb.user.entinc:                   0 ; 0x06a: 0x0000
kfffdb.group.entnum:                  0 ; 0x06c: 0x0000
kfffdb.group.entinc:                  0 ; 0x06e: 0x0000
kfffdb.spare[0]:                      0 ; 0x070: 0x00000000
kfffdb.spare[1]:                      0 ; 0x074: 0x00000000
kfffdb.spare[2]:                      0 ; 0x078: 0x00000000
kfffdb.spare[3]:                      0 ; 0x07c: 0x00000000
kfffdb.spare[4]:                      0 ; 0x080: 0x00000000
kfffdb.spare[5]:                      0 ; 0x084: 0x00000000
kfffdb.spare[6]:                      0 ; 0x088: 0x00000000
kfffdb.spare[7]:                      0 ; 0x08c: 0x00000000
kfffdb.spare[8]:                      0 ; 0x090: 0x00000000
kfffdb.spare[9]:                      0 ; 0x094: 0x00000000
kfffdb.spare[10]:                     0 ; 0x098: 0x00000000
kfffdb.spare[11]:                     0 ; 0x09c: 0x00000000
kfffdb.usm:                             ; 0x0a0: length=0
kfffde[0].xptr.au:                   36 ; 0x4a0: 0x00000024
kfffde[0].xptr.disk:                  1 ; 0x4a4: 0x0001
kfffde[0].xptr.flags:                 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                  15 ; 0x4a7: 0x0f
kfffde[1].xptr.au:                   45 ; 0x4a8: 0x0000002d
kfffde[1].xptr.disk:                  0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags:                 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk:                   7 ; 0x4af: 0x07
kfffde[2].xptr.au:                   34 ; 0x4b0: 0x00000022
kfffde[2].xptr.disk:                  3 ; 0x4b4: 0x0003
kfffde[2].xptr.flags:                 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk:                  11 ; 0x4b7: 0x0b
kfffde[3].xptr.au:                   36 ; 0x4b8: 0x00000024
kfffde[3].xptr.disk:                  0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags:                 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk:                  14 ; 0x4bf: 0x0e
kfffde[4].xptr.au:                   43 ; 0x4c0: 0x0000002b
kfffde[4].xptr.disk:                  3 ; 0x4c4: 0x0003
kfffde[4].xptr.flags:                 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk:                   2 ; 0x4c7: 0x02
kfffde[5].xptr.au:                   37 ; 0x4c8: 0x00000025
kfffde[5].xptr.disk:                  1 ; 0x4cc: 0x0001
kfffde[5].xptr.flags:                 0 ; 0x4ce: L=0 E=0 D=0 S=0
kfffde[5].xptr.chk:                  14 ; 0x4cf: 0x0e
kfffde[6].xptr.au:                   42 ; 0x4d0: 0x0000002a
kfffde[6].xptr.disk:                  2 ; 0x4d4: 0x0002
kfffde[6].xptr.flags:                 0 ; 0x4d6: L=0 E=0 D=0 S=0
kfffde[6].xptr.chk:                   2 ; 0x4d7: 0x02
kfffde[7].xptr.au:                   40 ; 0x4d8: 0x00000028
kfffde[7].xptr.disk:                  1 ; 0x4dc: 0x0001
kfffde[7].xptr.flags:                 0 ; 0x4de: L=0 E=0 D=0 S=0
kfffde[7].xptr.chk:                   3 ; 0x4df: 0x03
kfffde[8].xptr.au:                   39 ; 0x4e0: 0x00000027
kfffde[8].xptr.disk:                  3 ; 0x4e4: 0x0003
kfffde[8].xptr.flags:                 0 ; 0x4e6: L=0 E=0 D=0 S=0

 

 

其中字段的含义：

kfffdb.lobytes: 8331264 ; 0x010: 0x007f2000 ==>说明文件大小为8331264bytes
kfffdb.xtntcnt: 24 ; 0x014: 0x00000018
kfffdb.xtnteof: 24 ; 0x018: 0x00000018 ==> 说明该文件目前共24个extents
kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 ==> 4k的ASM Block size
kfffdb.fileType: 15 ; 0x021: 0x0f filetype=15 说明是ASM Metadata File
kfffde[0].xptr.au: 36 ; 0x4a0: 0x00000024 file number=4 的第一extent指向36号 AU
kfffde[0].xptr.disk: 1 ; 0x4a4: 0x0001 Disk number 1
kfffde[1].xptr.au: 45 ; 0x4a8: 0x0000002d file number=4 的第二extent指向45号AU
kfffde[2].xptr.au: 4294967295 ; 0x4b0: 0xfffffff 若 kfffde[N].xptr.au=4294967295 说明该FILE没有更多extent了

 

AU的指针情况， 可以这样查看:

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski aun=2 blkn=4| egrep "xptr.au|xptr.disk"|less

kfffde[0].xptr.au:                   36 ; 0x4a0: 0x00000024
kfffde[0].xptr.disk:                  1 ; 0x4a4: 0x0001
kfffde[1].xptr.au:                   45 ; 0x4a8: 0x0000002d
kfffde[1].xptr.disk:                  0 ; 0x4ac: 0x0000
kfffde[2].xptr.au:                   34 ; 0x4b0: 0x00000022
kfffde[2].xptr.disk:                  3 ; 0x4b4: 0x0003
kfffde[3].xptr.au:                   36 ; 0x4b8: 0x00000024
kfffde[3].xptr.disk:                  0 ; 0x4bc: 0x0000
kfffde[4].xptr.au:                   43 ; 0x4c0: 0x0000002b
kfffde[4].xptr.disk:                  3 ; 0x4c4: 0x0003
kfffde[5].xptr.au:                   37 ; 0x4c8: 0x00000025
kfffde[5].xptr.disk:                  1 ; 0x4cc: 0x0001
kfffde[6].xptr.au:                   42 ; 0x4d0: 0x0000002a
kfffde[6].xptr.disk:                  2 ; 0x4d4: 0x0002
kfffde[7].xptr.au:                   40 ; 0x4d8: 0x00000028
kfffde[7].xptr.disk:                  1 ; 0x4dc: 0x0001
kfffde[8].xptr.au:                   39 ; 0x4e0: 0x00000027
kfffde[8].xptr.disk:                  3 ; 0x4e4: 0x0003
kfffde[9].xptr.au:                   40 ; 0x4e8: 0x00000028
kfffde[9].xptr.disk:                  3 ; 0x4ec: 0x0003
kfffde[10].xptr.au:                  41 ; 0x4f0: 0x00000029
kfffde[10].xptr.disk:                 1 ; 0x4f4: 0x0001
kfffde[11].xptr.au:                  40 ; 0x4f8: 0x00000028
kfffde[11].xptr.disk:                 0 ; 0x4fc: 0x0000
kfffde[12].xptr.au:                  42 ; 0x500: 0x0000002a
kfffde[12].xptr.disk:                 1 ; 0x504: 0x0001
kfffde[13].xptr.au:                  41 ; 0x508: 0x00000029
kfffde[13].xptr.disk:                 0 ; 0x50c: 0x0000
kfffde[14].xptr.au:                  43 ; 0x510: 0x0000002b
kfffde[14].xptr.disk:                 2 ; 0x514: 0x0002
kfffde[15].xptr.au:                  42 ; 0x518: 0x0000002a
kfffde[15].xptr.disk:                 0 ; 0x51c: 0x0000
kfffde[16].xptr.au:                  41 ; 0x520: 0x00000029
kfffde[16].xptr.disk:                 3 ; 0x524: 0x0003
kfffde[17].xptr.au:                  43 ; 0x528: 0x0000002b
kfffde[17].xptr.disk:                 1 ; 0x52c: 0x0001
kfffde[18].xptr.au:                  44 ; 0x530: 0x0000002c
kfffde[18].xptr.disk:                 2 ; 0x534: 0x0002
kfffde[19].xptr.au:                  43 ; 0x538: 0x0000002b
kfffde[19].xptr.disk:                 0 ; 0x53c: 0x0000
kfffde[20].xptr.au:                  44 ; 0x540: 0x0000002c
kfffde[20].xptr.disk:                 1 ; 0x544: 0x0001
kfffde[20].xptr.disk:                 1 ; 0x544: 0x0001
kfffde[21].xptr.au:                  42 ; 0x548: 0x0000002a
kfffde[21].xptr.disk:                 3 ; 0x54c: 0x0003
kfffde[22].xptr.au:                  45 ; 0x550: 0x0000002d
kfffde[22].xptr.disk:                 2 ; 0x554: 0x0002
kfffde[23].xptr.au:                  45 ; 0x558: 0x0000002d
kfffde[23].xptr.disk:                 1 ; 0x55c: 0x0001
kfffde[24].xptr.au:          4294967295 ; 0x560: 0xffffffff
kfffde[24].xptr.disk:             65535 ; 0x564: 0xffff
kfffde[25].xptr.au:          4294967295 ; 0x568: 0xffffffff
kfffde[25].xptr.disk:             65535 ; 0x56c: 0xffff
kfffde[26].xptr.au:          4294967295 ; 0x570: 0xffffffff
kfffde[26].xptr.disk:             65535 ; 0x574: 0xffff
kfffde[27].xptr.au:          4294967295 ; 0x578: 0xffffffff

可以这样验证一下

select disk_kffxp, AU_kffxp, xnum_kffxp
from x$kffxp
where group_kffxp = 3 -- Diskgroup 3 (GROUPB)
and number_kffxp =4
/

DISK_KFFXP   AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
         1         36          0
         0         45          0
         3         34          0
         0         36          1
         3         43          1
         1         37          1
         2         42          2
         1         40          2
         3         39          2
         3         40          3
         1         41          3
         0         40          3
         1         42          4
         0         41          4
         2         43          4
         0         42          5
         3         41          5
         1         43          5
         2         44          6
         0         43          6
         1         44          6
         3         42          7
         2         45          7
         1         45          7

 

 

找出数据文件对应的目录记录directory entry:

SQL> select GROUP_NUMBER, FILE_NUMBER, NAME from v$asm_alias
  2  group by GROUP_NUMBER, FILE_NUMBER, NAME;

GROUP_NUMBER FILE_NUMBER NAME
------------ ----------- ----------------------------------------------------------------------
           3         253 REGISTRY.253.805993079
           3         256 users01.dbf
           3         256 users01.dbf.256.806828719
           3         257 system01.dbf
           3         257 system01.dbf.257.807460773
           3         258 sysaux01.dbf
           3         258 sysaux01.dbf.258.807460839
           3         259 example01.dbf
           3         259 example01.dbf.259.807460921
           3  4294967295 ASM
           3  4294967295 DATAFILE
           3  4294967295 ASMPARAMETERFILE

可以看到 system01.dbf 和 system01.dbf.257.807460773 是同一个file的2个alias

其文件号为 257， 257-256=1  则其file directory的记录位于AU=46的 第一个block

[grid@localhost ~]$ kfed read /dev/asm-diski  aun=46 blkn=1|less
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     257 ; 0x004: blk=257
kfbh.block.obj:                       1 ; 0x008: file=1
kfbh.check:                  3782876348 ; 0x00c: 0xe17a1cbc
kfbh.fcn.base:                     2055 ; 0x010: 0x00000807
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfffdb.node.incarn:           807460773 ; 0x000: A=1 NUMM=0x18106fd2
kfffdb.node.frlist.number:   4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:               828383232 ; 0x010: 0x31602000
kfffdb.xtntcnt:                    2373 ; 0x014: 0x00000945
kfffdb.xtnteof:                    2373 ; 0x018: 0x00000945
kfffdb.blkSize:                    8192 ; 0x01c: 0x00002000
kfffdb.flags:                        17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType:                      2 ; 0x021: 0x02
kfffdb.dXrs:                         19 ; 0x022: SCHE=0x1 NUMB=0x3
kfffdb.iXrs:                         19 ; 0x023: SCHE=0x1 NUMB=0x3
kfffdb.dXsiz[0]:             4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]:                      0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]:                      0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]:             4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]:                      0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]:                      0 ; 0x038: 0x00000000
kfffdb.xtntblk:                      63 ; 0x03c: 0x003f
kfffdb.break:                        60 ; 0x03e: 0x003c
kfffdb.priZn:                         0 ; 0x040: KFDZN_COLD
kfffdb.secZn:                         0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare:                      0 ; 0x042: 0x0000
kfffdb.alias[0]:                    160 ; 0x044: 0x000000a0
kfffdb.alias[1]:                      2 ; 0x048: 0x00000002
kfffdb.strpwdth:                      1 ; 0x04c: 0x01
kfffdb.strpsz:                       20 ; 0x04d: 0x14
kfffdb.usmsz:                         0 ; 0x04e: 0x0000
kfffdb.crets.hi:               32983534 ; 0x050: HOUR=0xe DAYS=0xf MNTH=0x2 YEAR=0x7dd
kfffdb.crets.lo:             2651955200 ; 0x054: USEC=0x0 MSEC=0x68 SECS=0x21 MINS=0x27
kfffdb.modts.hi:               32983534 ; 0x058: HOUR=0xe DAYS=0xf MNTH=0x2 YEAR=0x7dd
kfffdb.modts.lo:                      0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]:                       0 ; 0x060: 0x00
kfffdb.dasz[1]:                       0 ; 0x061: 0x00
kfffdb.dasz[2]:                       0 ; 0x062: 0x00
kfffdb.dasz[3]:                       0 ; 0x063: 0x00
kfffdb.permissn:                      0 ; 0x064: 0x00
kfffdb.ub1spar1:                      0 ; 0x065: 0x00
kfffdb.ub2spar2:                      0 ; 0x066: 0x0000
kfffdb.user.entnum:                   0 ; 0x068: 0x0000
kfffdb.user.entinc:                   0 ; 0x06a: 0x0000
kfffdb.group.entnum:                  0 ; 0x06c: 0x0000
kfffdb.group.entinc:                  0 ; 0x06e: 0x0000
kfffdb.spare[0]:                      0 ; 0x070: 0x00000000
kfffdb.spare[1]:                      0 ; 0x074: 0x00000000
kfffdb.spare[2]:                      0 ; 0x078: 0x00000000
kfffdb.spare[3]:                      0 ; 0x07c: 0x00000000
kfffdb.spare[4]:                      0 ; 0x080: 0x00000000
kfffdb.spare[5]:                      0 ; 0x084: 0x00000000
kfffdb.spare[6]:                      0 ; 0x088: 0x00000000
kfffdb.spare[7]:                      0 ; 0x08c: 0x00000000
kfffdb.spare[8]:                      0 ; 0x090: 0x00000000
kfffdb.spare[9]:                      0 ; 0x094: 0x00000000
kfffdb.spare[10]:                     0 ; 0x098: 0x00000000
kfffdb.spare[11]:                     0 ; 0x09c: 0x00000000
kfffdb.usm:                             ; 0x0a0: length=0
kfffde[0].xptr.au:                  365 ; 0x4a0: 0x0000016d
kfffde[0].xptr.disk:                  3 ; 0x4a4: 0x0003
kfffde[0].xptr.flags:                 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                  69 ; 0x4a7: 0x45
kfffde[1].xptr.au:                  368 ; 0x4a8: 0x00000170
kfffde[1].xptr.disk:                  1 ; 0x4ac: 0x0001
kfffde[1].xptr.flags:                 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk:                  90 ; 0x4af: 0x5a
kfffde[2].xptr.au:                  368 ; 0x4b0: 0x00000170
kfffde[2].xptr.disk:                  2 ; 0x4b4: 0x0002
kfffde[2].xptr.flags:                 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk:                  89 ; 0x4b7: 0x59
kfffde[3].xptr.au:                  368 ; 0x4b8: 0x00000170
kfffde[3].xptr.disk:                  0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags:                 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk:                  91 ; 0x4bf: 0x5b
kfffde[4].xptr.au:                  366 ; 0x4c0: 0x0000016e
kfffde[4].xptr.disk:                  3 ; 0x4c4: 0x0003
kfffde[4].xptr.flags:                 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk:                  70 ; 0x4c7: 0x46
kfffde[5].xptr.au:                  369 ; 0x4c8: 0x00000171
kfffde[5].xptr.disk:                  1 ; 0x4cc: 0x0001
kfffde[5].xptr.flags:                 0 ; 0x4ce: L=0 E=0 D=0 S=0

kfffde[0].xptr.au:                  365 ; 0x4a0: 0x0000016d
kfffde[0].xptr.disk:                  3 ; 0x4a4: 0x0003
kfffde[0].xptr.flags:                 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                  69 ; 0x4a7: 0x45
kfffde[1].xptr.au:                  368 ; 0x4a8: 0x00000170
kfffde[1].xptr.disk:                  1 ; 0x4ac: 0x0001

则该system01.dbf.257.807460773的前2个extent
指向 disk number=3 的aun=365 和 disknum=1 的aun=368

用X$KFFXP来验证一下

select disk_kffxp, AU_kffxp, xnum_kffxp
from x$kffxp
where group_kffxp=3    -- group number 
and number_kffxp=257   -- file number

DISK_KFFXP   AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
         3        365          0 
         1        368          0 
.......................

 

 

 

 

Directly addressed extents

 

来看一个大于500MB 的ASM上的数据文件的情况，sysaux01.dbf.258.807460839的 file number=258 大小为780M

 

 

SQL> select bytes/1024/1024 ,file_number from v$asm_file;

BYTES/1024/1024 FILE_NUMBER
--------------- -----------
     .001464844         253
     426.257813         256
     790.007813         257
     780.007813         258
     341.257813         259

select disk_kffxp, AU_kffxp, xnum_kffxp
from x$kffxp
where group_kffxp=3
and number_kffxp=258;

DISK_KFFXP   AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
         0        963          0 
         1        962          0 
         2        962          0 
         2        963          1
         0        964          1
         3        958          1
         1        963          2
         3        959          2
         0        965          2
......................................
......................................
         0       1549        780
         1       1548        780
         2       1547        780
         0        978 2147483648
         3        973 2147483648
         1        977 2147483648

2346 rows selected.

 

 

共有2346个extent分配给该数据文件，来看一下该数据文件的directory entry

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski aun=46 blkn=2|less
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     258 ; 0x004: blk=258
kfbh.block.obj:                       1 ; 0x008: file=1
kfbh.check:                  1890402582 ; 0x00c: 0x70ad4116
kfbh.fcn.base:                     2882 ; 0x010: 0x00000b42
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfffdb.node.incarn:           807460839 ; 0x000: A=1 NUMM=0x18106ff3
kfffdb.node.frlist.number:   4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:               817897472 ; 0x010: 0x30c02000
kfffdb.xtntcnt:                    2343 ; 0x014: 0x00000927
kfffdb.xtnteof:                    2343 ; 0x018: 0x00000927
kfffdb.blkSize:                    8192 ; 0x01c: 0x00002000
kfffdb.flags:                        17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType:                      2 ; 0x021: 0x02
kfffdb.dXrs:                         19 ; 0x022: SCHE=0x1 NUMB=0x3
kfffdb.iXrs:                         19 ; 0x023: SCHE=0x1 NUMB=0x3
kfffdb.dXsiz[0]:             4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]:                      0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]:                      0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]:             4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]:                      0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]:                      0 ; 0x038: 0x00000000
kfffdb.xtntblk:                      63 ; 0x03c: 0x003f
kfffdb.break:                        60 ; 0x03e: 0x003c
kfffdb.priZn:                         0 ; 0x040: KFDZN_COLD
kfffdb.secZn:                         0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare:                      0 ; 0x042: 0x0000
kfffdb.alias[0]:                    161 ; 0x044: 0x000000a1
kfffdb.alias[1]:                      3 ; 0x048: 0x00000003
kfffdb.strpwdth:                      1 ; 0x04c: 0x01
kfffdb.strpsz:                       20 ; 0x04d: 0x14
kfffdb.usmsz:                         0 ; 0x04e: 0x0000
kfffdb.crets.hi:               32983534 ; 0x050: HOUR=0xe DAYS=0xf MNTH=0x2 YEAR=0x7dd
kfffdb.crets.lo:             2724658176 ; 0x054: USEC=0x0 MSEC=0x1bf SECS=0x26 MINS=0x28
kfffdb.modts.hi:               32983534 ; 0x058: HOUR=0xe DAYS=0xf MNTH=0x2 YEAR=0x7dd
kfffdb.modts.lo:                      0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.dasz[0]:                       0 ; 0x060: 0x00
kfffdb.dasz[1]:                       0 ; 0x061: 0x00
kfffdb.dasz[2]:                       0 ; 0x062: 0x00
kfffdb.dasz[3]:                       0 ; 0x063: 0x00
kfffdb.permissn:                      0 ; 0x064: 0x00
kfffdb.ub1spar1:                      0 ; 0x065: 0x00
kfffdb.ub2spar2:                      0 ; 0x066: 0x0000
kfffdb.user.entnum:                   0 ; 0x068: 0x0000
kfffdb.user.entinc:                   0 ; 0x06a: 0x0000
kfffdb.group.entnum:                  0 ; 0x06c: 0x0000
kfffdb.group.entinc:                  0 ; 0x06e: 0x0000
kfffdb.spare[0]:                      0 ; 0x070: 0x00000000
kfffdb.spare[1]:                      0 ; 0x074: 0x00000000
kfffdb.spare[2]:                      0 ; 0x078: 0x00000000
kfffdb.spare[3]:                      0 ; 0x07c: 0x00000000
kfffdb.spare[4]:                      0 ; 0x080: 0x00000000
kfffdb.spare[5]:                      0 ; 0x084: 0x00000000
kfffdb.spare[6]:                      0 ; 0x088: 0x00000000
kfffdb.spare[7]:                      0 ; 0x08c: 0x00000000
kfffdb.spare[8]:                      0 ; 0x090: 0x00000000
kfffdb.spare[9]:                      0 ; 0x094: 0x00000000
kfffdb.spare[10]:                     0 ; 0x098: 0x00000000
kfffdb.spare[11]:                     0 ; 0x09c: 0x00000000
kfffdb.usm:                             ; 0x0a0: length=0
kfffde[0].xptr.au:                  963 ; 0x4a0: 0x000003c3

kfffdb.xtntblk:                      63 ; 0x03c: 0x003f  //63 extents described in this
kfffdb.break:                        60 ; 0x03e: 0x003c  // file directory block
kfffdb.alias[0]  ALIAS_INDEX

 

 

 

kfffdb.xtntblk=63 说明共有63个extent pointer指针，从kfffde[0].xptr.au到kfffde[59].xptr.au是60个直接盘区指针 direct extent pointer。

 

 

Indirectly addressed extents (kffixe structure)

 

kfffde[60].xptr.au指向剩下的文件目录信息， 这样查看。 kffixe 即是KFBTYP_INDIRECT 间接地址盘区Indirectly addressed extents块，与kfffde结构类似

 

 

[grid@localhost ~]$ kfed read /dev/asm-diski  aun=46 blkn=2|egrep "xptr.au|xptr.disk"

kfffde[60].xptr.au:                 978 ; 0x680: 0x000003d2
kfffde[60].xptr.disk:                 0 ; 0x684: 0x0000
kfffde[61].xptr.au:                 973 ; 0x688: 0x000003cd
kfffde[61].xptr.disk:                 3 ; 0x68c: 0x0003
kfffde[62].xptr.au:                 977 ; 0x690: 0x000003d1
kfffde[62].xptr.disk:                 1 ; 0x694: 0x0001

  1* select path,disk_number from v$asm_disk where group_number=3
SQL> /

PATH                 DISK_NUMBER
-------------------- -----------
/dev/asm-diskj                 3
/dev/asm-diski                 2
/dev/asm-diskh                 1
/dev/asm-diskg                 0

[grid@localhost ~]$ kfed read /dev/asm-diskg aun=978 blkn=0|less
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           12 ; 0x002: KFBTYP_INDIRECT
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:              2147483648 ; 0x004: blk=0 (indirect)
kfbh.block.obj:                     258 ; 0x008: file=258
kfbh.check:                  2166327859 ; 0x00c: 0x811f8a33
kfbh.fcn.base:                     2244 ; 0x010: 0x000008c4
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffixb.dxsn:                         20 ; 0x000: 0x00000014
kffixb.xtntblk:                     480 ; 0x004: 0x01e0
kffixb.dXrs:                         19 ; 0x006: SCHE=0x1 NUMB=0x3
kffixb.ub1spare:                      0 ; 0x007: 0x00
kffixb.ub4spare:                      0 ; 0x008: 0x00000000
kffixe[0].xptr.au:                  979 ; 0x00c: 0x000003d3
kffixe[0].xptr.disk:                  0 ; 0x010: 0x0000
kffixe[0].xptr.flags:                 0 ; 0x012: L=0 E=0 D=0 S=0
kffixe[0].xptr.chk:                 250 ; 0x013: 0xfa
kffixe[1].xptr.au:                  977 ; 0x014: 0x000003d1
kffixe[1].xptr.disk:                  2 ; 0x018: 0x0002
kffixe[1].xptr.flags:                 0 ; 0x01a: L=0 E=0 D=0 S=0
kffixe[1].xptr.chk:                 250 ; 0x01b: 0xfa
kffixe[2].xptr.au:                  974 ; 0x01c: 0x000003ce
kffixe[2].xptr.disk:                  3 ; 0x020: 0x0003

[grid@localhost ~]$ kfed read /dev/asm-diskj aun=973 blkn=0|less
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           12 ; 0x002: KFBTYP_INDIRECT
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:              2147483648 ; 0x004: blk=0 (indirect)
kfbh.block.obj:                     258 ; 0x008: file=258
kfbh.check:                  2166327859 ; 0x00c: 0x811f8a33
kfbh.fcn.base:                     2244 ; 0x010: 0x000008c4
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffixb.dxsn:                         20 ; 0x000: 0x00000014
kffixb.xtntblk:                     480 ; 0x004: 0x01e0
kffixb.dXrs:                         19 ; 0x006: SCHE=0x1 NUMB=0x3
kffixb.ub1spare:                      0 ; 0x007: 0x00
kffixb.ub4spare:                      0 ; 0x008: 0x00000000
kffixe[0].xptr.au:                  979 ; 0x00c: 0x000003d3
kffixe[0].xptr.disk:                  0 ; 0x010: 0x0000
kffixe[0].xptr.flags:                 0 ; 0x012: L=0 E=0 D=0 S=0
kffixe[0].xptr.chk:                 250 ; 0x013: 0xfa
kffixe[1].xptr.au:                  977 ; 0x014: 0x000003d1
kffixe[1].xptr.disk:                  2 ; 0x018: 0x0002
kffixe[1].xptr.flags:                 0 ; 0x01a: L=0 E=0 D=0 S=0
kffixe[1].xptr.chk:                 250 ; 0x01b: 0xfa
kffixe[2].xptr.au:                  974 ; 0x01c: 0x000003ce
kffixe[2].xptr.disk:                  3 ; 0x020: 0x0003
kffixe[2].xptr.flags:                 0 ; 0x022: L=0 E=0 D=0 S=0
kffixe[2].xptr.chk:                 228 ; 0x023: 0xe4
kffixe[3].xptr.au:                  978 ; 0x024: 0x000003d2
kffixe[3].xptr.disk:                  2 ; 0x028: 0x0002
kffixe[3].xptr.flags:                 0 ; 0x02a: L=0 E=0 D=0 S=0
kffixe[3].xptr.chk:                 249 ; 0x02b: 0xf9
kffixe[4].xptr.au:                  975 ; 0x02c: 0x000003cf
kffixe[4].xptr.disk:                  3 ; 0x030: 0x0003

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           12 ; 0x002: KFBTYP_INDIRECT
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:              2147483648 ; 0x004: blk=0 (indirect)
kfbh.block.obj:                     258 ; 0x008: file=258
kfbh.check:                  2166327859 ; 0x00c: 0x811f8a33
kfbh.fcn.base:                     2244 ; 0x010: 0x000008c4
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kffixb.dxsn:                         20 ; 0x000: 0x00000014
kffixb.xtntblk:                     480 ; 0x004: 0x01e0
kffixb.dXrs:                         19 ; 0x006: SCHE=0x1 NUMB=0x3
kffixb.ub1spare:                      0 ; 0x007: 0x00
kffixb.ub4spare:                      0 ; 0x008: 0x00000000
kffixe[0].xptr.au:                  979 ; 0x00c: 0x000003d3
kffixe[0].xptr.disk:                  0 ; 0x010: 0x0000
kffixe[0].xptr.flags:                 0 ; 0x012: L=0 E=0 D=0 S=0
kffixe[0].xptr.chk:                 250 ; 0x013: 0xfa
kffixe[1].xptr.au:                  977 ; 0x014: 0x000003d1
kffixe[1].xptr.disk:                  2 ; 0x018: 0x0002
kffixe[1].xptr.flags:                 0 ; 0x01a: L=0 E=0 D=0 S=0
kffixe[1].xptr.chk:                 250 ; 0x01b: 0xfa
kffixe[2].xptr.au:                  974 ; 0x01c: 0x000003ce
kffixe[2].xptr.disk:                  3 ; 0x020: 0x0003
kffixe[2].xptr.flags:                 0 ; 0x022: L=0 E=0 D=0 S=0
kffixe[2].xptr.chk:                 228 ; 0x023: 0xe4
kffixe[3].xptr.au:                  978 ; 0x024: 0x000003d2
kffixe[3].xptr.disk:                  2 ; 0x028: 0x0002
kffixe[3].xptr.flags:                 0 ; 0x02a: L=0 E=0 D=0 S=0
kffixe[3].xptr.chk:                 249 ; 0x02b: 0xf9
kffixe[4].xptr.au:                  975 ; 0x02c: 0x000003cf
kffixe[4].xptr.disk:                  3 ; 0x030: 0x0003

 

 

知识总结

 

  • asm disk的前50个AU(50MB)是为asm metadata保留的
  • ASM 的前255个file number是为metadata file保留的，文件号从1开始， file numner=1的1号文件为ASM的file directory
  • 普通的ASM File的file number从256开始
  • ASM disk的第二个AU即是file number=1的file directory (非必然)，在1MB AU和4096 bytes block的情况下可以存放255个file directory information，其block type为KFBTYP_FILEDIR
  • 普通ASM FILE的directory entry的位置，可以这样计算 File number=1的 第 (file number- 256)/256 +2  个extent，blkn=mod(file number-256),256) ，例如文件号 258  =》　第二个extent的blkn=2。
  • KFBTYP_FILEDIR中从kfffde[0].xptr.au到kfffde[59].xptr.au是直接盘区指针 directly extent pointers， kfffde[60].xptr.au以上是KFBTYP_INDIRECT(kffixe)间接盘区指针Indirectly extents pointers。

 

 Indirect Extents

 

由于FILE number 1 中可以存放的extent 指针是有限的，所以对于超过60个extent的文件使用Indirect Extents存放指针。如果需要使用indirect extents，则之后的extent map 记录都记录的是指向indirect extent的指针。

大多数文件仅仅需要一个Indirect Extent，除非文件确实很大。  只能有一级indirection extent，不会有多级。indirect extent中的指针只指向data extent ，不会再指向别的indirect extent 。

 

 

Filed Under: Oracle, Oracle ASM Tagged With: ,

【Oracle ASM】PST Partnership Status Table介绍

2014/12/14 by Leave a Comment

Partner and Status Table

相关：https://www.askmac.cn/archives/know-oracle-asm-basic-html.html

一般来说aun=1 是保留给Partner and Status Table(PST)的拷贝使用的。 一般5个ASM DISK将包含一份PST拷贝。多数的PST内容必须相同且验证有效。否则无法判断哪些ASM DISK实际拥有相关数据。

在 PST中每一条记录对应Diskgroup中的一个ASM DISK。每一条记录会对一个ASM disk枚举其partners的ASM DISK。同时会有一个flag来表示该DISK是否是ONLINE可读写的。这些信息对recovery是否能做很重要。

PST表的Blkn=0是PST的header，存放了如下的信息：

  • Timestamp to indicate PST is valid
  • Version number to compare with other PST copies
  • List of disks containing PST copies
  • Bit map for shadow paging updates

PST的最后一个块是heartbeat block，当diskgroup mount时其每3秒心跳更新一次。

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

以下为PST header

kfed read /oracleasm/asm-disk01 aun=1 blkn=0 aus=4194304 |less 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1024 ; 0x004: blk=1024
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                  3813974007 ; 0x00c: 0xe3549ff7
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHdrPairBv1.first.super.time.hi:32999670 ; 0x000: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdpHdrPairBv1.first.super.time.lo:1788841984 ; 0x004: USEC=0x0 MSEC=0x3e4 SECS=0x29 MINS=0x1a
kfdpHdrPairBv1.first.super.last:      2 ; 0x008: 0x00000002
kfdpHdrPairBv1.first.super.next:      2 ; 0x00c: 0x00000002
kfdpHdrPairBv1.first.super.copyCnt:   5 ; 0x010: 0x05
kfdpHdrPairBv1.first.super.version:   1 ; 0x011: 0x01
kfdpHdrPairBv1.first.super.ub2spare:  0 ; 0x012: 0x0000
kfdpHdrPairBv1.first.super.incarn:    1 ; 0x014: 0x00000001
kfdpHdrPairBv1.first.super.copy[0]:   0 ; 0x018: 0x0000
kfdpHdrPairBv1.first.super.copy[1]:   1 ; 0x01a: 0x0001
kfdpHdrPairBv1.first.super.copy[2]:   2 ; 0x01c: 0x0002
kfdpHdrPairBv1.first.super.copy[3]:   3 ; 0x01e: 0x0003
kfdpHdrPairBv1.first.super.copy[4]:   4 ; 0x020: 0x0004
kfdpHdrPairBv1.first.super.dtaSz:    15 ; 0x022: 0x000f
kfdpHdrPairBv1.first.asmCompat:186646528 ; 0x024: 0x0b200000
kfdpHdrPairBv1.first.newCopy[0]:      0 ; 0x028: 0x0000
kfdpHdrPairBv1.first.newCopy[1]:      0 ; 0x02a: 0x0000
kfdpHdrPairBv1.first.newCopy[2]:      0 ; 0x02c: 0x0000
kfdpHdrPairBv1.first.newCopy[3]:      0 ; 0x02e: 0x0000
kfdpHdrPairBv1.first.newCopy[4]:      0 ; 0x030: 0x0000
kfdpHdrPairBv1.first.newCopyCnt:      0 ; 0x032: 0x00
kfdpHdrPairBv1.first.contType:        1 ; 0x033: 0x01
kfdpHdrPairBv1.first.spares[0]:       0 ; 0x034: 0x00000000
kfdpHdrPairBv1.first.spares[1]:       0 ; 0x038: 0x00000000
kfdpHdrPairBv1.first.spares[2]:       0 ; 0x03c: 0x00000000
kfdpHdrPairBv1.first.spares[3]:       0 ; 0x040: 0x00000000
kfdpHdrPairBv1.first.spares[4]:       0 ; 0x044: 0x00000000
kfdpHdrPairBv1.first.spares[5]:       0 ; 0x048: 0x00000000
kfdpHdrPairBv1.first.spares[6]:       0 ; 0x04c: 0x00000000
kfdpHdrPairBv1.first.spares[7]:       0 ; 0x050: 0x00000000
kfdpHdrPairBv1.first.spares[8]:       0 ; 0x054: 0x00000000
kfdpHdrPairBv1.first.spares[9]:       0 ; 0x058: 0x00000000
kfdpHdrPairBv1.first.spares[10]:      0 ; 0x05c: 0x00000000
kfdpHdrPairBv1.first.spares[11]:      0 ; 0x060: 0x00000000
kfdpHdrPairBv1.first.spares[12]:      0 ; 0x064: 0x00000000
kfdpHdrPairBv1.first.spares[13]:      0 ; 0x068: 0x00000000
kfdpHdrPairBv1.first.spares[14]:      0 ; 0x06c: 0x00000000
kfdpHdrPairBv1.first.spares[15]:      0 ; 0x070: 0x00000000
kfdpHdrPairBv1.first.spares[16]:      0 ; 0x074: 0x00000000
kfdpHdrPairBv1.first.spares[17]:      0 ; 0x078: 0x00000000
kfdpHdrPairBv1.first.spares[18]:      0 ; 0x07c: 0x00000000
kfdpHdrPairBv1.first.spares[19]:      0 ; 0x080: 0x00000000
  • super.time wall clock time of last PST commit
  • super.last  last committed content version number
  • super.next next available content version number
  • super.copyCnt  # of disks holding PST copies
  • super.version   version of PST header format
  • super.ub2spare  pad to ub4 align
  • super.incarn incarnation of <copy> list
  • super.copy[0]  disks holding the PST copies
  • super.dtaSz  data entries in PST
  • newCopy[0]   new disks holding PST copies
  • newCopyCnt  new # disks holding PST copies

以下为PST table block:

kfed read /oracleasm/asm-disk02 aun=1 blkn=3 aus=4194304 |less 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1027 ; 0x004: blk=1027
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  4204644293 ; 0x00c: 0xfa9dc7c5
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpDtaEv1[0].status:               127 ; 0x000: I=1 V=1 V=1 P=1 P=1 A=1 D=1
kfdpDtaEv1[0].fgNum:                  1 ; 0x002: 0x0001
kfdpDtaEv1[0].addTs:         2022663849 ; 0x004: 0x788f66a9
kfdpDtaEv1[0].partner[0]:         49154 ; 0x008: P=1 P=1 PART=0x2
kfdpDtaEv1[0].partner[1]:         49153 ; 0x00a: P=1 P=1 PART=0x1
kfdpDtaEv1[0].partner[2]:         49155 ; 0x00c: P=1 P=1 PART=0x3
kfdpDtaEv1[0].partner[3]:         49166 ; 0x00e: P=1 P=1 PART=0xe
kfdpDtaEv1[0].partner[4]:         49165 ; 0x010: P=1 P=1 PART=0xd
kfdpDtaEv1[0].partner[5]:         49164 ; 0x012: P=1 P=1 PART=0xc
kfdpDtaEv1[0].partner[6]:         49156 ; 0x014: P=1 P=1 PART=0x4
kfdpDtaEv1[0].partner[7]:         49163 ; 0x016: P=1 P=1 PART=0xb
kfdpDtaEv1[0].partner[8]:         10000 ; 0x018: P=0 P=0 PART=0x2710
kfdpDtaEv1[0].partner[9]:             0 ; 0x01a: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[10]:            0 ; 0x01c: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[11]:            0 ; 0x01e: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[12]:            0 ; 0x020: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[13]:            0 ; 0x022: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[14]:            0 ; 0x024: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[15]:            0 ; 0x026: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[16]:            0 ; 0x028: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[17]:            0 ; 0x02a: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[18]:            0 ; 0x02c: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[19]:            0 ; 0x02e: P=0 P=0 PART=0x0
kfdpDtaEv1[1].status:               127 ; 0x030: I=1 V=1 V=1 P=1 P=1 A=1 D=1
kfdpDtaEv1[1].fgNum:                  2 ; 0x032: 0x0002
kfdpDtaEv1[1].addTs:         2022663849 ; 0x034: 0x788f66a9
kfdpDtaEv1[1].partner[0]:         49155 ; 0x038: P=1 P=1 PART=0x3
kfdpDtaEv1[1].partner[1]:         49152 ; 0x03a: P=1 P=1 PART=0x0
kfdpDtaEv1[1].partner[2]:         49154 ; 0x03c: P=1 P=1 PART=0x2
kfdpDtaEv1[1].partner[3]:         49166 ; 0x03e: P=1 P=1 PART=0xe
kfdpDtaEv1[1].partner[4]:         49157 ; 0x040: P=1 P=1 PART=0x5
kfdpDtaEv1[1].partner[5]:         49156 ; 0x042: P=1 P=1 PART=0x4
kfdpDtaEv1[1].partner[6]:         49165 ; 0x044: P=1 P=1 PART=0xd
kfdpDtaEv1[1].partner[7]:         49164 ; 0x046: P=1 P=1 PART=0xc
kfdpDtaEv1[1].partner[8]:         10000 ; 0x048: P=0 P=0 PART=0x2710
kfdpDtaEv1[1].partner[9]:             0 ; 0x04a: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[10]:            0 ; 0x04c: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[11]:            0 ; 0x04e: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[12]:            0 ; 0x050: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[13]:            0 ; 0x052: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[14]:            0 ; 0x054: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[15]:            0 ; 0x056: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[16]:            0 ; 0x058: P=0 P=0 PART=0x0
  • kfdpDtaEv1[0].status: 127 ; 0×000: I=1 V=1 V=1 P=1 P=1 A=1 D=1 disk status
  • fgNum   fail group number
  • addTs   timestamp of the addition to the diskgroup
  • kfdpDtaEv1[0].partner[0]:         49154 ; 0×008: P=1 P=1 PART=0×2  partner list

aun=1 的最后第二个block中备份了一份KFBTYP_DISKHEAD

[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1022 aus=4194304 |less  
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                    1022 ; 0x004: blk=1022
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  3107059260 ; 0x00c: 0xb931f63c
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        1 ; 0x024: 0x0001
kfdhdb.grptyp:                        3 ; 0x026: KFDGTP_HIGH
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:              DATA1_0001 ; 0x028: length=10
kfdhdb.grpname:                   DATA1 ; 0x048: length=5
kfdhdb.fgname:               DATA1_0001 ; 0x068: length=10
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32999670 ; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdhdb.crestmp.lo:           1788720128 ; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1a
kfdhdb.mntstmp.hi:             32999670 ; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdhdb.mntstmp.lo:           1812990976 ; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1b
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  4194304 ; 0x0bc: 0x00400000

AUN=1 的最后一个block为KFBTYP_HBEAT 心跳表：

[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1023 aus=4194304 |less  
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           19 ; 0x002: KFBTYP_HBEAT
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    2047 ; 0x004: blk=2047
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  1479766671 ; 0x00c: 0x5833728f
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHbeatB.instance:                  1 ; 0x000: 0x00000001
kfdpHbeatB.ts.hi:              32999734 ; 0x004: HOUR=0x16 DAYS=0x9 MNTH=0x2 YEAR=0x7de
kfdpHbeatB.ts.lo:            3968041984 ; 0x008: USEC=0x0 MSEC=0xe1 SECS=0x8 MINS=0x3b
kfdpHbeatB.rnd[0]:           1065296177 ; 0x00c: 0x3f7f2131
kfdpHbeatB.rnd[1]:            857037208 ; 0x010: 0x33155998
kfdpHbeatB.rnd[2]:           2779184235 ; 0x014: 0xa5a6fc6b
kfdpHbeatB.rnd[3]:           2660793989 ; 0x018: 0x9e987e85
  • kfdpHbeatB.instance   instance id
  • kfdpHbeatB.ts.hi timestamp
  • kfdpHbeatB.rnd[0]  随机加盐
  •  External Redundancy一般有一个PST
  • Normal Redundancy至多有个3个PST
  • High Redundancy 至多有5个PST

如下场景中PST 可能被重定位：

  • 存有PST的ASM DISK不可用了(当ASM启东时)
  • ASM DISK OFFLINE了
  • 当对PST的读写发生了I/O错误
  • disk被正常DROP了
  •  在读取其他ASM metadata之前会先检查PST
  • 当ASM实例被要求mount diskgroup时，GMON进程会读取diskgroup中所有磁盘去找到和确认PST拷贝
  • 如果他发现有足够的PST，那么会mount diskgroup
  • 之后，PST会被缓存在ASM缓存中，以及GMON的PGA中并使用排他的PT.n.0锁保护
  • 同集群中的其他ASM实例也将缓存PST到GMON的PGA，并使用共享PT.n.o锁保护
  • 仅仅那个持有排他锁的GMON能更新磁盘上的PST信息
  • 每一个ASM DISK上的AUN=1均为PST保留，但只有几个磁盘上真的有PST数据

 

kfbh.endian
kf3.h /*endiannessofwriter*/

Little endian = 1 Big endian = 0

kfbh.hard
kf3.h /*H.A.R.D.magic#andblocksize*/

kfbh.type
kf3.h /* metadata block type */

kfbh.datfmt
kf3.h /*metadatablockdataformat */

kfbh.block
kf3.h /*blocklocationofthisblock */

blk — Disk header should have T=0 and NUMB=0x0

obj — Disk header should have TYPE=0x8 NUMB=<disknumber> blkandobjvaluesarederivedfromaseriesofmacrosinkf3.h. See “KFBL Macros” in kf3.h for more information.

kfbh.check
kf3.h /*checkvaluetoverifyconsistency*/

kfbh.fcn
kf3.h /*changenumberoflastchange */

kfdpHdrB.time.hi
kf3.h HiorderedbitsfromthelastcommittedPSTupdate

kfdpHdrB.time.lo
kf3.h LoworderedbitsfromthelastcommittedPSTupdate

kfdpHdrB.last
kf3.h /* last version number */

kfdpHdrB.next
kf3.h /* next version number */

kfdpHdrB.copyCnt
kf3.h /* # of PST copies */

This defaults to “1” for external redundancy, “3” for normal redundancy and”5″forhighredundancy. Ifthenumberoffailuregroupsisless than the default value, the number failure groups is the value used.

kfdpHdrB.incarn
kf3.h /* incarnation of <copy> */

This is set to kfdpHdrB.last when the PST is moved to another disk.

kfdpHdrB.copy[0-4]
kf3.h /* disks holding the PST copies */

[0] — external redundancy [0-2] –normalredundancy [0-4] –highredundancy

kfdpHdrB.dtaSz
kf3.h /*#dtaentriesinPST */

This is the number of disks that it needs to keep track of. ub1[0-4027]

 

 

也可以参考ASM HANDS-ON TRAINING
Lab 6 Looking at The Partnership Status Metadata

 

Filed Under: Oracle, Oracle ASM

Oracle ASM保护工具ADHU

2014/09/27 by Leave a Comment

在11g中asm会在Disk Header的AU 1的最后第二个block中备份asm disk header。虽然在10.2中没有这个自动备份disk header的特性，但使用ADHU工具后该工具会以同样备份目的使用该block(ADHU补全了10.2.0.5之前没有disk header自动备份的功能)。ADHU工具同样可以将disk header的备份存放到本地文件系统中。已备份的Block可以通过adhu 工具的-repair选项来恢复出来。 以文件系统备份的block可以通过kfed工具来查看，也可以通过dd命令来恢复到磁盘上。

换句话说，对于10.2.0.5之前的asm 磁盘头常见的损坏/丢失情况，ADHU工具恰恰是一个有效的保护盾。

而对于10.2.0.5和11.1.0.7以后的asm,使用adhu也是一个不错的选择。

 

使用方法：

 

adhu [-dir dirname ] [-repair] [-quiet] [-readonly] [-syslog mask ] devname

 

默认情况下adhu将disk header备份为当前目录下的备份文件。 使用-dir选项可以指定存放的目录。

当需要使用adhu去修复一个损坏的asm disk header时使用-repair 选项。

-quiet 选项将过滤所有正常的输出信息，若执行成功则不打印任何输出。

-readonly选项 以只读方式来打开disk device，这样备份block将不被写入，而备份文件将在可能的情况下写入。

-syslog选项控制是否写出结果到系统日志和标准输出。

devname代表为asm disk的设备文件，asm头的备份文件将以该device name为基础，并存放在当前目录或者-dir指定的目录。

 

ADHU is  a utility to examine ASM disk headers, report status, create backups, and optionally restore them when the header is corrupt.

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

 

诗檀软件专业数据库修复团队

 

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

 

Filed Under: Oracle, Oracle ASM Tagged With: , ,

asm磁盘头丢失的N种情况 asm header损坏/丢失

2014/09/17 by Leave a Comment

asm磁盘头丢失的N种情况 asm header损坏/丢失：

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

BUG 14693394 – ORA-15196: INVALID ASM BLOCK HEADER [KFC.C:26076] [ENDIAN_KFBH]

 

BUG 14758001 – ORA-15196: INVALID ASM BLOCK HEADER [KFC.C:23924] [ENDIAN_KFBH] [2147483654]

 

BUG 14827224 – PS:WIN64:ORA-15196:INVALID ASM BLOCK HEADER[KFC.C:28261] ON DB CREATE ON VMS

BUG 14779268 – ASM DISK HEADER ERASED – NEED TO EXTRACT DATA

BUG 13772417 – LNX64-12.1-ASM:ORA-15196: INVALID ASM BLOCK HEADER [KFC.C:27615] [CHECK_KFBH]

 

Disk header copy

Lately there is an extra copy of the asm disk header. This copy can be used to fix the real header using kfed with the
repair option.

Location

This copy is stored as the last block of the PST. That means it is in the last block of allocation unit 1 (the original is
block 0 of au 0). The default sizes for an allocation unit is 1M and for the meta data block size is 4K, meaning 256
blocks in each au. So typically the copy is in au 1 block 254. (ASM counts from zero, the original is in allocation unit 0
block 0)

kfed repair
Provided you established that the only problem is with the lost/corrupt disk header, the fix is as simple as:
$ kfed repair <disk name>
If the AU size is non-standard, the above will fail with something like:
KFED-00320: Invalid block num1 = [3], num2 = [1], error = [type_kfbh]
But that is expected and no harm is done. All you need to do is specify the correct AU size. E.g. for 4MB AU the
command would be:
$ kfed repair <disk name> ausz=4194304

 

 

Filed Under: Oracle, Oracle ASM

PRM-DUL成功案例：成功为某券商机构从受损的ASM Diskgroup中恢复出数据文件和归档日志

2014/09/15 by 1 Comment

PRM-DUL又一个成功案例，成功为某券商机构从受损的ASM Diskgroup中恢复出数百个GB的数据文件和归档日志：

 

 

 

 

Filed Under: Oracle, Oracle ASM

沪ICP备14014813号-2

沪公网安备 31010802001379号