Timeflows for RAC provisioning of VDBs
Overview
This topic describes special considerations when provisioning by timestamp from a RAC time flow.
Timestamps in Oracle RAC time flows can be imprecise because of time skew among the hosts in a RAC configuration. The time stamps will generally track the host with the fastest clock. For this reason, provisioning by a timestamp may not leave the VDB provisioned at the exact time desired. The provision by SCN should be used if more fine-grained control is required when provisioning.
Introduction
The Delphix Engine provides the ability to link to an external database by creating a dSource within the Delphix system. Once linked, the Delphix Engine maintains a complete history of the database as part of a Timeflow, limited by the retention policies configured by the administrator. From any time within that Timeflow, you can provision a virtual database (VDB) from the Delphix Engine. This Timeflow is maintained through the use of SnapSync and LogSync.
The SnapSync operation pulls over the complete data set of the external database during the initial load. Subsequent SnapSync operations pull and store only incremental changes. At the end of each SnapSync operation, the Delphix Engine creates a snapshot that serves as the base point for provisioning operations. In addition, LogSync periodically connects to the host(s) running the source database and pulls over any log files associated with the database. These log files are stored separately from the SnapSync data and are used to provision from points in between SnapSync snapshots. Usually, SnapSync operates against a live database with changes actively being made to it. Hence the data that it pulls over is “fuzzy” and logs must be applied to the data to make it consistent and provisionable. If LogSync is enabled, SnapSync relies on it to copy the logs over. If LogSync is not enabled, SnapSync copies the logs itself. Occasionally, LogSync or SnapSync is not able to retrieve one or more log files from the database. This creates a break in the Timeflow or can prevent a snapshot from being provisioned. To remedy this situation, the Delphix Engine has tools to repair, or patch, a snapshot and the Timeflow.
Snapshot repair
ASM
The steps below do not apply if your archive logs are stored on ASM. If they are stored on ASM, you must move the archived logs to a supported filesystem directory.
When missing log files prevent the Delphix Engine from provisioning a snapshot, you can use the Delphix Management application to identify the missing logs and repair the snapshot. The Delphix Engine will generate a fault whenever missing logs prevent a snapshot from being provisionable. The fault will likely have the title "Cannot provision database from snapshot" and will contain a description of the cause. The common causes are:
Logs were deleted/moved/archived from the database before the Delphix Engine could retrieve them. In this case, the archive log retention policy on the source database may be too aggressive. Use the GUI snapshot repair tool to fetch the logs.
LogSync is still fetching the logs. SnapSync is relying on LogSync to fetch the logs needed to make the snapshot consistent. SnapSync normally will wait up to 15 minutes for LogSync to fetch the logs. If LogSync has not fetched the logs by then, SnapSync will generate a fault and finish. The best course of action, in this case, maybe to wait for LogSync to fetch the logs.
The source database is a physical standby in real-time apply mode. The changes described in the current online log of the database are needed to make the snapshot consistent. LogSync cannot retrieve the log until it is archived, and SnapSync cannot force the log to be archived because the source database is a physical standby. Force a log switch on the primary database or wait until the log is naturally archived.
Below is a screenshot of a snapshot with missing logs. Clicking on the snapshot causes the list of missing log(s) to appear. In this example, log sequence 404 is missing.
Snapshot with missing logs
If the snapshot can be repaired by fetching the logs from the source database, then you can use the GUI snapshot repair tool to fetch the logs. Hovering over the snapshot exposes more options ("...") which can then be clicked to show the Repair Missing Archive Logs option. Clicking on the option starts the repair tool.
Selecting the repair tool
Repair tool
To use the snapshot repair tool, as seen above:
Enter a Hostname. This should be the host from which to retrieve the log(s).
Enter a Username and Password. These should be the credentials for a user who can read the archived log file(s). The user credentials are optional if the host and user credentials have already been added to the Delphix Engine.
Enter a File Path. This should be the name of the directory containing the missing log(s).
If more than one file is missing, they should all exist in the directory specified by File Path. The tool will read every file in the File Path directory, so it is best that it only contains the files that are to be retrieved.
Timeflow patching
When missing log files cause a break in the Timeflow, you can use the command-line interface (CLI) to identify the missing logs and patch the Timeflow. The Delphix Engine will generate a fault whenever there are missing logs on a portion of the Timeflow. The fault will likely have the title “Cannot provision a database from a portion of Timeflow” and will contain a description of the cause. The most common cause is an overly aggressive archive log retention policy on the source database causing a log to be deleted before LogSync can fetch it. Other faults can also be generated by describing the specific errors encountered when fetching the log(s).
You can use the CLI to list the missing logs and patch the Timeflow. The following CLI Cookbook entry demonstrates how to do this: CLI Cookbook: Repairing a Timeflow
If you delete or move archivelogs from the source database that are not needed for a snapshot, you still may need to repair the TimeFlow to provision using LogSync. In this case, an icon will not be visible on the TimeFlow tabs. This means you cannot repair the TimeFlow in the GUI. However, you can still repair it using the CLI.