Re: Oracle High Availability Question(s)

From: Ls Cheng <exriscer_at_gmail.com>
Date: Fri, 16 Feb 2018 16:35:27 +0100
Message-ID: <CAJ2-Qb_HQXfxuajyJU9NE_MSrq6jPawZR1cHOTF2DivKJ6eMPA_at_mail.gmail.com>



Hello Elisabeth

Our were not application issues. It was OGG bugs which ignored DML operations. If a replication software cannot guarantee replicate all DML operations then we have a big problem.

BR

On Fri, Feb 16, 2018 at 3:57 PM, Reen, Elizabeth <elizabeth.reen_at_citi.com> wrote:

> GG requires that you understand the app. It also requires that you make
> the changes in both DBs. It’s not unpredictable, you just need to stay on
> top of it and the changes. We ran into all sorts of sequence issues. It
> turns out that the app was not using sequences but reading the max and
> adding 1. GG will find all of the weaknesses in your code.
>
>
>
> Liz
>
>
>
>
>
> *From:* oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_
> freelists.org] *On Behalf Of *Ls Cheng
> *Sent:* Thursday, February 15, 2018 5:50 PM
> *To:* Chris Taylor
> *Cc:* Tim Gorman; Scott Canaan; fuzzy.graybeard_at_gmail.com;
> oracle-l_at_freelists.org
> *Subject:* Re: Oracle High Availability Question(s)
>
>
>
> Hi
>
>
> Just some warning with GoldenGate.
>
> Recently we had a big issue with GoldenGate in the most critical database
> in one of or customers. GoldenGate ignored all updates in target because
> the target and source had different PK (target had same table structure as
> source but partitioned so PK had an additional column, the partitioning
> key), just because of different PK even we knew that and specified KEYCOLS
> in the target the updates was ignored until 1 month later a data analyst
> noticed some data divergence and adviced our support team. We had to
> restore 4 backups (each 4TB) to recover the data. It turns out bug 26553124
> and there werent even a Alert in MOS explaining such behaviour.
>
> Lesson learnt. GoldenGate is unpredictable, this is the second time in 2
> years I see such data divergence due to GoldenGate bug and the impact is
> huge, huge and huge because data divergence is soooo difficult to detect.
>
> So for DR stick with Data Guard (Physical Standby). I consider RAC as HA
> because you have several nodes available for a single copy of data (I
> consider DR more than one copy of data) and the death of one node still
> makes the application available, only 100%/number of nodes is impacted and
> the recovery is fast.
>
> Thanks
>
>
>
> On Thu, Feb 15, 2018 at 8:47 PM, Chris Taylor <
> christopherdtaylor1994_at_gmail.com> wrote:
>
> What about GoldenGate Tim??
>
>
>
> (Since I find myself trying to support this with no training/prior
> experience and learning in the deep end of the pool.... :)
>
>
>
> Chris
>
>
>
>
>
> On Wed, Feb 14, 2018 at 3:23 PM, Tim Gorman <tim.evdbt_at_gmail.com> wrote:
>
> Going into Data Guard without training is uncomfortable, but going into
> RAC without training is untenable. You can try it, but it is going to hurt
> a lot, and you'll end up with something you'll regret.
>
> ---
>
>
>

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Feb 16 2018 - 16:35:27 CET

Original text of this message