consolidate sending delete to remote with no pub

[Former Member]

We are seeing the following issue in our environment:

Cons - ASA 11.0.1 remote -SA 12.0.1:3994

Insert is complete in remote and data is replicated back to the consolidate then a delete is replicated back to the remote however the table is not part of the publication to the remote.

Data still exists in the consolidate but not the remote. I have translated the logs on both cons and remote. I don't see a delete in the consolidate but see the delete on the remote. I also see the delete coming through the Agent log file. Is this normal?

[regdomaratzki]

I'm confused. If the table is not part of the publication on the remote, why did the initial insert on the remote replicate to the consolidated?

[Former Member]

It is not part of the publication on the cons to the remote.

Data replication only one way from the remote to the consolidate

[regdomaratzki]

No, this is not normal.

There isn't enough information here to for us to help you though. The following information would let us figure out exatly what is going on :

1) The reload.sql file generated by "dbunload -n" when run against the consolidated and remote databases. 2) Verbose dbremote output logs (i.e. dbremote -v) showing the consolidated database applying the insert, sending a message back down to the remote, and the remote database receiving the message that contains the delete.

The first two pieces of information is probably enough, but I'll add a third.

3) The transaction log from the consolidated database corresponding to the time in which dbremote ran against the consolidated database in which it received the insert and sent the delete. We want to actual transaction log, not the output from dbtran run against the transaction log.

Reg

[Breck_Carter]

Here's a WAG... maybe it is the silent resolution of a potential referential integrity violation on the remote that is causing an unexpected row deletion. I never have liked that "silent resolution" stuff, mostly because I can never figure out what hit me 🙂

[regdomaratzki]

Silent RI resolution is a dbmlsync thing, not dbremote. If there is a FKEY violation at the remote when dbremote is applying message, the statement fails.

I. 2014-05-09 13:32:30. Received message from "cons" (0-0000576800-0000577187-0)

I. 2014-05-09 13:32:30. Applying message from "cons" (0-0000576800-0000577187-0)

I. 2014-05-09 13:32:30. DELETE FROM cons.parent WHERE p_pkey=1000011

I. 2014-05-09 13:32:30. COMMIT

E. 2014-05-09 13:32:30. SQL statement failed: (-194) No primary key value for foreign key 'parent' in table 'child'

I. 2014-05-09 13:32:30. ROLLBACK

I. 2014-05-09 13:32:30. Applying message from "cons" (0-0000576800-0000577187-0)

I. 2014-05-09 13:32:30. DELETE FROM cons.parent WHERE p_pkey=1000011

I. 2014-05-09 13:32:30. COMMIT

E. 2014-05-09 13:32:30. SQL statement failed: (-194) No primary key value for foreign key 'parent' in table 'child'

I. 2014-05-09 13:32:30. ROLLBACK

[Breck_Carter]

"Ahhhh, the tag... pay attention to the tag, Breck" 🙂