Re: Oracle High Availability Question(s)

  • From: Ls Cheng <exriscer@xxxxxxxxx>
  • To: "Reen, Elizabeth" <elizabeth.reen@xxxxxxxx>
  • Date: Fri, 16 Feb 2018 16:35:27 +0100

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@xxxxxxxx>
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@
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@xxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
*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@xxxxxxxxx> 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@xxxxxxxxx> 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.

---



Other related posts: