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.