I have the following materialized view -
CREATE MATERIALIZED VIEW TESTRESULT
ON PREBUILT TABLE WITH REDUCED PRECISION
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS
SELECT...
FROM...
WHERE...
This materialized view has no backing MATERIALIZED VIEW LOG. As seen in the clause above this MV has "ON DEMAND" specifies, and according to Oracle documentation,
"[ON DEMAND] indicate[s] that the materialized
view will be refreshed on demand by
calling one of the three DBMS_MVIEW
refresh procedures."
When I call DBMS_MVIEW.REFRESH('TESTRESULT') , what is occuring? Is it manually checking each record to see if it has been updated?
Oracle Version: 10g
By default (and this default changes in different versions of Oracle), that will do a full, atomic refresh on the materialized view. That means that the data in the materialized view will be deleted, the underlying query will be re-executed, and the results will be loaded into the materialized view. You can make the refresh more efficient by passing in a value of FALSE for the ATOMIC_REFRESH parameter, i.e.
dbms_mview.refresh( 'TESTRESULT', atomic_refresh => false );
That will cause the materialized view to be truncated, the query re-executed, and the results inserted into the materialized view via a direct path insert. That will be more efficient than an atomic refresh but the materialized view will be empty during the refresh.
Related
I created a materialized view which significantly sped up
select * from table
query above. After, I dropped materialized view, this query is still returning records as fast as with materialized view.
I used drop materialized view viewname query to drop MV. Do I need to do anything else to return table to previous state ?
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.
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.
I have two tables, TABLE_1 and TABLE_2. Then we have a synonym called TABLE that points to either TABLE_1 or TABLE_2. When TABLE_1 is active, an ETL populates TABLE_2 and when the run is complete, it switches the TABLE synonym to TABLE_2 to make it the active table. Then I have a materialized view that does something like this as the SQL: select * from TABLE. What I am seeing happen is that after the materialize view runs the first time, it caches the actual table the synonym is pointing too. So when the ETL runs and flips the synonym to point at TABLE_2, when a complete refresh is done on the materialized view, it still thinks the synonym is pointed at TABLE_1. Why when I do a complete refresh does the materialized view not pick up the new synonym pointer to TABLE_2?
Here is a workaround to Oracle's bug:
alter materialized view MV_NAME nocache;
BEGIN DBMS_SNAPSHOT.REFRESH( MV_NAME,'C'); end;
alter materialized view MV_NAME cache;
I cannot find anything useful in Oracle documentation but just enable the logic:
I firstly create materialized view
In reality to support this materialized view Oracle makes the TABLE with some specific structure (dependent on your query structure) and the rule to refresh the table (as far as I remember it is called SUMMARY, but the name does not play any role here)
I change synonym target to the table which has another structure
The new target table is not "fitting" to the previous structure (e.g. it has totally different amount/data types of columns), the previous structure is invalid then and not working anymore. The underground table must be recreated then.
That's why I would say it is the only way to prevent the errors: reference the real target instead of synonym for creating materialized view.
So, the answer is: because the materialized view is a static table-like object dependent on the data set it is selecting; that's why to prevent the inconsistencies materialized view references the real object.
Sometimes I really wonder how many details Oracle hides inside.
In one of our applications, we have a massive Materialized View that refreshes three times a day, and takes seven hours to refresh. (Not ideal, I know). This perplexed me, because I surely thought that users and sessions could not access this materialized view while it was being refreshed, but apparently they can!. (The type of refresh is a complete refresh)
During a complete refresh, to my understanding, the existing dataset is dropped and the query is then re-executed. If this is true, then how are users/other sessions able to access the materialized view while the materialized view is being refreshed?
There are two different ways that a complete refresh can happen-- an atomic refresh or a non-atomic refresh. An atomic refresh simply issues a DELETE to delete all the rows in the materialized view and then does an INSERT to insert the new data. This is all within a single transaction so Oracle's standard multi-version read consistency architecture lets Oracle show other sessions the old data until the refresh completes. In a non-atomic refresh, Oracle does a TRUNCATE on the materialized view and then a direct-path INSERT to insert the new data. This is substantially more efficient but since TRUNCATE is DDL, it means that the old data is not visible to other sessions during the refresh.