RE: HA options

From: Gerald Cunningham <gcunningham_at_proteuseng.com>
Date: Wed, 7 Aug 2013 10:28:09 -0400
Message-ID: <68F9DD51BF61E943BFA45D744048A7A7310FD19ACA_at_nbp-ex01.proteus-technologies.com>



Very well put, Mark!

My advice is this: Fight for your downtime. Under-promise and over-deliver.

Jerry



From: oracle-l-bounce_at_freelists.org [oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham [mwf_at_rsiz.com] Sent: Monday, August 05, 2013 2:30 PM
To: sethmiller.sm_at_gmail.com; lambu999_at_gmail.com Cc: 'oracle-l'
Subject: RE: HA options

I suspect when the original poster wrote "minimizing downtime" (which does mean zero if interpreted literally) I suspect what was really meant was a fairly short and predictable outage (since, after all, a database shutdown was specified.).

Now zero is indeed a tough mistress.

But otherwise, switching over to a dataguard destination that is not intentionally lagged should be a minimal outage. If you're patching hardware I'm thinking you patch the current dataguard destination and catch it up. Then if something has failed about the hardware patch and the switchover fails, you just resume on the original unpatched primary while you resolve the issues.

Of course you should switch over frequently enough to be confident that in normal operations everything will work, so the only surprise in the process would be artifacts of the hardware patch.

Also, in the general case of hardware patches, there is no guarantee that either RAC or Dataguard will work, so you are going to need to test. It is entirely possible that some hardware patch might mean you have to patch software as well, so you might not be able to restart the instance on the hardware patched host in a hybrid RAC cluster where other servers remain unpatched. You would need to be discussing a specific tested case to know for sure.

If you have "tidbits online where people have complained about delay in switching over" I would investigate to make sure their problems and expectations to not apply to you.

In framing your expectations, are you talking about requiring a small number of seconds or a small number minutes? Are you routinely already running dataguard or some flavor of physical backup continuous recovery? Do you already routinely switch over and switch back so that you know all the software pieces you need are in place and whatever web to application to database routing you have in place works seamlessly?

The key is to keep things like this as boring and simple as possible. Truly zero downtime is neither.

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Seth Miller
Sent: Sunday, August 04, 2013 10:17 PM
To: lambu999_at_gmail.com
Cc: oracle-l
Subject: Re: HA options

Ram,
There is a big difference between HA and DR. If you are looking for zero downtime for hardware patching, Data Guard (a DR solution) is not going to help you.

HA can be achieved at a couple of different levels. The most effective would be a multi-mastered application where you can have multiple installations that communicate with each other at the application level and synchronize their changes that way. You will have a global load balancer or connection pools that will fail over from one installation to another when it becomes unavailable making it transparent to the clients.

The other level is closer to what you are referring to here; the database or infrastructure level. Oracle's database clustering solution is called Real Application Clusters which has a single database that can be accessed from multiple instances (servers). In the case of RAC, you can bring down one node of the cluster and the application will continue to run uninterrupted on the other nodes. This scenario can even be implemented across data centers (in some cases) and is referred to as a stretched or extended cluster.

The only other viable solution for true HA is to use a sql apply solution like GoldenGate (or the deprecated Streams product). GG keeps a secondary database in sync similar to Data Guard, but the target is open read/write. In this case, the clients could be trickled over to a secondary database (be careful with this as you will lose ACID) or failed over all at once (possible delay and loss of ACID here as well). GG is tricky and requires an intimate knowledge of the application database architecture.

Seth Miller

On Sun, Aug 4, 2013 at 6:47 PM, Ram K <lambu999_at_gmail.com> wrote:

> List,
> As part of minimizing the downtime associated with some critical
> applications, we are exploring the available options. We are planning
> a hardware patch that will require us to shutdown the DBs.
>
> We have a DR site where we can set up dataguard for non clustered
> applications. I was looking into switch over, but it looks like
> switchover needs shutdown and startup and hence there is an associated
> downtime (twice
> - once switching over to standby and then again switching back). I
> also found some tidbits online where people have complained about
> delay in switching over.
> If there is a smoother way (any such thing as transparent switchover?)
> with dataguard I definitely want to explore the option before checking
> out other options. We have a mix of 10g and 11g. Can the listers share
> their experiences with DG.
>
> --
> Thanks,
> Ram.
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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


--
http://www.freelists.org/webpage/oracle-l--
http://www.freelists.org/webpage/oracle-l
Received on Wed Aug 07 2013 - 16:28:09 CEST

Original text of this message