ASM disk group mount fails with ORA-15036: disk is truncated [ID 1077175.1]

最新推荐文章于 2025-11-29 18:01:51 发布

最新推荐文章于 2025-11-29 18:01:51 发布 · 223 阅读

文章标签：

#数据库

本文介绍了解决Oracle ASM磁盘组挂载失败时出现ORA-15036磁盘被截断错误的方法。通过使用kfed工具校验并修正磁盘大小信息，然后调整ASM层面的磁盘大小设置。

部署运行你感兴趣的模型镜像

ASM disk group mount fails with ORA-15036: disk is truncated [ID 1077175.1]

--------------------------------------------------------------------------------

修改时间 05-OCT-2011 类型 PROBLEM 状态 PUBLISHED

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

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

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
...

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

$ kfed read /dev/oracleasm/disks/DATA10 | egrep "dskname|dsksize"

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
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

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

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;
3.3. Dismount and mount the disk group to verify that it mounts with no errors.

References