Home > Storage > Data Storage Essentials > AppSync > Dell AppSync: Integration with Oracle Database Server > ASM model with AppSync
The AppSync Oracle plug-in interacts with the ASM instance to discover, mount, and dismount ASM diskgroups. On the production system, during a copy or restore operation, AppSync interacts with the ASM instance serving the database.
For the copy operation, AppSync checks if an ASM rebalancing operation is in progress for any of the diskgroups that are involved. It fails protection if an ongoing operation does not complete within an hour. This check is mandatory to ensure copy consistency by guaranteeing that there are no data movements between the disks of the diskgroups that are protected by AppSync. AppSync does not have control over an ongoing, or user initiated rebalancing operation. However, it sets the ASM_power_limit parameter to 0 to prevent any new operation from triggering dynamically, while protection is in progress. The original value of the parameter is restored once protection is completed.
For the mount and recovery operations, AppSync uses UDEV rules based nomenclature in Linux, and mknod in IBM AIX, for making target devices available to the ASM instance of the mount host. AppSync adds /dev/emc-appsync-* to the ASM_diskstring parameter of the mount host ASM instance for recognizing the devices AppSync mounts.
Key points on setting ASM_diskstring parameter on LINUX mount hosts include setting the parameter correctly in order to ensure that the ASM instance sees only one path to the target devices. Duplicate paths lead to diskgroup mount failures. The key points are as follows:
The steps that are performed during mount are summarized as follows:
connect / as SYSASM;
select path from v$ASM_disk;
alter system set ASM_diskstring = 'Path1','Path2',
'/dev/emc-appsync-*’ scope=both;
select name from v$ASM_diskgroup;
alter system set ASM_diskgroups = DiskGroup1,DiskGroup2,DG1,DG2 scope=both;
alter diskgroup DG1 mount;
alter diskgroup DG2 mount;
AppSync automatically performs these steps during mount in Read-only and Read-write operations. For the mount option Mount on standalone server and prepare scripts for manual database recovery, you must perform the steps above manually, if the database should be recovered on the mount host.
Similarly, during unmount, the following steps are performed:
connect ASM_username/password as SYSASM;
select name from v$ASM_diskgroup;
alter diskgroup DG1 dismount;
alter diskgroup DG2 dismount;
alter system set ASM_diskgroups = DiskGroup1,DiskGroup2 scope=both;
select path from v$ASM_disk;
alter system set ASM_diskstring = 'Path1','Path2' scope=both;
AppSync automatically performs these steps during the unmount process if the copy was mounted in Read-only or Read-write with recovery mode.
For the mount option Mount on standalone server and prepare scripts for manual database recovery, you must perform the steps above manually.
If an ASM disk contains an ASMLIB volume header, this header is ignored during mount because the disks mounted by AppSync are blocked against ASMLIB. This action does not change the physical structure of the disk in any way and preserves the ASMLIB volume name if it must be restored back to production.
Note: For the mount-to-production-host scenario, production Oracle ASM disk groups cannot be mounted after a host reboot due to conflicting ASMLIB disks. This result occurs if the udev rules that mask the devices of an AppSync mounted copy do not get loaded after a reboot leading to conflict between the production ASMLIB devices and the devices of the mounted copy. If udev rules are not loaded, the devices of the mounted copy are exposed through their ASMLIB header, because that information is present on the replicated device and is not hidden by the udev rules. The ASM instance consists of two ASMLIB disks with the same name and is confused. This issue can be addressed either by unmounting and remounting the copy in AppSync or by manually reloading the udev rules. Follow standard commands based on Linux version.
The following requirements must be satisfied to mount a copy as a RAC database: