Partitions in oracle cannot be identified, leading to the failure to mount asm diskgroup. Solution

Some customers consulted because of the host restart, resulting in four disk groups in data2 disk can not mount (reporting ORA-15032, ORA-15017, ORA-15063), the database can not open, let us help Analysis Solution
Wed Mar 09 18:10:53 2016
NOTE: Assigning number (1, 1) to disk (/dev/oracleasm/disks/VOL011)
Wed Mar 09 18:10:53 2016
ERROR: no read quorum in group: required 1, found 0 disks
NOTE: cache dismounting (clean) group 1/0xBD42B778 (DATA2)
NOTE: messaging CKPT to quiesce pins Unix process pid: 45093, image: oracle @ BA (TNS V1-V3)
NOTE: dbwr not being msg 'd to dismount
NOTE: lgwr not being msg 'd to dismount
NOTE: cache dismounted group 1/0xBD42B778 (DATA2)
NOTE: cache ending mount (fail) of group DATA2 number = 1 incarn = 0xbd42b778
NOTE: cache deleting context for group DATA2 1/0xbd42b778
GMON dismounting group 1 at 16 for pid 18, object ID 45093
NOTE: Disk DATA2_0001 in mode 0x9 marked for de-assignment
ERROR: diskgroup DATA2 was not mounted
ORA-15032: not all alterations saved Med
ORA-15017: diskgroup "DATA2" cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup & quot; DATA2 & quot"
ERROR: alter diskgroup DATA2 MOUNT/* asm agent * // * {0: 431 }*/
The lack of asm disk makes data2 unable to mount normally. Further analysis shows that data2 is composed of two disks.
Mon Sep 14 13:14:35 2015
SQL> create diskgroup data2 external redundancy disk '/dev/oracleasm/disks/VOL010', '/dev/oracleasm/disks/VOL011'
NOTE: Assigning number (4, 0) to disk (/dev/oracleasm/disks/VOL010)
NOTE: Assigning number (4, 1) to disk (/dev/oracleasm/disks/VOL011)
NOTE: initializing header on grp 4 disk DATA2_0000
NOTE: initializing header on grp 4 disk DATA2_0001
NOTE: initiating PST update: grp = 4
Mon Sep 14 13:14:35 2015
GMON updating group 4 at 29for pid 26, osid 51535
NOTE: group DATA2: initial PST location: disk 0000 (PST copy 0)
NOTE: PST update grp = 4 completed successfully
NOTE: cache registered group DATA2 number = 4 incarn = 0xea085f62
NOTE: cache began mount (first) of group DATA2 number = 4 incarn = 0xea085f62
NOTE: cache opening disk 0 of grp 4: DATA2_0000 path:/dev/oracleasm/disks/VOL010
NOTE: cache opening disk 1 of grp 4: DATA2_0001 path:/dev/oracleasm/disks/VOL011
NOTE: cache creating group 4/0xEA085F62 (DATA2)
NOTE: cache mounting group 4/0xEA085F62 (DATA2) succeeded
NOTE: allocating F1X0 on grp 4 disk DATA2_0000
NOTE: diskgroup must now be re-mounted prior to first use
NOTE: cache dismounting (clean) group 4/0xEA085F62 (DATA2)
NOTE: messaging CKPT to quiesce pins Unix process pid: 51535, image: oracle @ BA (TNS V1-V3)
NOTE: lgwr not being msg 'd to dismount
NOTE: cache dismounted group 4/0xEA085F62 (DATA2)
GMON dismounting group 4 at 30 for pid 26, object ID 51535
GMON dismounting group 4 at 31 for pid 26, object ID 51535
NOTE: Disk DATA2_0000 in mode 0x7e marked for de-assignment
NOTE: Disk DATA2_0001 in mode 0x7e marked for de-assignment
SUCCESS: diskgroup DATA2 was created
Based on this information, we can determine that the data2 disk group is composed of two disk groups, VOL010 and VOL011, respectively. Since only VOL011 is found, the data2 disk group cannot be mounted normally. it is observed that the system uses asmlib and uses the oracleasm querydisk command in combination with the fdisk drive letter,
Oracleasm-querydisk
Basically, it can be determined that the loss of VOL010 should be on the mpathb disk (because only the disk and partition are not used, all other disks and partitions have been used as asmdisks by the asmlib currently available).
Disk/dev/mapper/mpathb: 3846.7 GB, 3846677987328 bytes
255 heads, 63 sectors/track, 467665 cylinders
Units = cylinders of 16065*512 = 8225280 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes
Disk identifier: 0x00000000
 
