Hi. This is Clay Jackson, Senior Software Engineer here at Quest Software. Today I'd like to talk to you about "Disaster Recovery and High Availability on Oracle 19c Standard Edition." As you probably know, in Standard Edition 19c, Oracle has discontinued support for RAC. Here is the My Oracle Support article that talks about that.
And they give you a couple of choices, three choices. You can upgrade from Standard Edition to Enterprise Edition and pay Oracle lots of money. You can convert your Oracle RAC database to a single-instance database and lose all the hard work, and the configurations you've taken, and the benefits you're getting from RAC. Or you can use Oracle's Standard Edition High Availability solution, which we'll talk about in a minute. But there are some other choices I'd like to talk to you about as well.
First of all, why RAC? We'll have a different talk that goes into great detail about why RAC and the things you can do with RAC. But suffice to say for this video that the major use cases are high availability, workload isolation, and disaster recovery.
Now, with disaster recovery, you've still got some issues, because you've got a single point of failure in the database and the disk storing the database. And you're going to be in the same location as your-- all your clusters are going to be in the same location. So if your data center goes down or, as Gilbert says, gets hit by a meteor, you're going to have a problem and not be able to use that database for high availability.
So if you're not going to have RAC, what are your options? Do without, obviously. You can just say, well, we're not going to need to use RAC anymore. We don't need DR. We don't need high availability. Or we don't need to isolate our workload and have the additional processing power in our workload.
You can upgrade to enterprise edition. That's easy, but costs money. You can use Oracle's SE/HA. Well, SE/HA is really just a fancy term for OS clustering. You set up cluster, where you set up ASM, and you set up an OS cluster. You've still got failover. You've still got a single point of failure in your disks, and not really much different from the 1990s OS clustering technology.
You can move to the cloud. You can go to Oracle Cloud Infrastructure and use their DR and backup capabilities. Or you can go to Amazon or any one of the other cloud vendors.
But there is another alternative. And that alternative is replication, specifically, Quest SharePlex. Let's talk about how Quest SharePlex can help you overcome the loss of RAC in your Oracle 19c environment.
First thing is, look at the diagram here. We are redo-log-based. We're capturing the results of transactions as they appear in the Oracle redo log. And we're taking them, and moving over to a target database, and posting those results of those transactions as SQL in the target database.
So right off the bat, you've got two databases, so no single point of failure, no issues there. Now, since we're redo log based and we're reading the redo log, once we read the redo log, we'll guarantee you that we'll take that transaction and apply it to the target or tell you that we couldn't apply it to the target and that something went wrong.
So we're asynchronous. You're not waiting on a two-phase commit or on a Data Guard commit, any of those things, to get your data from the source to the target. We ship it over to the target immediately, where it's not seen until you have your commit from the source. But we're shipping it immediately.
We're also not using any Oracle Advanced features like log miner, or [? Extremes, ?] or any additional features in Oracle that would make you want to have to buy additional licenses from Oracle. In fact, we'll work with Standard Edition. We'll also work back to Oracle version 11 with the latest version of SharePlex, which is 10.0. Or we can go back even further than that if you get an older version from our product management team to do a migration or something of that nature, so no issues there, no cross-version issues.
We'll also work across platforms. So if your source system is Solaris and your target system is Linux, no problem. We can handle that as well. We read the transaction out of the redo log with a capture process, move them to the read process. That is Traffic Cop.
We can also replicate from one source to multiple targets or multiple targets to one source. Maybe you want to have a data mart. Maybe you want to do data consolidation. Maybe you want to have a separate DR in a different data center from your standard high-availability environment that you have in the same data center. No worries, we can do both of those things.
Export and import are not Oracle's import and export process. They're our own high-speed export and import that move data across the network very quickly and very efficiently. And then we get the post and post takes of those redo log messages, translate them to SQL, and post them in your Oracle database.
So that's how you can have high availability or disaster recovery in Oracle 19c without having to use RAC or use Oracle SE/HA. One more thing I should mention, when you're doing replication and you have a system where you've got a target database, you're always worried that the target database might not look exactly like the source. Right out of the box, included in the SharePlex package, we give you the compare and repair utilities. And we'll let you compare two tables, the source and target. And if they're different, we'll give you the SQL to make the target look like the source.
So that's how you can, again,
05:26