Find dismissed updates here
Edit My Preferences
Visit Pure.ai Sales +1 800 976 6494 Everpure Careers
Visit Pure.ai Sales +1 800 976 6494 Everpure Careers
Choose Your Region
Choose Your Region
Our Platform Products Solutions Support Partners Resources Built for AI
Contact Us Start Here
Sales 1-800-976-6494
Contact Us
Main Menu
Our Platform
Products
Solutions
Support
Partners
Resources
Built for AI
Contact Us

Oracle Disaster Recovery and Data Movement with Everpure ActiveDR

Explore how Everpure simplifies Oracle DR with snapshot replication, ActiveDR, and automated recovery for resilient, low-downtime environments.
Walkthrough | 1747 min.
Watch Now
Resume Watching
The Everpure Platform
00:06
Hi everyone. I'm Graham Thornton, Field Solution Architect with Everpure. And today I want to talk about Oracle Database replication with failover and failback using an Everpure flash array. The Purity operating system has amongst the most powerful and flexible capabilities with respect to the need to copy and move large data sets.
00:25
This is in addition to class-leading performance, data protection, and non-destructive upgrades. The ability to move data starts with asynchronous snapshot replication. Taking Oracle ASM as our example, we would gather all of the ASM volumes of all of the ASM disk groups for a database into a protection group on the flash array.
00:43
We can then create an instant snapshot clone of that protection group. We can then copy that snapshot to another flash array, which could be across the data center, across the world, or even into the cloud. The snapshots in this scenario can be created ad hoc upon DBA need, or based upon a schedule up to every five minutes.
01:02
The second example is continuous replication. In this scenario, the protection group is continuously replicated from one flash array to another. We call this Active DR. And the replication is near synchronous, although exact latency will depend on the volume of changes to the source system being replicated and the throughput of the network
01:21
that connects the two flash arrays. The last example is synchronous replication. We call this Active Cluster. This is fully synchronous replication from source to target, the limitation being that the target system must be within eleven milliseconds of the source.
01:36
The last option offers a recovery point objective of zero. In this video, we are going to explore the second option, near synchronous snapshot replication with Everpure Active DR. With the volumes or ASM disks being continuously replicated, it would clearly make no sense for the database to be permanently in backup mode.
01:57
Luckily, the Everpure flash array supports crash consistent snapshots, where we can clone the underlying disk of the database without having to have Oracle in backup mode. Crash consistent snapshots are distinct from application consistent snapshots, where the database would be in backup mode. Interested DBAs might wish to review MOS Note 604683.1, where Oracle explains that crash
02:20
consistent storage snapshots are supported by Oracle if the underlying storage platform supports write ordering, which the Everpure flash array does. So let's review how Active DR can be used to failover and failback an Oracle database. Here's an example where we've created an Oracle database with four ASM disk groups, the OCR disk group for cluster resource and voting disks, the data ASM disk group, the FRA ASM
02:45
disk group, and in this example, we've broken out temp into its own disk group. This is not a requirement, but might be advantageous if the DBA has a database that makes heavy use of the temporary table space. Using Active DR, we can then replicate the RAS in disk groups to a second flash array on a continuous basis.
03:02
Again, in this example, we'd only replicate data in FRA. The OCR vote disk group would not be replicated. It contains cluster-specific data such as node names, IP addresses, and so on. Also, in this example, we're not replicating temp, as it does us no good. Whereas with asynchronous snapshot replication, we could script it to put the database into
03:22
backup mode, take the snapshot, and then take the database out of backup mode afterwards. With continuous replication, the source database is evidently not in backup mode. The replicated volumes exist on the target side, but they are not, at least initially, writable. On the target side, we can at any moment of our choosing promote the replica to a
03:42
read-write state. This allows us to access a complete read-writable replica of the source database at the moment we chose to promote. The DBA can then mount and open the database, which will be a full binary clone of the source database. Replication continues even while the clone is being accessed. And then we are done with our clone, we can
04:00
shut it back down again, demote the replica, and once again, our volumes are read only. In the event of a failure, the replicated volumes can immediately be promoted to a full read-write state, allowing database processing to be moved quickly from the failed primary to the DR side. What's more, replication can be reversed, propagating the changes from the newly promoted database back to the original.
04:24
Now, many DBAs prefer to use Oracle's own Data Guard replication tool to replicate an Oracle database, and that's fine. It's a great solution too. Here is a quick comparison of Active DR and Data Guard with some of the pros and cons of each approach. And bear in mind, you can use asynchronous
04:39
snapshot replication or Active DR to create the seed replica database and then have Data Guard take over the ongoing replication management. Many customers of Everpure use a mix of Data Guard and the functionality of Purity to protect their Oracle databases. All right, let's log into the lab and see how this looks.
04:58
We're going to explore how we continuously replicate and then clone an Oracle database using Purity's Active DR functionality. Here we are in the F06-33 flash array. This is our target flash array, the one we're gonna replicate to, and we're gonna start by creating a new pod.
05:14
It's good to give your pod a meaningful name, so I'm gonna call it GCTRDB Demo FA33-Pod. The pod name needs to be unique to the flash array on which it sits. Now we can go and find that pod, and we need to set it to a demoted state. And here you can see Purity showing us that the pod is now demoted.
05:33
Let's move over to the other flash array, the F06-27, where our production database is actually running. We're gonna create another pod here, and we're gonna call it GCTRDB Demo FA27-Pod. So again, the name is unique to the flash array on which it sits. Now if we click on the new pod, we can add volumes that we want to be replicated to the
05:55
other pod. We're going to click Move In, and then we can add the four ASM disks that are supporting the production database into our new pod. Now, when we add the volumes into the pod, Purity will remove them from any protection group that they are already a part of, and then we want to add them to the default protection group of our new pod, which will be P group dash auto.
06:16
So here's our new pod with four ASM disks added to it. Next, we need to add a pod replica link, so we can drop down the option list here. Select the F06-33 FlashArray as our remote target, and then we're gonna select the remote pod name, the one that we just created on the F06-33 FlashArray just a few minutes ago. Now Purity will baseline.
06:37
It's going to replicate all of the volumes of the pod from the source FlashArray, F06-27, to the target FlashArray, F06-33. The time required for baselining will of course depend on the volume of data and the speed of the link between the two FlashArrays. But when it completes, the status will change from baselining to replicating, meaning that
06:57
all of our ASM disks are now being continuously replicated from the source FlashArray to the target FlashArray. Once baselining has completed and replication has begun, we will see the volume show up on the target FlashArray, and these mirror the ones from the source array. Before we can map these to a host, we need to promote the pod.
07:15
Promoting the pod means that these target volumes will become readable and writable with a copy of the data from the moment of promotion, and replication will continue in the background. So let's promote the pod so that we can present the volumes to the host. Now that our pod is fully promoted, we can connect the volumes to the host.
07:31
We can click on them individually and add them to the host or host group so that our host can see them. Once you've connected all the volumes to the host group, you should be able to log into Linux, rescan the SCSI bus, and find the devices in the SCSI device table. If you're using VMware, you may have to add the volumes as RDMs or VVols to your guest.
07:49
Or maybe you're using iSCSI. It really depends on how you map the volumes. If you have a large number of volumes being replicated in the pod, you might want to script this step. Otherwise, it can get a little tedious. But it's worth remembering that this is a one and done step.
08:02
Once you demote the pod, the volumes will become read-only, but you can leave them presented to the host if you wish. Some administrators might choose to remove the demoted volumes from the host. It's really entirely up to you. We'll rescan the SCSI bus on our target host to discover the new volumes.
08:16
Our example Oracle host here is using ASM filter drivers. Now they've been replaced with ASMlib three. I just haven't gotten around to upgrading this lab yet. The process, however, is pretty much identical in both cases. We need to check the new ASM devices, and here we're using the AFD refresh command followed
08:32
by AFD LSDSK. With ASMlib, it would be Oracle ASM scan disks followed by Oracle ASM list disks. Once ASM has discovered the replicated disks, we can mount the replicated ASM disk groups on our target database servers. You can use the ASM CMD mount data and FRA commands to bring the two disk groups online.
08:52
Once we've done that, we can start the replicated database. Since this is the first time I am starting the replicated database, I'm going to use an existing instance on my target database server. But I need to make sure the SP file of the target instance roughly matches the SP file of the source instance in terms of things like the location of the control files, the size of
09:11
the recovery desk, the location of the recovery desk, and whether this is a pluggable database or not, which in this case it's not. Resetting the SP file when you clone database is generally best practice. For example, you may have renamed the ASM disk groups on the target on the previous clones or renamed the database with NID.
09:30
And when you refresh the clone from production, the newly cloned database will expect the settings from production. I'm using a quick script here to extract some key values from the source database so that I can reset the SP file on the target. Again, this is the sort of thing we automate in the scripts that we share in the Everpure
09:45
GitHub repository. I will confess I'm using a little bit of video magic here to accelerate the process. A few of these steps are taking a minute or two. Overall, the cloning process demonstrated here took about five minutes, including setting up replication between the two FlashArrays.
10:02
This step right now is familiar to Oracle DBAs. We've updated the target SP file and then restarted the target instance to read our new values. We should now be able to start and open our clone database. Recall our source database was not in backup mode.
10:16
It's being continuously replicated, so this is technically a crash consistent snapshot. Oracle will behave as if we pulled the power from our database server. It will perform instance crash recovery using the online redo logs and, where necessary, execute undo against uncommitted transactions. This is all standard asset compliant database behavior.
10:37
The database has started, and it did not report any errors. I'll do a quick check with select star from dual. Okay, looks good. Now let's see if we can start our application, which is Swing Bench, the Oracle Database test package written by Dominic Giles of Oracle in the United Kingdom.
10:52
I should remind DBAs that when you clone a database from production to another environment, be sure to update any database links or internal jobs so that your non-production clone is not trying to update data in the production environment. You will note here that our connect string is pointing at the target database server, so we'll test the connection, and now we can start the application against the full Oracle
11:12
Database clone, replicated not only to a second database server, but to a second FlashArray. At the conclusion of our testing, we can shut down the clone database on the target Oracle hosts. Purity has been replicating the changes from the source system continuously during the time
11:27
we had the target pod promoted, so there was never any risk of data loss had an event occurred. So I'll shut down the target database, and I'll use the immediate option in case I have any lingering sessions. Then we can unmount the data and FRA ASM disk groups on the target Oracle hosts, and we can
11:46
demote the pod on the target F06-33 FlashArray in Purity. When we demote the pod, the volumes that are the ASM disks become read-only again, and hence ASM cannot mount them. But since we've already unmounted the ASM disk groups, this presents no problem. The Purity interface will show the target pod being demoted and then
12:05
switch to a demoted state. You can see the direction of replication is from FlashArray F06-27 to FlashArray F06-33. Here we have our production system, and you can see we have SwingBench running at about thirty-nine hundred transactions per second. Now I want to show you a graceful switchover from production to DR, the sort of operation
12:26
you might undertake if you have planned maintenance. So I am going to shut down SwingBench, and then I'm going to shut down the Swing PRD database. I'm gonna use the immediate flag to ensure I get a clean database shutdown, and we're not waiting for any user sessions that might still be logged into Oracle.
12:42
Many of our customers routinely swap from primary to DR to ensure the process is well understood and that runbooks are up to date, the team is familiar, and timings are known in case of an emergency. With Swing PRD shut down, I'm going to unmount the ASM disk groups for the database, data and FRA.
12:59
Again, I'm using a little video magic here to spare you the joys of watching a flashing cursor. The database shutdown took about ten seconds and about another seven seconds to unmount the disk groups. And then I can gracefully demote the pod on the production array, which in this case is F06-27.
13:15
Now when I select the Demote option in the Purity interface, it offers me the choice of quiesce or skip quiesce. Quiesce allows all pending writes to be flushed through to the replica site. It's a graceful shutdown. Skip quiesce does not wait for the writes to be flushed to the replica.
13:29
It demotes the pod immediately, similar to the way in which a shutdown and board instantly terminates an Oracle database. Over on the F06-33 flash array, we can now promote the pod. We used the quiesce option when we demoted the pod on the production flash array, so this should be pretty simple.
13:46
Once we tell the pod to promote, the status of the pod changes to promoting, and after a short time, you will see the direction of the replication reverses. We are now replicating from the F06-33 flash array to the F06-27 flash array. Since we didn't remove the volumes from the DR host when we demoted the pod earlier in this video, the volumes are still connected.
14:07
The lsblk command shows us our four ASM disks. If we do an asmcmd lsdsk, we only see the disk for the grid disk group. But if we use the afd lsdsk command, we can see the disks for data and FRA. Again, this is an older server running ASM filter drivers. With ASM lib, you would use the Oracle ASM list disk command.
14:29
We can now mount the data and FRA disk groups on the DR server and then start the database. It was a graceful shutdown, so no recovery is necessary. And finally, we can start the SwingBench application up on DR. So that was a graceful switchover with a clean shutdown on the source system and a simple clean startup on the target side.
14:50
In the last section of this video, let's explore what happens when we have an abrupt, unplanned failover. Since our production and DR are currently reversed, let's execute an unplanned failover from the DR side to the prod side, from the F06-33 flash array to the F06-27 flash array.
15:09
So to mimic my unplanned outage, I'm going to demote the pod on the F06-33 flash array, the array that is currently supporting my production database. I am not gonna quiesce. This is gonna be a hard crash. And if I switch back to SwingBench, you will see it gets very ugly very quickly.
15:26
Yeah, this is not good at all. Lots of SQL and Java errors from the app. If I drop back to Linux, you will see that the Swing prod database on the DR server has now crashed. And if I try to list the ASM disk groups that are mounted, yep, that's not pretty either.
15:42
This is expected. I just yanked the disks away from the database without warning. ASM is now seeing disks suddenly go read-only, which it cannot handle. So let's close the SwingBench application, go over to the F06-27 flash array, currently the replication target, and promote the pod there.
15:59
You'll notice that the pod status is once again listed as idle, and the replication direction is currently from the F06-33 flash array to the F06-27 flash array. When we promote the pod, the pod will briefly go to a baselining state. You'll notice that the direction of replication has now reversed. Active DR is able to failover and fail back without issue.
16:21
To do this with Data Guard, you would need to have flashback logging enabled. Cool. The pod is now replicating again from the F06-27 flash array back to the F06-33 flash array. With the pod again promoted on the F06-27 flash array, we can again mount the data and FRA ASM disk groups on the PRD01 server.
16:43
And we can verify with ASM that the disks are visible and the disk groups are mounted. And then we can restart the Swing PRD database. Since this was mimicking a hard crash, we did not shut down the database on DR before failing over, and we did not quiesce the pod, the database will need to perform instance recovery, which Oracle does extremely well.
17:04
And now we can restart SwingBench. And that's it. In this video, we set up a continuous replication from source to target. We opened the replicated database to verify it was usable. We switched over gracefully from prod to DR, and we failed over abruptly
17:18
from DR back to prod. EverPure's Active DR is a very powerful feature to protect our customers' most critical workloads, including Oracle and other databases. I hope you found that useful. Thanks for watching.

