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
Related
We need to implement CQRS in our microservice architecture(SAGA). I have the following doubts regarding the materialized view in the read database.
Is CQRS materialized view refers to the actual tables?
Suppose we have different formats of reports from the same tables, do we need to keep multiple views?
In the future, if we need a schema/format change, how do we incorporate that change into view?
a) if rebuilding the view is possible, does it take time and resources?
b) if so, arethere any alternatives
I have gone through many examples. But didn't get a clear picture about materialized view.
Appreciate your answers.
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
Where are view constraints useful? By that I mean, Oracle allows a constraint to be created on a view. They are not enforced by the database. It seems to be just more metadata that can be used by the database, but I'm trying to understand under what circumstances they are useful.
Tom Kyte answered in a question:
They are used for complex query rewrites with materialized views and such. It is more "meta data"
-- it gives the optimizer more information, allows for a broader range of query rewriting to take
place.
... but that's a bit brief.
From Oracle Documentation :
View Constraints
You can create constraints on views. The only type of constraint supported on a view is a RELY constraint.
This type of constraint is useful when queries typically access views instead of base tables, and the database administrator thus needs to define the data relationships between views rather than tables. View constraints are particularly useful in OLAP environments, where they may enable more sophisticated rewrites for materialized views.
Quoted another Oracle Documentation page, but never used constraints on views anyway.
Minor use in an Oracle product. In the Designer-generated PL/SQL web applications, components based on views needed a primary key defined on the view. That allowed the application to hyperlink from a list of records to a single-record display.
I remember seeing a few cases with Hibernate where it generated better code when there were PK and FK constraints defined on views. (Can anybody else confirm that?)
And Tom points to query rewrite.
So I think the answer is "if your tools can use the information, then it's better to supply it." Of course, it's going to be hard to figure out which tools will use it.
I try to include them because
It's not much work, though the scripts to recreate views are somewhat more complicated.
It helps in making the physical implementation of the logical model complete
It reminds me of real data constraints that I need to implement somehow, via triggers or background packages or in a "constraint violation" report.
IF a create thousands of view, Does it hamper the database performance. I mean is there any problem with creating thousands of view in oracle. Please explain as I am new in this area...I am using oracle...
The simple existence of these views shouldn't harm performance at all. However, once those views start being used it's possible that there will be some negative performance impact. Oracle tries to "remember" the plan for each statement that it sees, but it compares statements by comparing the source code (the SQL). Your thousands of views will all be named differently since you can't have multiple views with the same name, and thus each time one of them is used Oracle is going to have to do a full parse of the SQL, even if it's something as basic as
SELECT * FROM VIEW_1;
and
SELECT * FROM VIEW_2;
All these re-parses will certainly take some time.
What's different about each of these views? I think it might be a good idea to step back and consider other possibilities. Questions I'd ask include
What is to be accomplished here?
Why are thousands of different views needed?
Is there some other way to accomplish what needs to be done without creating all these views?
I don't know the answers to 1 and 2, but I'm reasonably sure that the answer to #3 is "Yes".
Good luck.
Oracle views are an encapsulation of a
complex query and must be used with
care. Here are the key facts to
remember:
Views are not intended to improve SQL
performance. When you need to
encapsulate SQL, you should place it
inside a stored procedure rather than
use a view. Views hide the complexity
of the underlying query, making it
easier for inexperienced programmers
and end users to formulate queries.
Views can be used to tune queries with
hints, provided that the view is
always used in the proper context.
source: Guard against performance issues when using Oracle hints and views
View is as heavy to run as the select that creates it but Oracle loads balance and single select can't harm the DB. If you have thousands concurrent selects going then you might have a problem. The amount of views is not important but how heavy they are and how much you use them.
You would actually need to show the views code and tell what you are actually trying to do.
View should not affect performance, if optimizer is smart enough. I remember cases with other DB engines when Views do harm performance. As in many performance cases - I suggest to measure your particular case.