Question

I need to replicate a table from an external db to an internal db for performance reasons. Several apps will use this local db to do joins and compare data. I only need to replicate every hour or so but if there is a performance solution, I would prefer to replicate every 5 to 10 minutes.

What would be the best way to replicate? The first thing that comes to mind is DROP and then CREATE:

DROP TABLE clonedTable;
CREATE TABLE clonedTable AS SELECT * from [e-mail];

There has to be a better way right? Hopefully an atomic solution to avoid the fraction of a second where the table doesn’t exist but someone might try to query it.

Answer 1

The simplest possible solution would be a materialized view that is set to refresh every hour.

CREATE MATERIALIZED VIEW mv_cloned_table
  REFRESH COMPLETE 
  START WITH sysdate + interval '1' minute
  NEXT sysdate + interval '1' hour
AS
SELECT *
  FROM foo.external_table@database_link;

This will delete all the data currently in mv_cloned_table, insert all the data from the table in the external database, and then schedule itself to run again an hour after it finishes (so it will actually be 1 hour + however long it takes to refresh between refreshes).

There are lots of ways to optimize this.

• If the folks that own the source database are amenable to it, you can ask them to create a materialized view log on the source table. That would allow your materialized view to replicate just the changes which should be much more efficient and would allow you to schedule refreshes much more frequently.
• If you have the cooperation of the folks that own the source database, you could also use Streams instead of materialized views which would let you replicate the changes in near real time (a lag of a few seconds would be common). That also tends to be more efficient on the source system than maintaining the materialized view logs would be. But it tends to take more admin time to get everything working properly– materialized views are much less flexible and less efficient but pretty easy to configure.
• If you don’t mind the table being empty during a refresh (it would exist, it would just have no data), you can do a non-atomic refresh on the materialized view which would do a TRUNCATE followed by a direct-path INSERT rather than a DELETE and conventional path INSERT. The former will be much more efficient but will mean that the table appears empty when you’re doing joins and data comparisons on the local server which seems unlikely to be appropriate in this situation.

If you want to go down the path of having the source side create a materialized view log so that you can do an incremental refresh, on the source side, assuming the source table has a primary key, you’d ask them to

CREATE MATERIALIZED VIEW LOG ON foo.external_table
  WITH PRIMARY KEY
  INCLUDING NEW VALUES;

The materialized view that you would create would then be

CREATE MATERIALIZED VIEW mv_cloned_table
  REFRESH FAST
  START WITH sysdate + interval '1' minute
  NEXT sysdate + interval '1' hour
  WITH PRIMARY KEY
AS
SELECT *
  FROM foo.external_table@database_link;