【转】ASM Disk Directory

2

The ASM file number 2 – the ASM disk directory – keeps track of all disks in the disk group. As disk groups are independent storage units, each disk group will have its own ASM disk directory.

 

As far as the ASM is concerned, the disk directory is just another file. It has its own entry in the ASM file directory, it is mirrored, as per the disk group redundancy policy, and it grows as needed.

 

Each disk directory entry maintains the following information:

  • Disk number
  • Disk state
  • ASM disk name (this can differ from the disk OS name)
  • Failgroup name
  • Create time-stamp
  • Failure time-stamp
  • Failure timer
  • Resize target
  • Relative location in the staleness registry
  • Disk repair time
  • Zone information

 

V$ASM_DISK view

 

Most of the information maintained in the disk directory can be accessed via the V$ASM_DISK view. The view displays one row for every disk discovered, including the disks which are not part of any disk group. The ASM performs disk discovery every time this view is queried, so those queries are expensive.

 

The following example shows the query output from the V$ASM_DISK in an ASM instance:

 

SQL> SELECT group_number, disk_number, state, name, mount_status

FROM v$asm_disk;

 

GROUP_NUMBER DISK_NUMBER STATE    NAME         MOUNT_S

———— ———– ——– ———— ——-

0           0 NORMAL                CLOSED

0           1 NORMAL                CLOSED

0           2 NORMAL                CLOSED

0           6 NORMAL                CLOSED

1           0 NORMAL   ASMDISK1     CACHED

1           1 NORMAL   ASMDISK2     CACHED

1           2 NORMAL   ASMDISK3     CACHED

1           3 NORMAL   ASMDISK4     CACHED

2           0 NORMAL   ASMDISK5     CACHED

2           1 NORMAL   ASMDISK6     CACHED

 

10 rows selected.

 

SQL>

 

Note that we see all disks available to the ASM, including those that do not belong to a mounted disk group (GROUP_NUMBER=0).

 

V$ASM_DISK_STAT view

 

The V$ASM_DISK_STAT displays the same information as the V$ASM_DISK does, but without performing discovery of new disks. The information comes from the SGA of the ASM instance. This results in a less expensive operation, but since discovery is not performed, the query result does not include the information about disks that are new to the system.

 

The following example shows the query output from the V$ASM_DISK_STAT in an ASM instance:

 

SQL> SELECT group_number, disk_number, state, name, mount_status

FROM v$asm_disk_stat;

 

GROUP_NUMBER DISK_NUMBER STATE    NAME         MOUNT_S

———— ———– ——– ———— ——-

1           0 NORMAL   ASMDISK1     CACHED

1           1 NORMAL   ASMDISK2     CACHED

1           2 NORMAL   ASMDISK3     CACHED

1           3 NORMAL   ASMDISK4     CACHED

2           0 NORMAL   ASMDISK5     CACHED

2           1 NORMAL   ASMDISK6     CACHED

 

6 rows selected.

 

SQL>

 

This time, we only see disks for the mounted disk groups.

 

Locating the disk directory

 

We can query the fixed table X$KFFXP in the ASM instance, to find out which allocation units belong to the ASM file number 2. I will also join the V$ASM_DISK_STAT to get the disk names. Let’s do that for disk group 1:

 

SQL> SELECT x.xnum_kffxp “Extent”,

x.au_kffxp “AU”,

x.disk_kffxp “Disk #”,

d.name “Disk name”

FROM x$kffxp x, v$asm_disk_stat d

WHERE x.group_kffxp=d.group_number

and x.disk_kffxp=d.disk_number

and x.group_kffxp=1

and x.number_kffxp=2

ORDER BY 1, 2;

 

Extent         AU     Disk # Disk name

——— ———- ———- ———

0          2          3 ASMDISK4

0          3          0 ASMDISK1

0          3          1 ASMDISK2

 

SQL>

 

The result shows two things – that the ASM file directory is triple mirrored, and that the current size of the file directory is 3 physical extents (which in this case equals to 3 allocation units). It is worth pointing out that even in a normal redundancy disk group, the ASM disk directory is triple mirrored.

 

Let’s now use the kfed to look at the disk directory entries for disk group 1. As the data is the same in all three allocation units, we can look at the first one, i.e. the allocation unit 2 on disk ASMDISK4:

 

