Question on materialized view unregistered on master site

Hi
not sure how it is known, on master site, about the existence of an materialized view on another site referring some table of a master site. it seems registering is not necessary.
on master site orcl1 : I have a table A, and a materialized view log defined on table A.
on another site orcl2 : have a db link to orcl1 and a fast refreshable materialized view SCOTT.A_MVW (create materialized view A_MVW refresh fast as select * from A@orcl1)
on orcl1 I perform : exec DBMS_MVIEW.UNREGISTER_MVIEW (mviewowner => 'SCOTT' ,mviewname => 'A_MVW' ,mviewsite => 'ORCL2');
as a result the materialized view seems to be successfully unregistered (as it doesn't appear anymore in : select * from DBA_REGISTERED_MVIEWS; )
But, to my surprise, I can still perform fast refreshes on A_MVW, which also remove lines from the materialized view log . so how is site orcl1 still aware about the existence of the materialized view ?
it seems that, registered or not at master site, a materialized view behaves the same...or it doesn't ? where is it stored , on master site, information about materialized views (especially those fast refreshable) that reffer local tables ?
Thank you

The view allows the Administrator at the Master (Source) site to see information about MVs in remote databases that are querying his/her database.
A database in Singapore may be administered by DBA "Hemant" . This database may have built (with appropriate permissions !!!) an MV that queries table(s) in a database in London managed by "Alex". Alex can query DBA_REGISTERED_MVIEWS in his (London) database to see that a remote MV is referencing tables locally.
Why would "Alex" UNREGISTER the MV ? There's no real need to. Unless the information needs to be "hidden" from, say, an Outsource DBA who will be taking "Alex"'s place ! (just kidding !)
Hemant K Chitale

Similar Messages

Questions on Materialized Views and MV Log tables

Hello all,
Have a few questions with regards to Materialized View.
1) Once the Materialized View reads the records from the MLOG table the MLOG's records get purged. correct? or is it not the case? In some cases I still see (old) records in the MLOG table even after the MV refresh.
2) How does the MLOG table distinguish between a read that comes from an MV and a read that comes from a user? If I manually execute
"select * from <MLOG table>" would the MLOG table's record get purged just the same way as it does after an MV refresh?
3) One of our MV refreshes hangs intermittently. Based on the wait events I noticed that it was doing a "db file sequential read" against the master table. Finally I had to terminate the refresh. I'm not sure why it was doing sequential read on the master table when it should be reading from the MLOG table. Any ideas?
4) I've seen "db file scattered read" (full table scan) in general against tables but I was surprised to see "db file sequential read" against the table. I thought sequential read normally happens against indexes. Has anyone noticed this behaviour?
Thanks for your time.

1) Once all registered materialized views have read a particular row from a materialized view log, it is removed, yes. If there are multiple materialized views that depend on the same log, they would all need to refresh before it would be safe to remove the MV log entry. If one of the materialized views does a non-incremental refresh, there may be cases where the log doesn't get purged automatically.
2) No, your query wouldn't cause anything to be purged (though you wouldn't see anything interesting unless you happen to implement lots of code to parse the change vectors stored in the log). I don't know that the exact mechanism that Oracle uses has been published, though you could go through and trace a session to get an idea of the moving pieces. From a practical standpoint, you just need to know that when you create a fast-refreshable materialized view, it's going to register itself as being interested in particular MV logs.
3) It would depend on what is stored in the MV log. The refresh process may need to grab particular columns from the table if your log is just storing the fact that data for a particular key changed. You can specify when you create a materialized view log that you want to store particular columns or to include new values (with the INCLUDING NEW VALUES) clause. That may be beneficial (or necessary) to the fast refresh process but it would tend to increase the storage space for the materialized view log and to increase the cost of maintianing the materialized view log.
4) Sequential reads against a table are perfectly normal-- it just implies that someone is looking at a particular block in the table (i.e. looking up a row in the table by ROWID based on the ROWID in an index or in a materialized view log).
Justin

Question on Materialized View Log Table

