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?
Related
My case is that a third party prepares a table in our schema domain on which we run different spring batch jobs that look for mutations (diff between the given third party table and our own tables). This table will contain about 200k records on average.
My question is simply: does generating a material view up front provide any benefits vs running the query at runtime?
Since the third party table will be populated on our command (basically it's a db boolean field that is set to 1, after which a scheduler picks it up to populate the table. Don't ask me why it's done this way), the query needs to run anyway.
Obviously from an application point of view, it seems more performant to query a flat material view. However, I'm not sure if there is any real performance benefit, since the material view needs to be built on db level.
Thanks.
The benefit of a materialized view here is if you are running the multiple times (more so if the query is expensive and / or there is a big drop in cardinality).
If you are only hitting the query once then you there isn't going to be a huge amount in it. You are running the same query either way and you have the overhead of inserting into the materialized view but you also have the benefit that you can tune this a lot easier than you could querying via JPA and could apply things like compression so less data is transferred back to the application but for 200k rows any difference is likely to be small.
All in all, unless you are running the same query multiple times then I wouldn't bother.
Update
One other thing to consider is coupling. Referencing a materialized view directly in JPA would allow you to update any logic without updating the application but the flip side of this is that logic is hidden outside the application which can make debugging a pain.
Also if you are just referencing a materialized view directly and not using any query rewrite or rollup features then am simple table created via CTAS would actually be better as you still have the precomputed data without the (small) overhead of maintaining the materialized view.
I'm learning about Oracle Views and I got the concept of views but little confused about performance.
I was watching video and there I listen that oracle view can increase the performance. Suppose I have created view like below.
CREATE VIEW SALES_MAN
AS
SELECT * FROM EMP WHERE JOB='SALESMAN';
Ok now I have executed query to get SALES_MAN detail.
SELECT * FROM SALES_MAN
Ok now confusion start.
I listened in video that once the above query SELECT * FROM SALES_MAN will be executed the DATA/RECORD will be placed into cache memory after hitting the oracle DB. and if I will execute same query( IN Current Session/Login ) Oracle Engine will not hit to Database and will give you record from CACHED-MEMORY is it right?
But I have read on many websites that View add nothing to SQL performance more
Another Reference that says view not help in performance. Here
So Views increase performance too or not?
A view is just a kind of virtual table defined by a query. It has no proper data and performance will depend on the underlying table(s) and the query definition.
But you also have Materialized View wich stores the results from the view query definition. Data is synchronized automatically, and you can add indexes to the view. In this case, you can achieve better performances. The cost to pay is
more space (the view contains data dupplicated),
no access to the up to date data from the underlying tables
You (and perhaps the creator of the un-cited video) are confusing two different concepts. The reason the data that was in the cache was used on the second execution was NOT because it was the second execution of the view. As long as data remains in the cache, it is available for ANY query that needs it. The very fact that the first execution of the view had to get the data from disk should be a strong clue. And what if your second use of the view wasn't until hours or days later when the data was no longer in the cache? The answer remains. A view does NOT improve performance.
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
I have been use Materialized View in Oracle11g.By Using this View, Can growth to Database size?Please let me know,disadvantages of MV.
A materialised view is best thought of as three basic components:
**
A query that defines a result set
A table to store the result of the query in, and whatever supporting indexes you add to it.
Metadata that controls the way in which the result set is refreshed, whether the result set can be used for query rewrite or
not, the state of the metadata, etc..
**
So, evidently the table and indexes are indeed going to use space.
I'm afraid that you really need to go and read the documentation for your version to understand these basic concepts, as the answer to your question is derived from basic of knowledge of what a materialised view actually is.
Materialized views are tables created(/updated) by a select at a specific time. So yes, they take some space in DB.
Learn all about Materialized view : http://docs.oracle.com/cd/B10501_01/server.920/a96567/repmview.htm
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