Natively, PowerFlex replication forms a restart solution as the remote volumes are consistent with each other. It is therefore critical to include all database redo logs, data, and control files in a single Replication Consistency Group (RCG). In that way, if the replication stops, the target can be made read-writable, and the database will perform automatic crash/instance recovery. As explained earlier, the database at the target will open with data as-of the time when the restartable state was created. For PowerFlex replication, this is typically a few seconds behind the replication source, based on the replication lag.
Note: Typically, a planned failover scenario is different than unplanned because in a planned failover the database is first shutdown on the replication source, the replication synchronizes the latest changes, and then either a fail-over is performed (making the target read-writable), or switch-over (swapping the roles of the replication source and target). In either case, there is no loss of data because the database was shutdown first.
PowerFlex can take advantage of Oracle Storage Optimization feature to allow for a replication that is capable of both restart and recovery solutions. Natively, the PowerFlex replication creates a restart solution. By also replicating the archive logs to the target system in their own RCG, PowerFlex snapshots can be taken at the remote site and can be used for either restart or recovery solutions. The requirements for each such use case are explained in the next section.