58:46 Webinar
Oracle Resiliency: Choosing the Right Data Protection Approach for Every Failure
This session explains where each data protection layer does and doesn’t belong in an Oracle recovery architecture. Through practical failure scenarios, we’ll examine how to align RPO, RTO, retention, availability, and recovery-location requirements with the right recovery mechanism.
This webinar first aired on October 1, 2026
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, everybody, and welcome to another edition of Tech Talks. I'm your host, per usual, Jason Langer, and then today we're gonna be talking about Oracle Resiliency: Choosing the Right Data Protection Approach for Every Failure. Before we get started, though, I just wanna cover a little housecleaning items. Please, if you have any questions throughout the presentation, we want this to be as
interactive as possible, go ahead and throw them in the Q&A panel or throw them in the chat. We, we'll do our best to answer them live as we go through or, depending on, how our presenter's going, I might kinda queue them up towards the end. But please put them in there, we'll definitely do our best to approach them or get those answered.
And additionally, if you stick around, we are doing a raffle, so if you hang out towards the end of the, the webinar, you will be enter You're, you're entered to win now, but you do have a chance of actually winning the prize, and watch the chat for that. My good friend, Producer Laura, will be putting draments, or comments in there on who the winner is. But with all of that out of the way, let's go
ahead and get to our today's presenter and today's topic. I'm happy to introduce Mr. Lester Wells. Lester, do you wanna go ahead and give everybody a nice little intro about who you are, why you're here, and what do you do at Everpure? Thanks, Jason.
My name's Lester Wells. I am a field solution architect, Oracle specialist, a, a database whipping boy, a, master of all, a, guy who's been playing with Oracle database for a long time. Hopefully I've grayed out the three around decade enough to where you can't see that it's
been a very, very long time. I've worked with on, or for Oracle quite a while, but it gives me, a, a, a lot of experience from version six on up. And what I get to do here, it's, it's, it's a lot of fun because I get to make sure that, we keep the database focus on the hardware solutions, right?
We wanna make sure that it's not just the blinky lights in the data center, it's how does, make sure that we solve your database problems with hardware refresh. Perfect. Man, I love this, play on words with your graphic here of the Oracle of Oracle. The Oracle. So that's- Right like, like a g- a, a game
recognizes game, so I appreciate that, Lester. Yeah. Yes. So what I wanted to do today is I wanted to, talk Oracle, talk resiliency, and more importantly, I wanted to make sure that we talked about the database. Gonna go into some detail here about the architecture of the database.
No, we're not gonna do that. We're gonna talk about resiliency and reliability, right? You, you have discussions around databases and, hardware allows the infrastructure to go fast, right? We have the ability to provide performance to our end users, our customers, and,
that's a common challenge in day-to-day operations. But when it comes down to it, one of the biggest challenges for our businesses, for us as IT professionals, is making sure that the lights stay on, right? Right. Making sure that the in, in the event of a pro- a crisis, of a problem, we can
protect as much of our data and get our business operating as quickly as possible. That's, that's the nuts and bolts of it, right? We want to stay resilient and be reliable and, and keep our jobs. So that's what we're gonna talk about.
I wanna make sure that we make s- we, we identify the two differences, right? It's high availability and it's disaster recovery. Yeah. And there's a lot of different layers in this onion that we need to peel back.
It's, it's too easy to think you have one, you don't need the other, or within one you take care of one part of it, and that's all you need to do. So, especially within Oracle, we have to look at it from many different le- levels. Yeah. It's definitely, they're two different
outcomes, right? Like, it's, they're two different- Right I wanna say features, but they're two, they're two different kind of functionalities or business impacts with different outcomes based off what you're looking for. And one, they have a little bit of overlap if you looked at a Venn diagram, but they're very much very separate.
They are. They, they, they're very necessary. You, you can do one, some systems don't require, all of the different levels of one or the other, but you have to address both. Absolutely. Yeah. Right? High availability in data center.
Disaster recovery across data centers. So that's what we're gonna look at. You, you address both of these, and what do you get into? You're talking about continuous availability as you go up the graph, right? Continuous data protection.
Do all of your databases, do all of your systems need to keep going up? No, and that's one of the key aspects to the discussions I have with- Had with customers over the many, many years is it's the tier zero to through tier four type of databases, where do they fit in this chart, and, and how do you implement the different levels? But when you look at doing your tier zero, tier one type databases and the
continuous availability and the continuous protection, that's where you get into your zero RPO and zero RTO where you lose no data, no operational time recovery. That's the key to full business continuity, right? So, not, not gonna focus on just that because it's, it's not It doesn't have to be
just that. There's- Right complexity and cost to those that are tier three, tier four databases don't have to have. But you, you talk about backups. All of our systems need backups, but backups present their own challenges now too. I've, I've worked with customers where, their change rate on their databases, their daily
change rate exceeds 60%. Wow. Now, think about when you talk about database backups, Oracle RMAN database backups, you have a weekly full and daily incrementals on these database backups. If your da- daily change rate is over 60%, think about all the archive logs that are
going into those incrementals, and if you had a failure on the third or fourth day, for example, how many logs are having to be applied to that full backup, and how long, that recovery's gonna take, and what the opportunity for failure in that recovery's gonna be. And that's just, your RTO on that is just, enormous.
And the, the customers that I've worked with with those kind of change rates, they, they just, it's not a sustainable backup model. So you have to change your backup, workflow, your runbooks when you're, when you're starting to deal with that. And then you look at the backups that started these whole SLAs that are in place when they
started with a two, 300, gigabyte database, and now their databases are two, 300 terabytes, and the SLAs haven't changed to match the increase in their database size. So your, your whole backup challenges exist on the growth of data, the growth of workload, and the, the need to backup
additional databases. You'd think that your n- just real quick for the chat. Did he freeze for just me or for anybody else? Couple minutes. Anybody can put in the chat. What's that? Oh, you, you hung for about a good 10 seconds,
I think, at least on my side. Yeah, yeah. I just got a notification. Oh, okay. We are, we are in a, terrible storm here in Dallas. If anybody online is in Dallas- Oh, no.
Okay they know exactly what's happened. So I apologize for that. Yeah, no worries. No worries. I just was like, I don't know if it w- I was like, is it me, or is it you guys? No, no. It's, it's the fact that I've gotten three and
a half inches of rain this morning. Yeah. So- This shows we're doing it live too. That's right. It's, it's an opportunity. So how do you supplement it? Well, snapshots.
You think about how can I supplement my backups and reduce my recovery times, with snapshots? Snapshots can be used for a lot of things, right? But can you supplement your backup strategy with them, right? Absolutely. But snapshots aren't something that go off the array.
They're like a logical backup, if you will. You can use them for test dev refreshes. You can use them for, cyber protection. You can use them for a lot of things. But, if you will humor me for a minute in
thinking of all the different ways you can use your snapshots. Snapshots can be done in a matter of minutes, regardless of the size of the database. Think of the number of data files you have in the database. You can still create snapshots of your prod database non-disruptively and make so many uses of these snapshots.
I've had customers, very large customers, create hourly snapshots of their database for logical backups of their database in the event with high change rates, in the event that they had a problem, and then they mount their last snapshot of the day, and they backup that mount, all so they don't have any impact on their prod database, and their backup window SLA is much easier to keep.
So just one idea. You have executives, want their morning reports. Snapshot it, mount it, create the reports on it. There's no heavy, queries going against your prod database to create the reports. And as long as a five-minute,
staleness between prod and reporting is okay, then yours- your executive reports can run off of this. It's a very easy way to look at, using snaps all over your ecosystem. Yeah, one thing I want to add to that, Lester, is- Yeah you, you know, I'm looking at the screen and the slide. The one thing that we, that I wanna hint on is
these are also basically instantaneous. Instantaneous. Yeah, from a speed. So I don't, I wa- Speed is, you know, you've got the no wasted space, the automation, which is all important, don't get me wrong, I get it. But I also wanna call out, like, for folks that maybe they're not used to using a Pure
array, or maybe they're an Oracle folk that they know they're running on Pure, but they're not leveraging this. Like, these are It's like snapping a finger. It's that instance, 'cause we're doing, we're, we're using metadata pointers, stuff like that. So I, I do wanna call it, like, it's fa- The overhead is next to nothing. They're, they're almost immediate, you know?
And so you're It's not like you're gonna take the snap and you're gonna wait five minutes or 10 minutes or whatever. It's just gonna basically be as fast as you can click the mouse button or whatever to say, "Okay, do the snap," it's gonna be done, so. You're right, Jason. It takes longer to start up the database- Right than it does to create the snap, right?
Yeah. Near zero space consumed for them, and the, the starting of the database is what takes time. Yeah. That's the only thing that takes time. Yeah, you're not gonna be waiting on the storage, let's just put it that way. Nope, you are not. You are not.
So we're talking about resiliency but, you know, I'm mentioning all these other options. This area here in the snap diagram, this is where I want you to realize this is where you're able to protect your s- your environment. But that's just an example of snaps. What I wanna get into here is thinking about ActiveClusters and
active DR, right? This is at the storage level. This is with- within Everpure FlashArray, taking protection below the Oracle level into the hardware, how we can extend protection and resiliency, in the Oracle environment.
So I'm gonna get into this a little bit more, how we can use HA in the hardware for zero RPO/RTO, in an HA solution for continuity, and near zero asynchronous replication for your standby implementation, right? So we talked about, HA and DR being two unique, distinct,
necessary solutions working together here for Oracle, but in the Everpure FlashArray, hardware. Yeah, and just Sorry, Lester. I just, again, I- I try to think of the audience, and maybe folks can put in the chat if we've got existing customers or people that are looking into it.
I just wanna hit on the, the ActiveCluster and the active DR. If you're using FlashArray or you're looking at FlashArray, everything that Lester's gonna talk about here, even including the snapshots we mentioned before, it's all included. So there's no additional licensing. So I just kind of want to level set there, Lester, like, just in case
somebody's not familiar. It is. It's like, it's not like if I'm an Oracle cat, I'm like, "Oh, these are really great, now I gotta go get a PO or talk to my storage team to go, you know, purchase these things or get a license key." If you've got a FlashArray or you're looking at FlashArray, th- these features are, you know, they're included. Free gift with purchase, I like to say.
So, um- Yeah just wanted to level set there, Lester. Sorry. It's a bargain at twice the price, right? Yeah, right, right. Right. So with that, let's go ahead and see notes from the field, like how this is actually put to use. So sorry, Lester, go right, go right ahead.
No, that's fine. Thank you. Yeah. So HA, we're gonna get into the HA side, right? Solutions around HA. We have to look at HA at the Oracle level, at the compute level, and that's Oracle RAC, right?
Oracle RAC, it's, not inexpensive, I guess that's the nicest way to put it, but it is effective, right? It provides high availability at the database level, at the compute level. It is a horizontal scalable solution. And it gives you that, performance and s- availability at the
compute layer, right? It's, it introduces complexity and administration, and depending on the applications that the database is serving up, it can really improve, resiliency for your application and end users. However, comma, exclamation point- what it doesn't do is it doesn't protect
you in the event of, data center, your RAC failing, your data center failing, storage failing. Because all of this, the, the power of this is it uses shared storage, right? So if you have anything in the infrastructure side fail, below the compute, RAC fails, right?
There's a, there's a dependency there that, exposes Oracle RAC. So what we can do there, that's where ActiveCluster comes in and protects, protects you and your ecosystem, right? We are able to put two FlashArrays, whether it's in the same data center on two, two RACs, on each separate side of the data center,
or it's in two data centers within a, a 11 millisecond RTT or round trip, time latency. Mm-hmm. That's the latency threshold it needs to be in. As long as that time threshold is met, you can sp- you can stretch these out all you want. What you're doing at this point is you're r-
synchronously writing the data across the two FlashArray nodes, which is what we have here with the pretty lines blinking back and forth. So the FlashArrays are writing. Now you can extend your Oracle RAC. Think about this, right?
Get the little brain going here. I have RAC nodes on both sides. The cluster interconnect, the Oracle cluster interconnect is communicating between the nodes. Now, this means that Oracle RAC nodes knows that these servers are on each side, and it's
sharing data at the memory level on each side. So we're writing down here, we're writing down here, and you can even have them write across here. So you've got full stretched RAC cluster, so in the event of a failure, Oracle RAC doesn't know or doesn't care which side goes down, when, or for
how long, because the other side just continues to operate. Pause for effect, right? This has got a very high coolness factor. Dramatic pause. Right? Dramatic pause.
This is true R- zero RPO, RTO. Nobody is interrupted in working on your Oracle RAC cluster databases if a entire data center goes down over here. This guy keeps going. No data is lost.
Everything's operational. Yeah, and I want to hit on, Lester, you talked about the, the r- the network requirements between the, the FlashArrays. And so from a use case perspective, you kind of touched on a little bit, but you know, for folks on the call, think about this, as somebody that's done a lot of this in a
previous life. Think of this as like if you're on a campus or if you're a hospital or education, like, because again, the network connections, right? Like, the, the, the 11 milliseconds is, I mean, you're, you're basically within the same, I will say, geographical region, but even smaller than that. But like- Yeah like you said, even in the same data center, I've had customers where they do
this i- Yeah maybe it's in the same data center, but it's in row one, rack one, to row 10, you know, rack one or whatever, right? So just think about there's a lot of different ways to implement this, both within the same denis- data center or within your, I'll just say, the campus, for lack of a better word- Yeah where, you know, you've got that network requirement, so.
Yeah, because, I mean, you think about it, y- you're talking the same campus or, or, eh, tens of miles is typically- Yeah what you're gonna get- Yeah 11 milliseconds out of, right? And, and DR compliance is usually saying you gotta be at least 100 miles, right?
Th- so that's what, that's what we're looking at here. This works very well for getting you separated in the event that you have a RAC failure or you have this room, shut down 'cause the, the cooler, broke. Yeah. And then the other room takes over, and you're, you're continuing to operate.
But, when you've got to go to DR distances, this, this just won't work. Yeah. This keeps you operating in, in that campus setting. Yep. Jason was spot on with that. Right? Fire, flames, bad.
Cluster interconnect takes over, right? So they write to each other, everything's good. So now we go to DR, right? We're talking about asynchronous replication, synchronous replication. What are your RPOs and RTOs in the event of a failure and your overall DR,
solutions, right? That's what we, that's what we look at here. And the solutions here are many, and they're varied, and you've got a lot of things to consider with, DR. The, one of the most common at the Oracle level is Data Guard, right?
Data Guard, Data Guard's great. I used Data Guard for many years. Data Guard in and of itself is, free as well. Now Oracle, introduced Active Data Guard to extend the functionality of Data Guard, and they charge a decent amount of money for Active Data Guard.
There's Golden Gate, which is, a not free option as well. But popular, common Data Guard. It works, and it works well. It does redo transport, so your redo logs, sized properly, five or so an hour, transports those over to your standby, which is in read-only mode, applies the redo
logs to your standby database. You're protected. Everything's great, right? 15, 20 minute, RPO, because that's what's being transported over. That would be your, your potential loss, maximum loss. But this works very well.
Data Guard, n- nice thing about it is your database can write to, like, 10 different databases at once, all sorts of different strategies, max protection, max availability, max all sorts of different, settings in there to make Data Guard flexible. Challenges with Data Guard is Data Guard is latency sensitive. Data Guard manages, you manage Data Guard
database at a time. If you have more than one database In your business, which I think everybody does, then you're managing multiple replication implementations of Data Guard for your business. Now, that's not necessarily the funnest thing to do, right?
You've got other things to do in your day-to-day operations. So the other thing about Data Guard, and you have to think about this, is Data Guard is replicating your database data. That's all it's replicating. That could be a good thing, that could be a bad thing.
It depends on your focus, right? You want it to replicate your database data, and you can fail over your database data when you need to fail over or switch over Data Guard. If you need to fail over or switch over your applications or anything else that exists outside of the Oracle realm, you're gonna use something else, and that's the way it is.
So- Oh, so just so I'm clear, what you're meaning, Lester, is like if I've got an app server that's, that's It's sitting above this diagram and it's accessing this. That's what you're talking about, like- App server- Like, yeah, okay SQL Server, Postgres, any other, any other object, for the line of business outs- outside of this Oracle database. Yeah. Yes.
Any, basically anything that's trying to use its, use this data to do its job. Right. Okay. To make, you know, this data is there for a reason, right? Right. So, yeah. And actually, I just have a quick question, Lester. So I'm curious, and hopefully
folks will participate. I'm just curious, like, I'm not an Oracle guy. Like anybody that's been on this call, like I have a history of infrastructure background. I know about, enough about databases to talk to people like Lester to a level and, and know. But I- I'm curious if anybody, like how many folks here are actually using Data Guard or
Oracle RAC? If you want to, if you would just be willing to put a yes or a "I use both" or none in the chat, I'd be interested. Because I, I just don't know how widespread these are, Lester. Is this something that you would assume most people are leveraging or is it Obviously, it's probably case by case based off the- I would like to know what our audience says in that,
that- the database, right? Oh, sorry. No, I would like to know what our audience says. Oh, okay. But, when I go in and I have discussions with our customers, Data Guard is, is very widely used- Okay because it's not difficult
to set up, and it is free and it is there, so we can just put it in place and, and they can go with it. And then there's nothing wrong with Data Guard. There absolutely isn't. So, I see Data Guard a lot. Oracle RAC, there's a lot of customers with it, but Oracle RAC is
Oracle is very proud of RAC, right? So- and they charge accordingly. Um- Okay. That, that's what I figured you were going with that one. Anyway, so, so there's a lot of- Fair enough ways to get around RAC from an HA perspective, if you're virtualizing, for example.
So you have to be, you have to be ready to write that check for Oracle. Got it. Okay. Yeah, there you go. Jesse, "RAC is too expensive." It is. You know? Yeah. Oracle Database is expensive. RAC is, it's not far behind the database licenses, I'll just tell you right now.
Oh, really? Okay. I didn't So I didn't realize that way. Data's that expensive. Okay. So Active DR. The way Active DR works is this way, right? You are, you are setting up your active nodes, and you have a passive node.
What you're doing at this point is you are creating what's known as a pod on each, right? The pod is where you're putting the volumes of your database or anything in that line of business that you want to replicate over to your DR site. Then you'll have a pod over here, which is where the target is, for the replication. Once you have that pod defined and set in a demoted state, which is effectively saying
it's going to be the read-only target for your replication, then that, that replication will kick off. The cool thing about Active DR as opposed to Data Guard, for example, is that replication is only replicating the, compressed and deduped capacity, right?
If your database is a petabyte, but you've got a 4:1 DR rate, you're only rep- replicating 250 terabytes. I mean, that's not a small amount, but that is a significant reduction of data that's going across your pipe, right? So that is a, that is a significant advantage here within this technology too.
Now, once we have that in place, we want to use the Data G- the Active DR database. We're going to be able to create, or it will create a point in time snapshot right when we bring this node up. This point in time snapshot is going to protect our prod system and our DR
system so that when we bring it back. So, and I'll show this in more detail. I have a demo for us in just a moment. Now, the DR site is active. It's very quick.
This is just as quick as bringing up, doing snapshots, right? Yeah. That whole snapshot diagram I had. This is just as quick as bringing up snapshots on the DR side. There's something very compelling about that as well in doing, DR- Tests, right?
With Data Guard, y- you're, you wanna do tests for, your DR site. Make sure that you can recover your DR site. Many times you don't do those, or you do them every six or 12 months because, they're, they're painful. I've got a lot of other words to describe it, but they're- We'll just stick with painful.
With this, we can, we can bring up our DR environment very quickly, very easily, very non-disruptively. And, and we'll, we'll get into that in my demo. I'll show you. Yeah, and spoil Sorry, spoiler alert. This is all pretty much tr- transparent to
Oracle, like as far as the, the data piece, just to call this out. Like, I'm stealing a little bit of your thunder, Lester, but, you know, I wanna make sure there's kind of a blend here of like from the Oracle piece, it doesn't know that this is happening, like under the covers. Does not. So, like just to be clear for the database,
they'll say, "Well, hey, you know," 'cause you're messing with I'm messing with your database, like if I'm the storage cat. Right. But Oracle doesn't see this. Like, it, it's not even aware of it, so. Right, and this, and this, what we're, what we're talking about here, this is like doing a,
a failover. But what I'm also What I'm getting at as well is we're not having to do a switchover. You know, switchover is, is syntax within Data Guard where you switch over the database in Data Guard so that the DR side takes control, but the prod side doesn't fail. It's not in a failed state.
What we're able to do in this regard is we're able to bring up the DR site and let the prod site still, continue, continue operating in a non-disrupted, state, and that's what I wanna show right now, okay? I have a, I have a video of a lab where I built out a demo, and going to hopefully be able to show it to you right now.
Here we go. Jason, do you wanna try and click that for me? 'Cause- Yeah. There we go. There we go. All right. So I've got my prod and my DR environment here, right? I'm gonna start off at the top left by just doing some SQL inserts, and then I'm gonna
also do that over on the DR side in the upper right. And down in the bottom right, I'm gonna run this script, which is going to s- switch over, or it's going to start up a whole DR environment, right? And I'm gonna make I'm gonna show you that it's gonna be completely non-disruptive to bring the DR environment up.
Now, we're gonna kick this off. You're gonna see the top 10, SQL inserts going on here, right? There they are, 476, 477. We're gonna keep going. I'm gonna kick this off over here on the DR side, and the errors are going to happen, right?
I want these errors to show the database isn't running. The database is down. It's all in a read-only state. It's failed. What I'm gonna do over in the start side is this is where I'm going to promote that pod in the active DR site, right?
Promote pod. Yes, let's start it up. Now, the pod is being promoted. That is immediately snapshotting the database. I'll get into that in a moment. Now I'm gonna go, because this is virtualized, I'm gonna go into, vSphere, vCenter, and we're
gonna rescan the HBAs. And while we're scanning for those, we see the disks there for my ASM disk group. Once we have those, we're going to put them, ASM disks, and then we're gonna go in and we're going to, put, get the ASM disk groups as well. There's my ASM disks, and there's the disk groups.
And now we're going to start the database. I've got my disks and my disk groups. Now, the database starts up. What we're gonna see at the top right is we're gonna see the SQL statements start. You look over on the right, the numbers are different than the ones on the left.
But you see on the left, the database is still operating. My end users are still doing end user stuff in prod. On my DR on the right, you're able to do your DR tests, right? Now, what have I done? I've been able to show that the DR environment works.
If we had a failure, I can bring up DR. Now, all of the DR tests work. What does this mean? I don't have to come in on a weekend and spend the entire weekend going through disruptive, painful DR tests. I can do this any time of the week and show that
DR works. I've just done it right here. "Hey, IT director, CIO, whomever, this is why we know DR is going to protect us with a zero RPO, RTO. Thank you so very much." Now what I'm gonna do is I'm gonna shut down a- This DR drill,
my DR drill end bash. This is just gonna go in reverse. It's going to shut down the database, unmount the ASM disk groups, remove the volumes, and do and then, demote the pod. So you think, okay, that's all reverse, but what about the data that we just added in
the test on the DR database? That's a very good question, audience, thank you for asking. What, what's gonna happen is right when we promote it, and I mentioned it briefly, but right when we promoted that DR database, boom, it took, if you want, it took an undue snapshot of our database.
It's going to restore that because this whole time while prod's been working, those writes have been replicating over to the DR site, 'cause we want to ensure that our prod environment is protected. Because just because we're doing these DR tests, we don't want our prod environment to be unprotected in the event of a failure that just so happened to, just so happened to
happen during the test. We, it they're just queuing up, buffering up. Now, once this pod is demoted, the snap is re- is applied. Remember what Jason said, they're very quick, automagic happens.
The buffered up writes are then applied to that snapshot, and then the DR database is caught up and is current again. So just like that, we're back to having our DR, Active DR database current with prod and accepting all the writes. Thank you very much. Thank you very much.
Yeah, that was Now, what can you do? Think of this. Let's, let's take it a step further. How about putting them both together, right? We just went from a zero RPO, RTO ActiveCluster with Active DR together.
Now we really have a powerful HA and DR solution. Or maybe we want to apply Data Guard on top of this whole thing, and you say, "Wait a minute. Wait a minute. W- w- why would we wanna do this?" Well, maybe as a DBA, you think of that one or two or 10 times in your career you've had
to go into your DR database and recover that table or that schema or those couple of rows that, somebody needed, and that's all you needed to get, right? Well, the Data Guard database that you put on top of your Active DR is where you can do that.
That's your logical replication to your physical rep- your physical DR implementation, right? You could do that, through the, the DR drill example that I demoed, but this, you can also, apply the logical recovery here with a Data Guard, replication.
So, an example of creating a comprehensive, HA and DR solution. I have a question, but I don't know, I can't recall what your next couple slides are, so I'm gonna save it to see if you if we Okay. So I'm gonna ask it here. Well- Go back to that previous slide, 'cause
maybe I- I'll go back to the- Unless I misunderstood. Like, I see the, we've got the, the ActiveCluster on the top. Mm-hmm. And then you've got the data guard on the bottom. But I'm assuming, could you do this with, RAC on top as well? Yes. Okay. You can do, you can have RAC everywhere.
Okay. I have, I've had many customers because of the, honestly because of the cost of RAC- For sure. I just wanted to call it they put a single instance. Yeah. They put a single instance down at the DR site. It's all based on your, failover SLAs that you're, that you're willing to accept in the
event- Yeah of a failover. So you don't have to have your compute match down at your DR site of what it has in the prod. Yeah. I just- Absolutely I mean, for those that can afford the Cadillac, I, I just wanted to make sure if like if you could do the ac- our
ActiveCluster on the top with RAC sitting on top of it, and you could still do and, and also do the, Data G- I mean, that's full belt and suspenders, but I just wanted to make sure that that would be a- Yep a valid Okay. See, the thing, from a licensing perspective, you've got four nodes up here of RAC, you have two nodes of RAC down here, or you can put one larger server, a single
instance server down here. Yeah. You know? What, what you have from a cost perspective from a HA, here is nothing, here is nothing, and standard Data Guard is included as well. Okay. So, yeah.
Yeah, I, I know that's probably a bit extreme, both from a protection as well as it sounds like, as Jesse put in the chat, a cost, but I just wanted to call it out to see if that was an act- Oh, no if that would be possible, so. That's, that's fine. That's good. Okay. But then it gets into, you know, why do all of
those things? We're talking about recovering a table or some rows or a schema, that type of thing, because it comes down to corruption, the potential for corruption of your database or data in the database. And, how do we protect ourselves there? And that's why you have so many, different layers of protection.
Right? 'Cause where is it gonna come from? When are you gonna catch it, and how do you protect yourself from it? 'Cause any of these layers can create the corruption, right? You can, you can have a, what I affectionately refer to as an ID10T error, right? Right? Like writing something- I haven't heard that
in a long time, but yeah. Yeah. Or, or pepk care- Yeah where they go in and they inadvertently update or delete, millions of rows of data, and the replication will correctly replicate all of those, bad updates, deletes, inserts, whatever they've done. That is simply, something that's gonna happen because there's, there's nothing
wrong with the, with the replication of that mistake, right? You can have a replication of a misrepresented, ASM error. Something at the OS level gets replicated over. The HBAs or the fabric has a problem, and it replicates that failure over. At the com- at the controller, the, the DFMs, those, those replications are not that
common anymore, right? The storage, storage-based problems, those corruptions, they put a lot of protection mechanisms in the hardware to prevent those kind of replications. Could they happen? They may from time to time, but they're not near as common as, end user based or OS- Sure driver based
type of, type of replication problem or type of, write problems. But it just happens. So how do you, how do you protect yourself from this? Well, you can't stay on top of it and know immediately when a replication problem's going to happen.
So, there's a couple of ways you can repli- you can protect yourself. Data Guard is going to easily and efficiently and correctly replicate it over, so will Active, DR. What you can do, on the Data Guard side, you can enable Flashback Database.
Flashback Database, that technology on the database, you can rewind the transit- Yeah, you paused for about five seconds, so no worries. Oh, yeah. I'm getting all sorts of errors over here. Yeah. All right. So you can put a, Flashback Database so you can rewind prior to the point.
From a, from an Active DR perspective, you can, when you set up your pods, you set up protection groups for snapshots. So you can snap You can put enable snapshots in your pod, so snapshotting the database replicates the snapshots to the DR site as well. And so you have a retention policy on your snapshots.
So you can then restore a snapshot. Say, you have a frequency of an hourly snapshot, going back to my di- wonderful diagram, and prior to, the replication or prior to the corruption. I'll get it out right. Right? So there's, there's multiple ways to protect yourself from corruption.
Yeah, and just real quick, Lester, we did get a q- a question in from the chat saying, "Can we replicate the snapshots?" In Active DR, they are replicated automatically. It's a function of Active DR. Okay. You set, you actually set up the snap on your prod node, on your source node, and they are replicated over to the target.
Okay. So this is what I was just saying, storage level corruption is rare. We've got a lot of things in place to protect at the storage level. Let's take advantage of those. These guys, bad data is gonna be r- is gonna be replicated.
You don't know when it's there until it's already there and been there a while. So let's put in those, strategies to, to protect ourselves and to recover from them. So just a few minutes left. I wanna wrap up. I wanna make sure that you guys know that we're here for you, right?
If you would like, we can go over some AWR reports with you for, for all of your databases that you have. AWR reports are like voodoo, black magic, good stuff. Lot of information in AWR reports. We can go over them, get a bunch of them, you know, look at point in times, and just, do it
over coffee so we don't fall asleep. Or we can get together, you can collect them for us, and we can do an assess- a free assessment for you. Put them all through our system, aggregate them, analyze them, create some pretty charts, and talk about how the databases are performing, where the bottlenecks are, what we can do to improve in- inefficiencies in
infrastructure and all sorts of things there for you. Very much like to help you out with that. This will, this is a very good engagement to, to do on the databases. AWRs have so much information to go through to look at capacity, overall performance, tuning.
There's a lot of data in there. Remember when I started, we wanna make sure that we keep the application focus on infrastructure, and this is, this is where we can start with that. One question for you I have on that one, Lester- Yeah just in case. I don't know the mix, we, I don't know the mixture of the audience, right?
So if maybe you're looking into Everpure, you're not an Everpure customer, would, would this assessment work regardless of the storage vendor, or do you have to be running Pure for this to work? Regardless. Okay. This is independent of all hardware, computer, management- I figured as much, but I wanted to ask it out loud, so okay.
This is strictly in the database- Got it Oracle AWR reports. I don't, I don't care what the hardware is. Got it. So if you happen to be here and you're running something other than us, Dell, NetApp, Hitachi, whatever, this, we can still do this with you, so.
That's right. Go here, the GitHub. The, the bash scripts that I was doing the demo on will be here, as well as a lot of really cool Python scripts for snapshots and all sorts of other cool groovy stuff. Come, come to our GitHub repository and enjoy yourself there. They are examples only.
Yeah, examples, yeah. Here you go, guys. Please enjoy your journey with Everpure. Check out our documentation. I've got, quite a few SnapDocs that I've put together here, on, on this little, QR code.
You can run our test drive, demo environment where you can do Active DR, you can do snaps, you can I don't know if ActiveCluster 's on the test drive, but Active DR definitely is. No, Active Cluster is definitely in there. A- and I've even got a Pure 360 video, which is our- Oh, very cool kinda watch a demo where
I've done Active Cluster. So if you even just wanna see Active Cluster itself, regardless if it's for a database workload or not, because it's still, as far as that piece is concerned, it's the same. It walks through that and shows you the recovery and everything, so. Fantastic. Takes 12 minutes of your life. Well, you can do this one, and you can connect
with me and my colleagues, all right? Questions, comments, concerns, opinions, observations? Yeah. So we actually do have a questions, and I know we're, we're, we've got about five, six minutes left, but I think we can get through these. Jesse in the chat, I mean, I'm sure the answer
is yes, but I'm gonna ask you, Lester. It says: Would the RTO, I'm assuming be I think it says: Would the RTO be slower in the case if there is corruption? And my, my, my answer to that would be, I don't know if it's slower, it's just you're going to have to go back to an older version to, to make sure you recover the- The RTO-
part that isn't corrupted, but I'll let you answer that, Lester. No, thanks. The, so the RTO would typically be lower because you've got to, y- you've got to hunt, right? You got to hunt for that point in time prior to the corruption. Yeah. So your, your RTO would be lower there, and
then your RPO would be, it would ob- obviously be l- lower as well for longer because, depending on the level of corruption, we don't know how, how much we're going to lose. Yeah. It's, it's, I think it's the idea, Jesse, your RPO would be, RPO would be lower 'cause you're gonna have to go find the older- Yeah version, and then your RTO
might be higher, your recovery time, because you gotta go find the- Yeah the non-corrupted version. So I- We don't know how far we're gonna have to roll back. Yes. 'Cause you're gonna take time to go like, "Oh, it's not this one. Find this one." So, yeah, the, it goes up and it goes down based off the RTO and RPO.
So hopefully that answers Yeah. Thanks, Jesse. Hope I was like, "Well, how do we answer that?" the other one is, if we do use Active Cluster, let's see. Hold, let me reread it, I guess, my question, so we are going to Okay.
My question is, are we going to stretch the volume from the prod side to the DR side? Are we going to mount the same volumes WWN on both prod and the DR side? So it's basically, what- what's that plumbing look like is, is kind of what I'm getting from that. You, just like the Active DR, you have a pod on the prod and the DR.
You create two individual pods. With Active Cluster, you're stretching a pod across both arrays, but the volume exists on both arrays. So you're not stretching it, it's, it's, it exists in both places. And then, but I'm assuming maybe the, the W- like you're g- you're gonna present that
volume to both sides. Yeah. That's where I'm assuming the WWN- Yeah part comes in. Yeah. Is like, so if you've got f- two hosts si- at site A and two hosts at site B, you've got that one volume that's now being stretched across the pod. You need to zone it so
those hosts see that volume. Yeah, yeah. So, hopefully that answers the question. If not, please throw it in the chat, but I, I think that's what the, what you were getting at in the question, so. Yeah. It's basically you do need to zone it so all,
all the hosts see the same, the same volume across the sites. Yeah. And there's, in the, in the whitepapers, there's some real good information on different ways to zone it out. They call it optimal path and non-optimal. Yeah. So they have different, different ways to lay
it out so that you can force the, the hosts and the switching, down to the arrays a couple of different ways so you can control that. Okay. And well, all right, I'm just trying to check. I don't see any others in the chat, and we're almost at time, so I think that's a good spot to wrap. I do see we had a winner for the raffle.
We have a winner, and it looks like, Cindy. So congratulations, Cindy, if you made it to the end. And everybody else, thank you for sticking around. I do wanna tell everybody we are doing a, a summit, an Everpure Summit across the nation. So if you're in Dallas, Chicago, or Boston and you're wanting to learn more about Everpure,
if you're, you know, looking into us or if you're an existing customer, it's a good chance to go out and see fantastic presenters like Lester. We'll have our virtualization people, we'll have our database people, we'll have AI people. So check these out if, you know, you're, you're local to the Dallas, Chicago, or Boston. It might be a good use of your day.
One last thing if you, as well is if you're not, please go ahead and sign up and take a look at our Everpure, customer community. QR code is here. This is a great site where you can talk to other Everpure customers about all sorts of thing, Everpure products, solutions, Oracle. You know, we've got an Oracle forum, so you might put a question there, and Lester might
answer it, right? So we've got all of our experts that monitor that. It's a good way to ask questions, either of us or from, from our existing customers as well. My only caveat, as I say, is, you know, this is not a support site. So if you are having a production issue or a business impact issue, this is, please do not
go here for the quick answers. Please, you know, use your, the normal support, you know, c- avenues, phone support and all that other stuff. But go ahead and c- click there at purecommunity.purestorage.com or go ahead and s- scan that QR code. That will take you there. But like I said, thank
you for joining us today. Lester, thank you for the presentation. I definitely, as I said, I'm not a database cat, so I picked up some Oracle stuff to put in my tool belt, which is great. So thank you for coming on.
And then, of course, for those that attended, thank you for joining us, staying till the end. We'll be back in two more weeks with our next Tech Talk. But until then, I hope you have a fantastic Thursday and the rest of your week. Thanks, everybody. Thank you, everyone.
Lester Wells
Consulting Field Solutions Architect, Everpure
Jason Langer
Senior Technical Evangelist, Everpure
Oracle recovery requires more than a backup strategy. Accidental deletion, logical corruption, infrastructure failure, site loss, and ransomware demand different combinations of backup, snapshots, and replication.
This session explains where each data protection layer does and doesn’t belong in an Oracle recovery architecture. Through practical failure scenarios, we’ll examine how to align RPO, RTO, retention, availability, and recovery-location requirements with the right recovery mechanism. You’ll also learn how to identify overlap, avoid common recovery gaps, and use storage automation to apply consistent protection policies across production, development, test, and DR environments.
Session takeaways:
- Map Oracle failure scenarios to the appropriate data recovery mechanism.
- Identify protection overlap, operational complexity, and recovery gaps before an incident exposes them.
- Translate workload requirements into practical RPO, RTO, retention, availability, and recovery-location decisions.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.