Re: Replication Opinions

[Jim Oberholtzer <midrangel@xxxxxxxxxx>]

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...