Ready to connect?

Contact an Everpure Expert
Watch more from this series
Completion
Unlock premium content.

* indicates a required field.

Gain exclusive access to all premium Pure360 demo content and explore even more in-depth insights and features of the Everpure platform.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Your Browser Is No Longer Supported!

Older browsers often represent security risks. In order to deliver the best possible experience when using our site, please update to any of these latest browsers.

safari
chrome
firefox
edge
Close
Personalize for Me
Steps Complete!
1
2
3
Edit My Preferences
Start a Chat
Continue where you left off
Personalize your Everpure experience
Select a challenge, or skip and build your own use case.
Future-proof virtualisation strategies

Storage options for all your needs

Enable AI projects at any scale

High-performance storage for data pipelines, training, and inferencing

Protect against data loss

Cyber resilience solutions that defend your data

Reduce cost of cloud operations

Cost-efficient storage for Azure, AWS, and private clouds

Accelerate applications and database performance

Low-latency storage for application performance

Reduce data centre power and space usage

Resource-efficient storage to improve data centre utilization

Build My Use Case
Confirm your outcome priorities
Your scenario prioritizes the selected outcomes. You can modify or choose next to confirm.
Primary
Reduce My Storage Costs
Lower hardware and operational spend.
Primary
Strengthen Cyber Resilience
Detect, protect against, and recover from ransomware.
Primary
Simplify Governance and Compliance
Easy-to-use policy rules, settings, and templates.
Primary
Deliver Workflow Automation
Eliminate error-prone manual tasks.
Primary
Use Less Power and Space
Smaller footprint, lower power consumption.
Primary
Boost Performance and Scale
Predictability and low latency at any size.
Start Over
Select an outcome priority
Select an outcome priority
Next
What’s your role and industry?
We've inferred your role based on your scenario. Modify or confirm and select your industry.
Select your industry
Financial services
Government
Healthcare
Education
Telecommunications
Automotive
Hyperscaler
Electronic design automation
Retail
Service provider
Transportation
Which team are you on?
Technical leadership team
Defines the strategy and the decision making process
Infrastructure and Ops team
Manages IT infrastructure operations and the technical evaluations
Business leadership team
Responsible for achieving business outcomes
Security team
Owns the policies for security, incident management, and recovery
Application team
Owns the business applications and application SLAs
Back
Select an industry
 Select a team
