00:06
Hi, everyone. This is Graham Thornton, Field Solution Architect at Everpure. And in this video, I'm gonna walk you through a quick demonstration of using an Everpure FlashArray to create a storage snapshot clone of an Oracle Database, and then immutable snapshots to recover the database from disaster recovery.
00:23
The Everpure FlashArray has the most powerful storage snapshot function of any storage platform. And what that means for Oracle Database is that we support both application-aware immutable snapshots, where the DBA would put the SQL Server into backup mode first snapshot, and then take it out again.
00:40
We also support crash consistent snapshots, where we don't put the database into backup SafeMode at all. Oracle Database is able to recover from crash consistent immutable snapshots because we support write ordering. So to the database, it just looks like you pulled the power out of the server, and all needs to do is execute an instance recovery using the online redo logs and maybe a bit of
01:01
the undo tablespace. Oracle MOS Note 604683.1 is a great resource here for DBAs. It explains how Oracle Database supports this process for compliant storage devices Everpure FlashArray is. In the example we are going to look at today, we are using Oracle Database.
01:19
Oracle Database is comprised of ASM disks, which are then grouped into ASM disk groups. Most production databases will use multiple ASM disk groups. Those ASM disks will typically map to volumes on a FlashArray, and we will volumes into a protection group that allows us to snapshot and replicate those volumes as a single logical entity.
01:41
When using Everpure FlashArray snapshots for your Oracle Database, it is usually good practice to ensure that all ASM disk groups used by the database are included into a single protection group. Of course, you might also use technology like VMware, and in that case, your ASM disks might actually be VMDK disks drawn from a VMFS datastore.
02:02
That VMFS datastore will then be based on one or more volumes on the FlashArray. In this example today, we are going to make a snapshot clone of the protection group of the volumes that comprise the ASM disk groups of our database. We are then going to corrupt the database and then use our immutable snapshots to recover production database from the snapshot, offering a fast and simple mechanism to
02:24
recover from disaster recovery. So let's take a look and see how this looks in our lab environment. We have a Oracle Database host set up running, pulling the volumes from an Everpure FlashArray. So if we go into Purity and click on the Storage tab and then the Volumes tab, we can
02:40
use the dialog box up here at the top to search for our volumes, GKE, and we can find the matching volumes right here. We'll click on the first one of those. And you can see that it is seventy-four 74 GB in size, about, seventeen point three to one data reduction ratio.
02:57
There are multiple copies of SwingBench on this FlashArray, hence the sort of slightly higher perhaps than expected data reduction. I see the serial number there ends in B28E. It is mapped to the VCF 01 workload cluster 1, which is our vSphere cluster VMware, and it's part of the RDM udev zero one PG protection group.
03:17
If I click on that, you can see the other member of that protection group, second volume right there. And these two volumes together are both STaaS disks, part of a two-disk ASM disk group under our Linux database server. Next, let's go and take a look in our KVDB host. So I'm gonna log into Oracle Database here.
03:38
This is Oracle Database single instance, but it's running with the Oracle restart have STaaS available as well. So logging into ASM, we're now going to take a look at the disk groups available for our database. And we have two disk groups.
03:55
There is a grid where we have the API for ASM and then a SwingData disk group, which is about a hundred and fifty GB with about nine point three GB currently, available. If we look at the disks, we can see that there are three disks. There's one for the grid disk group, and then there are two, those two seventy-four GB
04:13
volumes for the SwingData. You can see each one's got about four point six GB of free space on it. And if I look to see which databases or which instances are using which disk groups, we can see that Swing PRD is using the SwingData disk group. Next, let's take a look at the database.
04:31
I said it was called Pure Fusion. It is a SwingBench database. But for the purposes of this demonstration, I'm going to use the Scott Dietzen Tiger demonstration tables. We have the EMP table here with our fictitious employees and their salaries,
04:45
this is the table that I'm going to corrupt as part of this demonstration. So before we do anything else, let's take an immutable snapshot of our database. And since we want our snapshot to be application-aware, we're gonna put our database into hot backup mode first. So we'll log into the database, and we'll issue the alter database begin backup command.
05:04
And now we can go into Purity, go to our protection group that covers those two ASM volumes, and make a snapshot at the Purity storage level. So let's go ahead and name our snapshot. We'll call it, Swing Snap 1, and then we'll click the Create button. And we see the immutable snapshots now has shown up on the Purity interface,
05:27
right there on the screen. Going back to the Oracle Database host, we can now take our database out of backup mode it's important to try and keep that backup window as short as possible on a main production database for reasons of performance. Let's drop out of the database.
05:44
And next, we're going to use a little script here to find the Scott EMP table in our database and corrupt it. This is relying on a little Perl script called Find Block, which was written by Bane Radulovic some years ago. Pretty clever script, and we've adapted it now to find that block and then write JSON over
06:01
our ASM disk. This is not something a production DBA would typically do, but we're using it here for reasons of demonstration. So it's found our block. It's now written garbage over that block. And now if we go back into our database and try and select data from the Scott EMP table, Oracle Database will report corruption.
06:21
So now we can recover that database from the snapshot that we made just a minute ago. Now, before we can use the snapshot to recover our database, we are going to need to shut down the swing PRD database. So I'm gonna use the SRBCTL command to do that, and then I'm gonna go to ASM and I'm gonna unmount the swing data disk group, that is the disk group that has the corrupt block on it.
06:52
All right, our database is down and our ASM disk group is unmounted. We can now go to the Purity interface and find that immutable snapshots we made earlier in this demonstration. If we click on the snapshot, we see our two volumes, and we have this Restore Volume from Snapshot button in the interface.
07:09
It's warning us that it's going to overwrite the contents of the current volume, which is exactly what we want as it's corrupted. We're gonna restore both of the volumes. We'll click on the Close button, and now our ASM disk group should be restored to the point of the immutable snapshots. So now we can bring our swing data SAP HANA
07:28
disk group backup online, and then we can restart the swing PRD database. But remember, it was in hot backup mode when we made that snapshot, so we're gonna have to start it up to a mount state and then log into the database as SYS DBA, take the database out of hot backup mode, and then we can shut it down completely and then restart it in a fully open read-write state.
07:54
Now, I'm using a little video magic here to skip over some of the starting and stopping operations. They typically take between five and ten seconds each, but I'm skipping over that to make it appear instantaneous here in the video. Once we've restarted the database to a fully read-write state, we can log back in as the
08:12
Scott Dietzen, and we should be able to select from that emp table that was just a minute ago, corrupted. So logging in as user Scott Dietzen, we will do a SQL Server from the emp table, and now you can see that all of our data is back and our JSON file is, no longer corrupted. Now, in this video demonstration, we went through those Oracle Database commands one
08:39
and a typical production DBA would obviously script that. We have a rich library of scripts in our GitHub repository which you can use for your own purposes, and we also have a library of white papers that dives very deeply into many aspects of managing the Oracle Database. We can also help with workload analysis and proof of concepts.
08:58
And lastly, we have our online test drive labs where you can try all of this out. And that's all we have time for. I hope