Home » RDBMS Server » Performance Tuning » "Fast refresh" MV too slow
"Fast refresh" MV too slow [message #476450] Thu, 23 September 2010 06:29 Go to next message
ss1_3
Messages: 4
Registered: December 2009
Junior Member
Hi,

We have a MV which fetches data from around 27 tables containing 26 joins out of which 25 are outer joins. Some tables in the query are being referred multiple times through different alias names and hence the actual no of physical tables used is 18. This MV takes about 50 mins to refresh through complete refresh mechanism. We decided to make it fast refresh and thus made these configurations:

- Created MV logs based on rowid for each of the base tables.
- Recreated MV using FAST refresh,with primary key option enabled
- Pulled rowid for all these tables in the select column statement.

Even after making all the recommendations suggested by Oracle for fast refresh MV's we are still getting refresh time of around 65 mins(refresh time increased!!!).We already have indexes built on all the join columns of the base tables. What else do we need to do to make this a "fast" refresh MV ?

Thanks
Re: "Fast refresh" MV too slow [message #476457 is a reply to message #476450] Thu, 23 September 2010 07:53 Go to previous messageGo to next message
Michel Cadot
Messages: 68716
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator
Quote:
What else do we need to do to make this a "fast" refresh MV ?

Nothing, joining 27 tables with 25 outer joins can only lead to bad peformances. There can't be NO fast refresh for this.

Regards
Michel
Re: "Fast refresh" MV too slow [message #476733 is a reply to message #476457] Fri, 24 September 2010 18:03 Go to previous message
rleishman
Messages: 3728
Registered: October 2005
Location: Melbourne, Australia
Senior Member
Michel Cadot wrote on Thu, 23 September 2010 22:53
Quote:
What else do we need to do to make this a "fast" refresh MV ?

Nothing, joining 27 tables with 25 outer joins can only lead to bad peformances. There can't be NO fast refresh for this.

Regards
Michel

Hogwash.

If those 27 tables are all heavily updated, I'd agree. But we don't know the distribution of data or the way in which the data is changed. What if only a couple of those tables change?

Run SQL Trace when refreshing, and use TKPROF to obtain readable output from the trace. The TKPROF output will contain the internal SQL Oracle used to refresh the MV.

Find the bad SQL and start tuning. Of course, you cannot change the text of the SQL, but you can add indexes to base table and MV Logs, and also gather statistics on base tables, MV Logs, and their indexes when the CBO is making bad choices.

If you like, past the SQL, plan and statistics from TKPROF here and one (or more) of us might take a look.

Ross Leishman

[Updated on: Fri, 24 September 2010 18:03]

Report message to a moderator

Previous Topic: will effect the performace of DML on Fast refresh of Materialized view
Next Topic: Flushing Buffer Cache.
Goto Forum:
  


Current Time: Fri Nov 22 06:53:18 CST 2024