RE: HA options
- From: Gerald Cunningham <gcunningham@xxxxxxxxxxxxxx>
- To: "mwf@xxxxxxxx" <mwf@xxxxxxxx>, "sethmiller.sm@xxxxxxxxx" <sethmiller.sm@xxxxxxxxx>, "lambu999@xxxxxxxxx" <lambu999@xxxxxxxxx>
- Date: Wed, 7 Aug 2013 10:28:09 -0400
Very well put, Mark!
My advice is this: Fight for your downtime. Under-promise and over-deliver.
Jerry
________________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf
Of Mark W. Farnham [mwf@xxxxxxxx]
Sent: Monday, August 05, 2013 2:30 PM
To: sethmiller.sm@xxxxxxxxx; lambu999@xxxxxxxxx
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Seth Miller
Sent: Sunday, August 04, 2013 10:17 PM
To: lambu999@xxxxxxxxx
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@xxxxxxxxx> 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.
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l--
//www.freelists.org/webpage/oracle-l
Other related posts:
