Hello,
I plan to use the Target database (OE Repl Plus) as a source for bulk copying processes (primary sinchronization).
I think this will eliminate the undesirable impact on performance of Source database caused by the large amount of reading due to synchronization processes.
I also want to use the Target database as a source for replication processes.
Only replication triggers will be used on the Source database (machine) to capture changes to the Repl database.
But before I start testing this idea, maybe anyone of you has already tried it?
Can there be any problems for such a Pro2 scheme?
Regards,
Valeriy
You can use the OE Repl Plus target (OER) as the source db for initial seeding. You are correct in that the OER "source" db will have the triggers on it and do the event recording into the production repl db. If you are also attempting to use the OER target as the source db for the replication feed, be aware that Pro2 MUST be connected to the LIVE repl db since the replication process will be modifying queue records on the fly. So use of a read-only repl db connection won't work.
While this configuration is technically feasible, there could be concern with timing of the reads, specifically with respect to Pro2 reading a source row that was modified and had not yet been replicated via OER. To be 100% accurate, I would modify the bulk load template to perform a replqueue lookup for rows having the same table name/rowid combination. If a queue record exists then simply have bulk-load skip the copy for that row, log it if you want an indicator, and let normal replication send the data. In theory this should eliminate the potential for reading stale data.
Hope this helps and let me know if you have additional questions.
Terry
You can use the OE Repl Plus target (OER) as the source db for initial seeding. You are correct in that the OER "source" db will have the triggers on it and do the event recording into the production repl db. If you are also attempting to use the OER target as the source db for the replication feed, be aware that Pro2 MUST be connected to the LIVE repl db since the replication process will be modifying queue records on the fly. So use of a read-only repl db connection won't work.
While this configuration is technically feasible, there could be concern with timing of the reads, specifically with respect to Pro2 reading a source row that was modified and had not yet been replicated via OER. To be 100% accurate, I would modify the bulk load template to perform a replqueue lookup for rows having the same table name/rowid combination. If a queue record exists then simply have bulk-load skip the copy for that row, log it if you want an indicator, and let normal replication send the data. In theory this should eliminate the potential for reading stale data.
Hope this helps and let me know if you have additional questions.
Terry
Hi Terry,
Thank you very much for your answer!
I missed a possible gap between Source and Target, I'll take this into account.
Regards,
Valeriy