sync tables that are different layouts (Oracle to Oracle)
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 315
- Joined: Tue Oct 31, 2006 3:38 pm
sync tables that are different layouts (Oracle to Oracle)
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
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
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Premium Member
- Posts: 315
- Joined: Tue Oct 31, 2006 3:38 pm
-
- Premium Member
- Posts: 315
- Joined: Tue Oct 31, 2006 3:38 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.![Wink :wink:](./images/smilies/icon_wink.gif)
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.
![Wink :wink:](./images/smilies/icon_wink.gif)
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
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.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers