How to do data refresh

Question

Hi,
I'm required to refresh our production database from a warehouse. There are a number of tables to be refreshed.
Now, I cannot have materialized views that does incremental refreshes since the tables in the warehouse do not have mview logs on them. So I go for full table refreshes. So I create a temp tables, refresh that first, and then post it into the production tables. I use the temp tables instead of the production tables refreshing directly off the remote tables to reduce the refresh time of the production tables. Please find below the sample code.
begin
execute immediate 'create table table1_temp as select * from remote_tab@dblink';
execute immediate 'drop table prod_table1';
execute immediate 'create table prod_table1 as select * from table1_temp';
execute immediate 'drop table table1_temp';Now, I've read this somewhere that temporary tables can fragment disk space and degrade DB performance over time.
Could you please suggest any alternative strategies for this task, and their pros and cons?
Thanks,
CJM

Answer 1

user13102515 wrote:
I'm required to refresh our production database from a warehouse. There are a number of tables to be refreshed.
Now, I cannot have materialized views that does incremental refreshes since the tables in the warehouse do not have mview logs on them. That is not a valid reason for not using materialised views.
A materialised view can be done as an incremental refresh and as a full refresh.
So I go for full table refreshes. So I create a temp tables, refresh that first, and then post it into the production tables. So how is your approach for a full table refresh then better?
I use the temp tables instead of the production tables refreshing directly off the remote tables to reduce the refresh time of the production tables.
begin
execute immediate 'create table table1_temp as select * from remote_tab@dblink';
execute immediate 'drop table prod_table1';
execute immediate 'create table prod_table1 as select * from table1_temp';
execute immediate 'drop table table1_temp';
This code reads X amount of rows (using a very expensive server operation, called I/O). It writes X amount of rows into a temp table (using a very expensive server operation, called I/O).
It then reads X amount of rows from the temp table (using a very expensive server operation, called I/O). Finally writes X amount of rows into a the production table (using a very expensive server operation, called I/O).
So.. your approach is reading and writing the SAME data set, consisting of the SAME X amount of rows, twice. Spending the most expensive of all server operations, I/O, on it.
Now how is this better than simply doing all this, once - using a single materialised view refresh?
Now, I've read this somewhere that temporary tables can fragment disk space and degrade DB performance over time.Your approach is already degrading server performance by hitting the same dataset twice - doing double the amount of I/O needed. Why worry about hypothetical fragmentation, and what a temp table may do or may not do..?