Skip to main content

Display OracleASM Headers

 So.... I am up at 3AM troubleshooting an "issue" that mysteriously appeared when our DBAs restart CRS/ASM/WTH earlier during some maintenance.  Apparently ASM was unable to find 3 devices.

In this example 0c32 is a known-good and 0c33 is a suspected-bad.

dd if=/dev/mpath/ITSHDS06_0c35p1 bs=8 skip=13 count=4 2>/dev/null|strings
TT6SMS_DATA01

[root@smsdba01 mapper]# dd if=/dev/mpath/ITSHDS06_0c32p1 bs=8 skip=13 count=6 2>/dev/null|strings
TT6SMS_DATA01
TT6SMS_DATAASM31
[root@smsdba01 mapper]# /etc/init.d/oracleasm querydisk /dev/mpath/ITSHDS06_0c32p1
Device "/dev/mpath/ITSHDS06_0c32p1" is marked an ASM disk with the label "TT6SMS_DATAASM31" 


 [root@ttgllpsmsdba01 mapper]# dd if=/dev/mpath/ITSHDS06_0c33p1 bs=8 skip=13 count=6 2>/dev/null|strings
TT6SMS_DATA01
TT6SMS_DATAASM32
[root@ttgllpsmsdba01 mapper]#  /etc/init.d/oracleasm querydisk /dev/mpath/ITSHDS06_0c33p1
Device "/dev/mpath/ITSHDS06_0c33p1" defines a device with no label