$ kfed read /dev/oracleasm/disks/ASMDISK4 aun=2 | more

kfbh.endian:                          1 ; 0x000: 0x01

kfbh.hard:                          130 ; 0x001: 0x82

kfbh.type:                            6 ; 0x002: KFBTYP_DISKDIR

kfddde[0].entry.incarn:               1 ; 0x024: A=1 NUMM=0x0

kfddde[0].entry.hash:                 0 ; 0x028: 0x00000000

kfddde[0].entry.refer.number:4294967295 ; 0x02c: 0xffffffff

kfddde[0].entry.refer.incarn:         0 ; 0x030: A=0 NUMM=0x0

kfddde[0].dsknum:                     0 ; 0x034: 0x0000

kfddde[0].state:                      2 ; 0x036: KFDSTA_NORMAL

kfddde[0].ddchgfl:                  132 ; 0x037: 0x84

kfddde[0].dskname:             ASMDISK1 ; 0x038: length=8

kfddde[0].fgname:              ASMDISK1 ; 0x058: length=8

kfddde[0].crestmp.hi:          32960657 ; 0x078: HOUR=0x11 DAYS=0x4 MNTH=0xc YEAR=0x7db

kfddde[0].crestmp.lo:        2843202560 ; 0x07c: USEC=0x0 MSEC=0x1f5 SECS=0x17 MINS=0x2a

kfddde[0].failstmp.hi:                0 ; 0x080: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0

kfddde[0].failstmp.lo:                0 ; 0x084: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0

kfddde[0].timer:                      0 ; 0x088: 0x00000000

kfddde[0].size:                    4094 ; 0x08c: 0x00000ffe

kfddde[0].srRloc.super.hiStart:       0 ; 0x090: 0x00000000

kfddde[0].srRloc.super.loStart:       0 ; 0x094: 0x00000000

kfddde[0].srRloc.super.length:        0 ; 0x098: 0x00000000

kfddde[0].srRloc.incarn:              0 ; 0x09c: 0x00000000

kfddde[0].dskrprtm:                   0 ; 0x0a0: 0x00000000

kfddde[0].zones[0].start:             0 ; 0x0a4: 0x00000000

kfddde[0].zones[0].size:           4094 ; 0x0a8: 0x00000ffe

kfddde[0].zones[0].used:             47 ; 0x0ac: 0x0000002f

kfddde[1].entry.incarn:               1 ; 0x1e4: A=1 NUMM=0x0

kfddde[1].entry.hash:                 1 ; 0x1e8: 0x00000001

kfddde[1].entry.refer.number:4294967295 ; 0x1ec: 0xffffffff

kfddde[1].entry.refer.incarn:         0 ; 0x1f0: A=0 NUMM=0x0

kfddde[1].dsknum:                     1 ; 0x1f4: 0x0001

kfddde[1].state:                      2 ; 0x1f6: KFDSTA_NORMAL

kfddde[1].ddchgfl:                  132 ; 0x1f7: 0x84

kfddde[1].dskname:             ASMDISK2 ; 0x1f8: length=8

kfddde[2].entry.incarn:               1 ; 0x3a4: A=1 NUMM=0x0

kfddde[2].entry.hash:                 2 ; 0x3a8: 0x00000002

kfddde[2].entry.refer.number:4294967295 ; 0x3ac: 0xffffffff

kfddde[2].entry.refer.incarn:         0 ; 0x3b0: A=0 NUMM=0x0

kfddde[2].dsknum:                     2 ; 0x3b4: 0x0002

kfddde[2].state:                      2 ; 0x3b6: KFDSTA_NORMAL

kfddde[2].ddchgfl:                  132 ; 0x3b7: 0x84

kfddde[2].dskname:             ASMDISK3 ; 0x3b8: length=8

$

 

The disk information is in the kfddde fields, where kfddde[0] is about disk 0, kfddde[1] is about disk 1, and so on. This way we can access all information about all disks for this disk group. As it can be seen, most of the information is externalized via the V$ASM_DISK views.

 

Conclusion

 

The ASM disk directory maintains the information about the disks in the ASM disk groups. That information is externalized via V$ASM_DISK views and can also be accessed via the kfed utility.

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号