SAP ASE environment and data sources
After an uncontrolled failover has been triggered, on the target/staging host, the SAP ASE dSource/VDBs mounts, corresponding to the source engine, will still be present. This can be checked using the following command on the target host:
mount | grep <source-engine-ip>
These mounts will be mounted in the user-provided toolkit directory (Example /work) and these would be of the form /ork/<Engine-UUID>-[staging/vdb]/[datafile/archive/temp]. The following is an example for a dSource staging database mount /work/4201763f-2f8d-1c8f-381a-effb180b0328-staging-2/datafile.
All the mounts will be using the source engine's UUID.
Attempting to 'Enable' or 'Start' the ASE dSources/VDBs on the target engine while the NFS mounts are in this stale state, will cause the jobs to hang or timeout or result in a job failure.
To clear off these stale mounts, one of the following options can be used:
Manually unmount
Shutdown the concerned SAP ASE instances which host the dSource's staging database and VDBs.
List all the dSource/VDB mounts with a mount | grep <source-engine-ip>.
Remove all the mounts with a umount -lf <Delphix-mount> for example: umount -lf /work/4201763f-2f8d-1c8f-381a-effb180b0328-staging-1/archive, this might require sudo privileges. NOTE: Use the appropriate syntax for umount for your operating system. The above example is for Linux.
Restart the SAP ASE instances.
OR
Reboot the target/staging host
Reboot the target/staging host corresponding to the concerned dSources/VDBs. This option is probably the cleanest way of clearing the source engine's leftover dSource/VDB mounts, but should only be used if the concerned target/staging host(s) do not host any other databases that are not part of the uncontrolled failover.
Enabling Environments, dSources, and VDBs
Enable the source environment and then the target environment.
Enable the dSources and VDBs on the target engine.
Mounts will be moved to a new Delphix(Target Engine) and can be checked by using the following command: mount | grep <target-engine-ip> These mounts still use the source engine's UUID and not the target engine's UUID, but validated/manual syncs on dSources and refreshes/rewinds on VDB operations will be successful.