[root@ttgllpsmsdba01 mapper]# for DEV in 32 33 34 35; do od -c /dev/mpath/ITSHDS06_0c${DEV}p1 | head -10; echo; done
0000000 001 202 001 001  \0  \0  \0  \0   (  \0  \0 200 370  \v   Q 312
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040   O   R   C   L   D   I   S   K   T   T   6   S   M   S   _   D
0000060   A   T   A   A   S   M   3   1  \0  \0  \0  \0  \0  \0  \0  \0
0000100  \0  \0      \v   (  \0 001 003   T   T   6   S   M   S   _   D
0000120   A   T   A   A   S   M   3   1  \0  \0  \0  \0  \0  \0  \0  \0
0000140  \0  \0  \0  \0  \0  \0  \0  \0   T   T   6   S   M   S   _   D
0000160   A   T   A   0   1  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000200  \0  \0  \0  \0  \0  \0  \0  \0   T   T   6   S   M   S   _   D
0000220   A   T   A   A   S   M   3   1  \0  \0  \0  \0  \0  \0  \0  \0

0000000 001 202 001 001  \0  \0  \0  \0   ,  \0  \0 200 252 310 247   N
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000040   O   R   C   L   D   I   S   K  \0  \0  \0  \0  \0  \0  \0  \0
0000060  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000100  \0  \0      \v   ,  \0 001 003   T   T   6   S   M   S   _   D
0000120   A   T   A   A   S   M   3   2  \0  \0  \0  \0  \0  \0  \0  \0
0000140  \0  \0  \0  \0  \0  \0  \0  \0   T   T   6   S   M   S   _   D
0000160   A   T   A   0   1  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000200  \0  \0  \0  \0  \0  \0  \0  \0   T   T   6   S   M   S   _   D
0000220   A   T   A   A   S   M   3   2  \0  \0  \0  \0  \0  \0  \0  \0

[root@ttgllpsmsdba01 mapper]# /u02/app/oracle/product/11.2.0/bin/kfed read /dev/mapper/ITSHDS06_0c32p1 | head -25
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:              2147483688 ; 0x008: disk=40
kfbh.check:                  3394309112 ; 0x00c: 0xca510bf8
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:ORCLDISKTT6SMS_DATAASM31 ; 0x000: length=24
kfdhdb.driver.reserved[0]:   1396069460 ; 0x008: 0x53365454
kfdhdb.driver.reserved[1]:   1147097933 ; 0x00c: 0x445f534d
kfdhdb.driver.reserved[2]:   1094800449 ; 0x010: 0x41415441
kfdhdb.driver.reserved[3]:    825445715 ; 0x014: 0x31334d53
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                       40 ; 0x024: 0x0028
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:        TT6SMS_DATAASM31 ; 0x028: length=16
kfdhdb.grpname:           TT6SMS_DATA01 ; 0x048: length=13
kfdhdb.fgname:         TT6SMS_DATAASM31 ; 0x068: length=16
[root@ttgllpsmsdba01 mapper]# /u02/app/oracle/product/11.2.0/bin/kfed read /dev/mapper/ITSHDS06_0c33p1 | head -25
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:              2147483692 ; 0x008: disk=44
kfbh.check:                  1319618730 ; 0x00c: 0x4ea7c8aa
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:         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:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                       44 ; 0x024: 0x002c
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:        TT6SMS_DATAASM32 ; 0x028: length=16
kfdhdb.grpname:           TT6SMS_DATA01 ; 0x048: length=13
kfdhdb.fgname:         TT6SMS_DATAASM32 ; 0x068: length=16


I believe the resolution for this particular issue is:
/etc/init.d/oracleasm force-renamedisk  /dev/mpath/ITSHDS06_0c33p1 TT6SMS_DATAASM32


Sure enough...
[root@ttgllpsmsdba01 mapper]# for DEV in 33 34 35; do dd if=/dev/mpath/ITSHDS06_0c${DEV}p1 of=/tmp/ITSHDS060c${DEV}p1.dd bs=1024 count=51200; done
51200+0 records in
51200+0 records out
52428800 bytes (52 MB) copied, 3.65476 seconds, 14.3 MB/s
51200+0 records in
51200+0 records out
52428800 bytes (52 MB) copied, 3.28705 seconds, 16.0 MB/s
51200+0 records in
51200+0 records out
52428800 bytes (52 MB) copied, 2.98838 seconds, 17.5 MB/s
[root@ttgllpsmsdba01 mapper]# /etc/init.d/oracleasm force-renamedisk  /dev/mpath/ITSHDS06_0c33p1
TT6SMS_DATAASM32
 Renaming disk "/dev/mpath/ITSHDS06_0c33p1" to "TT6SMS_DATAA[  OK  ]
[root@ttgllpsmsdba01 mapper]# /etc/init.d/oracleasm force-renamedisk  /dev/mpath/ITSHDS06_0c34p1 TT6SMS_DATAASM33
Renaming disk "/dev/mpath/ITSHDS06_0c34p1" to "TT6SMS_DATAA[  OK  ]
[root@ttgllpsmsdba01 mapper]# /etc/init.d/oracleasm force-renamedisk  /dev/mpath/ITSHDS06_0c35p1 TT6SMS_DATAASM34
Renaming disk "/dev/mpath/ITSHDS06_0c35p1" to "TT6SMS_DATAA[  OK  ]
[root@ttgllpsmsdba01 mapper]# /etc/init.d/oracleasm querydisk  /dev/mpath/ITSHDS06_0c33p1 Device "/dev/mpath/ITSHDS06_0c33p1" is marked an ASM disk with the label "TT6SMS_DATAASM32"

 

Comments

Popular posts from this blog

P2V using dd for KVM-QEMU guest

Preface: I have certainly not exhaustively tested this process.  I had a specific need and found a specific solution that worked. Situation:  I was issued a shiny new laptop running Red Hat Enterprise Linux 7 (with Corp VPN, certs, Authentication configuration, etc...)  The image was great, but I needed more flexibility on my bare metal.  So, my goal was to P2V the corporate image so I could just run it as a VM. * Remove corporate drive and install new SSD * install corp drive in external USB-3 case * Install RHEL 7 on new SSD * dd old drive to a disk-image file in a temp location which will be an image which is the same size as your actual drive (unless you have enough space in your destination to contain a temp and converted image) * convert the raw disk-image to a qcow file while pushing it to the final location - this step should reduce the disk size - however, I believe it will only reduce/collapse zero-byte blocks (not just free space - i.e. if you de...

Sun USS 7100 foo

TIP: put ALL of your LUNs into a designated TARGET and INITIATOR group when you create them.  If you leave them in the "default" group, then everything that does an discovery against the array will find them :-( I'm struggling to recognize a reason that a default should even be present on the array. Also - who, exactly, is Sun trying to kid.  The USS is simply a box.. running Solaris .. with IPMP and ZFS.  Great.  If you have ever attempted to "break-in" or "p0wn" your IBM HMC, you know that there are people out there that can harden a box - then.. there's Sun.  After a recent meltdown at the office I had to get quite intimate with my USS 7110 and learned quite a bit.  Namely: there's a shell ;-) My current irritation is how they attempt to "warn you" away from using the shell (my coverage expired a long time ago to worry about that) and then how they try to hide things, poorly. I was curious as to what version of SunOS it ...

"Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)"

"Error getting authority: Error initializing authority: Could not connect: No such file or directory (g-io-error-quark, 1)" One issue that may cause this to arise is if you managed to break your /etc/fstab We had an engineer add a line with the intended options of "nfsvers=3" but instead added "-onfsvers=3" and it broke the system fairly catastrophically.