ORA-15036: disk '/oracle/devices/asm_data_002' is truncated ora error message

Admin — Wed, 20 May 2009 15:19:20 GMT

I was getting the following ora error and I couldn't drop the diskgroup. It was so frustrating cuz i couldn't figure out why.

Go through this post throughly to see the fix for it. Also, make sure if you have data on that disk to BE CAREFUL!!! If you want to loose the data then only follow these steps. In my case, it was brand new install so I really didn't care as long as my ASM instance was able to see the disk correctly.

SQL> alter diskgroup SHARED_DATA_DG01 mount;
alter diskgroup SHARED_DATA_DG01 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15036: disk '/oracle/devices/asm_data_002' is truncated

I queried the ASM instance and found something weird. Look ath the second diskgroup. Everything is 0 and File Size has nothing.

SQL> SELECT name, type, total_mb, free_mb, required_mirror_free_mb,usable_file_mb FROM V$ASM_DISKGROUP;

NAME TYPE File Size (MB) FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
------------------------------ ------ -------------- ---------- ----------------------- --------------
SHARED_AUXFILES_DG01 EXTERN 714,752 714696 0 714696
SHARED_DATA_DG01 0 0 0 0
SHARED_FRA_DG01 EXTERN 28,672 28622 0 28622
--------------
Grand Total: 743,424

So then this baffled me and I went to look at the disks by issuing the following commands.

SQL> set linesize 200

SQL> col path format a65

SQL> SELECT name, header_status, path FROM V$ASM_DISK;

NAME HEADER_STATU PATH
------------------------------ ------------ ----------------------------------------
MEMBER /oracle/devices/asm_data_002
CANDIDATE /oracle/devices/asm_data_003
SHARED_AUXFILES_DG01_0000 MEMBER /oracle/devices/asm_data_001
SHARED_FRA_DG01_0000 MEMBER /oracle/devices/asm_fra_001

This was even more weird now because my diskgroup doesn't show up and one of the disk now shows that it's a member of no diskgroup name. This is totally weird. Then I went onto metalink and i saw an article on there. DOC ID: 553319.1 There is a command that they have which you can use to verify the disk size and compare it to what should be on the OS size. The command is kfed. ( like briney's ex ) :) If you don't have kfed, you can compile it as below:

# which kfed

# no kfed in

/bin /oracle/dba/local /usr/local/bin /usr/bin /usr/ccs/bin /usr/ucb /etc /usr/sbin /sbin /usr/dt/bin /usr/lpp/X11/bin /opt/bin /usr/lbin /usr/bin/X11

To make kfed do following:

# cd $ORACLE_HOME/rdbms/lib

# make -f ins_rdbms.mk ikfed

After running the make command, you can issue the following against the disk with issues:

# kfed read /dev/vx/rdsk/asm_dg/asm_dg_002

kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 563600374 ; 0x00c: 0x2197dbf6
kfbh.fcn.base: 6603 ; 0x010: 0x000019cb
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: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: SHARED_DATA_DG01_0000 ; 0x028: length=21
kfdhdb.grpname: SHARED_DATA_DG01 ; 0x048: length=16
kfdhdb.fgname: SHARED_DATA_DG01_0000 ; 0x068: length=21
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32909522 ; 0x0a8: HOUR=0x12 DAYS=0x6 MNTH=0xa YEAR=0x7d8
kfdhdb.crestmp.lo: 2203590656 ; 0x0ac: USEC=0x0 MSEC=0x208 SECS=0x35 MINS=0x20
kfdhdb.mntstmp.hi: 32917794 ; 0x0b0: HOUR=0x2 DAYS=0x9 MNTH=0x2 YEAR=0x7d9
kfdhdb.mntstmp.lo: 1437176832 ; 0x0b4: USEC=0x0 MSEC=0x265 SECS=0x1a MINS=0x15
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 512000 ; 0x0c4: 0x0007d000
kfdhdb.pmcnt: 6 ; 0x0c8: 0x00000006
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 65535 ; 0x0da: 0xffff
kfdhdb.redomirrors[2]: 65535 ; 0x0dc: 0xffff
kfdhdb.redomirrors[3]: 65535 ; 0x0de: 0xffff
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32909522 ; 0x0e4: HOUR=0x12 DAYS=0x6 MNTH=0xa YEAR=0x7d8
kfdhdb.grpstmp.lo: 2203507712 ; 0x0e8: USEC=0x0 MSEC=0x1b7 SECS=0x35 MINS=0x20
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000

Take the two numbers in red above and multiply it: 1048576 x 512000 = 53,687,0912,000. This should be the size of your disk. This is how oracle recognizes it. Remember, don't use this command unless you absolutely exhausted all other options. Talk to oracle because they say that this command might damage your disks. :) Careful.

Anyhow, for me it matched fine. So i saw another article and tought to give it a try. It was asking me to write to the diskgroup by cleaning it up using this command:

dd if=/dev/zero of=/dev/vx/rdsk/asm_dg/asm_dg_002 bs=1024k count=100

100+0 records in
100+0 records out

That one solved my problem. If you still have issues, i suggest you now contact your SA and have them reformat your disks and fix it on their end.

SQL>
SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance started

Total System Global Area 700448768 bytes
Fixed Size 2032736 bytes
Variable Size 673250208 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown

Good luck. Hope this helped you out.

Do reply and let me know if this helped you out.

=====================================================================

ORACLE'S CODE:

ORA-15036: disk "string" is truncated

Cause: The size of the disk, as reported by the operating system, was smaller than

the size of the disk as recorded in the disk header block on the disk.

Action: Check if the system configuration has changed.

Thanks,

FranklinFaces.com - Oracle & SQL Server Database Forums for all IT Professionals / Oracle Forum / ORA - Oracle Database Error Codes - Search via specific error codes. / ORA-10560 Through ORA-19999 / ORA-15036: disk '/oracle/devices/asm_data_002' is truncated ora error message / Latest Posts

ORA-15036: disk '/oracle/devices/asm_data_002' is truncated ora error message