Does anyone have the best way to optimize an materilaized view drawing from a View in a database on a monthly basis. I have used the "standard" but are there any other bells and whistles that could provide quick and efficent Views of refreshing data and reducing query time?
Thanks in advance.
MATERIALIZED VIEW Table_X
REFRESH
FAST
START WITH SYSDATE
NEXT DATE '2016-01-01' + 31
WITH PRIMARY KEY
As <Query>
Refresh of a materialized view, whether fast or complete, is just as amenable to performance tuning as any other operation, and generally by just about the same methods.
A refresh is just an encapsulation of various queries against the base tables, materialized view logs, the materialized view, and system tables, and all you need is insight into the complete process. It's important to realise that everything is just SQL, and that means you can add indexes, modify memomry allocations, use partitioning, and just about every other procedure
The best mechanisms for getting insight are Oracle own tools, such as AWR or event tracing. I've used both, but the latter is very insightful and will give you precise information on where the refresh time is being spent. When you see the SQL itself by using event tracing, you can probably work out where any missing indexes etc are. Look out for the potential to index on Sys_Op_Map_Nonnull(column_name).
So, having said that the techniques are all pretty standard, here are some links with info too long/specific too include here.
https://oraclesponge.wordpress.com/2006/04/12/a-quick-materialized-view-performance-note/
http://oraclesponge.blogspot.co.uk/2005/09/optimizing-materialized-views-part-i.html
http://oraclesponge.blogspot.co.uk/2005/09/optimizing-materialized-views-part-ii.html
https://oraclesponge.wordpress.com/2005/11/23/optimizing-materialized-views-part-iii-manual-refresh-mechanisms/
https://oraclesponge.wordpress.com/2005/12/08/optimizing-materialized-views-part-iv-introduction-to-holap-cubes/
http://oraclesponge.blogspot.co.uk/2005/12/optimizing-materialized-views-part-v.html
Related
Here is current scenario - We have 3 tables in Oracle DB (with millions of records) which are being used to generate SSRS reports.
These reports are displaying complex data calculation such as deviations, median etc.
SSRS fetch data using stored procs in oracle (joining all the 3 tables) based on date parameters
Calculations are performed in SSRS and data is displayed in tables and charts
Now, for small date duration, report is getting generated quite fast, so no issues there.
When date range is big like a week or 2-3 months, report takes lot of time to process and most of the time it gets timed out as well.
To resolve this issue, I am thinking to remove calculations from SSRS and move them to DB level. Where we can have pre-calculated data
which will be served to SSRS reports for faster report generation.
In order to do this, I can see 2 options -
Oracle Materialized Views
SSAS Cube
I have never used Materialized Views before, so I am a bit skeptical about its performance specially FAST REFRESH issues.
What way would you prefer? MV or SSAS or mix of both?
Data models (SSAS) are great for organizing data, consolidating business logic, and defining how calculations behave in different scopes. They are generally faster to query than the raw data which is what you currently have. There is some caching involved, but you still have to query the data and wait for it to be processed. Models are also most appropriate when you have multiple reports that will be using a common set of data.
With a materialized view, you can shift the heavy lifting of calculation time to the scheduled refresh. Think of it as essentially the same as creating a new table that is refreshed by a procedure. This will greatly improve query times for the report especially if the date column you're filtering on is indexed. Also, the development and maintenance requirements are much lower for this than a model.
So, based on your specifications I would suggest the materialized view.
I would concur with the Materialized View (MV) approach. Depending on the amount and type (insert vs update vs delete) would determine if a fast refresh is possible or practical.
Counter intuitively, a FULL refresh is often a better approach, since you can better take advantage of set based SQL processing, together with parallelism to build the MV.
So I have been working with Oracle support over an Materialized view compile issue with our dataguard standby database and they recommended turning off query rewrite (setting query_rewrite_enabled=false). We have many MV's that have "enable query rewrite" in them, so I am a little hesitant to turn it off and cause potential performance problems..
Is there any way to tell if the MV's are in fact using query rewrite (perhaps a V$ view or something?)? When I tested querying one of the base tables it did not use the materialized view and an explain plan showed a full table scan. I am thinking that most our the queries wouldn't be rewritten, but I wanted to be sure before making a change.
Also, are there any other big impacts I should be aware off if I turn off query_rewrite_enabled?
So I have a process to design where there are few base tables on which I have to create a view and from that view I will extract and derive data and insert into an another table.
we would use this last table for extracting reports
This process will run daily, since the data on the base tables have updates have everyday.
he whole purpose of this process is to make things "faster" for reporting,
So my concern here is with using the view. I am wondering if a materialized view would be better to use here in terms of performance instead the view or view itself would be the better.
Has anyone had to deal with such situation and found an approach that performs well and works efficiently??
Any leads on this would be highly appreciated
I have been researching using materialized views for data aggregation and reporting purposes for a company that is largely centered around transactions (using an Oracle db). The current reporting system is dependent upon a series of views that obscure a lot of the complex data logic of the application. These views place a heavy burden on the system when they are called.
We are interested in using the "fast refresh" for incremental updates to perform some of the complex query logic prior to use in reporting; however, there is a concern within the organization that the materialized view logs (which are required for this fast refresh) will have an impact on our current transaction performance in the database. This performance is very essential to our organization therefore there is a great fear of any change.
Here is an example of the type of materialized view log we would need to implement:
create materialized view log on transaction
with rowid, sequence(transaction_id,account_id,order_id,currency_id,price,transaction_date,payment_processor_id)
including new values;
We would not be using the "on commit" clause for updates but rather the "on demand" clause in creation of the view, as we understand this would have a performance impact.
Will implementing this type of logging affect database transaction performance? I imagine that it must slightly affect performance as there is an additional write procedure (to the log) that is wrapped in the commit, but I cannot find any reference to this in the Oracle documentation. Any literature or advice on this subject would be greatly appreciated.
Thanks for your help!
Yes, there will be an impact. The materialized log needs to be maintained synchronously so the transactions will need to insert a new row into the materialized view log for every row that is modified in the base table. How great an impact depends heavily on the system. If your system is I/O bound and you've optimized it so that physically writing the changes to the base table is a significant fraction of the wait time, the impact will be much greater than if your system is CPU bound and most of your wait time is spent reading data or performing computations.
If you are really concerned about the performance of the OLTP system, it would make sense to offload reporting to a different database on a different server. You can replicate the data to the reporting server using Streams (or GoldenGate if you can afford the additional licensing) which will have less of an impact on the source than materialized views because the redo information can be read asynchronously (and can be read on the reporting server rather than putting that workload on the production server). You could then define materialized views on the reporting server where they won't have any impact on the OLTP server. Or you could create a logical standby database as your reporting server and create the materialized views there. Either way, moving the reporting workload off the production server and reading the redo data asynchronously will protect the performance of the production server.
i am new to oracle.Already there is a store procedure which fetches data from many tables.Due to performance issue,i need to modify it.So i want to know about materialised view (since,i already searched it in net,but i am not able to understand it).can anyone explain the features of it?
Also,i am using TOAD for oracle.Can someone suggest me any materials(book,websites etc.) to learn?
I'll take the Toad portion - you can get a ton of great help online for free at ToadWorld.com. I have a 35 page free tutorial there as well link text
Materialized View is covered in the documentation (eg here).
They don't make anything magically run faster. They move the performance hit (eg refresh the view at midnight and your procedure may run faster at 9am) but possibly at the expense of being 'up-to-date'. Or you could have REFRESH ON COMMIT MVs which can be more up to date, but maybe at the expense of concurrency and are also 'time shifting' work to when inserts/updates are done rather than queries.
MVs would be a long way down the list of things I'd consider for fixing a problem in a specific stored procedure.