Good day,
Is it technically possible to create a materialized view against a another view in the master database (as opposed to a solid table)?
My DBA advises that oracle does not allow creation of materialized view logs against a view. IMO a view is pretty much the same as a table, so it ought to be possible.
Has anyone ever done this successfully (Oracle 11g).
The documentation is pretty clear about this:
Restrictions on Master Tables of Materialized View Logs
The following restrictions apply to master tables of materialized view logs:
You cannot create a materialized view log for a temporary table or for a view.
You cannot create a materialized view log for a master table with a virtual column.
A view is not pretty much the same as a table. It's a stored query, so it has no storage and DML is only possible through instead-of triggers. It doesn't have the basis for noticing an underlying data change.
Just thinking about it, in order to support a view log - even for a simple single-table view - an update to the view's base table would have to check if there were any views; check if any of those had materialized view logs; and then work out if the change needed to be logged - which would mean executing each view's query and looking at the entire result set. Imagine doing that for every change to the underlying table. And then imagine a more complicated view query, with aggregates or multiple tables, etc.
You'd effectively be materialising the view query to decide whether was a change that needed to be logged, to update an actual materialized view. This is partly what actual materialized views do - stop you having to repeatedly re-execute an expensive view query by tracking changes on the master table(s).
You have to create the materialized view logs on the (normal) view's base tables.
Related
I am migrating Oracle objects to Snowflake. I have materialized view in Oracle that fetches data from multiple tables but in Snowflake a materialized view can be created on single table only. Can I use Oracle materialized view script and use it as a simple view to load into a temporary table and then use this temporary table to create a materialized view on top of it?
Can I use Oracle materialized view script and use it as a simple view to load into a temporary table and then use this temporary table to create a materialized view on top of it?
No, this won't work. A materialized view in Snowflake cannot be based on another view. But don't despair, just because you needed a materialised view in Oracle does not mean that you will need one in Snowflake ! On the contrary, it is typical in scenarios where a materialized view was needed in traditional RDBMS, that no special handling is required in Snowflake due to it's superior performance. Snowflake recommends the following considerations when deciding to use a materialized or regular view:
Create a materialized view when all of the following are true:
The query results from the view don’t change often. This almost always means that the underlying/base table for the view doesn’t change often, or at least that the subset of base table rows used in the materialized view don’t change often.
The results of the view are used often (typically significantly more often than the query results change).
The query consumes a lot of resources. Typically, this means that the query consumes a lot of processing time or credits, but it could also mean that the query consumes a lot of storage space for intermediate results.
Create a regular view when any of the following are true:
The results of the view change often.
The results are not used often (relative to the rate at which the results change).
The query is not resource intensive so it is not costly to re-run it.
I'm new to oracle and materialized views. I have created a view for data that was producing a big bottleneck in our application. For reducing the complexity of the virtual view, the data were divided in respective part virtual views reflecting some business domain. I.e. the main virtual view which I want to use for the materialized view contains data joined from the part virtual views.
My question is, if I can create a materialized view from the main virtual view. Forther, II would like the data updated by each commit.
create materialized view log on main_view;
create materialized view main_view_mv refresh fast on commit
as select col_1 from main_view;
commit;
Is it possible to create the materialized view? Are these commands OK to refresh the materialized view?
Thnaks for the any hint.
To answer your question: no, you can't create materialized view logs on a view - only on tables. The requirements for a FAST refreshable materialized view are described in this answer
Materialized views aren't a magic tool to make slow views execute fast. You'll probably have to examine why the main view is slow.
May I know the difference for these two items?
Data in materialized view can be refresh but so as view when we use select statement. Why not just use view instead of materialized view?
When you need performance on data that don't need to be up to date to
the very second, materialized views are better, but your data will be
older than in a standard view.
While creating Materialized view Oracle creates two objects, a table where the results are actually materialized and a materialized view that has all the metadata (the query, the attributes, etc.).
But while creating View Oracle creates only one object, which has all the metadata(the query, the attributes, etc.)
You use materialized views for performance reasons mainly.
According to the Oracle docs:
A materialized view is a replica of a target master from a single point in time.
A regular view loads data 'on demand' and can 'automatically' change when the underlying data changes.
Good afternoon,
I have 3 databases; the SIDs are config, prod1 and prod2.
I am using Materialized Views to replicate data on 11 tables in the config database onto the other two databases. The Materialized Views are currently refreshing every five seconds but it would be ideal if they were updated on commit.
I came across this website that explains that when replicating from a remote database that on commit is not supported.
This is what I was expecting to work
CREATE MATERIALIZED VIEW "schema"."table" USING INDEX REFRESH FORCE ON COMMIT AS select column1 from schema.table#config;
The method "refresh fast on demand with primary key" is suggested in the link but obviously this is on demand. I am wondering what ideas anyone may have in order to get a refresh-on-commit environment running if possible?
Thanks
You can't create a materialized view refreshed on commit from a remote table. From the documentation:
Restrictions on Refreshing ON COMMIT
This clause is not supported for materialized views containing object types or Oracle-supplied types.
This clause is not supported for materialized views with remote tables.
The reason is that the database link is defined in the "child" database, not in the "parent" database. Therefore, the parent database can't possibly trigger or modify anything in the child database on its own.
If you want a 100% real-time copy of a table, I suggest a view.
If you want to replicate the data on commit, you could modify your DML procedures so that they update the children remote tables at the same time.
How can I update a materialized view? Is there any downside to updating materialized views? I'm in a situation where I can either
Update the materialized view (OR)
Copy the records to another table, update them, truncate or drop the materialized view table, insert the updated records back into the materialized view.
These two options revolve around the long amount of time required to rebuild the materialized view (literally 5+ days).
Version : Oracle 10g
The intention of a materialized view is to store the results of some complex long running query that the query rewrite mechanism can use to save lots of time. It looks like the sql that is used to build the MV needs some tweeking.
You cannot update an MV, unless you meant doing a full/fast refresh/rebuild.
What is eating the time in during the MV refresh? Did you check the addm reports?
Did you configure full or fast refreshes?