The following sections describe how to configure and test ActiveDR with Oracle Database. These sections assume that the primary and secondary sites are already configured to work with FlashArray pods. For more information, see Setting Up Oracle Disaster Recovery Using Purity ActiveDR.
While these sections describe configuring and testing ActiveDR using the Everpure user interface, administrators can also use PowerShell scripts to achieve the same goals. ActiveDR and other Everpure scripts are located on GitHub.
Configuring ActiveDR
The following steps must be completed using the Everpure user interface to initiate ActiveDR replication. To ensure a seamless implementation, ensure the Oracle Database configuration matches the structure shown in the below figure.
Configuring ActiveDR for Oracle Database involves the following general steps:
-
Configure Oracle Database to store user database files on FlashArray volumes at the primary site.
-
Create a production pod.
-
Create a protection group within the pod.
-
Move volumes out of the current protection group or create new volumes.
-
Move volumes into the production pod.
-
Add volumes to the protection group in the production pod.
-
Create a remote pod.
-
Create a replica link.
Verify the Environment
Let's confirm the disks match the one we see on the primary Oracle Database server.
-
Confirm the Oracle Database volumes on the source primary pod. The two volumes used are oraadr-data and oraadr-fra, with serial numbers ending in 316A and 316B.
Figure 2. Verifying the volume namesFigure 3. Verifying the serial numbers -
Next, using the lsblk command, confirm that the two drives, sdb and sdc, match the serial numbers from the user interface, with their disks mounted on /u01 and /u02. In this example, we are using Oracle Database File System; however, it would work the same if we were using Oracle ASM for disk management.
-
We can see the correct disk path from inside the Oracle environment by using SQL*PLUS to query the names of the datafiles.
[root@oraadr1 ~]# lsblk -o name,serial NAME SERIAL sda sda1 sda2 sda3 ol-root ol-swap ol-home sdb 3BC12BFC226B41C30085316A sdb1 sdc 3BC12BFC226B41C30085316B sdc1 sr0 00000000000000000001[root@oraadr1 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 18M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/ol-root 61G 9.1G 52G 15% / /dev/sda2 1014M 457M 558M 46% /boot /dev/mapper/ol-home 30G 3.2G 27G 11% /home /dev/sda1 599M 6.0M 593M 1% /boot/efi tmpfs 1.6G 48K 1.6G 1% /run/user/54321 /dev/sdb1 100G 14G 87G 14% /u01 /dev/sdc1 100G 1.4G 99G 2% /u02 [root@oraadr1 ~]# SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_system_mtodco38_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_sysaux_mtodfd7z_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_undotbs1_mtodg5d1_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_system_mtodgrxr_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_sysaux_mtodgrxt_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_users_mtodg6h5_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/datafile/o1_mf_undotbs1_mtodgrxw_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/2DD56AB3E54447A9E065025056971309/datafile/ o1_mf_system_mtodrh06_.dbf /u01/app/oracle/oradata/oraadr/ORAADR/2DD56AB3E54447A9E065025056971309/datafile/Now that we've verified the disk paths, we can take a look at the data. Let's create some tables on the source, generate data, and then confirm the data/tables that we created have been replicated to the target Oracle server.
-
To do this, we will use the SQL command CREATE TABLES to create adr101, adr102, and adr103, and to then populate them with data from dba_objects.
SQL> create table adr101 as select * from dba_objects; Table created. SQL> create table adr102 as select * from dba_objects; Table created. SQL> SQL> create table adr103 as select * from dba_objects; Table created. SQL> SQL> SQL> select count(*) from adr101; COUNT(*) ---------- 77010 SQL> SQL> select count(*) from adr102; COUNT(*) ---------- 77011 SQL> SQL> select count(*) from adr103; COUNT(*) ---------- 77012
Now we can create the pod on the source array.
Configure the ActiveDR Primary Site Pod in the Everpure User Interface
To configure the primary site pod:
-
From the primary site's Everpure user interface, select Storage in the navigation pane, and then select the Pods tab.
Figure 4. The Pods tab in the Everpure user interface -
Click the + icon in the Pods group to create a new pod.
-
In the Name field in the Create Pod dialog box, enter a name for the pod, and then click Create. The pod appears in the Pods group.
Figure 5. The Create Pod dialogue box -
In the Pods group, select the name of the pod that was created to display the Pod management view.
-
In the Volumes group, click the ellipsis, and then click Move In to display the Move Volumes In dialog box.
Figure 6. Moving volumes into a pod -
Select the Oracle Database ASM volumes that will be moved into the pod, and then click Move. The volumes appear in the Volumes group using the naming convention <pod name>::<volume name>.
We can see from the figure below that the pod has been created, the volumes have been moved into the pod, and the default protection group has been created.
Note: Volumes can also be created by clicking the + icon under the Volumes section of the Pod view.Figure 7. Confirming pod creation
The primary site pod is now configured with the database files. ASM volumes that contain container databases, pluggable databases, database files, and redo log files should all be configured in an ActiveDR pod.
The next step is to create a replica link to the remote site's FlashArray, which enables ActiveDR replication.
Create a Replica Link in the Everpure User Interface
-
From the remote site's Everpure user interface, select Protection in the navigation pane.
-
In the Array Connections group, click the ellipsis, and then select Get Connection Key.
Figure 8. Getting a connection key on the Array tab -
In the Connection Key dialog, click Copy to copy the connection key to the clipboard.
-
From the primary site's Everpure user interface, click Protection.
-
In the Array Connections group, click the ellipsis, and then select Connect Array.
-
In the Connect Array dialog box, enter or select the following information:
-
Management Address: The IP address of the remote site's FlashArray.
-
Type: Select Async Replication from the drop-down list.
-
Connection Key: Paste the connection key that you copied from the remote site's Everpure user interface.
-
Replication Transport: Select Ethernet (IP) from the drop-down list.
-
Encrypted: Select the button to toggle replication encryption on or off.
-
-
Click Connect. The secondary site array appears in the Array Connections group.
Figure 9. Displaying the secondary site in the Array Connections group -
In the Pod Replica Links group, click the ellipsis, and then select Create.
Figure 10. Creating a replica link -
In the Create Replica Link dialog box, select the remote site FlashArray from the Remote Array drop-down list, and then select a remote pod.
Figure 11. Creating a replica linkNote: Note: If a pod hasn't been created on the remote site's FlashArray, click Create Remote Pod, enter a pod name in the Name field, and then click OK. -
Select Create.
Once a replica link has been created from the primary site's pod to the secondary site's pod, the primary site's pod begins a baseline replication of the volumes to the secondary site's pod.
During a baseline replication operation, the primary site's FlashArray replicates a full copy of the volumes to the secondary site, which, depending on the size of the data, can take a significant amount of time. The status of the baselining progress can be monitored in the Status field in the Pod Replica Links group. When the baseline replication completes, the Status field changes from "baselining" to "replicating."
Figure 12. Monitoring pod replica link statuses on the primary site's FlashArrayIn addition to monitoring the pod replica link status at the primary site, the replica link status can also be monitored in the secondary site's Everpure user interface in the Pod Replica Links group.
Figure 13. Monitoring the pod replica link status on the secondary site's FlashArrayActiveDR can now be used for the desired pods.
-
In the Storage section on the production/primary array, click the Pods tab, and then observe the state of the Pod Replica Links in a specific pod's details, which will show as promoted.
Figure 14. Checking the pod status on the primary array -
In the Storage section on the target/disaster recovery array, click the Pods tab, and then observe the state of the Pod Replica Links, which will show as demoted.
Figure 15. Checking the pod status on the target array
Non-disruptive Failover Testing
Non-disruptive failover with ActiveDR allows for any one of the disaster recovery/target sites to bring a pod online without interruption to the production/primary pod. This is non-disruptive to the production instance database, and it allows for nondisruptive failover testing and the target database to be used for testing and development.
When using this process, the primary site will still queue changes, which will be applied to the target site once the process is undone.
To perform a non-disruptive failover, the state of the environment must be as follows:
-
There is a functioning database residing on one or more volumes in a promoted ActiveDR pod.
-
There is a demoted remote pod on a separate array in the same active pod replica link.
-
The volumes in the demoted pod are connected to, and have been discovered by, a host with a running Oracle database.
-
The demoted volumes are offline.
A non-disruptive failover consists of the following steps:
-
Promote the ActiveDR pod on the target array.
-
Set the disks online and, if required, provide a drive letter or mount to a folder.
-
Attach the database to the Oracle Database.
A failback after a non-disruptive failover only requires that the pod be demoted on the target system. Replication will automatically resume from the source pod to the target.
Verification before a Test Failover
-
To complete the non-disruptive failover and failback between two arrays and different Oracle Database host systems, we must first create tables on the source and confirm they have been replicated.
SQL> create table adr101 as select * from dba_objects Table created. SQL> create table adr102 as select * from dba_objects; Table created. SQL> SQL> create table adr103 as select * from dba_objects; Table created. SQL> SQL> SQL> select count(*) from adr101; COUNT(*) ---------- 77010 SQL> SQL> select count(*) from adr102; COUNT(*) ---------- 77011 SQL> SQL> select count(*) from adr103; COUNT(*) ---------- 77012 -
Verify that the ActiveDR replication link is in a healthy state.
-
Use
purevol list --snaporpurevol list --replicato confirm replication health.
-
-
Confirm the target Oracle Database server volumes are not mounted and the Oracle Database is not running. For example, the /u01 and /u02 file systems are not mounted.
[root@oraadr2 ~]# [root@oraadr2 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 18M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/ol-root 61G 7.9G 53G 13% / /dev/sda2 1014M 457M 558M 46% /boot /dev/mapper/ol-home 30G 3.2G 27G 11% /home /dev/sda1 599M 6.0M 593M 1% /boot/efi tmpfs 1.6G 12K 1.6G 1% /run/user/42 tmpfs 1.6G 4.0K 1.6G 1% /run/user/54321 [root@oraadr2 ~]# [root@oraadr2 ~]#[root@oraadr2 ~]# lsblk -o name,serial NAME SERIAL sda sda sda1 sda2 sda3 ol-root ol-swap ol-home sdb 21F018170267441100064061 sdb1 sdc 21F018170267441100064062 sdc1 sr0 00000000000000000001 [root@oraadr2 ~]# -
Verify the disk serial numbers for the target server are correct. In the example shown in the figure below, we can see the serial numbers on the target server volumes match the serial numbers in the target pod, … 4061 and … 4062.
Figure 17. Confirming the serial numbersNow we can perform the test failover.
Execute a Test Failover
-
In the Storage section on the production/primary array, click the Pods tab, and then observe the state of the Pod Replica Links in a specific pod's details, which will show as promoted.
Figure 18. Displaying the state of the production/primary array pod. -
Navigate to the specific pod in Pods under Storage on the target/disaster recovery array, click the ellipsis, and then select Promote.
Figure 19. Promoting the podFigure 20. The Promote Pod dialogueWhen the pod has been promoted, it will have a promotion status of promoted.
Figure 21. Displaying the state of the pod -
Mount the volumes on the target server.
[root@oraadr2 ~]# [root@oraadr2 ~]# mount /dev/sdb1 /u01 [root@oraadr2 ~]# [root@oraadr2 ~]# [root@oraadr2 ~]# mount /dev/sdc1 /u02 [root@oraadr2 ~]# [root@oraadr2 ~]# [root@oraadr2 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 18M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/ol-root 61G 8.1G 53G 14% / /dev/sda2 1014M 457M 558M 46% /boot /dev/mapper/ol-home 30G 3.2G 27G 11% /home /dev/sda1 599M 6.0M 593M 1% /boot/efi tmpfs 1.6G 12K 1.6G 1% /run/user/42 tmpfs 1.6G 4.0K 1.6G 1% /run/user/54321 /dev/sdb1 100G 14G 87G 14% /u01 /dev/sdc1 100G 1.4G 99G 2% /u02 -
Prepare Oracle Database by doing the following:
-
Switch user to Oracle.
-
Load and execute the configuration settings for the Oracle Shell Profile.
-
Use SQL*PLUS to connect to the database and run the startup command.
-
Confirm the correct host by querying the hostname from v$instance.
-
Confirm the tables adr101, adr102, and adr103 have been replicated, as seen in the following example.
[root@oraadr2 ~]# su – oracle [oracle@oraadr2 ~]$ [oracle@oraadr2 ~]$ . ./.bash_profile [oracle@oraadr2 ~]$ [oracle@oraadr2 ~]$ [oracle@oraadr2 ~]$ sqlplus / as sysdba SQL*Plus: Release 21.0.0.0.0 - Production on Thu Feb 20 10:10:42 2025 Version 21.3.0.0.0 Copyright (c) 1982, 2021, Oracle. All rights reserved. Connected to an idle instance. SQL> SQL> startup ORACLE instance started. Total System Global Area 4949275712 bytes Fixed Size 9696320 bytes Variable Size 1476395008 bytes Database Buffers 3456106496 bytes Redo Buffers 7077888 bytes Database mounted. Database opened. SQL> SQL> select host_name from v$instance; HOST_NAME ---------------------------------------------------------------- Oraadr2.localdomain SQL> select count(*) from adr101; COUNT(*) ---------- 77010 SQL> select count(*) from adr102; COUNT(*) ---------- 77011 SQL> select count(*) from adr103; COUNT(*) ---------- 77012
-
-
Because the source production pod is still replicating the data from the target pod onto the replication space, create three more tables on the source pod.
SQL> select host_name from v$instance; HOST_NAME ---------------------------------------------------------------- oraadr1.localdomain SQL> create table adr104 as select * from dba_objects; Table created. SQL> create table adr105 as select * from dba_objects; Table created. SQL> create table adr106 as select * from dba_objects; Table created. -
Verify the new tables do not exist on the target pod, which should still be promoted and running.
SQL> select count(*) from adr104; select count(*) from adr104 * ERROR at line 1: ORA-00942: table or view does not exist SQL> select count(*) from adr105; select count(*) from adr105 * ERROR at line 1: ORA-00942: table or view does not exist SQL> select count(*) from adr106; select count(*) from adr106 * ERROR at line 1: ORA-00942: table or view does not exist
The replication site is now verified to be functional and available for use.
Failback from a Planned Non-disruptive Failover
-
Shut down Oracle Database and unmount the file systems.
SQL> shut immediate; Database closed. Database dismounted. ORACLE instance shut down. [root@oraadr2 ~]# umount /u01 [root@oraadr2 ~]# [root@oraadr2 ~]# umount /u02 [root@oraadr2 ~]# [root@oraadr2 ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.7G 0 7.7G 0% /dev tmpfs 7.7G 0 7.7G 0% /dev/shm tmpfs 7.7G 9.2M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/ol-root 61G 8.1G 53G 14% / /dev/sda2 1014M 457M 558M 46% /boot /dev/mapper/ol-home 30G 3.2G 27G 11% /home /dev/sda1 599M 6.0M 593M 1% /boot/efi tmpfs 1.6G 12K 1.6G 1% /run/user/42 tmpfs 1.6G 4.0K 1.6G 1% /run/user/54321 -
Navigate to the ActiveDR pod on the target/disaster recovery array, and then select Demote Local Pod. This will apply all changes from the production/primary instance and then set the pod as read-only.
Figure 22. Demoting the local pod -
When selecting Demote Local Pod, a prompt to confirm demotion appears. Select Demote when ready.
Figure 23. Confirming the pod demotion -
Once the pod has been demoted, it will show as demoted in the Pod Replica Links pane.
Figure 24. Displaying the pod statusNext, we need to attach the database to the remote site's Oracle Database instance again to confirm the new tables we created (ADR104, ADR105, and ADR106) are there.
-
When ready to perform the failover, navigate to the specific pod in Pods, under Storage, on the target/disaster recovery array, click the ellipsis, and then select Promote.
Figure 25. Promoting the target/disaster recovery array pod -
When the pod has been promoted, it will have a promotion status of promoted.
Figure 26. The promoted pod on the target/disaster recovery array -
Mount the file systems /u01 and /u02.
-
Switch user to Oracle, and then start the database.
-
Confirm the new tables exist.
SQL> SQL> select count(*) from adr104; COUNT(*) ---------- 77013 SQL> select count(*) from adr105; COUNT(*) ---------- 77014 SQL> select count(*) from adr106; COUNT(*) ---------- 77015
Once you've confirmed the new tables are present, operations can resume.
Conclusion
ActiveDR provides database and storage teams with a powerful, low-overhead disaster recovery solution for Oracle Database environments. With continuous, near-synchronous replication and support for non-disruptive failovers, failbacks, and disaster recovery testing, organizations can protect mission-critical data while maintaining uptime and performance.
By enabling seamless recovery without complex integration or added operational burden, ActiveDR helps businesses build resilient Oracle environments that are ready for the unexpected—whether caused by hardware failure, cyber threats, or site outages.
For more information, visit www.purestorage.com/solutions/databases-applications/oracle.html or try the functionality in a test drive at www.purestorage.com/products/unified-block-file-storage/flasharray-x/test-drive-dba.html.