OPERATIONAL DEFECT DATABASE
...
...
A reboot of the AppSync Production Host after an AppSync mount / recovery of a replica back to the AppSync Production Host. A reboot of the AppSync Production Host brought duplicate volumes and DiskGroups online.Upon the reboot, the ASM disks are no longer part of the ASM ASM DiskGroups and the database(s) were gone.
This failure was triggered due to udev rules not loading after a reboot.The reboot followed by the fact that the udev rules did not get loaded automatically.This caused the target devices and the production devices having the same ASMLIB headers on the production host.
In this case the customer can continue to use ASMLIB for their production devices because they have procured that software for naming the ASM disks in the production environment.AppSync does not use ASMLIB because it is not freely available and many open source variants reduce the reliability of that software.Command outputs may be inconsistent across different variants of ASMLIB but udev rules provide a common mechanism for naming ASM disks across Linux flavors.In the absence of free availability of ASMLIB binaries on RHEL,AppSync relies solely on udev rules for naming the ASM disks during mount.This is a default feature in all Linux flavors (If absent the user can do a yum install udev and get it).If ASMLIB binaries are present, AppSync will continue to configure and use the udev rules for naming ASM devices.The 99-emc-appsync.rules file is a rules file created by AppSync for naming target devices that are mounted as part of the Oracle database copy.This file is located in /etc/udev/rules.d/. This file is used to identify the target devices via the naming convention /dev/emc-appsync-*.This naming convention allows AppSync to identify the ASM candidate disks for each of the Disk Groups that needs to be mounted.The command differs across RHEL 5x and 6x.For RHEL 5x we can use /sbin/udevcontrol reload_rules , /sbin/start_udev (optional), /sbin/udevtrigger, /sbin/udevsettle.For RHEL 6x we can use /sbin/udevadm control --reload-rules, /sbin/udevadm trigger --type=devices, /sbin/udevadm settle.After a reboot, these steps need to be run manually or they can be a part of the init script that runs during boot-up.This issue can occur post a reboot if the copy is mounted onto production and the production is using ASMLIB.If the user was using udev rules instead of ASMLIB.The production DiskGroups would not have come up and that would have prompted him to check on the udev rules.
Click on a version to see all relevant bugs
Dell Integration
Learn more about where this data comes from
Bug Scrub Advisor
Streamline upgrades with automated vendor bug scrubs
BugZero Enterprise
Wish you caught this bug sooner? Get proactive today.
