Re: ER: target loses inserts

See below... Richard Kofler <richard.kofler@chello.at> wrote in message news:<40578ADF.6B53E5CF@chello.at>... > IFX V9.21.UC4 > Solaris 7 > > 2 multicpu machines connected via Gbit Ethernet > exclusively used for ER only > > ER: update everywhere, tx based conflict resolution > based on the timestamps > > 20 CPUvps, tons of disks, approx 700 tables in the > replication. > > Database in log mode ANSI > All tables in LOCK MODE ROW > GLS is in place > > Here is a 'skeleton' of what we think has happened: > > <---------- SOURCE -----------> <----- TARGET --------> > Time 1 > Source does an INSERT Target does nothing > INSERT does a join and is very > slow due to missing index > > Time 2 > COMMIT; Target does nothing > > Time 3 > SendQ - - - spools the INSERT to - - - RECV Q > > Time 4 > Source does an update Target starts to do > to the former inserted the INSERT and this takes > row. This is quick long (like 10 times longer > than the UPDATE > running on Source right now > > Time 5 > COMMIT; Target still is doing INSERT > > Time 6 > SendQ - - - - spools the update to - - - - RECV Q > > Time 7 > Source is idle Target CPUvp#1 still doing > the INSERT > Target CPUvp#2 start to try > the UPDATE. Rows is not here > Therefore an Insert is done > instead and a ris file gets > written > > Time 8 > Source is idle Target CPUcp#1 finishes join > and tries to do the INSERT > which is - of course - not possible > because the row is already here > > > My questions now: > Can / does it happen like this? It should not. With 9.21, there is no dynamic apply parallelism. That means that from a given source the apply of a replicate is serialized. By default the apply of data from a given source is serialized by the source. There can be some parallelism of the apply of transactions from the same source, but only if the replicates are defined as parallel. But even if they are marked as parallel, there is parallelism only if different replicates are involved. In 9.3, we introduced dynamic parallelism, but we serialize based on the rows contained within the transaction. If the transaction contains an operation on row 'X', then subsequent transactions which might contain the same row are serially applied. So I guess that I don't see how what you are describing can occur. I'd need to examine the logical log contents to see if this is really what happened. M.P. > How to prevent that an UPDATE happens in the target earlier than > the INSERT of the row the UPDATE belongs to > > Every help or comments appreciated > > dic_k