While trying to link a dSource, you receive the following warning:
message_action: The snapshot control file should reside in a location accessible from all cluster nodes. Current snapshot control file location is configured to "/zba/exabackup05/XXXXX/snapcf_XXXXXXX.f". If this is not a shared location, use RMAN "CONFIGURE SNAPSHOT CONTROLFILE NAME TO <fullpath shared location>;" command to set it to a correct shared location. If it is a shared location, no action is required. message_code: exception.oracle.snl.nonshared.snapshot.controlfile message_details: RAC database "XXXX" has a snapshot controlfile that may not reside in a shared location.
This causes the initial dSource SnapSync job to fail.
Reason the warning is thrown:
If the snapshot controlfile is not set up correctly, Delphix SnapSync will fail at the end of the snapshot. In scenarios where the snapshot took a day to complete, it would take a day to find out there is a problem. Delphix proactively added this check at the beginning of the process so that corrective action could be taken immediately. The real controlfile is always accessible from all nodes, but what occurs here is a snapshot controlfile (a copy that is taken so that the 'slow' backup of the file does not harm the current controlfile).
This warning is raised for Oracle 11.2 and later because Oracle changed how the snapshot controfile is created (Configuring the RMAN Snapshot Control File Location). Even if you add a RAC environment to Delphix as a single instance and the snapshot is created in a directory that is not accessible from the configured node, then the SnapSync will fail at the end.
How does Delphix check for this file and raise a warning fault?
Delphix cannot know if the snapshot controlfile is accessible from every node so these checks are intended to help understand why the SnapSync might fail and warn the user in advance:
- Is the snapshot controlfile referenced in the message in ASM?
- If the controlfile is in ASM (does the fully qualified filename start with a “+” symbol?), no fault is thrown.
- If the controlfile is not in ASM, proceed to the next check.
- Is there a value that has been explicitly configured for the snapshot controlfile in RMAN?
- If the RMAN “show all” command shows "; # default" at the end of the CONTROLFILE parameter, this parameter has not been explicitly configured and the warning will be thrown. Delphix needs this parameter configured explicitly because it is unlikely that $ORACLE_HOME/dbs directory is shared across the cluster. Also, if it is not configured then SnapSync will not be possible for a RAC dSource (added as a RAC) because the “CONFIGURE SNAPSHOT CONTROLFILE” command command sets the configuration for the location of the snapshot control file for every instance of your cluster database.
- If the controlfile has been explicitly configured, proceed to the next check.
- Are there any ASM datafiles?
- If there are any ASM datafiles, Delphix expects that the snapshot controfile also be in ASM and will throw the warning.
- If none of the datafiles are in ASM, then Delphix allows the snapshot controlfile to be not in ASM as long as it is not the “default” location (see #2 above).
This check was broken before 4.2.4 (see DLPX-37492), such that even if the condition is met, Delphix still throws a fault.
- Is the SNAPSHOT controlfile accessible from all nodes in the cluster?
- If the SNAPSHOT controlfile is not accessible from all nodes in the cluster, the warning can be thrown. If the environment was added as a RAC, Delphix may connect to any node in the cluster and if the file is not accessible the warning is thrown.
Recovery from this fault:
If these conditions are not met during an initial dSource link, the fault will be thrown and the snapshot will not be taken. The reason for this is to allow the user to correct the problem before proceeding to the initial load.
If it is certain that the conditions have been met, the user can try manually taking a snapshot by clicking on the camera icon. Assuming the SNAPSHOT controlfile is accessible from all nodes, one can expect the SnapSync to succeed.
Regularly scheduled snapshots should also succeed (until they do not because node X can read the snapshot, but on another day node Y does the backup and it cannot read the snapshot controlfile).
If the snapshot succeeds, mark the warning “ignored”.