Agreed that GG will handle the differences, I’m just saying
that unless you make the whole record a PK ( and I have had to do that) it is
possible to have dups on one side and not the other. That it was not reporting
that the records were not inserted is the bug to me. I had a similar issue
with a table that had an active indicator. On one system records where there
with the indicator set to Y and N. It worked on one system because the PK was
the whole record. I blew up on the other system because they did not include
the indicator as part of the OK. I would expect GG to report the error. The
issue was found during the initial load.
Liz
From: Ls Cheng [mailto:exriscer@xxxxxxxxx]
Sent: Friday, February 16, 2018 10:57 AM
To: Reen, Elizabeth [ICG-IT]
Cc: Chris Taylor; Tim Gorman; Scott Canaan; fuzzy.graybeard@xxxxxxxxx;
oracle-l@xxxxxxxxxxxxx
Subject: Re: Oracle High Availability Question(s)
Hi
We know how to handle table with different PK with KEYCOLS, precisely that is
what we did but it turns out a bug which happens only in Integrated Extract
(Classic Extract handle this correctly). It is not a bug we invented, we opened
a SR and after 3 weeks support finally admitted it as bug and being worked by
development.
By the way the table does not need be exactly the same in OGG. Our use case is
replicating operational database to historical database.
BR
On Fri, Feb 16, 2018 at 4:44 PM, Reen, Elizabeth
<elizabeth.reen@xxxxxxxx<mailto:elizabeth.reen@xxxxxxxx>> wrote:
The objects have to be the same to be replicated. A different
PK may allow duplicates on one database which are not possible on the other.
It should have flagged the error, but I don’t see this as a bug. A pk on
orders would have duplicate accounts. A PK on accounts would blow up with dups.
Liz
From: Ls Cheng [mailto:exriscer@xxxxxxxxx<mailto:exriscer@xxxxxxxxx>]
Sent: Friday, February 16, 2018 10:35 AM
To: Reen, Elizabeth [ICG-IT]
Cc: Chris Taylor; Tim Gorman; Scott Canaan;
fuzzy.graybeard@xxxxxxxxx<mailto:fuzzy.graybeard@xxxxxxxxx>;
oracle-l@xxxxxxxxxxxxx<mailto:oracle-l@xxxxxxxxxxxxx>
Subject: Re: Oracle High Availability Question(s)
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<mailto: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@xxxxxxxxxxxxx>
[mailto:oracle-l-bounce@xxxxxxxxxxxxx<mailto:oracle-l-bounce@xxxxxxxxxxxxx>] On
Behalf Of Ls Cheng
Sent: Thursday, February 15, 2018 5:50 PM
To: Chris Taylor
Cc: Tim Gorman; Scott Canaan;
fuzzy.graybeard@xxxxxxxxx<mailto:fuzzy.graybeard@xxxxxxxxx>;
oracle-l@xxxxxxxxxxxxx<mailto: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<mailto: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<mailto: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.
---
