Copy management requires you to unmount and expire copies over time. Unmounting an Oracle copy is the opposite of mounting a copy. When you perform an unmount, AppSync completes the following actions:
- Shuts down the running database that it has started. If the Mount and generate Scripts for Manual recovery or Mount Filesystem modes are used, AppSync does not shut down the database. You must perform this action manually.
- Dismounts the mounted ASM diskgroups, if ASM is part of the environment. See the section ASM Model with AppSync for details.
- Unmounts file systems if file systems are part of the environment.
- Deports or exports third-party volume groups.
- Updates the AppSync server with the necessary information that is required for AppSync to perform a restore or another mount later. This action is critical and contains information regarding paths, such as datafile paths. If a datafile was mounted using an alternate path, the control file was updated with the new path. Any subsequent mount operations must consider previous path changes to maintain an accurate chain of events.
An ASM instance user with SYSASM privileges is required to perform tasks in AppSync. The ASM instance user information provided is used during the mounting phase to perform the ASM_diskstring and ASM_diskgroup operations during mount and unmount operations. In cases where SYSASM privileges are revoked from the ASM instance user before the unmount operation, the operation fails.
Starting with AppSync versions 3.7 and later, you can retry recovery of a mounted and recovered copy without having to unmount the copy. This ability saves time that is spent in removing the target devices from the host and ESX rescans, if VMware hosts are involved.
You can use this feature in the following cases:
- You retry recovery with a different set of options like changing the open mode, specifying a different database name or SID or ASM diskgroup, or adding customized initialization parameters.
- You retry recovery if it fails to recover the copies during the initial mount operation. This action reduces the time that is taken for the unmount and remount operations. This action is used if there is a recovery failure due to a user or host issue, as recovery can be retried after rectifying the problem.
- Recovery mode remains fixed across retries. For example, if the copy was first mounted and recovered as RAC database, you cannot attempt to retry recovery with recover as the standalone database option.
- This option is also available for repurposed copies.