One way to handle this problem is to not schedule your jobs to push
from Y and Z to X. If transactions occur on Y and Z, they will become
deferred transactions, waiting to be pushed to X, but will never push.
Then, periodically you can delete the transactions from Y and Z (bound for
X). I
Would you be able to send sample of your scripts.
Thanks.
-Original Message-
Sent: Friday, May 03, 2002 1:29 PM
To: Multiple recipients of list ORACLE-L
Very interesting question.
Couple years ago, I had very similar problem: I had one "central" database,
which had to consolidate dat
Very interesting question.
Couple years ago, I had very similar problem: I had one "central" database,
which had to consolidate data from multiple "source" databases (having
identical schemas) in "real time" with as little delay as possible after
transaction occurs on the "source" database, and a
Not, if you want "real-time" row-level replication.
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Friday, May 03, 2002 11:33 AM
> Looks like snapshots make the most sense.
>
>
> --- Softhome - Fico
Looks like snapshots make the most sense.
--- Softhome - Fico <[EMAIL PROTECTED]> wrote:
> hi experts,
>
> In my replicated environment, i have one site
> (example: site X) that
> consolidate data from other sites (example : site Y
> and Z).
>
> I'm using multimaster to push transaction from
