Re: Replication Opinions

I would concur with one slight alteration.

Add the trigger
Trigger posts an entry to a /remote data queue /on the target system. Error handling in the event the remote data queue is not available. Maybe stack the entries on a local queue, and when the remote comes back forward the entries.
Target system has a job to retrieve data queue entries and apply them as appropriate.

This has the advantages of being very easy to do, easy to debug, and very straight forward.

Using remote journals will also work quite well but applying a journal image is more work than grabbing a data queue entry and processing it.

The problem as I see it is sending each change precisely one time and ensuring it gets there and is processed. That's were the remote journal idea has more of an advantage, and as some have suggested, the commercial products available also do this sort of thing. That becomes a build/buy decision.

Depending on the criticality of the update, I would use the remote data queue and be done with it.

Jim Oberholtzer
CEO/Chief Technical Architect
Agile Technology Architects, LLC


On 1/6/2011 2:33 PM, Albert York wrote:

I would do the following:

Add a trigger to the file
Have the trigger program submit the change buffer to a data queue
Have a program running in batch to read the data queue and update the
remote file using DDM

Albert

On Thu, Jan 6, 2011 at 11:55 AM, Michael Ryan<michaelrtr@xxxxxxxxx> wrote:

> Have a file that I need to replicate in near real time to another
> system. What techniques do folks use? I'm thinking of triggers on the
> from file, remote SQL connect, ACD as appropriate. I guess journaling
> would be an option too. Opinions welcome. Thanks...