CLAY JACKSON: 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, Standard Edition 19c Oracle has discontinued support for RAC. Here's the 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's some other choices I'd like to talk to you about, as well. First of all, why RAC? I have a different talk that goes into great detail about why RAC, and the things you can do with RAC, but suffice it to say, for this video, 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 discs 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 Dilbert 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 the-- 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 upgraded Enterprise Edition. That's easy, but money. You can use Oracle's SEHA Well, SEHA 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 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's 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, you can 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 sequel 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 to target, 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. You get your data from the source of the target. We ship it over to the target immediately, where it's not seen until you have your committed 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 to 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 reading log with a capture process, move them to the read process. That is traffic cop. We can also replicate it from one source to multiple targets, or multiple targets to one source.
Maybe you want to have a data mart, maybe want to do data consolidation, maybe want to have a separate DR in a different data center from your standard high availability environment 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. Their own-- they are 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 those redo log messages, translates them to Sequel, and posts 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 SEHA.
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 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 that will let you compare two tables, the source and the target, and if they're different, we'll give you the Sequel to make the target look like the source. So that's how you can, again alleviate, the need