I'm replicating the entire database, and refresh the replica using dump
marker method.
After I load the replica and resume connection, all of a sudden I get a
flurry of duplicate inserts into quite a few tables.
How is this possible? Isn't the dump supposed to have a marker above which
all new transactions are being replicated - therefore how could anything be
deleted from the source (and not caught by an active agent) or how did the
new records make it both in the dump and through replication agent at the
same time?

Any ideas?



--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---

On Feb 27, 2:32*am, "Axel" <tes... (AT) tester (DOT) cc> wrote:
Hi Axel

Just to understand the problem more precisely - do you use MSA with
database replication definitions and subscriptions? If so - do you use
"define subscription" with dump marker? Please explain the steps that
you take to refresh your replication.

Leonid Gvirtz
http://www.gvirtz-consulting.com

On Feb 26, 6:32*pm, "Axel" <tes... (AT) tester (DOT) cc> wrote:
Fix 1: make sure that you're not replicating BOTH the triggers and
their actions, which seems (oddly) to be the default in 12.6 MSA
repdefs,
You can turn the trigger replication off with something like
(can't find it in my notes just now):

ALTER [database] replication definition foo set
keep_dsi_triggers 'off'

Sometimes this works, but YMMV. The fullproof method seems to be:

Fix 2: Drop your triggers on the replicate.

Yesl I know, in the event of a failover you'll need to turn them back
on, but that's the best I've been able to come up with.

Keith

That actualy was the case. I figured it out after several skip transactions
returned me a reference in an actual trigger procedure as a source of the
erroneous SQL command. My dsi_keep_triggers setting had a syntax error and
was never executed during setup. However, some rep errors did not contain
these references, making you wonder if someone had updated the target
directly.

After I ran the "alter connection" command directly the errors stopped and
DSI in question ran fine without breaking.

Thanks both, Kevin & Leonid!

---------------------------------------------------------------------------
Keith wrote:
Fix 1: make sure that you're not replicating BOTH the triggers and
their actions, which seems (oddly) to be the default in 12.6 MSA
repdefs,
You can turn the trigger replication off with something like
(can't find it in my notes just now):

ALTER [database] replication definition foo set
keep_dsi_triggers 'off'

Sometimes this works, but YMMV. The fullproof method seems to be:

Fix 2: Drop your triggers on the replicate.

Yesl I know, in the event of a failover you'll need to turn them back
on, but that's the best I've been able to come up with.

Keith



--- news://freenews.netfront.net/ - complaints: news (AT) netfront (DOT) net ---