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.

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 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 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

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>

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.

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

Materialized views Doubt

Hi All,
I have a question regarding materialized view.
I am adding new columns to the base table of a materialized view.As part of this I do recompiling dependent objects.Do I need to take any action on materialized views? I mean Validating or recreating?
Thanks
Hena

Assuming that you're not expecting the new column to appear in the materialized view, you shouldn't need to do anything.
Justin

Materialized View and Ord Media questions

Hey Guys,
My first question is on the use and creation of materialized views which i have previously done using TOAD. The question that i have is where/if can i visually see the constraints that are on a materialized view and where is the information for "next refresh" times placed?
Question two is about viewing informaiton on ord media objects that are stored. Previously, i had the ability to double click one of these elememts in the data view and see the information related to that instance of the ord media object, but the SQL developer does not seem to have this ability??
Thanks in advance.

Thanks Kris,
The reason that i asked about the constraints on MV is because when you create a materialized view over a db link with primary key, it will place a not null constraint on every column. This is obviously no good because some rows are bound to contain nulls and these need to be removed and updated before it will work!
As for the ord objects, it just makes it a little easier for testing to see what they are :).
Anyway, its looking great and i hope these features will be in the next release?
Cheers David

Create Materialized View question

Hi all,
I have a question about MV.
Toad creation wizard of a new snapshots (materialized view) on "Refresh Info" tab I set
Refresh mode: complete On demand
With: ROWID (I can't use primary key because on my table there isn't PK)
Writing teh query, next the Materialized View is successfully created and this is a toad script:
CREATE MATERIALIZED VIEW ASDF
TABLESPACE USERS
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH PRIMARY KEY
AS
select CDA_PART, DES_PART, DES_MAT, CDA_APPART, CDA_PROVEN
from ldanapr01
where dat_end>(sysdate-1);Why is specified WITH PRIMARY KEY if I created the view with ROWID option?
Indeed if a drop a MV and directly run the create VM script above obtain error ORA-14012 table 'LDANAPR01' does not contain a primary key constraint.
So, if I modify the script in this way
CREATE MATERIALIZED VIEW ASDF
TABLESPACE USERS
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD IMMEDIATE
REFRESH COMPLETE ON DEMAND
WITH ROWID
AS
select CDA_PART, DES_PART, DES_MAT, CDA_APPART, CDA_PROVEN
from ldanapr01
where dat_end>(sysdate-1);the MV is successfully created!!
What is difference between WITH PRIMARY KEY and WITH ROW ID... and why Toad show always the created MV script as WITH PRIMARY KEY ?

>
WITH PRIMARY KEY is used to create a primary key materialized view i.e. the materialized view is based on the primary key of the master table instead of ROWID (for ROWID clause). PRIMARY KEY is the default option. To use the PRIMARY KEY clause you should have defined PRIMARY KEY on the master table or else you should use ROWID based materialized views.
Primary key materialized views allow materialized view master tables to be reorganized without affecting the eligibility of the materialized view for fast refresh.
Rowid materialized views should have a single master table and cannot contain any of the following:
* Distinct or aggregate functions
* GROUP BY Subqueries , Joins & Set operations
source : http://www.dbasupport.com/oracle/ora9i/mat_views2.shtml

Materialized view log update question

Hi, I am running into a question regarding mview - not sure if it should behave that way or I didn't use it right.
I have two base tables, sales and customers (drived from nested materialized view example in oracle doc):
CREATE TABLE sales
cust_ID VARCHAR2(32 BYTE) NOT NULL,
amount_sold NUMBER,
TEMP VARCHAR2(100 BYTE),
CONSTRAINT sales_pk PRIMARY KEY (cust_id)
CREATE TABLE customers
cust_ID VARCHAR2(32 BYTE) NOT NULL,
CUST_LAST_NAME VARCHAR2(100 BYTE),
TEMP VARCHAR2(100 BYTE),
CONSTRAINT cust_pk PRIMARY KEY (cust_id)
CREATE MATERIALIZED VIEW LOG ON sales
WITH ROWID (cust_id, amount_sold);
CREATE MATERIALIZED VIEW LOG ON customers
WITH ROWID (cust_id, cust_last_name);
Then I create a fast refresh materialized view based on them:
CREATE MATERIALIZED VIEW join_sales_cust
REFRESH FAST ON DEMAND AS
SELECT c.cust_id, c.cust_last_name, s.amount_sold, s.rowid srid, c.rowid crid
FROM sales s, customers c
WHERE s.cust_id = c.cust_id;
Since this materialized view only invole cust_id and amount_sold from sales and cust_id and last_name from customers table, I do not want to trigger materialized view log entry if the TEMP column value gets updated. So follow update shouldn't trigger mlog:
update sales set TEMP='TEMP2' where cust_id=1
but this update should:
update sales set amount_sold=3 where cust_id=1
What I am seeing happenning is any update on the base table will triger mlog entried regardless whether the column is involed in the materialized view or not.
Can someone please confirm if this is the correct behavior and whether there is a way to accomplish what I wanted to do?
Thank you!
Edited by: user3933488 on Jan 8, 2010 12:53 PM

