sync tables that are different layouts (Oracle to Oracle)

kirankota79 · Post by **kirankota79** » Wed Oct 15, 2008 6:57 am

Hi,

I have an requirement where i need to sync two tables with different layouts in two different instances (oracle to oracle). Can we do this in real time mode? What should i need for this. Please let me know.

Thanks

chulett · Post by **chulett** » Wed Oct 15, 2008 8:22 am

The difference in layouts shouldn't be an issue as long as you can define what "sync" means between the two. And "real time" or batch won't change what the "sync" does, only the DataStage implementation.

kirankota79 · Post by **kirankota79** » Wed Oct 15, 2008 6:36 pm

some advice please....

chulett · Post by **chulett** » Wed Oct 15, 2008 7:23 pm

Advise... patience.

ray.wurlod · Post by **ray.wurlod** » Wed Oct 15, 2008 7:43 pm

The answer to your original question is Yes. What you should do is simply to design your jobs do to precisely what is required.

kirankota79 · Post by **kirankota79** » Wed Oct 15, 2008 8:08 pm

Thanks Craig,

I can implement this....but do i need to have RTI components for this? since the source and target tables should be in sync always.

kirankota79 · Post by **kirankota79** » Wed Oct 15, 2008 8:09 pm

Thanks Craig,

I can implement this....but do i need to have RTI components for this? since the source and target tables should be in sync always.

chulett · Post by **chulett** » Wed Oct 15, 2008 8:11 pm

I agree with Ray. There's nothing stopping you from "synchronizing" any two tables regardless of structures or databases as long as you can define what that synchronization should consist of. We can't do that for you - you need to detail out for your efforts how it all will work: how to match the records, what are the key fields, what data fields to sync and exactly "sync" means in this context. And as noted earlier, you'll also need to determine how you'll recognize or capture changes in the source system - CDC? CDD? Update timestamps? In other words, what is driving this synchronization effort?

And real time or batch doesn't really factor into this. Synchronize is synchronize. What kind of change volumes are you expecting? That anticipated volume and your requirements as to the timeliness of the data, how vital it is to get changes over in real or "near real" time, should drive the choice. And while that choice may factor into the exact mechanism chosen to implement this - real time, near real time or batch - that won't change what "synchronize" means here.

Lastly, I don't see any significant differences in your scenarios.

1. Don't bring over the "extra" columns from the source, i.e. bring over just the applicable columns.

2. Join the parent and child tables in the source, bring over the applicable columns.

3. Bring over the applicable columns.

My long way of saying what Ray did - design your jobs to do precisely what is required.

chulett · Post by **chulett** » Wed Oct 15, 2008 8:16 pm

You'd need RTI if you wanted to expose your job as a web service or otherwise operate in an "always on" mode for "real time" updates. If you only need "near real time" and could run periodic "micro batches" or did one large daily update, then no, RTI is not required.