Select an industry
 Select a team
Next
Describe your ideal environment
Tell us about your infrastructure and workload needs. We chose a few based on your scenario.
Select your preferred deployment
Hosted
Dedicated off-prem
On-prem
Your data centre + edge
Public cloud
Public cloud only
Hybrid
Mix of on-prem and cloud
Select the workloads you need
Databases
Oracle, SQL Server, SAP HANA, open-source

Key benefits:

  • Instant, space-efficient snapshots

  • Near-zero-RPO protection and rapid restore

  • Consistent, low-latency performance

 

AI/ML and analytics
Training, inference, data lakes, HPC

Key benefits:

  • Predictable throughput for faster training and ingest

  • One data layer for pipelines from ingest to serve

  • Optimised GPU utilization and scale
Data protection and recovery
Backups, disaster recovery, and ransomware-safe restore

Key benefits:

  • Immutable snapshots and isolated recovery points

  • Clean, rapid restore with SafeMode™

  • Detection and policy-driven response

 

Containers and Kubernetes
Kubernetes, containers, microservices

Key benefits:

  • Reliable, persistent volumes for stateful apps

  • Fast, space-efficient clones for CI/CD

  • Multi-cloud portability and consistent ops
Cloud
AWS, Azure

Key benefits:

  • Consistent data services across clouds

  • Simple mobility for apps and datasets

  • Flexible, pay-as-you-use economics

 

Virtualisation
VMs, vSphere, VCF, vSAN replacement

Key benefits:

  • Higher VM density with predictable latency

  • Non-disruptive, always-on upgrades

  • Fast ransomware recovery with SafeMode™

 

Data storage
Block, file, and object

Key benefits:

  • Consolidate workloads on one platform

  • Unified services, policy, and governance

  • Eliminate silos and redundant copies

 

What other vendors are you considering or using?
Back
Select a deployment
 Select a workload
Select a deployment
 Select a workload
Finish
Thinking...
Your personalized, guided path
Get started with resources based on your selections.
Start a Chat
My Updates
No updates at this time.