RE: Cloud-based Real-Time Site Fail-over

I would also take a look at the options available from DBVISIT. I would not be surprised if they already have this polished for cloud to cloud, but I have not looked lately.  

IF you decide to “roll your own” as we used to do before Dataguard existed, that can remove essentially all the limitations imposed by the Oracle software, though you may then need to fully license RDBMS software at both your primary and failover sites. (As opposed to any “I’m only really running it at one site at a time” deals that may exist.)  

Paper #16 from the IOUW97 conference goes over how to do this in great detail if you can find that on line somewhere.  

In the new world of timesharing bureaus, it *may* also be useful to download to a machine on one of your physical campus locations as a middleman site. Presumably you have high bandwidth between at least one of your campuses to both of your proposed disparate sites, and these pathways should be something you can monitor for throughput and service levels you are paying for as opposed to vendor supplied communications between the two sites. This will also give you frequently up to date recoverable data sets under your control, which I believe is a major advantage in too many ways to recount. (If you want to test the recoverability of this “on-premises” database instantiation, you may need to license at least one node for Oracle software on the on-premises site, especially if you want to test your recoverability every day.  

This method was used in serious massive production implementations by Sequent, Millipore, and Cisco that I know of and am certain I am free to state before Oracle had a product.  

Also notice that being able to completely make an up to the last transaction committed copy of your database available at whim or emergency is NOT the same as making up to date copies of all your applications similarly available at both sites. To usefully do that is also required, and the only verifiable way to test that you are getting it right is to actually switch sites in operation reasonably frequently. Even if your applications suites are also cloud based separately from the RDBMS, when the plan is to be able to switch over to different database cloud sites you must comprehensively test on a reasonably frequent schedule or you may find yourself with a perfectly cut over database that cannot be reasonably used to continue business operations.  

Good luck. I’m sure there are specific kinks to work out in actually making it work between two disparate cloud environments. For sufficient remuneration I would probably be inclined to bespoke this for someone despite my “mostly retired” status.  

Regards,  

mwf    

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala Sent: Monday, May 27, 2024 6:31 PM
To: oracle-l_at_freelists.org
Subject: Re: Cloud-based Real-Time Site Fail-over  

On Mon, 2024-05-27 at 16:37 -0400, Alan Sterger wrote:

Hello,  

Looking for technical solutions (white papers, URLs, pricing...) for

cloud-based, real-time failover between geographically disparate sites.

Client currently utilizes Azure in its Sweden data center. Application

is web based with Oracle clients and IIS communicating with a single

Oracle database (non-CDB).  

Some in management are convinced an all Oracle solution would be

prohibitively expensive and/or not feasible when used with Oracle VPD

(DBMS_RLS).   Can you shed any light?  

• Alan Sterger

asterger_at_earthlink.net

--

http://www.freelists.org/webpage/oracle-l      

Well, you may call me adventurous, but I would go with the classic standby (not active DG). The problem with the active DG is that it is possible to connect to both databases, the primary and the standby. One relies on redirection from standby to the primary in case of a DML. However, redirection is not available in the public cloud and you mentioned Azure cloud:  

https://apex.oracle.com/pls/apex/features/r/dbfeatures/features?feature_id=1093  

So, that means that active DG is no good for the public cloud. A normal mounted standby in the maximum availability (meaning synchronous commit) mode will probably do the trick. Depending on the traffic on the primary side, you will probably need a hefty network pipe between the primary and the standby. You can use far sync to reduce the network traffic and increase throughput. RAC is not supported in a non-OCI cloud so the only way is some kind of replication. You can use Golden Gate or SharePlex to create a copy of the database, but the catch is that is necessary to automate fail-over yourself, no DG observer in that case.      

--

Mladen Gogala

Database SME

https://dbwhisperer.wordpress.com  

--

http://www.freelists.org/webpage/oracle-l Received on Fri May 31 2024 - 14:20:51 CEST