Hello,
One of our MLOG table keeps growing without the records getting flushed out ...The Materiazed view gets refreshed successfully though...The master/mlog tables are remote..
There is only one MV attached to the master table as evident from the results below...
//On the Master site
select owner,name, mview_site, mview_id from all_registered_mviews where owner='SSP' and name='TRANS_STATUS'
Owner Name MVIEW_SITE MVIEW_ID
SSP TRANS_STATUS SSPRD     12864
The above output is expected and good but I was surprised to see the output below...
select owner,master,to_char(mview_last_refresh_time,'MM-DD-YYYY HH:MI:SSAM'), mview_id from all_base_table_mviews where owner='SSP' and master='TRANS_STATUS'
Owner Master MVIEW_LAST_REFRESH_TIME MVIEW_ID
SSP TRANS_STATUS     01-27-2011 06:32:05PM     12724
SSP TRANS_STATUS     01-29-2011 12:03:06PM     12844
SSP TRANS_STATUS     06-18-2011 07:32:55AM     12864
I'm not sure why I see differnt MVIEW_IDs...We refresh this MV every day....
On 01-27-2011 it was a regular normal refresh using dbms_mview.refresh
On 01-29-2011 we had to drop and recreate our MV and then refresh it using dbms_mview.refresh
On 06-18-2011 it was a regular normal refresh using dbms_mview.refresh
Why are there different MVIEW_IDs when there is only one MV that is attached to the master table. Could this be the reason why the logs are not getting flushed out?
Thanks for your time...

What is your database version?
How did you even manage to create two objects with the same name?
As I know, it is impossible, oracle will throw errors like below:
SQL> create table FOO (str varchar2(5), num number(3,0));
Table created.
SQL> CREATE MATERIALIZED VIEW FOO
2 BUILD DEFERRED
3 REFRESH COMPLETE ON DEMAND
4 enable query rewrite as
5 select SUM(NUM)
6 from FOO GROUP BY STR;
from FOO GROUP BY STR
ERROR at line 6:
ORA-00955: name is already used by an existing object
SQL>

Question on MATERIALIZED VIEW and table

HI
there are table (name is test123) and MATERIALIZED VIEW (name also is test123) stored in the same schema (name is schema123).
If I run sql : select from schema123.test123;*
I wanna know the result data I get is data of table test123 or MATERIALIZED VIEW test123, which one of them?
Thanks in advance!

What is your database version?
How did you even manage to create two objects with the same name?
As I know, it is impossible, oracle will throw errors like below:
SQL> create table FOO (str varchar2(5), num number(3,0));
Table created.
SQL> CREATE MATERIALIZED VIEW FOO
2 BUILD DEFERRED
3 REFRESH COMPLETE ON DEMAND
4 enable query rewrite as
5 select SUM(NUM)
6 from FOO GROUP BY STR;
from FOO GROUP BY STR
ERROR at line 6:
ORA-00955: name is already used by an existing object
SQL>

Question on Materialized View

Hi All
We are executing a materialized view fast refresh and go an error on the child view
SQL> execute DBMS_MVIEW.REFRESH('ADRN_MV', nested => TRUE, atomic_refresh=>false);
BEGIN DBMS_MVIEW.REFRESH('ADRN_MV', nested => TRUE, atomic_refresh=>false); END;
ERROR at line 1:
ORA-30439: refresh of 'ADRN_CH_MV' failed because of ORA-12008:
error in materialized view refresh path
ORA-00001: unique constraint (ADRN_CH_MV_PK) violated
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2454
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
ORA-06512: at line 1
I disabled the primary key and ran the fast refresh of the parent MV(ADRN_MV), the refresh got succeeded without any error. I also looked at the MV (ADRN_CH_MV) which was complaining of primary key but found there are no duplicates.
1. What might have happened here?
2. How can we trace which row threw an error for primary key violation?
3. How can we trace what is happening in "ADRN_MV"
Any help or pointers wold be appreciated.
Thanks
SB

which was complaining of primary key but found there are no duplicates.I wonder how did you search for duplicate records??
2. How can we trace which row threw an error for primary key violation?http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:15258974323143
HTH.

Who can help to solve this question on MATERIALIZED VIEW and table?thanks

Hi,dear all.
If there is a MV with the same name as a table and they both exist in the same schema .
e.g: MV : test123 and table : test123 (they have same name) exist in schema : schema123.
when I run a sql : select * from schema123.test123; , what's the result of the execution?? MV or table which of them's data are populated???
thanks in advance!

solved.

Materialized view questions..

