sam15
asked on
CopyiingRemoteTables
I have an oracle 9i web application with a slow main menu (3-5 seconds) page. The menu design is such that the page is about 20 KB in size because it builds dynamically list of vendors to view/edit data for and list of contacts, etc. Also, all the application links are listed on the main menu.
It also has a few derived numbers that are calculated real time (i.e open orders). so every time
user navigates to main menu we run the sql again.
I did a SQL trace and checked the tkprof report and found that two SQL commands that use a dblink to lookup an organzation and contact table cause the delay sometimes. It could be a network or machine issue.
The tables in the remote db which is on same machine do not get updated that often. I am also
looking up a few columns in those tables.
i am thinking of copying those remote tables locally to speed things up and refresh the tables
nightly from remote tables.
Do you agree? and how would you implement this.
WOuld you
a) create a local table with same structure and procedure and job to DELETE data and the INSERT new
data from remote table.
b Run DDL (CREATE TABLE AS SELECT * FROM TABLE@LINK) in local database to create the local table
from remote table every night..
c) WOuld you create Materialized view for local table and schedule to refresh nightly from remote
table..
Can you advise?
It also has a few derived numbers that are calculated real time (i.e open orders). so every time
user navigates to main menu we run the sql again.
I did a SQL trace and checked the tkprof report and found that two SQL commands that use a dblink to lookup an organzation and contact table cause the delay sometimes. It could be a network or machine issue.
The tables in the remote db which is on same machine do not get updated that often. I am also
looking up a few columns in those tables.
i am thinking of copying those remote tables locally to speed things up and refresh the tables
nightly from remote tables.
Do you agree? and how would you implement this.
WOuld you
a) create a local table with same structure and procedure and job to DELETE data and the INSERT new
data from remote table.
b Run DDL (CREATE TABLE AS SELECT * FROM TABLE@LINK) in local database to create the local table
from remote table every night..
c) WOuld you create Materialized view for local table and schedule to refresh nightly from remote
table..
Can you advise?
ASKER
Data hardly changes in those tables but still i need to copy it nightly. I only use a few columns so i was wondering if i copy a aubset of the table.
But why cant you DELETE and INSERT into a table too.
I guess if i went with MV solution i would still need a job to refresh it nightly.
But why cant you DELETE and INSERT into a table too.
I guess if i went with MV solution i would still need a job to refresh it nightly.
you can set up the materialized view to refresh each night (sysdate+1). A refresh group will be created automatically for this task (implicit job). Don't need to create an aditional job.
Of course, you can also delete and insert (manually or using a job), but this way you have the two "tables" consistently related, and you will not need to run anything to sync them.
Of course, you can also delete and insert (manually or using a job), but this way you have the two "tables" consistently related, and you will not need to run anything to sync them.
Why do manually what the database can do for you automatically? As suggested, use the materialized view approach as suggested. With a log on the master table it will track every changed row and only move what needs to be moved at the time of refresh.
Materialized views can be build with a subset of data. Be sure that check the rules for fast refresh to ensure that you are still able to do a fast refresh. That way only changes need to be propogated.
Materialized views can be build with a subset of data. Be sure that check the rules for fast refresh to ensure that you are still able to do a fast refresh. That way only changes need to be propogated.
ASKER
I normally use this format MV for complex sql and refresh via job nightly.
CREATE MATERIALIZED VIEW MV_SUMMARY_REPORT
build immediate refresh on demand
as
SQL Query
For this case to copy remote tables shall i make READ only view
CREATE MATERIALIZED VIEW hr.contacts FOR UPDATE AS
SELECT * FROM hr.contact@hr_link;
How often this will refresh though if i only want it nightly?
CREATE MATERIALIZED VIEW MV_SUMMARY_REPORT
build immediate refresh on demand
as
SQL Query
For this case to copy remote tables shall i make READ only view
CREATE MATERIALIZED VIEW hr.contacts FOR UPDATE AS
SELECT * FROM hr.contact@hr_link;
How often this will refresh though if i only want it nightly?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Great. so i dont need a job to refresh nighly using the log approach instead of ON DEMAND.
How can i tell that the MV is getting refreshed though. Can i add another timestamp column to the VIEW to check if it is getting refreshed and has up to date data nightly?
just in case DB was down or MV refresh failed .
How can i tell that the MV is getting refreshed though. Can i add another timestamp column to the VIEW to check if it is getting refreshed and has up to date data nightly?
just in case DB was down or MV refresh failed .
The log is not what generates the job. The specifications of START WITH and NEXT set up the job for you.
You can check DBA_MVIEW_REFRESH_TIMES to see when the last time a view was refreshed.
You can check DBA_MVIEW_REFRESH_TIMES to see when the last time a view was refreshed.
ASKER
yes, that view has it. I guess i dont need to add a TIMESTAMP column in the MV_table itself.
In case the remote DB was down for days, would the MV delete the data it has or it keeps it until remote DB comes back up.
In case the remote DB was down for days, would the MV delete the data it has or it keeps it until remote DB comes back up.
If the master database was down or not accessible for days, the view would not be refreshed. Any data in the view would remain. It would not be deleted.
This may not be true of a complete refresh, however since you are setting up a fast refresh, it should not be an issue.
This may not be true of a complete refresh, however since you are setting up a fast refresh, it should not be an issue.
ASKER
Excellent answer.
I have another question on MV but i will post separately. it is for storing a derive value so it may need diff implementation than this. I will post it now.
I have another question on MV but i will post separately. it is for storing a derive value so it may need diff implementation than this. I will post it now.
Make it fast refreshable using materialized view logs, and it will run quite fast :)
Kind regards,