Pvcreate ASM disk causes abnormal recovery of ASM disk group - sparing separation

title ：pvcreate asm disk Lead to asm Disk group abnormal recovery

A client asm Disk group exception , It doesn't work mount

SQL> alter diskgroup datadg mount 2022-05-28T19:08:55.114960+08:00 NOTE: cache registered group DATADG 1/0x2B504997 NOTE: cache began mount(first) of group DATADG 1/0x2B504997 NOTE: Assigning number (1,3) to disk (/dev/oracleasm/disks/DATA05) NOTE: Assigning number (1,2) to disk (/dev/oracleasm/disks/DATA03) NOTE: Assigning number (1,1) to disk (/dev/oracleasm/disks/DATA02) 2022-05-28T19:08:55.150062+08:00 ERROR: no readquorum ingroup: required 1, found 0 disks 2022-05-28T19:08:55.150684+08:00 NOTE: cache dismounting (clean) group 1/0x2B504997(DATADG) NOTE: messaging CKPT to quiesce pins Unix process pid: 15103, image: [email protected] (TNS V1-V3) NOTE: dbwr not being msg'd to dismount NOTE: LGWR not being messaged to dismount NOTE: cache dismounted group 1/0x2B504997(DATADG) NOTE: cache ending mount(fail) of group DATADG number=1 incarn=0x2b504997 NOTE: cache deleting context forgroup DATADG 1/0x2b504997 2022-05-28T19:08:55.191073+08:00 GMON dismounting group 1 at 36 forpid 37, osid 15103 2022-05-28T19:08:55.191258+08:00 NOTE: Disk DATA02 inmode 0x8 marked forde-assignment NOTE: Disk DATA03 inmode 0x8 marked forde-assignment NOTE: Disk DATA05 inmode 0x8 marked forde-assignment ERROR: diskgroup DATADG was not mounted ORA-15032: not all alterations performed ORA-15017: diskgroup "DATADG"cannot be mounted ORA-15040: diskgroup is incomplete

By reporting the wrong information , The preliminary judgment is due to the lack of asm disk Lead to （ basis :1. ORA-15040,2.asmlib Medium DATA01 The loss of ), It is preliminarily judged that for some reason asmlib Disk exception for , Thus making asm The disk group is not working properly mount, Through to dd To the local asm Disk for analysis

C:\Users\XFF>kfed readH:\TEMP\asmdd\sdb6-o.dd kfbh.endian:                          0 ; 0x000: 0x00 kfbh.hard:                            0 ; 0x001: 0x00 kfbh.type:                            0 ; 0x002: KFBTYP_INVALID kfbh.datfmt:                          0 ; 0x003: 0x00 kfbh.block.blk:                       0 ; 0x004: blk=0 kfbh.block.obj:                       0 ; 0x008: file=0 kfbh.check:                           0 ; 0x00c: 0x00000000 kfbh.fcn.base:                        0 ; 0x010: 0x00000000 kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000 kfbh.spare1:                          0 ; 0x018: 0x00000000 kfbh.spare2:                          0 ; 0x01c: 0x00000000 0066E8200 00000000 00000000 00000000 00000000  [................]         Repeat 31 times 0066E8400 4542414C 454E4F4C 00000001 00000000  [LABELONE........] 0066E8410 4E06D490 00000020 324D564C 31303020  [...N ...LVM2 001] 0066E8420 34535542 476A7667 42546C48 6D384675  [BUS4gvjGHlTBuF8m] 0066E8430 7A385273 4B495777 73336242 33637449  [sR8zwWIKBb3sItc3] 0066E8440 48001000 000001E8 00100000 00000000  [...H............] 0066E8450 00000000 00000000 00000000 00000000  [................] 0066E8460 00000000 00000000 00001000 00000000  [................] 0066E8470 000FF000 00000000 00000000 00000000  [................] 0066E8480 00000000 00000000 00000002 00000000  [................] 0066E8490 00000000 00000000 00000000 00000000  [................]   Repeat 214 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

Through this part of information, we can confirm , One asm disk Was created pv, Further analysis pv Information
 

---

In such a case , Express asm disk Was created pv however pv Not added to any vg in , Which means disk Not much damage , Confirm by information
 

---

The main reason is that the information in these two parts is corrupted , There are several ways to do this block Information is reconstructed

