>> I think when I divided the tasks the source latency has increased.
Yup, that feels normal/expected to me.
You failed to indicate the source or target db types used. That may well make a difference for the right advice
What problem are you trying to fix? If latency is too high, then would it not be better to try to figure out what the root cause/tables for that is/are, and deal with that - vs blindly splitting up 50/50?
In doing this analysis you should determine which tables to combine or not and may well find that an 80/20 split is better based perhaps on change volume or other considerations such as 'high priority' tables.
When you split the same tables from 1 task to 2 then you are causing the source changes logs (Redo) to be read twice, transferred twice, interpreted twice. That's double the read cost right there, and zero gain potential.
The tasks are also likely to read and accumulated less changes to be applies in the same interval making the bulk apply less efficient. There will be two smaller changes files (CSV) transferred, or smaller change tables created. That's double the bulk prepare/execution overhead and limited gain potential (gain could be more rows/tables.)
With 2 tasks there can be increased sorter parallelism. That's limited Replicate server CPU overhead which indeed could benefit from two processes.
On the apply side, the target apply engine may already be able to run in parallel (SnowFlake, SQL server, Oracle,... ) and putting that in 2 tasks just makes it less controllable, more peaky.
If you do decide that 2 tasks is better, for example after determining that as @SushilKumar suggest there perhaps are slower tables without PK, or with LOB lookups, or with source|target_lookup transformation) then it is probably best to go for 3 tasks in a LOGSTREAM configuration.
That is have 1 task (LogStream parent) read the change logs and look for changes to tables of interest only and 2 child tasks to process those pre-read, pre-selected changes.
Hein.
