57:02 Webinar
No Downtime, No Surprises: Best Practices to De-Risk Oracle Database Storage
In this session, discover how organisations are eliminating those risks with infrastructure designed for continuous availability, predictable costs, and simplified operations.
This webinar first aired on 04 December 2025
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Hello, and welcome to, today's, tech talks, session. We really appreciate you taking the time out of your busy schedule and joining us, today. Our topic is around best practices to de-risk your Oracle Database storage. I'm Nihal Mirashi, product marketing manager here at, Pure Storage, and I'm joined with m- our Oracle, subject matter expert, Graham Thornton.
Graham, w- would you like to introduce yourself? Absolutely, yes. Thanks, Nihal. My name's Graham Thornton, database specialist at Pure Storage. Now, I'm not a storage guy, I'm a database, specialist, part of a team at Pure Storage that focuses on key workloads like Oracle, like SQL, and like SAP.
Awesome. Lovely to have you here, with us, Graham. So let's, get, things started. So I'm gonna set the stage. So, if we move on to the, the next slide. So I'm sure a lot of you are in the process of, adopting or
thinking about adopting modern workloads like SQL Server 2025 or Oracle, 20- 26 AI. And one of the key aspects as you look to modernizing or moving to these modern database workloads is the role of the underlying data infrastructure, specifically storage. And, there's a re- a number of reasons why modernization projects,
stall or, have issues, and it could be, due to the legacy storage, that, that has been there, it's been in your environment for a while. And as you look to adopting these modern workloads, it tends to be the, the bottleneck. You know, one aspect is around, you know, the aspect of the risk of downtime. You know, you cannot really, w- work with any kind of downtime.
When you have to, deal with multiday database migrations that are forced upon you because of the legacy storage that you have, that is that's a risk in itself. And a, an additional risk could come from data silos. You know, when you are dealing with, STaaS storage platforms that have to be dedicated to specific applications, or need multiple tools to manage the storage, that tends to be
another risk, to your modernization projects. Another risk is around refresh cycles. You know, when you have to do a forklift upgrade in order to get to the latest version of s- your storage platform, you know, that's gonna Or if you have to revalidate do any kind of retraining, all of that is gonna compound risk as you look to modernize
your database. And last but not least is any kind of delays, you know, where you have to, wait for weeks for storage to be provisioned, just for your app, you know, s- sourcing your new applications. That is gonna add, an additional layer of risk. So, this is something that, you know, Pure has taken into account, and we, we have,
looked at all of these issues, and we right, We're gonna share with you some best practices that can help you get past that. So, I'm gonna turn it over to Graham. You know, Graham, as you mentioned in your introduction, you're all about databases. So let's, let's, hear what, what kind of things that, we can, consider as we're
modernizing these databases. All right. Thanks, Nihal. Yes. So as my colleague here at Pure, Anthony Nonsantino, likes to say, it's all about the databases. Obviously, the industry very much at the moment is focused on things like machine
learning and AI/ML, but databases really underscore all of that. They are absolutely a critical part of our ecosystem and our infrastructure, and so keeping that squarely in mind as we make infrastructure decisions, I think is very important for all of our customers going forward. So here was one of our leading questions: Oracle environments online during upgrades and
migrations with resilient, non-disruptive infrastructure. This is one of the key points about the Pure Storage architecture. It's the idea that when you buy a Pure Storage array, you can continue to upgrade it almost indefinitely. This slide really sort of talks to some of the underlying architectures behind that.
The upgradable controllers and blades, the idea that you can take a FlashArray and pull out the controllers on it and replace them live, non-disruptively with newer ones. The back-end chassis are engineered for a 10-year lifespan or more, and that applies to both the FlashArray and the FlashBlade. And then the DFM, the Direct Flash Modules, where the data is actually stored.
Currently, we're shipping 150 TiB modules. Next year, we expect to ship 300 TiB modules. And again, you can non-disruptively upgrade from the originals to the latest ones as they become available. I like this slide very much.
This is proven in the real world, and this talks to a few of our customers that joined on with Pure back in the early days, the giddy days back of 2012, buying one of those FA320, the early FlashArrays. And some of them have gone non-disruptively, upgrading every three to f- three years or so, pulling in new controllers, putting in new DFMs, all the way through to today in 2025
with an X90 R5 with dramatically more capacity and dramatically more performance which they started out with. And all of it non-disruptively to the end applications.Now Harold was talking to me earlier and said, "You know, can we do a demonstration of a non-disruptive upgrade?" Remember, I'm a database guy.
I work with databases all day long. A non-disruptive upgrade demonstration from where I'm sitting is basically sitting still doing absolutely nothing whatsoever. So it would be a really boring demo for us DBAs. But that's actually really important because the one thing that we really don't like to do
is to have to move our databases from an old storage platform to a new storage platform every three to four years or so. It is a non-disruptive event. It requires a lot of planning. It requires a lot of testing, and we always also need to have a contingency plan in case
things don't go correctly. With Pure, all of that goes away. Once you put your databases onto a Pure FlashArray, you can basically leave them there indefinitely. There's not gonna be a requirement for us DBAs to ever have to move data around again.
Here's a quick, peek at the XL-R5 line. This one came out this year, the XL 170 R5. This system can deliver in excess of 1 point three million IOPS and throughput of sixty-three GB per second on the read. So an extremely high-performance system that can really handle all of the most demanding
workloads that an Oracle Database is likely to throw at it. Now, I do sometimes hear customers say to me, "Well, it's a dual controller architecture, correct?" Yes, and w- and we're really sort of concerned about that. In the past, some vendors have said you have to have four controllers or more to be truly enterprise ready. I think that's technical debt.
I think that's old thinking. And for example, I use the example of Singapore Airlines. The longest commercial air route in the world is Changi to, I believe, London or maybe it's New York. I'm sorry. Changi to, to New York, JFK.
It's the longest, commercial flight in the world, over sixteen hours, and they use an Airbus A350 two-engine aircraft to do that. Now, twenty years ago, that wouldn't have been possible. You would have had to have used a four-engine aircraft. But advances in technology mean that the two-engine design is now actually superior.
It is just as reliable as the four-engine design, and it is also considerably simpler. And it's that simplicity that I wanted to focus in on here. We're working with a customer right now that has got one of those older architectures, many, many engines, many, systems are, are, are quite, quite old in their architecture. And despite having multiple engine design, there are multitude single points of failures
throughout the overall application stack. This is a diagram of the current solution. And then when we move that onto Pure, we're able to eliminate so much of that complexity, take away that technical debt, and really simplify the entire process. So the hardware is just as reliable, but we've eliminated those single points of failure,
delivering a far more resilient solution that is going to be much easier, to work with going forward and far less likely to cause any kind of outages, than the existing stack that they have today. Now, another factor here is the idea of the, Pure Fusion. And we're working towards a concept that we call the Enterprise Data Cloud.
And the idea here is that we want to give you a cloud-like experience for you don't have to sit there and worry about creating LUNs or worrying which FlashArray they're going to sit on or can this FlashArray talk to my database servers. We want to give you more of a cloud-like experience, and part of that is the idea of presets.
When you create a preset, you can basically define what your database storage is going to look like at a macro level. How many volumes you're going to have, what protection groups they're going to be in. Is it going to be sitting on a, a, a tier zero storage platform or maybe a lower tier? Are you going to want to have automatic replication handled for you by the FlashArray?
Are you going to want snapshots created of your database, and if so, how frequently, and how long do you want to hold onto them for? You can set protection levels, quality of assurance levels. You can tag the workloads with various metadata tags so that you can read them later on, to get a better insight as to what's going on.
And you can bundle all of that into a preset, which then when you deploy it, will completely and faithfully replicate everything you've decided in a policy-driven fashion on the appropriate storage platform when you want it. Here's an example of comparing the preset approach versus the manual approach. All those steps basically become automatic, and you can then turn it into a turnkey
process whereby you deploy your database storage over and over again, with no variation between the deployments. No human error comes into the process. It's much simpler to manage going forward. What's more is you can also then do compliance reporting against this. So having defined your workload, you may subsequently decide that you
want to change something. Perhaps you want to change the number of volumes, or you want to change the replication schedule or the snapshot schedule. Well, what the pl- compliance reporting will do for you is then tell you any of the deployed workloads that do not comply with your revised, template, preset, and therefore allowing you to quickly identify where any deviations may occur.
Imagine, for example, that you have a primary database and a Data Guard standby. You add some volumes to the preset and to the primary side, but perhaps you forgot to add them to the standby side, a situation many DBAs have dealt with many, many times. The standby then might actually fail and fall behind. But the compliance reporting would catch that and tell you that there's another part of the
solution that you have to go and apply those, additional volumes, to. This all, as I said, feeds into the Enterprise Data Cloud, the idea that you don't have to worry about which FlashArray the volumes are going to land on. You don't have to worry about, if it's gonna connect to your host correctly. No, the EDC eventually will do all of that automatically.
You just to say how much storage you want for your database, which preset and it will then go and work out everything else for you entirely like a cloud-like experience.Most mission critical performance apps will also benefit from this. Here we've got in-memory databases over on the left. We have NoSQL databases on the right, and the most important relational databases right
there in the center with mission critical complex long, long-running queries and transactions and log write the bottlenecks down to microseconds in duration. So we've got a little demonstration right now where we're gonna show you workloads in action. So in this demonstration, we're gonna be showing you a feature of Pure Fusion, and that
is presets and workloads, which enable us to deliver rapid, storage provisioning for our databases. So we're gonna create a new preset here, and we can call this preset pretty much anything that we want. There can't be any spaces in the name, but we can choose pretty much whatever we want, and we're gonna give it a description of Oracle Workload Preset number one.
And then with our preset, we can add some optional parameters here. So we're gonna add a snapshot config. We're gonna make our storage snapshot hourly, create that every hour, and then keep it, those snapshots for one day and add that rule to the preset that we just, just created. Next, we're gonna add some replication to our new preset.
The replication will allow the snapshots to be replicated to a remote, Pure FlashArray. So here we've got a dropdown in our box for the FlashArrays in our fleet, and we're gonna pick out the, F06-33, and we're gonna call this rule Replicate. We're gonna replicate the snapshot every day at, one o'clock in the morning, and we're gonna keep those replicated snapshots around for another day, and then we'll add that rule
to our preset. There it goes. Next, we can define our workload type from the dropdown. So we'll pick Oracle, and we'll set the storage class to FlashArray//X. You see in the dropdown there, we have the choice between FlashArray
C, X, and FlashBlade. And then next, we're gonna put in our storage resources. So for our Oracle Database, we're gonna want six ASM data disks at ten GB each, we're gonna set using those, that disk group to use an hourly snapshot and use replicate rules that we just defined just a moment ago.
So now we can go ahead and create our preset. And now if we want to create a database, we can basically, create a new workload that will use that preset that we just created. So we can drop down, and we can pick it from our dropdown, say Continue, and it will suggest a, target array on which to put it on based on the criteria that
of the preset. So we'll call it Oracle Workload one. You'll see we've actually asked it for a recommendation. It will tell us what it thinks are the associate, appropriate, targets. And then we'll say, go ahead and create the workload. And that will now create, six volumes at ten GB each,
called Workload One. There it is. And it will already be set up with the snapshot, the protection groups and the replication already defined for us for our new, ASM disks. Now, we can already see that our new has been defined with two protection
the 5WZZD and the JJ249, protection groups. And it's the JJ249 which is being replicated over to the second FlashArray. So if we click on F06-33 and go to Protection and Snapshots, we can see that it has already replicated our six data volumes across, to this second FlashArray, giving us immediate storage protection for any databases that we deploy on this new workload.
By the way, if you're not actually familiar with what a protection group is, it's a way of allowing us to group a, a set of volumes together as a single logical entity. You can kind of think of it as like an ASM disk group, the way it relates to a bunch of ASM disks. Okay, so we've got our new volumes, our protection group, our replication and snapshot
set up. The next thing we wanna do is connect these volumes to the host that's going to use them. So we can click on the Connect button, highlight all the volumes, and select the, the virtualized workload cluster that we are going to actually present these volumes to. So as I said before, we're using a VMware cluster here for our database service.
So to present our storage, we could choose between vVoles, which unfortunately are being deprecated. We could use iSCSI, but in this case, we're gonna use RDMs, Raw Device Maps. So the first thing that we need to do is to find out what the actual volume IDs of our six new volumes are. And I'm using a little Python script here to
actually go ahead and pull those out from Purity. I'm gonna copy those volumes, and I'm going to now use another Python script to quickly add those to my Oracle Database server as RDMs. So here it runs through just to make sure that it can find those volumes. And next up, I can go ahead and add the execute flag to this script and have it go
ahead and map those six RDMs to that VM, which will now allow us to create our Oracle ASM disk groups upon the six new volumes. There we can now see the RDMs being added to the, to the VM guest. And then next, we're going to go into the VM guest, and we're gonna rescan the SCSI bus to make sure that it can actually see those six new volumes.
So I'm gonna log in as the root user. I'm gonna use another little shell script here that just quickly, forces a SCSI bus rescan. You can see it running through right there. And we're using ASM filter drivers on this Oracle host. I realize that filter drivers also are now being deprecated.
Those haven't got around to upgrading to ASM lib yet. But now if we run our device check, we can see that we have ten, we have, six new volumes at ten GB each. So the next job will now be to go ahead and create an ASM disk group upon those six new volumes.So we're gonna use the ASMCMD label command here to label
each of our six new volumes. Those are devices, SDB, SD, D, and then G, H, I, and J. So I'm just gonna jump ahead a little bit here in the video to, the point where we've got all six volumes labeled, and then I'm gonna use the AFDSCAN and LSDSK commands to show you
that we actually have those, six new volumes. Next, we're gonna connect to the Oracle ASM user and use the ASMCMA command, sorry, ASMCA command to actually go ahead and create a new disk group using those six new volumes. This is all very much standard Oracle ASM interaction just to provision our new storage. And that's it. We have a new ASM disk group.
But not only that, it is already being automatically snapshotted, for protection and also replicated to a second FlashArray. And in the next demonstration here, we're also gonna show you how you can use the Pure Snapshots to rapidly clone a database. Okay, so in this next demonstration, we're gonna show how to rapidly clone an Oracle
database from, let's say, a production system to a non-production system. This is the common use of the Pure SafeMode Snapshots technology. So once again, we'll show you the protection group. We've got a protection group set up here that bundles all of our volumes together in a single logical entity. It's called PRD01-PG.
We have a snapshot there that we made from an earlier demonstration, and we have another protection group here, called Dev01PG. So what we're gonna do is we're gonna snapshot clone, prod PG and then sync giving us a full read-writable clone of our database. So here we are on the Dev01 machine, and if I do a, device check, you can see that we have,
I think, multiple devices, on this, VM. That not found means that it's a VMFS it's a VMDK within a VMFS, whereas the two volumes, 74-GB volumes, are actual RDMs mapped from the Purity, from the Pure FlashArray. If I do an AFDSCAN and an AFD LSDSK, you can see that there's one disk, grid one, and it's
on SDC, which is a VMFS disk, not the RDMs coming in as E and F. So basically, there's two volumes here, and there's nothing on them. They're not even recognized as being ASM disks. So we're gonna use a little Python script here to help us out. The Python script's gonna do several things for us.
It's going to take our source database and put it into backup mode. It's then going to call the function to snapshot clone the volumes of the ASM disks of the source database. It's then gonna take that source database out of backup mode. It's going to map those, snapshot volumes onto the target protection group that I
a second ago, and then it's gonna bring the ASM disk groups online, and it's going to start the development database, which is now sitting on those clone disks. So you can see that that development database is now coming up. We've requested that the database be opened at the end of this process, and it's gonna go through and reset the target SP file.
The reason you would do this is you might, having cloned the database in the past, have changed the ASM disk group names, or maybe changed the database name, or done something else to it that might then mean that the fresh clone coming through would no longer start up. Maybe the SGA is too big or too different. So we're resetting the SP file on the target to match the source that we're
We gathered those in- that information from the source database. You can see it doing so there. Going into backup mode, coming out of backup mode, checking it got the snapshot we expected to see. We're tagging our snapshot with the snapshot time that we actually made it,
making sure that we have, the snapshot volumes. We are checking that our target instance is not running. We're not gonna clobber something that's already there. We're going to make sure that the, are not mounted, that we're gonna the development machine, and then we go ahead and sync the two snapshots
made from production over the volumes of development. And then when we do an AFDSCAN disks on the development machine, we actually see that there are, those two new, DR data zero zero and DR data zero one have now shown up as valid volumes on the development server. So we can go ahead and mount the ASM disk group, which is called ADR data, and then go
ahead and start the clone database, over on the development machine. We just cloned the entire database here, and the entire process, start to finish, took about, two minutes, maybe two and a half minutes, to complete. So that's a very, very fast database clone. That's certainly a lot faster than, for example, using an RMAN, backup and recovery.
Now, if I connect to the database as the famous Scott Tiger account and do a select star from the emp table, you can see that all of our data, is here. Okay, so one of the points of, of this presentation is to talk about recovering instantly from outages or data loss to maintain business continuity. DBAs really spend a lot of their time concerned about making sure that the database
will always be available and there'll be no outages. There's a whole hierarchy of technologies that you can use when we're thinking about data resiliency for our database. Starting at the top there with zero RPO, RTOs, ActiveCluster synchronous replication, the idea that you can take two FlashArrays and have them present to our databases as if they
were Evergreen//One. That way, an entire FlashArray could go offline, and your database wouldn't actually know. And when you combine that with technologies like ActiveCluster, that allows for a solution where essentially you have zero outages, even with entire, data centers can go offline.
Next is Active DR, continuous replication.Somewhat similar to how Data Guard works, but with some important differences that we'll dive into a little bit more in just a minute. Asynchronous replication, the idea that I can make a snapshot and then send it to another FlashArray anywhere in my, in my fleet, re-replicating my database very, very quickly.
Snapshot offload, where we can take a snapshot and then we can send it to a FlashArray, or even into the cloud. Local snapshots, obviously we can make Rapid clones of our databases instantly, taking up practically no space whatsoever. But none of this should ever be used, in place of a traditional backup.
We are still big supporters of using things like Oracle RMAN to make full, full copies, full backup set copies, or merge copies of our database for long-term and resilience. Another interesting point here on the FlashArray is this ability to watch the workload itself. Here's an interesting one. We can actually see if the data reduction of
the workload is changing in real time, such as if there was a ransomware attack being performed against the database. Haven't seen this yet with Oracle, but we have seen this with SQL Server, with Postgres, and with things like MySQL, where attackers have gone after the database as a way of, extracting data and trying to hold our customers, to, to ransomware.
The FlashArray can detect this in, and potentially advise our customers, to an attack in process, before it becomes, a major event. Simplify backup, recovery, and cloning for faster test and dev cycles. So let's talk about that a little bit more now, and next I'm gonna show you a demonstration of rapidly recovering an Oracle Database that's been corrupted using the
Pure Snapshot technology. Okay, in this next video we're gonna show you a quick Oracle Rapid Recovery Snapshot technology. So we've got an Oracle Database here, and we have it in a protection group called PRD01PG.
There's two volumes. These are, I think, about 74 GB each. Yep, they are indeed 74 GB. And there is an Oracle ASM disk group defined upon these two, Pure volumes. So what we're gonna do first is we're gonna go ahead and make a snapshot of that, protection group.
So we'll call this, November.26, and we'll give it a time, just give it a little bit of uniqueness. We don't want to apply retention or any replication to it. This is just a simple, straightforward snapshot. There it is. It's shown up in Purity for us.
If we click on it, we'll see that there are two volumes in it, as we would expect. Go ahead and close that out. And then going over to our database, we've got a, Scott, Tiger account over here. You would be familiar with that from, many years of working with, databases. This is a database called Swing DB.
It's actually part of a Swing bench database, but we've defined a Scott there as well. And so if we log in as, as Scott, user Scott, and we'll take a look at the famous emp table. There it is in all its glory. So next what we're gonna do is we're gonna corrupt that table.
We're gonna run a little, Python script here, sorry, a little Perl script here, that will actually corrupt, that block of the database. So we've got a little script here called Corrupt DB. It will go in, it will find where the Scott emp table is, and it will allow us to, corrupt, corrupt that, that, table, that block in the database.
So now if we go back into Oracle and try and select from the emp table again, we're gonna get an error, 'cause we've actually just written garbage, over the disks there. Scott Tiger, do a select star from emp. And now Oracle tells us that we've got corruption in our database. So what we can do is we can shut down the database, take the ASM disks offline, and then
we should be able to use our Purity snapshot to restore the database to the the corruption, allowing us to do a rapid recovery from a, from a, from, from a critical event. So database will shut down. Takes a second for Oracle to shut down here. There it goes. And next, we will connect to the ASM
instance and just, offline the, the disk group, for this database, which I think is called, DR Data. Take it offline. And now if we go back into Purity, we can click on our snapshot that we made earlier, and we can use the little, time icons over on the far right there to reset the volume to the point in time when that snapshot was made.
So we're restoring the volumes to the point where the snapshot was made. Remember, we've done both disks within the ASM disk group, so now we can bring that disk group back online. And then we'll be able to restart our database. If we connect to the right database, of course.
And we can do a startup. Takes a moment for Oracle to, to And now if we do a select star from the, Scott, emp table, we should now have a fully valid database once again. So we'll just connect to Scott Tiger and then do a select star from emp.
And we can see that all of our da- tables are back, and our database so the FlashArray supports two kinds of snapshots, the crash-consistent snapshot and the application-consistent snapshot. So what's the difference for our DBAs here? The crash-consistent basically means that Oracle was never in hot backup mode.
We basically went ahead and snapshotted the database without the, without the database ever entering into hot backup mode or leaving it. That can have important advantages for systems that are, are extremely high performance. And Oracle actually supports this. There is an entire MOS note, that talks about if the storage supports write ordering, then
Oracle will support a snapshot of the database made even if it wasn't in hot the Pure FlashArray does support write ordering. On the right-hand side, though, we have the application-consistent snapshot. That's the idea that the DB has put into backup mode first, then we take a snapshot, and then we come out of backup mode once the snapshot is completed.
And that backup mode for a snapshot is gonna last maybe a second, if that, so an extremely fast process, on that snapshot clone. What that means for us DBAs is that we are then free to roll that copy forward using archive logs until we read an SCN, or a number, or a date, or a, a log that we stop at, and then we can do an open reset logs at that point.
So data movement. We talked about volume snapshots. We also talked about Active DR, the idea that I can replicate, have the Pure FlashArray replicate my data from, the current location to another FlashArray on a almost synchronous basis. And then lastly, the ActiveCluster.
And as I mentioned that one already, that's the idea where you can have two FlashArrays appear to our database as if they are just one, and that, what that means is, is that one entire FlashArray could potentially fail and go offline, and our database will be unaffected by that. So that's for those situations where you need extremely high resilience,
for your end application. So I talked about ActiveCluster DR and how it's similar to Data Guard with some important differences. And oftentimes our DBAs will say, "Well, I've got Data Guard. I like Data Guard. I'm going to continue using Data Guard." And
we think that's absolutely the right decision t-t-to make. But there's also cases where Active DR can actually help, and, and what, what I'm gonna show you next is provisioning a Data Guard standby using snapshots and ActiveCluster to seed the database. Okay, so in this next video, we're going to show a use of the Pure Snapshot and replicate
functionality, to actually provision a Data Guard standby. So DBAs will often say to us, "I don't need replication. I've already got Data Guard to do it for me." And that's perfectly fine. We totally understand that, and Data Guard is a fine product. But there can be times when you want to rapidly provision a new Data Guard standby.
That might be just setting it up for the first time, or if you've had to do a failover and you don't have flashback logging enabled, then you have a new incarnation number, and you're gonna have to re-seed the old database to create the new standby following that failover event. So in this example, we've got our protection group here, PRD01, and we have a target for
that protection group of F0633. So I'm gonna go ahead and make a new snapshot, and I'm gonna replicate my target, to that other FlashArray, so that when the snapshot is created, it will actually get sent over automatically, to the second FlashArray. If I go into Protection and click on Snapshots, I can now see that my two volumes in my
protection group have shown up here as snapshots on the target array. So I'll take my database out of backup mode now that I've made the snapshot of that database and I've replicated it to the second FlashArray. And then what I'm gonna do is I have a target, protection group for my DR database that I've already got set up over here.
So if I go ahead and find that, and matching number of volumes of matching sizes, in the second protection group. It's called DR01-PG. And next what I'm gonna want to do is to just go ahead and find the volumes in that, development protection group.
These are the volumes that I'm going to sync my snapshot to. So I've got two product- two volumes on production, I got two volumes on the DR side, and I'm going to sync that snapshot to the, the DR protection group. So the two volumes are shown there. They're hundred and twenty GB each.
And then next what I'm gonna want to do is I'm gonna go and find the snapshot on the target FlashArray. So this is the FA33 FlashArray. There's the November 26, 16:24 snapshot, and we've got our snapshot, which I'm gonna call my source.
I've got my DR protection group, which is my target, and I'm going to now sync those volumes from the source snapshot to the target protection group, thereby overwriting any content that was already on there and giving me a full clone of the database from production onto the DR server. Now that I've cloned the disk groups, I can bring the ADR disk group
online on the DR01 machine. This is our disaster recovery machine. And now I can start up my clone database, but I'm gonna start it up to a no-mount state. Actually, you know what? I'm gonna start it up to a mount state, and then I'm going to create a standby control file off the clone database.
So now with my clone started, I can issue the, alter database create standby control file command. And now I can go into, ASM and go find that standby control file that we just created. So I'm gonna use the, ASM CMD command and basically issue the, the find command to go
find that, new control file that we just created. There it is. It's found it for us. And now what we're gonna do is we're going to update our control file's parameter on the DR clone to point at the backup control file that we just made. Obviously, we have to give that a scope=spfile.There's a couple more things that
we also need to do with our soon-to-be, Data Guard Standby. We need to change the DB unique name. It can't be the same as the source database, and we should also change because that also has come across from the production clone that we just made, and we don't want it pointing at the wrong listener.
So we'll go ahead and change that to the local listener here on the DR01 server, so that there's no conflict. So next, we're going to shut down our clone database here on the DR01 machine so we can actually honor those changes that we've just made to the SP file. And then when we've done that, we can add the standby, redo logs.
Those will be the logs that the Data Guard system will write into, depending on how we actually have the replication set up. So let's just go ahead and shut down the database that we've just cloned. Takes a second for the database to go down. We'll bring it back up, with a startup nomount command, of course.
This is now a Data Guard Standby. Remember, we changed the control files. So now we're gonna have to do an alter database mount standby database command, so that Oracle recognizes that this is, in fact, a, a standby database and it is not a, a full rewritable production clone.
Now we can go ahead and add those standby log files, and we've added redo group plus one as Oracle recommends. And lastly, we'll also set the, standby file management to automatic, and that's, a change that we can do on the fly. We don't have to bounce the instance for that to take effect.
Okay, so we've cloned our database from production over to our development machine. We have changed the control files to control files, and we've added the files on there as well. We changed the local listener, and we've set the DB unique name. Next, we want to actually, start the Data Guard shipping process, so we've got a couple
of scripts set up here to help us do that. This is the Data Guard on for the, the, the DR side of the, of the fence. And then over on the production machine that we cloned from, we're going to kind of repeat the same process. So what we're doing here is we're setting things like the file
server and the file client. We're setting the, the secondary archive location to point at our And what I'll do now is I'll just, tail the alert log of the, database, on the da- on the DR01 machine. Now, if I do an alter system switch log file, you'll see that the alert log of our standby
is acknowledging the fact that a ar- an archive log has been sent over from the production machine. Now let's log in another session on the DR01 machine. Remember, this is our Data Guard Standby that we've started up. We've set up as a Data Guard Standby.
We have now shipped a log across, but we haven't actually put it into recovery mode yet. So let's issue a recover managed standby database disconnect from session against the Data Guard Standby that we just created using a snapshot clone. And now as we kick that process off, you can see that Oracle is now r- rolling the standby database forward, using Data Guard to manage the process.
So we basically used the Pure Snapshot, replication functionality to very rapidly create a Data Guard Standby on a second machine, and then we've had Data Guard take over, the care and feeding of that snapshot on an ongoing basis, allowing us to, create and recreate Data Guard Standbys, very, very quickly. And I'll just show you what's actually in that, DG on script.
There it is. It's got the setting the archive dest and the format, setting the file server and client. There's also a couple more things in there, parallel execution message size management, automatic, and then setting, the, standby database to maximum availability. Of course, that's entirely the DBA's choice as to how you want to set that up.
And the one for production is basically the same thing. A few things are a little bit different. The file and the, file server and file client are, of course, reversed here. That's in case we Everpure wanted to reverse the flow, you know, do a switch over to the standby, and it would then archive in the opposite direction.
So there you go, a Data Guard Standby in eight minutes. So when we talk about the Pure Snapshot and replication technology, it allows us to start to realize that three-two-one-one architecture for Oracle Database in practice. And here on the slide, I've got some examples of how you might use the Pure FlashArray and FlashBlade technology to deliver that ig- that very high level of availability, very
similar to how Oracle Database defines the massively available architecture, for the engineered systems. This is a la carte. You do not need to have everything in the, in the diagram. But you could if you wanted to be fully, protected against all conceivable outages,
achieve that using this combination or a similar combination of Pure solutions. So I talked about how the snapshot technology and the replication important for our Oracle DBAs, but how none of it should ever be considered as a replacement for an ultimate RMAN backup of our DB. I think we, as DBAs, still want to have that level of protection, and
to do granular restores, for example, recovering a single block or a single table, a tablespace. Very much a, a powerful tool that every DBA wants to be able to use. But RMAN can also be a major drag on a performance system. It generates a lot of IO traffic.
So in our next demonstration, I'm gonna show you how to offload the RMAN backup to a snapshot clone of the database and then use that to recover a corrupted database.So in this next video we're gonna show offloading an RMAN backup by running that RMAN backup from a snapshot made with the Pure Snapshot technology.
This is a fairly common use of snapshots. It allows DBAs to offload the RMAN backups from the production machine onto a different machine, and therefore free up, capacity for the production workloads. So we're gonna use a Python script here to snapshot clone the production database. This Python script does several things for us.
It puts a source database into backup mode, it makes a snapshot, it comes out of backup mode, it then syncs the snapshot to target volumes on the non-production machine, then mount that clone of the production database in a state suitable for running an RMAN backup. So of course, we don't want to open our clone in this example. We want to bring the database
up to a mounted state. We're also gonna reset our SP file to make sure that it matches the production machine so our database will come up cleanly in a mounted state, and in a state suitable for running an RMAN backup. Now that we have our clone database up and mounted on the non-production machine, we can run RMAN to backup the database.
We're backing this up to, an RMAN backup set, sitting on an NFS mount, that was accessible from our, from both the production machine and also from the machine on which our clone of the database is actually, running. So now what we can do is we can test this out, so we're gonna corrupt our production database.
And this is a, a script, a corn shell script, that actually calls a Perl script that was written, I think, originally by Bane, Radulovic. It finds the block of the Scott, emp table, and it, corrupts it so that if we now go in and select from the Scott emp table, Oracle will tell us that the table is now corrupted. And this is where we are now going to use the backup of the database made on a
machine, to actually recover, the database. So if I go into RMAN on production and ask it to tell me my backups, it will tell us we don't have any 'cause it doesn't know about them. But then what we can do is we can catalog, the backup that was made on the clone of the database, that was made from a snapshot clone of
the production machine. So we'll go ahead and catalog those files that are sitting on that NFS mount. It's obviously called out the, the 1touch file here. That was just me touching a file to make sure that I had the right permissions. That's not actually an RMAN backup set file, so don't worry about that.
And now if we list our backup of the database, we can see that, backups now exist. It's found those backups that we made on the, snapshot clone, and we can now use those, that, that cloned, that, that cataloged database, that cataloged recovery, to now go ahead and, recover our database. So we're gonna offline the Scott tablespace, we're gonna tell RMAN to recover the corrupted blocks, and now the Recovery
Manager is complete. And now if I go back in as Scott Tiger, I can select from the emp table. So there we have it, offloading an RMAN backup from a snapshot clone. All right, Nihal, back to you. Thanks, Graham. Really awesome, awesome information and
awesome, demos. We wanna continue the conversation beyond the Stack Talks, and I wanted to share with, all of you some of the ways that we would love to continue this, this conversation. We have a Pure community, and, we've provided a link and the QR code so that you can join the Pure community.
We have great, conversational, conversations happening in the Pure community with, with not only experts from Pure, but also some of your peers. There's a dedicated databases section, so I'd really encourage everyone to, check this out, and, and sign up and be notified when new, new discussion topics are, are posted. So this is, this is one way.
If we move on to the, the next slide, we also have, public GitHub, repository, and there's some, some great examples that are posted on the GitHub repository, copied around, copied, data dev management, volume management, and some of the, ways you can get, metrics. So really encourage you to check out our GitHub, repository, try some of the, the,
samples that are, are posted here, and do let us know your, your feedback on, on these, examples. So this is the second way. The third way, if we move on to the next slide, it- I just want to just Oh, yeah, yeah. Please go ahead if you're looking for any of
the Python scripts that you saw in the demonstration, you should find them on that, on that code repository. So thanks for calling that one out. Perfect. Yeah. And, and so, in addition to that, we also have content that is a much, deeper dive.
We have a dedicated, Pure, solutions page for Oracle, and you'll see some of these, deeper dive, white papers, posted on the solutions page. I, I will provide you with a, a link and a QR code for, for the page. So, this is one way that we are providing, details on the different aspects of data management for, for Oracle.
In addition to that, we also have a lunch and learns, Demo Hub sessions, ways that we would love t- to share with you some of the, the best practices in, using, Pure for Oracle, environments. And, in addition to all of this, if we move on to the, the next slide, our experts can engage with you on proof of concepts, that would be in your
environment and can demonstrate, uhYou know how Pure is being able to solve some of your pain points for your Oracle environment. So, for this activity, I would encourage you to talk to your Pure, sales account team and, and learn how you, we can help you and assist in setting up that proof of concept in your environment.
And last but not the least, if you, are still in the process of kicking, kicking the tires, one great way to do that is through our Pure Storage, Test Drive. So, it does not require any kind of infrastructure set up on yours- on your side. All you have to do is sign up for Test Drive and, and we have specific modules, and we have specific, ways you, you can try out features, some of the features that
covered in his section. And it's a, it's a great way to just try things out and kick the tires and, and just, just get comfortable with, the Pure Storage So, looking forward to continuing the, the conversation with you. And speaking of that, I've been Graham, you've been, presenting, I've been monitoring
the, the questions. I see a bunch of great questions that have already come in. Would encourage everyone, if you haven't had a chance to ask your questions, please, submit your questions. And if, you know, we have limited time, but if we are not able to get to all of the questions, we'll, we'll still be able
to, get to you offline. So, let's keep the conversation going. All right. So, looking through the, the questions, the first question that came in, very interesting question. We all, we all know that Oracle redo generation can be extremely bursty.
So the, so the question is, how does Pure's Async replication and Active DR actually handle these larger redo b-burst while preserving, RPO objectives? That's a, that's a great question. Obviously, one critical to DBAs, right? When we're replicating a database, how do we handle bursts in workloads?
The, what the DR will do is it will actually allow the standby to fall a little bit behind. It's very similar to Active, to, to Data Guard's maximum availability mode. So in Data Guard, you've got maximum protection mode. You basically create synchronous copies, and in that scenario, the secondary copy would slow down primary.
As well as DBAs, we, we very rarely want to do that. There's also the maximum protection mode, which basically, you know, that can go as fast as it possibly can, and who cares about the standby? Active DR is similar to a maximum availability. It's gonna keep it as close as it can, but it's not going to allow that replica copy to
slow down the primary. So if there is a burst in redo activity, if there's a burst in writes, then there may be a, a lag opens up between the two systems, and you can monitor that from the Purity interface. Awesome. Yeah. That, that's, great information, Graham. Another question that's come in is around, the immutably, immutability
mechanisms that we have. So, like, what kind of controls or time logs, are enforced on FlashArray to protect, Oracle RPO objectives? Yeah. Another in- another great question, and certainly, you know, top of mind, we've ransomware attackers go after backups
after snapshot copies of databases in order to try and maximize, the attack, that they're performing on customers. So with the Pure Snapshots, the Pure Snapshots themselves are, by definition, And that's a little bit of a difference from the way that many of our competitors do it. When you make a snapshot of a volume or in case of Oracle, let's say an ASM disk, that
snapshot itself is not mountable to a target host. As you saw in the demonstrations, I had to make a snapshot and then sync it to a secondary volume of equal or greater size that can then be mounted and presented to a host to create a rewritable database. So that snapshot itself is not writable.
But there's an interesting other point to this. When you delete that snapshot, it goes into what we call an eradication bucket, and we didn't talk about this in the demonstration. But the eradication bucket is kinda like the redo bin. It's like the recycle bin. And it will stay in there until it expires or
unless you go in there and manually eradicate what you have deleted. And by the way, that applies to snapshots, and it also applies to volumes. Now, what you might say to me, though, the ransomware attacker may have compromised the credentials to my FlashArray. What if they go into the eradication bucket?
What if they delete that snapshot, they delete those volumes? There is an option in the FlashArray called SafeMode. And in SafeMode, you can define how long things must stay in the eradication bucket. They cannot be deleted even if you have root level access. In fact, the only way to get rid of in the eradication queue prior to its expiry
date, if SafeMode is enabled, is to call back into Pure support, who will then have two authorized users, who will then have to agree that those objects can be deleted. So if you are in a situation where you want to be absolutely certain that nobody can prematurely delete your data, your snapshots, or the volumes, then SafeMode is an absolutely critical technology to do that.
Great question. Awesome. And I think, we have time for one more question. Obviously, performance is table stakes. So the question is, what isolation of service mechanisms does Pure use to keep Oracle log writer latency predictable, even when, you're running any kind of dev test,
clones or any kind of, other workloads on the, on the same system? Yeah, that's a great question. Obviously, as you say, right, performance is top of mind for Oracle DBAs, and you in the slide on the FlashArray//XL5, and twenty microseconds of latency, consistently off that platform. So performance is very important, but what you may also recall from when we did the, the
preset workload demonstration is that, there is that ability to set quality of service controls on my, on my storage. So I can, I can define how much noise a volume group can make. So what you could do is if, for example, if you're going to commingle production, non-production workloads on the same FlashArray, which many, many customers do
exactly that, you can then set quality of service controls on the non-production workloads to ensure that they cannot exceed certain thresholds. So for example, if you DBAs give your developers access to, like, SQL Developer and they go and run a multimillion row Cartesian joint product on the dev won't impact the production system by swamping the IO channels.
So that's a very important technology there to use for that purpose. Awesome. Well, that's all the time we have for, questions today. But, like I said, we'd love to continue the conversation with you. Graham, thank you so much for, sharing your expertise.
And I'll leave you on the next slide with, a QR code, which, is, a link to basically our Pure Storage Solutions webpage for Oracle. So, there's a wealth of information on that, on that webpage. We have, videos. We have white papers.
We have, solution briefs, as well as links to some of the previous, Tech Talk that we have, recorded and are available. So encourage everyone to check that out. We hope this Tech Talk session has been helpful in, in your journey to, m-modern workloads and looking forward to continuing the, the conversation with you.
Thank you so much. Thanks, everyone.
Nihal Mirashi
Senior Product Marketing Manager, Everpure
Graham Thornton
Consulting Field Solutions Architect, Databases, Everpure
Modernising Oracle database infrastructure is essential for performance and agility, but legacy storage often turns upgrades, migrations, and refreshes into high-risk projects. In this session, discover how organisations are eliminating those risks with infrastructure designed for continuous availability, predictable costs, and simplified operations.
Key takeaways:
- Keep Oracle environments online during upgrades and migrations with resilient, non-disruptive infrastructure.
- Recover instantly from outages or data loss to maintain business continuity.
- Simplify backup, recovery, and cloning for faster test and dev cycles.
- Ensure consistent performance and scalability across on-premises and hybrid cloud environments.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.