C:\Users\XFF>kfed readH:\TEMP\asmdd\sdb6.dd|more kfbh.endian:                          1 ; 0x000: 0x01 kfbh.hard:                          130 ; 0x001: 0x82 kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt:                          1 ; 0x003: 0x01 kfbh.block.blk:                       0 ; 0x004: blk=0 kfbh.block.obj:              2147483648 ; 0x008: disk=0 kfbh.check:                  3196491921 ; 0x00c: 0xbe869891 kfbh.fcn.base:                        0 ; 0x010: 0x00000000 kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000 kfbh.spare1:                          0 ; 0x018: 0x00000000 kfbh.spare2:                          0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr:   ORCLDISKDATA01 ; 0x000: length=14 kfdhdb.driver.reserved[0]:   1096040772 ; 0x008: 0x41544144 kfdhdb.driver.reserved[1]:        12592 ; 0x00c: 0x00003130 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:                203424000 ; 0x020: 0x0c200100 kfdhdb.dsknum:                        0 ; 0x024: 0x0000 kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname:                  DATA01 ; 0x028: length=6 kfdhdb.grpname:                  DATADG ; 0x048: length=6 kfdhdb.fgname:                   DATA01 ; 0x068: length=6 kfdhdb.capname:                         ; 0x088: length=0 kfdhdb.crestmp.hi:             33083792 ; 0x0a8: HOUR=0x10 DAYS=0xc MNTH=0x4 YEAR=0x7e3 kfdhdb.crestmp.lo:           2268043264 ; 0x0ac: USEC=0x0 MSEC=0x3e6 SECS=0x32 MINS=0x21 kfdhdb.mntstmp.hi:             33134479 ; 0x0b0: HOUR=0xf DAYS=0x1c MNTH=0x5 YEAR=0x7e6 -- More  -- C:\Users\XFF>kfed readH:\TEMP\asmdd\sdb6.ddblkn=1|more kfbh.endian:                          1 ; 0x000: 0x01 kfbh.hard:                          130 ; 0x001: 0x82 kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC kfbh.datfmt:                          2 ; 0x003: 0x02 kfbh.block.blk:                       1 ; 0x004: blk=1 kfbh.block.obj:              2147483648 ; 0x008: disk=0 kfbh.check:                  2177715180 ; 0x00c: 0x81cd4bec kfbh.fcn.base:                  3721754 ; 0x010: 0x0038ca1a kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000 kfbh.spare1:                          0 ; 0x018: 0x00000000 kfbh.spare2:                          0 ; 0x01c: 0x00000000 kfdfsb.aunum:                         0 ; 0x000: 0x00000000 kfdfsb.max:                        1014 ; 0x004: 0x03f6 kfdfsb.cnt:                        1014 ; 0x006: 0x03f6 kfdfsb.bound:                         0 ; 0x008: 0x0000 kfdfsb.flag:                          1 ; 0x00a: B=1 kfdfsb.ub1spare:                      0 ; 0x00b: 0x00 kfdfsb.spare[0]:                      0 ; 0x00c: 0x00000000 kfdfsb.spare[1]:                      0 ; 0x010: 0x00000000 kfdfsb.spare[2]:                      0 ; 0x014: 0x00000000 kfdfse[0].fse:                        0 ; 0x018: FREE=0x0 FRAG=0x0 kfdfse[1].fse:                        0 ; 0x019: FREE=0x0 FRAG=0x0 kfdfse[2].fse:                        0 ; 0x01a: FREE=0x0 FRAG=0x0 kfdfse[3].fse:                        0 ; 0x01b: FREE=0x0 FRAG=0x0 kfdfse[4].fse:                        0 ; 0x01c: FREE=0x0 FRAG=0x0 kfdfse[5].fse:                        0 ; 0x01d: FREE=0x0 FRAG=0x0 kfdfse[6].fse:                        0 ; 0x01e: FREE=0x0 FRAG=0x0 kfdfse[7].fse:                        0 ; 0x01f: FREE=0x0 FRAG=0x0 kfdfse[8].fse:                        0 ; 0x020: FREE=0x0 FRAG=0x0

adopt dd Write to original disk , adopt oracleasm scandisks Scanning disks
 

---

Disk group mount success
 

---

The database is running smoothly open

---

This case can be perfectly recovered , The main reason is that the customer didn't do any further damage , Didn't put this pv Add to vg And write data , There have been similar cases in the past because data has been written , Recovery is much more difficult than this , The effect is not as good as this asm disk Be added vg recovery
If unfortunately there is something similar oracle asm disk Be destroyed ( format ,dd part , Make it lv etc. ), Recovery support is required , You can contact us , Do a professional recovery assessment , maximum , The fastest way to rescue data , Reduce the loss
Recovered part asm Abnormal cases :
Delete partition oracle asm disk recovery
asm disk The disk is partially emptied and restored
another asm Format file system recovery
A perfect asm disk It's formatted ntfs recovery
oracle asm disk Format recovery — Formatted as ext4 file system
oracle asm disk Format recovery — Formatted as ntfs file system
Share oracleasm createdisk Recreate asm disk Post data 0 Lost recovery cases