[ID 1077175.1]
Information in this document applies to any platform.
NOTE: kfed is an Oracle internal utility and should not be used unless advised by Oracle Support. Interpreting kfed output is outside of the scope of this article.
Attempt to mount ASM disk group (DG1) fails with the following errors:
Resized the disks at the OS level.
ASM administrator/DBA created ASMLIB disks DATA09 and DATA10 with those LUNs and added the disks to disk group DG1.
As the disks were incorrectly sized, the system/storage admin resized the disks to the intended size - 61530 MB. But they did not advise ASM administrator/DBA about this change, so noALTER DISKGROUP RESIZE DISK was performed at the ASM level.
Next time the disk group mount was attempted, the above errors were received and the disk group could not be mounted.
1.1. The affected disks (ORCL:DATA09 and ORCL:DATA10) are ASMLIB disks:
1.2. Check the ASM disk headers
That shows the ASM disk header looks fine. Do the same for disk DATA10...
1.3. Check the disk size in the ASM disk header:
That shows that both disk headers have the disk size as 65530 MB.
1.4. Check the disk size of the associated LUNs (sd devices):
Note the major and minor device numbers above.
1.5. Get the disk size at the OS level:
Above shows that both disk partitions (/dev/sdk1 and /dev/sdl1) are 61530 MB.
2. Using kfed utility correct the disk size info by updating the ASM disk headers for disks DATA09 and DATA10.
2.1. Read the ASM disk header and save the output into a file:
2.2. Using a text editor (e.g. vi) edit file /tmp/DATA09_header.kfed, to modify the following line:
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
to
kfdhdb.dsksize: 61530 ; 0x0c4: 0x0000f05a
Save the changes.
Repeat for disk DATA10:
Modify:
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
to
kfdhdb.dsksize: 61530 ; 0x0c4: 0x0000f05a
2.3. Update the ASM disk headers:
3. Mount the disk group and update the disk size info at the ASM level
3.1. Log into ASM instance with the correct privileges
3.2. Resize the disks
3.3. Dismount and mount the disk group to verify that it mounts with no errors.
In this Document
Symptoms
Changes
Cause
Solution
References
Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.2.0.1 [Release: 10.2 to 11.2]Information in this document applies to any platform.
NOTE: kfed is an Oracle internal utility and should not be used unless advised by Oracle Support. Interpreting kfed output is outside of the scope of this article.
Symptoms
This problem can be seen in a both single instance and RAC and in any ASM version.Attempt to mount ASM disk group (DG1) fails with the following errors:
ORA-15032: not all alterations performed
ORA-15036: disk 'ORCL:DATA10' is truncated
ORA-15036: disk 'ORCL:DATA09' is truncated
ORA-15036: disk 'ORCL:DATA10' is truncated
ORA-15036: disk 'ORCL:DATA09' is truncated
Changes
Added two disks, ORCL:DATA09 and ORCL:DATA10 to ASM disk group DG1.Resized the disks at the OS level.
Cause
System/storage administrator presented two new LUNs, 65530 MB each, to the OS to be used by ASM.ASM administrator/DBA created ASMLIB disks DATA09 and DATA10 with those LUNs and added the disks to disk group DG1.
As the disks were incorrectly sized, the system/storage admin resized the disks to the intended size - 61530 MB. But they did not advise ASM administrator/DBA about this change, so noALTER DISKGROUP RESIZE DISK was performed at the ASM level.
Next time the disk group mount was attempted, the above errors were received and the disk group could not be mounted.
Solution
1. Verify that the issue is just with the disk size mismatch between ASM metadata and the actual disk size. To do that, make use of ASM utility kfed and OS utility fdisk.1.1. The affected disks (ORCL:DATA09 and ORCL:DATA10) are ASMLIB disks:
$ ls -l /dev/oracleasm/disks
brw-rw---- 1 oracle dba 8, 2 Mar 14 11:25 DATA01
...
brw-rw---- 1 oracle dba 8, 161 Mar 14 11:25 DATA09
brw-rw---- 1 oracle dba 8, 177 Mar 14 11:25 DATA10
brw-rw---- 1 oracle dba 8, 2 Mar 14 11:25 DATA01
...
brw-rw---- 1 oracle dba 8, 161 Mar 14 11:25 DATA09
brw-rw---- 1 oracle dba 8, 177 Mar 14 11:25 DATA10
1.2. Check the ASM disk headers
$ kfed read /dev/oracleasm/disks/DATA09
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.driver.provstr: ORCLDISKDATA09 ; 0x000: length=14
kfdhdb.dsknum: 4 ; 0x024: 0x0004
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATA09 ; 0x028: length=6
kfdhdb.grpname: DG1 ; 0x048: length=3
kfdhdb.fgname: DATA09 ; 0x068: length=6
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32934511 ; 0x0a8: HOUR=0xf DAYS=0x13 MNTH=0x2 YEAR=0x7da
kfdhdb.crestmp.lo: 1158806528 ; 0x0ac: USEC=0x0 MSEC=0x7f SECS=0x11 MINS=0x11
kfdhdb.mntstmp.hi: 32934511 ; 0x0b0: HOUR=0xf DAYS=0x13 MNTH=0x2 YEAR=0x7da
kfdhdb.mntstmp.lo: 1158852608 ; 0x0b4: USEC=0x0 MSEC=0xac SECS=0x11 MINS=0x11
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
...
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfdhdb.driver.provstr: ORCLDISKDATA09 ; 0x000: length=14
kfdhdb.dsknum: 4 ; 0x024: 0x0004
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATA09 ; 0x028: length=6
kfdhdb.grpname: DG1 ; 0x048: length=3
kfdhdb.fgname: DATA09 ; 0x068: length=6
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32934511 ; 0x0a8: HOUR=0xf DAYS=0x13 MNTH=0x2 YEAR=0x7da
kfdhdb.crestmp.lo: 1158806528 ; 0x0ac: USEC=0x0 MSEC=0x7f SECS=0x11 MINS=0x11
kfdhdb.mntstmp.hi: 32934511 ; 0x0b0: HOUR=0xf DAYS=0x13 MNTH=0x2 YEAR=0x7da
kfdhdb.mntstmp.lo: 1158852608 ; 0x0b4: USEC=0x0 MSEC=0xac SECS=0x11 MINS=0x11
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
...
That shows the ASM disk header looks fine. Do the same for disk DATA10...
1.3. Check the disk size in the ASM disk header:
$ kfed read /dev/oracleasm/disks/DATA09 | egrep "dskname|dsksize"
kfdhdb.dskname: DATA09 ; 0x028: length=6
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
kfdhdb.dskname: DATA09 ; 0x028: length=6
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
$ kfed read /dev/oracleasm/disks/DATA10 | egrep "dskname|dsksize"
kfdhdb.dskname: DATA10 ; 0x028: length=6
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
kfdhdb.dskname: DATA10 ; 0x028: length=6
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
That shows that both disk headers have the disk size as 65530 MB.
1.4. Check the disk size of the associated LUNs (sd devices):
# ls -l /dev/sd* | egrep "8, 161|8, 177"
brw-rw---- 1 root disk 8, 161 Mar 14 11:25 sdk1
brw-rw---- 1 root disk 8, 177 Mar 14 11:25 sdl1
brw-rw---- 1 root disk 8, 161 Mar 14 11:25 sdk1
brw-rw---- 1 root disk 8, 177 Mar 14 11:25 sdl1
Note the major and minor device numbers above.
1.5. Get the disk size at the OS level:
# fdisk -l /dev/sdk
Disk /dev/sdk: 68.7 GB, 68719476736 bytes
255 heads, 63 sectors/track, 8354 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdk1 1 7844 63006898+ 83 Linux
# fdisk -l /dev/sdl
Disk /dev/sdl: 68.7 GB, 68719476736 bytes
255 heads, 63 sectors/track, 8354 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdl1 1 7844 63006898+ 83 Linux
Disk /dev/sdk: 68.7 GB, 68719476736 bytes
255 heads, 63 sectors/track, 8354 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdk1 1 7844 63006898+ 83 Linux
# fdisk -l /dev/sdl
Disk /dev/sdl: 68.7 GB, 68719476736 bytes
255 heads, 63 sectors/track, 8354 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdl1 1 7844 63006898+ 83 Linux
Above shows that both disk partitions (/dev/sdk1 and /dev/sdl1) are 61530 MB.
2. Using kfed utility correct the disk size info by updating the ASM disk headers for disks DATA09 and DATA10.
2.1. Read the ASM disk header and save the output into a file:
$ kfed read /dev/oracleasm/disks/DATA09 > /tmp/DATA09_header.kfed
2.2. Using a text editor (e.g. vi) edit file /tmp/DATA09_header.kfed, to modify the following line:
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
to
kfdhdb.dsksize: 61530 ; 0x0c4: 0x0000f05a
Save the changes.
Repeat for disk DATA10:
$ kfed read /dev/oracleasm/disks/DATA09 > /tmp/DATA10_header.kfed
Modify:
kfdhdb.dsksize: 65530 ; 0x0c4: 0x0000fffa
to
kfdhdb.dsksize: 61530 ; 0x0c4: 0x0000f05a
2.3. Update the ASM disk headers:
$ kfed merge /dev/oracleasm/disks/DATA09 text=/tmp/DATA09_header.kfed
$ kfed merge /dev/oracleasm/disks/DATA10 text=/tmp/DATA10_header.kfed
$ kfed merge /dev/oracleasm/disks/DATA10 text=/tmp/DATA10_header.kfed
3. Mount the disk group and update the disk size info at the ASM level
3.1. Log into ASM instance with the correct privileges
$ sqlplus / as sysdba (or 'sqlplus / as sysasm' in ASM version 11.1 and above)
3.2. Resize the disks
SQL> alter diskgroup DG1 resize disk DATA09 size 61530 M;
SQL> alter diskgroup DG1 resize disk DATA10 size 61530 M;
SQL> alter diskgroup DG1 resize disk DATA10 size 61530 M;
3.3. Dismount and mount the disk group to verify that it mounts with no errors.
References
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/38267/viewspace-715754/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/38267/viewspace-715754/