So, you now know that DATA0 is stored on /dev/sdd1, the first partition of /dev/sdd. The presence of the "oracleasm querydisk" command indicates you have ASMLib, and the command tells you the standard device name of each ASM disk device it sees. but do /dev/sdb and /dev/sdc contain filesystems or should one of them be used by ASM? I assume that /dev/sda is probably your system disk. And the listing also shows the visible ASM disks as /dev/sd. If your naming is consistent, that would mean that a disk called FRA0 would be missing. We have a Netapp SAN and I'm looking for commands that I can use to see if I can get mapping info so we could try to re-map from Oracleasm back to the SAN.ĭo you know what the name of the missing disk should be? Your DATA disks are numbered starting from 0, but the FRA disks starting from 1. However we want to do it right and would have to set it up under UUID and udev so if the SAN fails again, we don't have to go thru this again. We're not sure if we want to just add another disks to the OS and then allocate it to Oracleasm. Oracle is having the issue and can't see some of the disks that are allocated to the Oracleasm. Scanning the system for Oracle ASMLib disks: # oracleasm querydisk -d DATA0ĭisk "DATA0" is a valid ASM disk on device init.d]# oracleasm querydisk -d DATA1ĭisk "DATA1" is a valid ASM disk on device init.d]# oracleasm querydisk -d DATA2ĭisk "DATA2" is a valid ASM disk on device init.d]# oracleasm querydisk -d DATA3ĭisk "DATA3" is a valid ASM disk on device init.d]# oracleasm querydisk -d DATA4ĭisk "DATA4" is a valid ASM disk on device init.d]# oracleasm querydisk -d DATA5ĭisk "DATA5" is a valid ASM disk on device init.d]# oracleasm querydisk -d FRA1ĭisk "FRA1" is a valid ASM disk on device init.d]# oracleasm querydisk -d FRA2ĭisk "FRA2" is a valid ASM disk on device /dev/sdk1 oracleasm statusĬhecking if /dev/oracleasm is mounted: init.d]#. Here is the status for Oracleasm on that RHEL server: init.d]#. I didn't have the RHEL OS setup with either UUID or udev and we had an issue with our SAN and now we can't get map back to those disks on the SAN that hold the Oracleasm info. as I'm dealing with a situation that I detailed in another post here, however I'm looking for more info in order to troubleshoot to see if I can save this system. However I have to ask, as you mention there are ways to pass the raw disk devices to pull their ASM labels off of them. I maybe a day later and a dollar short on this one. From there you can assemble the device mappings in order and get ASM to mount cleanly This will map all the ASM disks into /dev/oracleasm/disks/XXXX, the /dev/oracleasm/disks path should then be used as the base path in the ASM configuration to search for block devices.ĪSM is very temperamental when disks are out of order (which is painful), but if you need to recover from this there are commands you can pass to the raw disk devices to pull their ASM labels off them. Using this hash you can create udev rules to create the ASM device mappings (which are just symlinks). This will return a unique device string off the disk that looks similar to an md5 hash. The commend in the Oracle documentation is as follows: scsi_id -page=0x83 -whitelisted -device=/dev/sdb Without this option in VMWare, the SCSI command to retrieve the UUID will fail. If you are using VMWare you need to ensure you have the configuration option 'disk.EnableUUID' set to true to ensure the UUID is being passed through. Oracle recommends using UUID of the disk to identify it and generate the rule in the udev configuration. The reason it likely occurred is that other block devices were mapped through to the VM or the existing disks were setup in a different order in the VM (order of devices isn't guaranteed) The /dev/sd* devices shouldn't be used directly in ASM. You need to create mappings in UDEV to create the ASM devices based on the UUID of the disk (or another unique identifier), this ensures that the disks falling out of order will not cause issues in ASM.
0 Comments
Leave a Reply. |