Device Boot Start End Blocks Id System
/Dev/mapper/mpathbp1 1 267350 2147483647 + ee GPT
 
Disk/dev/mapper/mpathbp1: 3846.7 GB, 3846675890176 bytes
255 heads, 63 sectors/track, 467665 cylinders
Units = cylinders of 16065*512 = 8225280 bytes
Sector size (logical/physical): 512 bytes/512 bytes
I/O size (minimum/optimal): 512 bytes/512 bytes
Disk identifier: 0xb84bb99a
 
Device Boot Start End Blocks Id System
/Dev/mapper/mpathbp1p1 1 200513 1610620641 83 Linux
/Dev/mapper/mpathbp1p2 200514 267349 536860170 83 Linux
/Dev/mapper/mpathbp1p3 267350 467665 1609038270 83 Linux
Here we found a strange phenomenon: the mpathb disk uses parted to be divided into one mapthbp1 partition, and then fdisk to divide three p1p1, p1p2, and p1p3 subpartitions. then we can view the device information in/dev/mapper/.

We found that the three subpartitions p1p1, p1p2, and p1p3 should belong to mapthb. now it is basically clear that mapthb uses the parted partition first and then fdisk partition. After the operating system is restarted, the related sub-partitions cannot be identified. there are three ways to solve this problem.
1. Because the disk partition table information is normal, that is, the partition table information is not synchronized to the operating system. You can find a way to synchronize the information in the past. The OS content is ignored here.
2. the two asm disks of data2 are directly reorganized by means of data file reorganization. Here, we can directly scan the mapthbp1 partition because the three subpartitions are not found. For details, refer to: asm disk header completely damaged and restored.
3. the partition mainly sets the offset and size of the disk for the asm disk. If the offset of the disk is found, determine the size of the asm disk, directly run the dd command to add this part to the new disk device, and then mount the disk group directly. Here, we will focus on the third method for recovery.
Use dd to find out the disk header of mapthp1, and then use bbed to find out the offset, mainly based on the first part that displays 01820101 information.
BBED> d
File: bp1 (0)
Block: 64 Offsets: 0 to 63 Dba: 0x00000000
------------------------------------------------------------------------
01820101 00000000 00000080 bc60223c 00000000 00000000 00000000
4f52434c 4449534b 564f4c30 31300000 00000000 00000000 00000000
 
<32 bytes per line>
 
BBED> show all
FILE #0
BLOCK #64
OFFSET 0
DBA 0x00000000 (0 0, 64)
FILENAME bp1
BIFILE bifile. bbd
LISTFILE
Blocsize 512
MODE Browse
EDIT Unrecoverable
IBASE Dec
OBASE Dec
WIDTH 80
COUNT 64
LOGFILE log. bbd
SPOOL No
Here, we can basically find that the offset of the asm disk header for mapthbp1 is 32256, and the asm disk header is analyzed by dd.

 

Analysis

Use kfed to View disk header information




Now it can be basically determined that the asm disk size is 1572871 M, the disk offset is 32256, and then use the dd command to dd this part to the new disk device, then oracleasm scandisks





Data2 mount is successful, and the database is open normally. The database is restored perfectly.

Original article from:
Http://www.xifenfei.com/2016/03/parted-fdisk-asm-diskgroup-cannot-mount.html

Copyright: [you shall not reprint the content in any form without your consent. Otherwise, you have the right to further pursue legal liability.]