Skip to Main Content
  • Questions
  • Efficient method in Oracle to continuously poll data from one database and move to another

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Annie.

Asked: October 29, 2016 - 6:06 am UTC

Last updated: October 31, 2016 - 11:22 pm UTC

Version: 11g Release 2

Viewed 1000+ times

You Asked

Hi,

I have a scenario where I have to continuously( in every 1 hour) poll updated data from tables of one database and move to another database. What do you think is the standard approach. (anything similar to DTS in Sql server in Oracle) or would you advise using a scheduled job to run custom stored procs to do it). I am a newbie hence the question.

Annie

and Connor said...

Advanced Queueing if you want to do it yourself (ie, code up the capture and transmission).

or Goldengate, which will scrape the Oracle redo logs and trasmit the data to another destination (Oracle or otherwise).

http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Thank you very much for the answer - Added Question

Annie Philip, October 29, 2016 - 7:27 am UTC

Thank you very much for the answer. Is reading the source schema tables with data links and transferring with the stored proc to destination schema tables a bad idea. If so can you cite why you feel this is bad?

Annie
Connor McDonald
October 30, 2016 - 9:50 am UTC

Its often harder than you think to do this.

If there is an uncommmitted transaction on source, it can easily be missed by a home grown replication mechanism.

9am: source:
insert into T values ( "9:00:00am"); -- not committed

9:01am: target:
select * from source where date > "8:30am" (lets says thats the last refresh)
update control_table set last_refresh = 9:01am
commit;

9:02am: source
"commit"

So the source now has a row marked 9am, which the target never saw, and the next refresh will only get data from 9:01am, thus never seeing the source row.

Flashback

Duke Ganote, October 31, 2016 - 3:25 pm UTC

Even low-volume tables with hourly DIY copying would probably require flashback queries as of a certain PIT (point-in-time), especially if there are inter-table dependencies, no?
Connor McDonald
October 31, 2016 - 11:22 pm UTC

Yup. Do-it-yourself replication always *seems* easy until you have to do it :-)