Skip to Content
Find dismissed updates here
Edit My Preferences

Understanding Oracle Async Replication and Recovery Workflows

See how Everpure async replication powers Oracle DR, testing, dev, and business continuity—all from a single replicated dataset.
Watch Now
Resume Watching
00:06
Hi everyone, I'm Graham Thornton, Field Solution Architect with Everpure. And today, I want to talk about Oracle Database cloning and replication using an Everpure FlashArray. Purity has amongst the most powerful and flexible capabilities with respect to the need to copy and move large data sets.
00:23
This is in addition to class-leading performance, data protection, and non-disruptive upgrades. The ability to move data starts with asynchronous snapshot replication. Taking Oracle Database ASM as our example, we would gather all of the ASM volumes groups for a database into a protection group on the FlashArray.
00:41
We can then create an instant snapshot clone of that protection group, and then we can copy that snapshot to another FlashArray, which could be across a data center, across the world, or even to the cloud. The immutable snapshots in this scenario will be created ad hoc or on a schedule up to every five minutes.
00:59
The second example is continuous replication. In this scenario, the protection group is continuously replicated from one FlashArray to another. We call this ActiveCluster, and the replication is near-synchronous. Although the exact latency will depend on the volume of changes to the source system being
01:15
replicated and the throughput of the network that connects the two FlashArrays. The last example is ActiveCluster. We call this ActiveCluster. 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:32
This last option offers a near-zero RPO. In this video, we are going to explore the first option, asynchronous immutable snapshots replication. Since we are going to explore asynchronous snapshot replication, let's quickly revisit snapshot technology on the Everpure FlashArray.
01:50
We support two types of snapshot technology. Application-aware is where the database is placed in backup mode, the volumes are immutable snapshots, and then the database is taken out of backup mode. We also support crash-consistent snapshots, where the database is not in backup mode. DBAs are invited to review Oracle MOS Note 604683.1 that
02:11
explains Oracle does support crash-consistent immutable snapshots to clone a database technology supports write ordering, which the Everpure FlashArray does. This all-flash works. Here is 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 disk group, and in this example, we've
02:34
chosen to break temp into its own dedicated disk group as well. We could replicate this database to another RAC cluster by creating a snapshot clone of the data and FRA disk groups, and then replicating that snapshot to a second FlashArray. Note that we don't snapshot clone the cluster disks, as these are RAC cluster-specific,
02:51
containing data such as node names, network addresses, and so on. We also don't replicate temp, as it's unnecessary. Once we've replicated the snapshot across, we can then use that snapshot to create replica volumes on the target FlashArray, present them to the host, mount the ASM disk groups and start the clone database, which will be an exact binary replica of the source database at
03:12
the time the immutable snapshots was taken. Okay, so let's log into our lab and see how this looks. So here we are in the Purity interface, and you'll notice that this is FlashArray//X60 dash twenty-seven in our lab. We have a protection group on this FlashArray called GCTRDB Demo PRD zero
03:34
PSTG It is the protection group for a production Swing Bench database. There it is. There are four volumes in this protection group, two for the data STaaS disk group and two for the FRA. If I click on one of the data disks, you'll see that they are 150
03:49
GB in size, and currently we're seeing about a 6.7 to 1 data reduction, from that data. The FRA disks are 40 GB in size, and there we're seeing a 3.4 to 1 data reduction on those volumes. These volumes are all mapped to the VCF zero one workload, cluster one. That is our vSphere cluster where our VMs are running.
04:13
And here's the application. Here's Swing Bench running on our Oracle Database server. We're currently doing about thirty-eight hundred transactions per second. And if we minimize that window, take a look at the host itself. This is running on the VMware right here, this PRD 01 VMware.
04:29
If I check for the processes, you'll see that we have an ASM instance. We have that dummy instance KVDB. We have an RMAN catalog, and also the Swing Bench database is running here as well. Now, if I go into Oracle Database ASM, we can look to see our ASM disk group layout. So let's do an ASM CMD LSDG, and we will see that we have a data disk group, an FRA disk
04:53
group, and also we have a grid which is used by the, by the, the, ASM instance itself. If we do an LSDSK, you will see that those are the two data disks you saw in the, in the interface a minute ago, a hundred and fifty GB each in size. And there's the two FRA disks, for the FRA, ASM disk group. And if we do an LSCT, we can see that the Swing Bench database is using data in FRA.
05:18
The ASM instance is actually also using data. I think the pure.json file is sitting in the data ASM disk group. Now let's jump over to our second FlashArray This is the F06- 33 FlashArray. We have a protection group set up here.
05:32
It's GKE KVDB Demo DR zero 1 - PSTG, and it's basically a mirror of the one from production. It also has four volumes, two at a hundred and fifty GB each, two at forty GB each. You do not have to have a mirrored protection group on the target FlashArray
05:53
immutable snapshots to work. It's entirely optional. But remember that the snapshot itself is just metadata. It's not a mountable volume. If you want to be able to access clones of your ASM disks, you're gonna need to have
06:04
matching volumes and then copy that snapshot to those volumes and then map them to your database host. Okay, so I've logged into my Oracle Database server, my DR server, and if I look at ASM, you'll see that we have one disk group over here. We only have the grid disk group. Data and DR are not present.
06:22
If we do an lsdsks, you'll find that we only have one ASM disk for that grid disk group. But if I look at lsblk, you'll see that we do actually have two 150 GB volumes and two 40 GB volumes presented to this host. There's just nothing on them. They're blank right now.
06:40
Now I'm gonna go back to the FlashArray for my source database. This is the F06-27 FlashArray, and I'm looking at the protection group for my production database. What I'm gonna do is I'm gonna add a target to the protection group for replication. I've just added the F06-33 FlashArray as a replication target.
07:00
Now if I create a snapshot, I can click that Replicate Now button that you see on the screen, and it will replicate that snapshot from the source FlashArray to the target. Now let's see if we can find that snapshot on our target FlashArray. So let's go over to F06-33, go to Protection and snapshots, and there you can see the four immutable snapshots have shown up on the target FlashArray.
07:26
If I want to be able to actually mount that snapshot though as a volume, I'm gonna need to copy the immutable snapshots over those target volumes in the protection group a minute ago. So we can click on Copy, give it the name of the target volume that we're gonna overwrite with the contents of this snapshot, and then check the Overwrite box and tell it to go ahead and copy that data.
07:48
Now, for this example with just a handful of disks, the GUI is just fine. But if you had a very large database with many ASM disks, this might get a little tedious. So let me show you a JSON example as well. I'm gonna use the FlashArray snap script. It's a Python script that's available from the Everpure GitHub repository, and what it's
08:07
going to do is copy the Everpure test two snapshot from the source protection group, PRD01-PG, to the target protection group, DR01-PG, on the target FlashArray. And it does this by looking at the volumes in the source protection group, looking at the snapshot, and then finding equivalent volumes in the target protection group of equal or
08:31
greater capacity. And if we look here on the screen, we can see how it's chosen to map our snapshots. All right, so we made an immutable snapshot of our production database. We replicated that snapshot to a target FlashArray. We then used the snapshot to clone the ASM disks from production, and now we're gonna use
08:47
the AFD refresh command and an AFD lsdk command to see if ASM can see our clone disks. And there you can see them. The data and FRA disks are there. So let's go ahead and see if we can mount the data and FRA disk groups on our target Oracle Database server. And of course, it would help if we actually
09:07
sourced the ASM environment first, so let's just go ahead and fix that. And then we'll try that ASM CMD mount command one more time. Okay, and there we are. The data and FRA ASM disk groups are now cloned and mounted on our target SQL Server.
09:23
All right, so we made an immutable snapshot clone of our production database. We then replicated that snapshot to a second FlashArray and then used the snapshot to clone the ASM disks and brought the ASM disk groups online on our target Oracle Database server. I have an instance on my target SQL Server server that I'm going to use to mount and open
09:42
the clone database. But before I can do that, I need to make sure that I'm pointing at the correct JSON files, the one that I just copied across from the snapshot from production. So I'm gonna connect at the production database and extract the control file location, the location of the FRA, the size of the recovery desk, database name, and whether or
09:59
not this is a pluggable database. I can then start my target instance in a no-mount state and use that information to update the API file on the target database side. Once I've done that, I can restart the instance, and I should be able to go ahead and mount the database clone.
10:15
The source database was not in hot backup mode when we made that snapshot copy. It's a crash-consistent copy of the database, and so some of the steps you're seeing on the screen right now are taking a minute or two to complete as the database has to complete instance recovery. I'm using a little video magic to speed things along, but you can see the process.
10:32
We reset the SP file to match the cloned ASM disk groups, and then we can start up, mount, and open our database to a fully read-writable state. The entire cloning process has taken us about seven minutes. That's to clone our database, move it to a second FlashArray, and reopen a read-writable copy on a second SQL Server instance.
10:50
Most DBAs would script the entire process start to finish, and we have worked examples on our Everpure GitHub repository that fully automate that process. Lastly, I'm gonna start Swing Bench up on my target database host. This demonstrates that we have a full and valid copy of our original source database. The process we demonstrated here was asynchronous snapshot replication, the
11:11
creation of a storage immutable snapshots upon demand or on a time schedule. The database might be in backup mode, or it might not. This is distinct from the continuous replication of active DR, which I will cover in another video.

Ready to connect?

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.

Personalize for Me
Steps Complete!
1
2
3
Continue where you left off
Personalize your Everpure experience
Select a challenge, or skip and build your own use case.
Future-proof virtualization 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 center power and space usage

Resource-efficient storage to improve data center utilization

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.
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
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 center + 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

  • Optimized 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

 

Virtualization
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?
Thinking...
Your personalized, guided path
Get started with resources based on your selections.
My Updates
No updates at this time.