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
Related
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.
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 am new to oracle and i wanted to know if materialized views can be created on top of views. I also need a column in the mview that has a complex calculation for which I am thinking of writing a function.
There are materialised views, and then again there are materialised views.
By which I mean that the capabilities of the materialised view can vary greatly with respect to query rewrite and refreshability according to the exact nature of the tables (or views) that it references, and according to their properties.
So although you might be able to create an MV that references a view, whether it is useful to you or not is a matter that depends on a great many other issues.
I find that the documentation can sometimes be unclear, particularly in edge-cases, and the best approach is generally to create the MV and then to test its capabilities using Oracle built-in procedures -- here's a link to DBMS_MView for 10.2 http://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_mview.htm#CEGGEHHC
Is it possible to create a view in a database A of tables of another database B? If possible, can somebody please help me, I'm totally clueless.
Of course, just use a database link. So, your view would be:
create or replace view my_view as
select some_columns
from my_table#the_other_database
Beware though it's not always that efficient and you may have some problems with queries doing things you don't expect. If there's any volume to the data you're trying to select it might be worth using a materialized view instead to take data cross server. Then you can select data from the server you're on currently, which'll probably be a lot quicker.
I am converting sybase stored procedures into oracle views. This is what they want and this is not my first choice. My question is:
Are there any limitations in oracle views? Total number of columns? Can you create indexes for views? Since I will be creating subviews and joining views within views, are there any limitations on how many layers of views you can do?
Thanks
Are there any limitations in oracle views?
Total number of columns?
are there any limitations on how many layers of views you can do
All covered here: http://docs.oracle.com/database/121/REFRN/GUID-685230CF-63F5-4C5A-B8B0-037C566BDA76.htm#REFRN0043
The number of columns in a view has the same limits as the number of columns in a table.
Can you create indexes for views?
No you cannot. However you cate create a materialized view, that can be indexed
You're limited to 1000 columns in a table. It wouldn't shock me if there was a similar limit for views. But if you're creating a view with 1000 columns, you're probably doing something very wrong.
You cannot create indexes on views but you can create indexes on the underlying tables that queries against views can use. You can index materialized views since, as the name implies, they materialize the data into a separate structure. But then you have to deal with refreshing the materialized view on commit, which adds overhead to transactions, or tolerate stale data and refresh the materialized view on some schedule.
There is no limit to the number of layers of views you can have. Depending on the Oracle version, the complexity of the views, and things like the presence of constraints, you can end up with queries that either force Oracle to do extra work (i.e. joining in additional tables in view layers that your end query doesn't actually need) or that are too complex for the optimizer to find a decent plan.
There aren't any significant limitations on the complexity of views.
The Oracle cost-based optimizer does a decent (if inscrutable) job of figuring out how to carry out queries to views using the indexes of the underlying tables.
If that performance isn't enough, you might consider looking into materialized views.
The usual way of doing the kind of project you're doing is to get the views working, then use EXPLAIN PLAN to do the optimization.