You created the materialized view logs with some columns, which is not necessary when creating a join MV on top of them. You can happily skip those in your MV log definition. And then it becomes clear that those columns are not involved in the decision whether a MV log needs to be updated or not. Everything that happens to the base table gets recorded. The "WITH ROWID" and "INCLUDING NEW VALUES" and the column list only specify WHAT should be recorded when something changed.
Regards,
Rob.

Materialized View Fast Refresh. Quick Question

Hi all
I have an assumption that I would love to have validated quickly if possible.
I am assuming that once a refresh operation is kicked off, any changes to the MLOG$ log table subsequent to the start of the refresh will not be picked up on that refresh cycle.
I'm basing this on my understanding of cursor consistency logic, but if someone could validate or refute the above then it would be much appreciated.
Many thanks
Chris

MV log entries are deleted when all registered materialized views that depend on them have refreshed.
For example: Suppose you have a table T and materialized views A and B that are fast-refresh and depend on the MV log for T.
On Monday you refresh MV A. The log entries are nto purged because B has not yet incorporated them.
On Tuesday you refresh MV B. At this point the log entries are purged up to the time on Monday that A was refreshed, because all MVs have processed them.
On Wednesday you refresh MV A again. At this point the log entries are purged up to the time on Tuesday that A was refreshed. etc.

Materialized View On top of View Refesh Question

I have senario...where we have a MVW on top of view....How can I refesh the MVW everytime the view refreshes...?
THe MVW is very small (less than 150 rows)..and its straight data from view
any suggestions?

Hi dude,
Please refere below code
Materialized View Built on View Rewritten for FAST REFRESH
SQL> DROP MATERIALIZED VIEW scott.emp_v_MV;
SQL> CREATE MATERIALIZED VIEW scott.emp_v_MV
NOLOGGING
PARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS
select * from emp_v
SQL> truncate table mv_capabilities_table;
SQL> exec dbms_mview.explain_mview('scott.emp_v_mv');
SQL> set linesize 100
SQL> SELECT capability_name, possible, SUBSTR(msgtxt,1,60) AS msgtxt
           FROM mv_capabilities_table
           WHERE capability_name like '%FAST%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST                   N
REFRESH_FAST_AFTER_INSERT      N named view in FROM list not supported   for this type MV
REFRESH_FAST_AFTER_INSERT      N named view in FROM list not supported for this type MV
REFRESH_FAST_AFTER_INSERT      N view or subquery in from list
REFRESH_FAST_AFTER_INSERT      N the detail table does not have a materialized view log
REFRESH_FAST_AFTER_ONETAB_DML N see the reason why REFRESH_FAST_AFTER_INSERT is disabled
REFRESH_FAST_AFTER_ANY_DML     N see the reason why REFRESH_FAST_AFTER_ONETAB_DML is disabled
REFRESH_FAST_PCT               N PCT is not possible on any of the detail tables in the mater
SQL> DROP MATERIALIZED VIEW scott.emp_v_MV;
SQL> CREATE MATERIALIZED VIEW scott.emp_v_MV
NOLOGGING
PARALLEL
BUILD IMMEDIATE
REFRESH FORCE ON DEMAND
ENABLE QUERY REWRITE
AS
select * from emp;
SQL> TRUNCATE TABLE mv_capabilities_table;
SQL> EXEC dbms_mview.explain_mview('scott.emp_v_mv');
SQL> SELECT capability_name, possible, SUBSTR(msgtxt,1,60) AS msgtxt
           FROM mv_capabilities_table
           WHERE capability_name like '%FAST%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST                   Y
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_DML     Y
REFRESH_FAST_PCT               N PCT is not possible on any of the detail tables in the mater
Materialized View Aggregation with Required Materialized View Logs:
SQL> CREATE MATERIALIZED VIEW LOG ON scott.emp
WITH SEQUENCE, ROWID (JOB, DEPTNO, SAL)
INCLUDING NEW VALUES;
SQL> CREATE MATERIALIZED VIEW LOG ON scott.dept
WITH SEQUENCE, ROWID (DEPTNO)
INCLUDING NEW VALUES;
SQL> DROP MATERIALIZED VIEW scott.sal_dept_mv;
SQL> CREATE MATERIALIZED VIEW scott.sal_dept_mv
           NOLOGGING
           PARALLEL
           BUILD IMMEDIATE
           REFRESH FORCE ON DEMAND
           ENABLE QUERY REWRITE
           AS
          SELECT e.job, e.deptno, sum(e.sal)
          FROM emp e,
               dept d
          WHERE e.deptno=d.deptno
          GROUP BY e.job, e.deptno;

Question on Materialized View

Similar Messages

Maybe you are looking for