Hi all..
Please help me with the following question on materialized view.
I need to create a MV on my LOCAL_DB on a table which is on REMOTE_DB.
Do i need to created the materialized view log in the ""REMOTE_DB".
1)
Is there any cons using the materialized views? I mean , is there any maintence needed
when the database got shut down or
2)
I am creating the materliazied view as ""select * from table_name"".
If the base table changes, does it effect my materialized view.
I have the following sqls to create mv, please let me know whether that are correct.
-- LOCAL_DATABASE
CREATE MATERIALIZED VIEW plates_mv
REFRESH Fast
START WITH SYSDATE
NEXT SYSDATE + 1
AS SELECT * FROM plates@home_dmv.world;
-- REMOTE_DATABASE or LOCAL_DATABASE??
CREATE MATERIALIZED VIEW LOG ON plates;
Thank in advance.

+Do i need to created the materialized view log in the ""REMOTE_DB".{code}+
Yes.If you want your materialized view is fast refreshable.
+{code}
1)
Is there any cons using the materialized views? I mean , is there any maintence needed
when the database got shut down{code}+
It all depends.If remote data base got shut down Materialized view won't refresh. refresh will fail and oracle try again to refresh till it reaches max failure count i.e 16.
If current DB got shut down ....It is like a regular table and it will refresh as per next refresh scheduled time.May be this time it would do complete refresh.
+{code}2)
I am creating the materliazied view as ""select * from table_name"".
If the base table changes, does it effect my materialized view.{code}+
Never create a Mview using "select *". If Remote DBA added/Dropped columns for remote table then your Mview refresh will end up with errors.So Always specify the column names in the definition.
create mview log on Remote table. first time it will do the complete refresh and from next refresh it will use the Mview log to fast refresh. Use refresh Method as "Force" let oracle decide which refresh it wants to do.
Hope this info helpful!
First read the documentation or related information and understand about the Materialized views then implement or Test it in your Dev or your localDB environment.

[help]why data on table (master ) different from materialized view(slave)?

We have had Oracle RAC 2 Groups (master and slave).
We have created materialized from slave to master. and I have created materialized view log on master .
When slave group job is broken a long time(12 Hrs). We refreshed job and runned job id.
But I have found database on materialized view (slave) different from TABLE on master group. (m$log =0row)
Please tell me how can we resolve Or because that problem is m$log

Yes I do have a unique identifier on each record in the base table and therefore also in the MV.
So now the Downstream application has to update some of its own database tables based on what is in the MV that I provide - just so I understand how would that work e.g.:
1. MV gets refreshed from my base table every minute
2. Some records are newly inserted and some simply updated
and this is the part I don't understand (I might be missing something obvious)....
3. Downstream application interrogates the MV every (say 1-2 minutes) and updates its own tables based on the data there.....but let's say MV contains 10,000 records and in the last minute 100 of those records have been updated and another 100 inserted - how will it know the 200 records it needs to pull?
Thanks again

Regarding Error in Materialized view Fast Refresh

