- The Oracle Database application has been installed and any Protector prerequisites are met.
- The Protector Master software has been installed and licensed on a dedicated node.
- The Protector Client software has been installed on the source node where the Oracle Database application resides.
- The Protector Client software has been installed on the nodes that will act as a proxy for both the primary and secondary Hitachi Block storage devices. Note that for a TrueCopy replication, the source and destination LDEVs are located on different devices.
- The storage devices have been set up as per the Protector requirements and prerequisites.
- Permissions have been granted to enable the Protector UI, required activities and participating nodes to be accessed. In this example all nodes will be left in the default resource group, so there is no need to allocate nodes to user defined resource groups.
Snapshot of a remote clone enables both rapid recovery to a point in time by using Thin Image snapshots, while adding an additional level of protection by creating a full remote clone of the database using Universal Replicator (UR) technology. UR uses Journaling to perform volume consistent, asynchronous replication. In asynchronous replication, the storage system signals each write completion as soon as it is performed on the primary volume, it then transfers it to the secondary volume (copy after write).
UR journaling ensures the write order is completely guaranteed and the secondary volume is crash-recoverable at any point in time. However, if there is a long duration of link interruption between the primary and secondary sites, there might be a service level violation with increased RPO.
The data flow is as follows:
- Set the replication type to Asynchronous Remote Clone.
- Choose a Pool from one of the available Dynamic Pools.
- Select the required Source Journal and Destination Journal.
- Leave the remaining parameters at their default settings and click OK.
- Then continue with the procedure.