PowerFlex provides native asynchronous consistent replication for disaster restart solution. The following are required to satisfy such a solution:
- All the database storage volumes containing the Oracle data, redo logs, and control files are aggregated into a single Replication Consistency Group (RCG).
- The replication is in a consistent state.
The following are additional considerations and recommended best practices:
- It is recommended that if Oracle ASM (Grid Infrastructure, or GI) is used, it is pre-installed at the target site. The reason is that if the Oracle ASM stack is already running at the target site, if a fail-over, switch-over, or remote snapshots are taken, then remote ASM disk groups can simply be mounted into the already running GI at the target site in a matter of seconds. This is true whether the database is clustered or not.
- For restart solution alone, there is no specific need to separate the datafiles from redo logs or archive logs. They just need to be replicated in a single RCG.
- Since archive logs are not part of a restart solution, there is no need to replicate the archive logs. However, if, after a replication fail-over or switch-over, the expectation is for the database to continue generating archive logs, either a matching space for the archive logs should exist at the target site, or, if the bandwidth allows it, it might be simpler to replicate the archive logs as well, so their remote space is accounted for. In that case, it is recommended to place them in their own RCG.
- If Oracle flashback database feature is used, then Oracle generates a large amount of flashback logs into the Flash Recovery Area (FRA) space. In that case, due to the high capacity demand of the flashback logs, it is recommended to separate the archive logs to their own space (rather than mixing them with the flashback logs). To make use of the flashback database feature at the replication target site, the FRA must be consistent with the database datafiles and therefore included in the same RCG as the data, redo, and control files.
- During active replication, the remote volumes are not accessible to the remote servers. To ensure the remote servers are aware of them, or even more importantly, to test the disaster restart strategy, it is recommended to use the PowerFlex Test Failover feature. This feature does not stop the replication. Instead, it automatically creates a remote snapshot and it maps to the same target volumes of the replication, making them read-writable. Therefore, one or more remote servers can discover the remote volume and disaster restart testing can be performed. When the Test Failover is finished, the snapshot is discarded.
By following these requirements and best practices, PowerFlex replication provides for an easy to use, comprehensive restart solution including a single Oracle (clustered, or single instance), multiple Oracle or using other databases.
PowerFlex asynchronous replication feature allows other databases, message queues, and external data, keeping all of them consistent.
PowerFlex replication can be extended to create remote database instances for purposes such as to run database reports, create test and development environments, performance testing, and other such uses. This is done without disturbing the PowerFlex replication by using remote PowerFlex snapshots. PowerFlex snapshots are coordinated with PowerFlex asynchronous replication to ensure that the remote snapshot data is consistent. The following are required to satisfy such a solution:
- Since all the database storage volumes containing the Oracle data, redo, and control files are already replicated as part of a single Replication Consistency Group (RCG), the only requirement is that the remote snapshot contains these same remote volumes, therefore satisfying the requirements for a restart solution.
- Once the snapshot target volumes are mapped to a server, if ASM is used then the ASM disk groups are mounted, and if file systems are used then the file system are mounted. At this point, the database instance is simply restarted. It is important that media recovery is not performed, as the purpose of this snapshot is a restart and not recovery solution.
The following are additional considerations and recommended best practices:
- It is recommended that if Oracle ASM (Grid Infrastructure, or GI) is used, it is pre-installed at the target site. The reason is that if the Oracle GI stack is already running at the target site, once the remote snapshot target volumes are mapped to a server, then their ASM disk groups can be mounted into the already running GI at the target site in a matter of seconds. This is true whether the database is clustered or not.
- Before refreshing a snapshot, remember to shut down the remote instance and dismount the ASM disk groups (or file system). This prevents any remaining locks by the database if it was still open.
- It is possible to mount multiple snapshots to a single server (or set of servers in the case of Oracle RAC). This requires a few extra steps, including renaming the ASM disk groups (or file system mount points), renaming the Oracle datafiles to match the new ASM disk groups (or file system mount points), and renaming the Oracle database ID and instance ID. While it can be easily executed and automated, the exact steps are not in the scope of this paper.
By following these requirements and best practices, PowerFlex replication can be used to create remote database instances for many purposes, including the creation of test, development, and reporting instances.
PowerFlex replication can be extended to create remote database backups. These backup images can be mounted to a remote server and used by RMAN to perform a backup to Data Domain or other backup targets, recover a database image at the remote site, or replicated back to the source side to recover the production database at the replication source site. The creation of such backup images is done without disturbing the PowerFlex replication by using remote PowerFlex snapshots of both the database files and the archive logs in a specific order. The following are required to satisfy such a solution:
- To allow for remote snapshots that can satisfy the requirement for a recovery solution, the database data, redo log, and archive log files need to be in separate ASM disk groups or file system mount points. The reason is that if the production redo logs survived a disaster and the administrator must restore the older datafiles image from the snapshot, they can be restored without overwriting the redo logs that survived. In addition, the archive logs snapshot is taken later than the datafiles snapshot and therefore requires the archive logs separated. For example, if ASM is used, the Oracle files should be in disk groups such as +DATA, +REDO, and +FRA for the datafiles, redo logs, and archive logs respectively.
- The archive logs must be part of the PowerFlex replication so a remote snapshot of the archive logs can be taken. It is recommended to include the archive logs in their own RCG so there is no dependency between synchronization and replication of the database files, and the archive logs.
- If flashback database feature is used, it is recommended to separate the archive logs from the flashback logs. This is because the flashback logs must be consistent with the datafiles and therefore included in the same RCG as the datafiles. Another reason is so there is no dependency between synchronization and replication of the database files (and flashback logs), and the archive logs.
The process of creating a remote snapshot in a recoverable state is important and must include the following steps:
- For Oracle databases earlier to release 12c, place the production database in hot-backup mode, for example, by running the following SQL command: alter database begin backup. For Oracle database of release 12c or higher there is no need for hot-backup mode due to Oracle Snapshot Optimization feature.
- Only if the database was placed in hot-backup mode, to ensure the begin hot-backup mode marker from the replication source has reached the target, perform the following PowerFlex CLI commands on the database RCG: sync_now_replication_consistency_group. The output is a key that you provide to the second command: query_sync_now_replication_consistency_group, providing the sync key and waiting for a successful response, before going to the next step.
- Create a remote snapshot. If the purpose of the remote snapshot is recovery solution alone, it should contain just the remote volumes with the replicated Oracle datafiles. If the purpose of the remote snapshot is to provide a hybrid solution, making it capable of both restart and recovery solutions, it should contain all data, control, and redo logs files (the same volumes as the database RCG).
- Only if hot-backup mode was used in the production database, perform the command to end hot-backup mode, for example, by performing the following SQL command: alter database end backup.
- In the production database, switch and archive the current redo logs. This is done to generate archive logs from a time after the datafiles snapshot was created. This is the minimum set of archive logs required to recover the database. If additional archive logs are available during recovery, they can be used as well, but this step ensures minimum necessary archive logs to provide enough recovery to the database so it can be opened. This step is done by performing the following SQL command in the production database: alter system archive log current.
- To ensure the archive logs from the replication source have reached the target, execute the following PowerFlex CLI commands on the archive logs RCG: sync_now_replication_consistency_group. The output is a key that you provide to the second command: query_sync_now_replication_consistency_group, providing the sync key and waiting for successful response, before continuing to the next step.
- Create a remote snapshot of the archive logs remote volumes.
The following are additional considerations and recommended best practices:
- Since Oracle recovery is allowed if the database ID remains the same, whether local or remote snapshots are used to create backup images, it does not matter. The snapshot image contains the same Oracle database ID and therefore can be used to recover the production database, be it locally or remotely.
- If the remote snapshot is used to allow RMAN to create a backup image and store it in Data Domain (or similar targets), it is important that the database is only mounted, or opened in read-only mode, but not in read/write mode. If the database is opened in read/write mode prior to RMAN backup the database will perform reset-logs, which invalidates it as a backup image. Therefore, just mount it, or open it in read-only mode. Either of these options is sufficient for RMAN to perform a backup.
By following these requirements, PowerFlex replication can be used to create remote backup images of the Oracle database. The two snapshots - the one with the datafiles, and the one with the archive logs - can be used to perform media recovery either at the remote site, or at the source (if the snapshot is restored and the data replicated back).