ORA-12015: cannot create a fast refresh materialized view from a complex query
CREATE MATERIALIZED VIEW MVCONTENTHISTORY_01
BUILD IMMEDIATE
REFRESH FAST
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS
SELECT a.DAY, a.contentname,
SUM
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) COUNT,
COUNT
(CASE
WHEN (b.subscriptionstartdate) <= (a.DAY)
AND ((CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (a.DAY)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
) <=
(CASE
WHEN b.subscriptionenddate IS NOT NULL
THEN (b.subscriptionenddate)
ELSE TO_DATE ('01/20/1990', 'MM/DD/YYYY')
END
THEN 1
ELSE 0
END
) cnt
FROM TBLTDATEWISECONTENT a,
(SELECT TRUNC (a.subscriptionstartdate) subscriptionstartdate,
TRUNC (a.subscriptionenddate) subscriptionenddate, b.NAME,
b.contentid
FROM syntbltcontentsubscrhistory a, syntblmcontent b
WHERE b.contentid = a.contentid(+)) b
WHERE a.contentid = b.contentid(+) AND a.DAY = b.subscriptionstartdate(+)
GROUP BY a.contentname, a.DAY;
I can't create Materialized view with fast Refresh .
Kindly provide solution .
Regards,
nayana chavda.

Kindly provide full Oracle version since option vary by release.
There error message says it is impossible to fast refresh based on a complex query.
On 10g Oracle provides a package procedure that will tell you why the view cannot be fast refreshed: dbms_mview.explain_mview.
Otherwise see the Advanced Replication Manual for a list of restrictions.
10gR2 >>Restrictions for Materialized Views with Subqueries
The defining query of a materialized view with a subquery is subject to several restrictions to preserve the materialized view's fast refresh capability.
The following are restrictions for fast refresh materialized views with subqueries:
Materialized views must be primary key materialized views.
The master's materialized view log must include certain columns referenced in the subquery. For information about which columns must be included, see "Logging Columns in the Materialized View Log".
If the subquery is many to many or one to many, join columns that are not part of a primary key must be included in the materialized view log of the master. This restriction does not apply to many to one subqueries.
The subquery must be a positive subquery. For example, you can use the EXISTS condition, but not the NOT EXISTS condition.
The subquery must use EXISTS to connect each nested level (IN is not allowed).
Each table can be in only one EXISTS expression.
The join expression must use exact match or equality comparisons (that is, equi-joins).
Each table can be joined only once within the subquery.
A primary key must exist for each table at each nested level.
Each nested level can only reference the table in the level above it.
Subqueries can include AND conditions, but each OR condition can only reference columns contained within one row. Multiple OR conditions within a subquery can be connected with an AND condition.
All tables referenced in a subquery must reside in the same master site or master materialized view site.
<<
HTH -- Mark D Powell --
Message was edited by: added list of restrictions left off initial post
mpowel01

Materialized View Logs Query

Hi All,
I had some problem with my Materialized views, that's why Dropped all of the Logs + Materialized Views from my Production Database. Kindly tell me that, Is there any Query, which I can run and make Materialized View Logs from my Existing Tables . Thanks
Regards,
Imran

Incremental Materialized View creation steps
Hi,
Find the below steps to create MV's with logs.
1.     Materialized view log creation at master.
2.     DB link creation at MV site to master site.
3.     Materialized view creation at MV site.
4.     Refresh the MV.
Materialized view log creation at master.
SQLPLUS <USER_MASTER_SITE>/<PASSWORD>@<MASTER_SITE>
CREATE MATERIALIZED VIEW LOG ON <TABLE_NAME>;
DB link creation at MV site.
SQLPLUS <USER_MV_SITE>/<PASSWORD>@<MV_SITE>
CREATE Database Link <MASTER_SITE> Connect To <USER_MASTER_SITE> Identified By <PASSWORD> Using ‘<tnsnames>’
Materialized view creation at MV site.
SQLPLUS <USER_MV_SITE>/<PASSWORD>@<MV_SITE>
CREATE MATERIALIZED VIEW <TABLE_NAME> BUILD
IMMEDIATE REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE
AS SELECT * FROM <TABLE_NAME>@<MASTER_SITE> REFRESH ;
Refresh the MV.
SQLPLUS <USER_MV_SITE>/<PASSWORD>@<MV_SITE>
Execute DBMS_SNAPSHOT.REFRESH( '<TABLE_NAME>','f');
Regards,
Prasanna

Materialized View and Redo Information

Hi!!
I have created a materialized view with fast refresh. I have created a materialized view log on master table with NOLOGING. My view is refresh every 3 seconds but My problem is that my archivelogs is now growing so much!!!
Please, How I avoid that redo information increasing so much?
Thank you,
Roxana.

I want to show on line some tables of my database,
because I have created materialized view every 3
seconds on test enviroment. I'm not sure I follow exactly what you're saying here.
- Are you sure that you need materialized views here? And not just a regular view? If you need to display the data online and you need a lag of no more than three seconds, is there some reason that you're not using a regular old view? Are you doing some significant aggregation of the data?
- Are you sure that you need the materialized views to refresh every 3 seconds? And not on some longer interval?
- If you're looking for near real-time data replication, you may be better served by using Streams rather than materialized views.
When I use stand by database, I have to replica my
full database???.- I'm assuming this is a completely separate question with no relation to the previous section.
- Yes, DataGuard (physical or logical) would create and maintain a copy of your existing database on a separate server in order to fail over in the event of a disaster or to be a reporting server.
Justin

Create a materialized view on a base view

I want to create a materialized view on a master view (ordinary view, not a mat. view). But i can not make it work. can it work? I have created a primary key on the master view as:
create or replace force view v_xxx(a, b)
unique rely disable novalidate,
constraint a_pk primary key (a) rely disable novalidate)
as select a ,b
from xxx
When I then try to create the mat. view:
create materialized view mv_xxx refresh complete
with primary key
as
select * from [email protected]
I get:
ORA-12014: table 'V_xxx' does not contain a primary key constraint
What am I doing wrong?

I suppose OP is on a 9i db (cause I can't reproduce on 11gr2) and the error is because of the database link:
SQL> create table emp_t
as
   select * from emp
Table created.
SQL> create or replace view v_emp_t
   empno   constraint v_emp_t_pk primary key rely disable novalidate,
   ename
as
   select empno, ename from emp_t
View created.
SQL> create materialized view mv_emp_t refresh complete
with primary key
as
select * from v_emp_t
Materialized View created.
SQL> drop materialized view mv_emp_t
Materialized View dropped.
SQL> create materialized view mv_emp_t refresh complete
with primary key
as
select * from v_emp_t@loopback
Error at line 32
ORA-12014: table 'V_EMP_T' does not contain a primary key constraintYou can wrap the view with the db link in another view though:
SQL> create or replace view v_emp_t2
   empno   constraint v_emp_t2_pk primary key rely disable novalidate,
   ename
as
   select empno, ename from v_emp_t@loopback
View created.
SQL> create materialized view mv_emp_t refresh complete
with primary key
as
select * from v_emp_t2
Materialized View created.

What's the impact of rowid materialized view in oracle 10g

Hello to all ;
Oracle official docs saying
ROWID materialized views should be used only for materialized views based on master tables from an Oracle7 database, and should not be used from Oracle8 or higher.
For 10g or higher versions can we consider rowid materizlized view ?
product 10.2.0.4 and 11g r2 on Redhat 5.1

No
should not be used from Oracle8 or higher10g is higher

Oracle Materialized View | Deletion of Records, Oracle Materialized View

One question reg Materialized views.
If as part of housekeeping of the Source database we delete some records (older records), will the materialized view also be updated with the deletion?
I believe the answer is yes. In that case can we ensure that this delete does not happen?
Is there anyway we can prevent MView refresh from deleting the records that is once inserted even if we delete the same records in source DB?

This is a common scenario, particularly with materialised views that summarise detail data where you want to keep the summary but not the detail, and it is addressed in the documentation.
The technique is to make the MV refresh on demand, delete the data from the detail tables, and use the CONSIDER_FRESH procedure to prevent the changes propagating to the MV. You'll probably find it in the docs by searching on DBMS_MView.Consider_Fresh. There are a few warnings to note I think.

Table Operator Vs Materialized View Operator

Hi All,
Could you please give the differences between Table Operator and Materialized view Operator in Oracle Warehouse Builder 11g.
Regards,
Subbu

Below an extract of my notes of the Materialized view. The complete notes are here :
http://gerardnico.com/wiki/dw/aggregate_table
=====Notes=====
Materialized views are the equivalent of a summary table. (Materialized views can be also use as replica).
In a olap approach, each of the elements of a dimension could be summarized using a hierarchy.
The end user queries the tables and views in the database. The query rewrite mechanism in a database automatically rewrites the SQL query to use this summary tables.
This mechanism reduces response time for returning results from the query. Materialized views within the data warehouse are transparent to the end user or to the database application.
This is relatively straightforward and is answered in a single word - performance. By calculating the answers to the really hard questions up front (and once only), we will greatly reduce the load on the machine, We will experience:
* Less physical reads - There is less data to scan through.
* Less writes - We will not be sorting/aggregating as frequently.
* Decreased CPU consumption - We will not be calculating aggregates and functions on the data, as we will have already done that.
* Markedly faster response times - Our queries will return incredibly quickly when a summary is used, as opposed to the details. This will be a function of the amount of work we can avoid by using the materialized view, but many orders of magnitude is not out of the question.
Materialized views will increase your need for one resource - more permanently allocated disk. We need extra storage space to accommodate the materialized views, of course, but for the price of a little extra disk space, we can reap a lot of benefit.
Also notice that we may have created a materialized view, but when we ANALYZE, we are analyzing a table. A materialized view creates a real table, and this table may be indexed, analyzed, and so on.
Success
Nico

Question on materialized view unregistered on master site

Similar Messages

Maybe you are looking for