If you are using the enterprise edition of the database, it sounds like you could use either Streams or materialized views to replicate the data.
Streams works by asynchronously mining the redo data that is generated on the source system to find changes to the tables in question which then get delivered to the destination database using Oracle's Advanced Queues (AQ). Streams is generally the preferred architecture-- it is the newer technology, it generates less load on the source system, it doesn't involve creating any new objects in the source system and has lower latency. The downside to Streams is that there can be a decent amount of administrative work getting Streams set up and working depending on the Oracle version(s) involved.
Materialized views are an older replication technology that would also seemingly meet your needs. Materialized views work can also replicate changes but they have to do so by recording the change data in materialized view logs that are created on the tables that you want to replicate. On the source system, you'd need to create materialized view logs on the tables you want to replicate-- those logs would be automatically written to when changes are made to the table but those writes will be synchronous with the transaction so it may affect INSERT and UPDATE performance. On the destination side, you would then create a materialized view that did an incremental refresh on a set schedule (i.e. every few minutes) that would read the data from the materialized view logs, pull the data over the network, and update the materialized view's copy of the data. Materialized views tend to be easier to set up but they're not as efficient and the requirement of creating materialized view logs in the source database can be a point of contention.
Either solution is relatively easy to shut down in 2 months when you no longer need the replication.
