Materialized View and I_SNAP$ Indexes

Hello Everybody,
At the time of doing REFRESH of the Materialized View, we are getting error like -
SQL> EXECUTE DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF');
BEGIN DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (MV_TEST.I_SNAP$_FIN_RESULT_EXPENSE1) violated
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2545
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2751
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2720
ORA-06512: at line 1
I tried to drop and recreate the index I_SNAP$_FIN_RESULT_EXPENSE1 but it didn’t helped.
Later I dropped the index I_SNAP$_FIN_RESULT_EXPENSE1 and refreshed the materialized view and it was successful (obvious). But when I tried to recreate the index, I got the following error –
SYS_OP_MAP_NONNULL("FIN_MULT"), SYS_OP_MAP_NONNULL("FIN_CD"))
ERROR at line 8:
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
When I look at the value of SYS_OP_MAP_NONNULL('FIN_CD'), it seems to be unique.
SQL> select SYS_OP_MAP_NONNULL('FIN_CD') from dual;
SYS_OP_MAP_NONNULL('FIN_CD’)
46494E5F5650545F4C564C5F335F434400
My questions are:
1.     Why are the indexes (I_SNAP$_*) automatically created for?
2.     What is the purpose of these (I_SNAP$_*) indexes?
3.     What harm can be there if we drop these (I_SNAP$_*) indexes?
4.     Why it is complaining about the Duplicate records / Uniqueness?
5.     How to know where exactly the problem is in this case?
6.     What is the solution for this problem? How to recreate these indexes successfully?
Thanks!

Hello Rafi,
I don't have any MLOG$_<table> in the database, After connecting as SYS -
SQL> select tname from tab where tname like '%MLOG%';
TNAME
MLOG_REFCOL$
MLOG$
C_MLOG#
SQL> select count(*) from mlog$;
COUNT(*)
0
I am not using Replication here -
SQL> select tname from tab where tname like '%RUPD%';
no rows selected
Why you think that granting SELECT access to MLOG$_* tables will solve this issue?
Thanks,
Roopesh

Similar Messages

Refreshing Materialized View and (Bitmap) indexes

In my data warehouse I have an MV that is re-built every night.
1. Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule
2. It was sometimes sensitive to changes in the underlying objects
3. Its has union alls in it so is complex
It has 6 indexes (4 bitmap and 2 b-tree) built on it which take between 8 and 20 minutes each to create. I would like to reduce this time. I'm already doing the index creation as parallel jobs.
I can re-organise the underlying tables so that the MV is no longer complex, and put an MV log on, to enable a fast refresh. Then, ideally, the indexes can be permanent But I know that bitmap indexes don't like certain changes (they can multiply in size an become unusable). Does this include refreshes of MVs? If it does I might be able to switch to b-tree indexes as our report performance is well within the allowable window, unlike my nightly ETL.
The MV has 160M rows in it and the rate of change is rarely more than 1%/day
I'm on 9i

<Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule >
Huh? I wouldn't think that a drop and recreate would be any faster, but won't argue with your results. I assume the same events happen for both and take the same amount of time, with the drop/refresh promoting fragmentation.
< It was sometimes sensitive to changes in the underlying objects >
Yup. All kinds of views are, even real ones. I've found that on 10g MVs are also very tempermental
< Simplest answer from me is that I will go for a fast refresh with MV logs. >
I'm not sure you can fast refresh a query with UNIONS. There's a list of restrictions for fast refreshes that's so long I can't keep track of all the rules.
< would you drop and recreate the bitmp indexes either side of the fast refresh? >
If you're doing a fast refresh you shoud not need to.
You might also consider using the NOLOGGING option on index dropping recreation, used to turn archivel logging off. Since you won't be restoring a failed index creation in case of database failure anyway it should be fairly safe.
Also, when creating the bitmaps make sure you're allocating enough memory to the process. Check your initialization/session parameters, particularly the ones pertianing to bitmap indexes.
Message was edited by:
riedelme

Materialized View Refresh and I_SNAP$ Indexes issue

At the time of doing REFRESH of the Materialized View, we are getting error like -
SQL> EXECUTE DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF');
BEGIN DBMS_MVIEW.REFRESH('MV_TEST.MY_VIEW,'CF'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-00001: unique constraint (MV_TEST.I_SNAP$_FIN_RESULT_EXPENSE1) violated
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2545
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2751
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2720
ORA-06512: at line 1
I tried to drop and recreate the index I_SNAP$_FIN_RESULT_EXPENSE1 but it didn’t helped.
Later I dropped the index I_SNAP$_FIN_RESULT_EXPENSE1 and refreshed the materialized view and it was successful (obvious). But when I tried to recreate the index, I got the following error –
SYS_OP_MAP_NONNULL("FIN_MULT"), SYS_OP_MAP_NONNULL("FIN_CD"))
ERROR at line 8:
ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found
When I look at the value of SYS_OP_MAP_NONNULL('FIN_CD'), it seems to be unique.
SQL> select SYS_OP_MAP_NONNULL('FIN_CD') from dual;
SYS_OP_MAP_NONNULL('FIN_CD’)
46494E5F5650545F4C564C5F335F434400
My questions are:
1.     Why are the indexes (I_SNAP$_*) automatically created for?
2.     What is the purpose of these (I_SNAP$_*) indexes?
3.     What harm can be there if we drop these (I_SNAP$_*) indexes?
4.     Why it is complaining about the Duplicate records / Uniqueness?
5.     How to know where exactly the problem is in this case?
6.     What is the solution for this problem? How to recreate these indexes successfully?
Thanks!

This forum is for the OLAP Option (which supports a cool featured called cube-organized materialized views). If this question if about table-based materialized views you should post it the General Oracle Database forum. Good luck.

Materialized view and Partition

Hi,
I want to discuss a scenario, with which i am dealing nowadays. there is only a single table (named livecdr ) has 22-23 fields and the records are updating in every sec (on daily basis) and in 24hrs livecdr contains approximately more than 2 crore records.
Problem is that the query processing time is so slow due to large number of records and query is fetching records from a view created on livecdr table. I want to know the options, how the query would fetch these records in a short time. Firstly i did range partitioning on livecdr and then i created materlized view but the view didn't create on partition table and when i removed partitioning it was created. After view creation, query performance is much better. i also applied indexing on livecdr.
Can you please tell me, whether this approach is okay or i am doing mistake. should i create partitioning on materialized view and how would i select records from view if partitioning would be applied on materialized view. Please guide me with best approaches.
thankyou.

Hello,
Here is how I created partitioned table (monthly partitions) and partitioned mview on the table. This is just an example you might have to change the mview partitions from monhtly to yearly or quartely.
CREATE TABLE live_cdr
   CALLID              VARCHAR2 (20),
   CD                  VARCHAR2 (25),
   CG                  VARCHAR2 (25),
   RE                  VARCHAR2 (25),
   OPC                 VARCHAR2 (12),
   DPC                 VARCHAR2 (12),
   STIME               VARCHAR2 (25),
   SDATE               DATE,
   ATIME               VARCHAR2 (25),
   ADATE               DATE,
   ETIME               VARCHAR2 (25),
   EDATE               DATE,
   schangeTime         VARCHAR2 (25),
   schangeDate         DATE,
   STATUS              VARCHAR2 (25),
   bucket              NUMBER (20),
   CIC                 NUMBER (20),
   charge              VARCHAR2 (30),
   ported              VARCHAR2 (30),
   jurisdiction_Info   VARCHAR2 (30),
   origLine_Info       CHAR (1),
   Variant             NUMBER,
   auto_inc            NUMBER
PARTITION BY RANGE (EDATE)
PARTITION LIVE_CDR_JAN_2009 VALUES LESS THAN (TO_DATE(' 2009-02-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS,
PARTITION LIVE_CDR_FEB_2009 VALUES LESS THAN (TO_DATE(' 2009-03-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS
);Mview definition
CREATE MATERIALIZED VIEW KLONDIKE.LIVE_CDR_MV
LOGGING
PARTITION BY RANGE (EDATE)
PARTITION LIVE_CDR_MV_JAN_2009 VALUES LESS THAN (TO_DATE('20090201',
      'YYYYMMDD'))
    LOGGING
    NOCOMPRESS,
PARTITION LIVE_CDR_MV_FEB_2009 VALUES LESS THAN (TO_DATE('20090301',
      'YYYYMMDD'))
    LOGGING
    NOCOMPRESS
BUILD IMMEDIATE
REFRESH COMPLETE
START WITH SYSDATE
NEXT SYSDATE + 2 /24
AS
SELECT   DISTINCT (ic.callid) callid,
                  ic.CG,
                  ic.CD,
                  ic.RE,
                  ic.OPC,
                  ic.DPC,
                  ic.SDATE,
                  ic.STIME,
                  ac.ADATE,
                  ac.ATIME,
                  ec.ETIME,
                  ec.EDATE,
                  ec.STATUS
FROM   live_cdr ic, live_cdr ac, live_cdr ec
WHERE       ic.callid = ac.callid
         AND ic.callid = ec.callid
         AND ic.stime = ac.stime
         AND ic.stime = ec.stime
         AND ic.sdate = ac.sdate
         AND ic.sdate = ec.sdate
         AND ac.ADATE IS NOT NULL
         AND ec.EDATe IS NOT NULL
         AND ec.etime IS NOT NULL
         AND ic.CD IS NOT NULL
         AND ic.cg IS NOT NULL;Regards

Diff materialized view and view

what is diff materialized view and view

Check these documents please
[Overview of Materialized Views|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#CNCPT411]
[Overview of Views|http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/schema.htm#i20690]
Kamran Agayev A. (10g OCP)
http://kamranagayev.wordpress.com

Updatable Materialized View and Master Table on same database

Hi all,
My first question - Is it possible to have an Updatable Materialized View and the associated Master Table located on the same database?
This is the requirement scenario:
One unique database D exists.
A is a batch table. Only inserts are allowed on Table A.
M is an updatable materialized view on Table A (Master). Only updates are allowed on M (no insert or delete).
Requirement is to push updates/changes from M to A periodically and then get the new inserted records from A into M via a refresh.
Is this possible? What other approaches are applicable here?

John,
My question is related to the implementation and setup of the environment as explained in the above example. How can I achieve this considering that I have created an updatable m-view?
If possible, how do I push changes made to an updatable m-view back to it's master table when/before I execute DBMS_MVIEW.REFRESH on the m-view? What is the procedure to do this if both table and mview exist on the same database? Do I need to create master groups, materialized view refresh groups, etc.?
One more thing.. Is there a way to retain changes to the m-view during refresh? In this case, only newly inserted/updated records in the associated table would get inserted into m-view. Whereas changes made to m-view records would stay as-is.
Hope my question is directed well. Thanks for your help.
- Ankit

Materialized view and snapshot

Hi gurus,
Could you please tell me what is the difference between materialized view and snapshot.
Regards
Koustav

A snapshot, is in general terms, a picture, a click of a camera, an image that captures the position/state of something at sometime.
Snapshot in a database can take many points of view.
Materialized view (MV) is an object in Oracle database. It "materializes" a view, by taking a snapshot, of the view when you actually create the MV, and preserve it for future use. It can be refreshed in several available ways.
A view doesn't occupy any space, a MV does.
HTH,
Aswin.

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

Materialized view and policies

Hello,
We created an materialized view and on this view why created a policy.
SYS.DBMS_RLS.ADD_POLICY
Now we added some values to the MV via drop MV and create MV.
The policy on this MV is gone after the drop statement.
Is there away to secure this?
Thanks,
Remco

Why are you dropping and re-creating the materialized view in the first place? That's not something that should ever happen in a live system. You should just be refreshing the data in the materialized view, in which case the privileges & policies associated with the materialized view would be retained. It's no different than dropping and re-creating a table that has a policy associated with it-- you'd have to re-apply the policy after re-creating the table.
Theoretically, I suppose you could create a DDL trigger that would throw an error if you tried to drop an object with an associated policy. Fixing your approach, though, so that you're not dropping & re-creating objects is going to be the better long-term solution.
Justin

Materialized View and Indexing

I have the following Materialized view based on the join of 2 tables merchant and address.
Name Null? Type
FIRST_NAME VARCHAR2(15)
MEMBER_DATE DATE
DBA_NAME VARCHAR2(15)
LEGAL_NAME VARCHAR2(15)
STREET VARCHAR2(50)
CITY VARCHAR2(25)
STATE VARCHAR2(2)
PHONE NUMBER
Then I create the preference as below
BEGIN
CTX_DDL.CREATE_PREFERENCE ('my_pref', 'MULTI_COLUMN_DATASTORE');
CTX_DDL.SET_ATTRIBUTE ('my_pref', 'COLUMNS', 'first_name, member_date, dba_name, legal_name, street, city, state, phone');
END;
When I create an index on the above view, I specify the First_name as the column on which the index is based.
This is fine if I have search queries based on First_name.
But the moment I use the contains query to search on any other column name e.g: Legal_name, Oracle text gives an error saying the column is not indexed.
When we have such a scenario where any column of the view can be searched, how do you create the index? Can we specify multiple columns when creating the index? If not, then how do we solve this problem?

Hi,
You still keep the indexed column name in the WHERE clause, but can search for anything in any of the columns. Example using the HR sample schema:
BEGIN
CTX_DDL.CREATE_PREFERENCE ('my_pref', 'MULTI_COLUMN_DATASTORE');
CTX_DDL.SET_ATTRIBUTE ('my_pref', 'COLUMNS', 'FIRST_NAME,LAST_NAME,EMAIL,PHONE_NUMBER,SALARY');
END;
CREATE INDEX EMPLOYEE_IDX ON EMPLOYEES(FIRST_NAME)
INDEXTYPE IS CTXSYS.CONTEXT
PARAMETERS ('DATASTORE MY_PREF');
-- Searching on first name works
SELECT SCORE(1), FIRST_NAME, LAST_NAME, PHONE_NUMBER, SALARY
FROM EMPLOYEES
WHERE CONTAINS(FIRST_NAME, 'JENNIFER', 1) > 0;
SCORE(1) FIRST_NAME LAST_NAME PHONE_NUMBER
SALARY
8 Jennifer Dilly 650.505.2876
3600
8 Jennifer Whalen 515.123.4444
4400
-- Searching for last name, but keeping the indexed column name in the WHERE clause
SELECT SCORE(1), FIRST_NAME, LAST_NAME, PHONE_NUMBER, SALARY
FROM EMPLOYEES
WHERE CONTAINS(FIRST_NAME, 'whalen', 1) > 0;
SCORE(1) FIRST_NAME LAST_NAME PHONE_NUMBER
SALARY
9 Jennifer Whalen 515.123.4444
4400
-- A search for a salary
SELECT SCORE(1), FIRST_NAME, LAST_NAME, PHONE_NUMBER, SALARY
FROM EMPLOYEES
WHERE CONTAINS(FIRST_NAME, '3600', 1) > 0;
SCORE(1) FIRST_NAME LAST_NAME PHONE_NUMBER
SALARY
8 Jennifer Dilly 650.505.2876
3600
8 Renske Ladwig 650.121.1234
3600
Thanks,
Ron

Moving all Materialized View and logs at schema level using data pump

Hi Experts,
Please help me on how can I exp/imp all Materialized Views andMV logs (as these are local MVs) only of complete schema to other database. I want to exlude everything else.
Regards
-Samar-

Use DBMS_METADATA. Create the following SQL script:
SET FEEDBACK OFF
SET SERVEROUTPUT ON FORMAT WORD_WRAPPED
SET TERMOUT OFF
SPOOL C:\TEMP\MVIEW.SQL
DECLARE
    CURSOR V_MLOG_CUR
      IS
        SELECT DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW_LOG',LOG_TABLE) DDL
          FROM USER_MVIEW_LOGS;
    CURSOR V_MVIEW_CUR
      IS
        SELECT DBMS_METADATA.GET_DDL('MATERIALIZED_VIEW',MVIEW_NAME) DDL
          FROM USER_MVIEWS;
BEGIN
    DBMS_METADATA.SET_TRANSFORM_PARAM(DBMS_METADATA.SESSION_TRANSFORM,'SQLTERMINATOR',TRUE);
    FOR V_REC IN V_MLOG_CUR LOOP
      DBMS_OUTPUT.PUT_LINE(V_REC.DDL);
    END LOOP;
    FOR V_REC IN V_MVIEW_CUR LOOP
      DBMS_OUTPUT.PUT_LINE(V_REC.DDL);
    END LOOP;
END;
SPOOL OFFIn my case script is saved as C:\TEMP\MVIEW_GEN.SQL. Now I'll create a mview log and mview in SCOTT schema and run the above script:
SQL> CREATE MATERIALIZED VIEW LOG ON EMP
2 /
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW EMP_MV
2 AS SELECT * FROM EMP
3 /
Materialized view created.
SQL> @C:\TEMP\MVIEW_GEN
SQL> Running script C:\TEMP\MVIEW_GEN.SQL generated a spool file C:\TEMP\MVIEW.SQL:
CREATE MATERIALIZED VIEW LOG ON "SCOTT"."EMP"
PCTFREE 10 PCTUSED 30 INITRANS
1 MAXTRANS 255 LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1
MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL
DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
WITH PRIMARY KEY EXCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW "SCOTT"."EMP_MV" ("EMPNO", "ENAME", "JOB", "MGR",
"HIREDATE", "SAL", "COMM", "DEPTNO")
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40
INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576
MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE
"USERS"
BUILD IMMEDIATE
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE
DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "USERS"
REFRESH FORCE ON
DEMAND
WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
USING ENFORCED
CONSTRAINTS DISABLE QUERY REWRITE
AS SELECT "EMP"."EMPNO"
"EMPNO","EMP"."ENAME" "ENAME","EMP"."JOB" "JOB","EMP"."MGR"
"MGR","EMP"."HIREDATE" "HIREDATE","EMP"."SAL" "SAL","EMP"."COMM"
"COMM","EMP"."DEPTNO" "DEPTNO" FROM "EMP" "EMP";
                               Now you can run this on other database. You might need to adjust tablespace and storage clauses. Or you can add more DBMS_METADATA.SET_TRANSFORM_PARAM calls to C:\TEMP\MVIEW_GEN.SQL to force DBMS_METADATA not to include tablespace or/and storage clauses.
SY.

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

Creation of Materialized view and Materialized view log.

I wanted to create materialized view with 'REFRESH FAST ON COMMIT' option.
1) Table1 --it is partitioned range + list -- Added primary key
2) view1   -- having primary keys on view's base table
Steps:
1) create materialized view log on Table1 ; -- default primary key
2) create materialized view log on view1. --- It is giving below error.
ORA-00942: table or view does not exist
i wanted to create Materialized view like below
create materialized view
REFRESH fast ON commit
as
select ...
... from table1
where c1 in (select c1 from view1 where ... );
Question:
1) As i am getting above error while creating MV log on view. Can we create MV log on view or we have to create MV log on view base table?
2) To create MV with ''REFRESH FAST ON COMMIT' option , do we need to have primary key on master tables?
Any pointers on this will really helpful.
Thanks
Prasad

Also created MV LOG on 3 tables and tried with joins ..
create materialized view
REFRESH fast ON commit
as
select ...
... from table1 , tab2 t2,tab3 t3
where ....
and ...
Get same error ORA-12052: cannot fast refresh materialized view AVSYS.EVENT_LOG_MV
2052. 00000 - "cannot fast refresh materialized view %s.%s"
*Cause:    Either ROWIDs of certain tables were missing in the definition or
           the inner table of an outer join did not have UNIQUE constraints on
           join columns.
*Action:   Specify the FORCE or COMPLETE option. If this error is got
           during creation, the materialized view definition may have be
           changed. Refer to the documentation on materialized views.

Issue with materialized view and fast refresh between Oracle 10g and 11g

Hi all,
I've hit a problem when trying to create a fast-refreshable materialized view.
I've got two databases, one 10.2.0.10, another 11.2.0.1.0, running on 32-bit Windows. Both are enterprise edition, and I'm trying to pull data from the 10g one into the 11g one. I can happily query across the database link from 11g to 10g, and can use complete refresh with no problem except the time it takes.
On the 10g side, I've got tables with primary keys and m.v. logs created, the logs being of this form ...
CREATE MATERIALIZED VIEW LOG ON table WITH PRIMARY KEY INCLUDING NEW VALUES
On the 11g side, when I try to create an m.v. against that ...
CREATE MATERIALIZED VIEW mv_table REFRESH FAST WITH PRIMARY KEY AS SELECT col1, col2 FROM table@dblink;
... I get an ORA-12028 error (materialized view type is not supported by master site).
After running the EXPLAIN_MVIEW procedure it shows this;
REFRESH_FAST_AFTER_INSERT not supported for this type mv by Oracle version at master site
A colleague has managed to build a fast-refresh m.v. from the same source database, but pulling to a different one than I'm using; his target is also 10g, like the (common) source, so I've no idea why I'm getting the 'not supported' message whilst he isn't.
I've been able, on previous projects, to do exactly what I'm trying to achieve but on those someone with more knowledge than me has configured the database!
I'm now stumped. I'm also no DBA but despite that it's been left to me to install the new 11g database on the 32-bit Windows server from scratch, so there are probably a couple of things I'm missing. It's probably something really obvious but I don't really know where to look now.
If anyone can give me any pointers at all, I'd be really grateful. This question is also duplicated in the Replication forum but hasn't had any replies as yet, so I'm reproducing it here in hope!
Thanks in advance,
Steve

Hi Steve,
You should have a look at metalink, Doc ID 1059547.1
If that does not help, there may be something else in Mater note ID 1353040.1
Best regards
Peter

Materialized Views and Substr ?

Hi,
I'm currently trying to create a materialized view that can be fast refreshed, but it complains each time. I think it's because I'm using a constraint substr(x,1,10) so complete refreshes are all that can be done?
My steps are :
create materialized view log on a_table with rowid;
create materialized view log on b_table with rowid;
create materialized view log on c_table with rowid;
create materialized view log on d_table with rowid;
and the materialized view is
create materialized view MY_VIEW
build immediate
enable query rewrite
REFRESH FAST
as
SELECT bt.mid AS mid, ct.imid AS imid, bt.iid AS iid, vendor_name AS make, at.dname AS dname, bt.timestamp AS timestamp
          FROM b_table bt, c_table ct, d_table dt, a_table at
               WHERE bt.mid=ct.mid
                    AND substr(bt.iid,1,5)=dt.val1
                    AND at.profile_id=dt.profile_id
          order by bt.timestamp desc;
ORA-12052: cannot fast refresh materialized view MY_VIEW
I'm at a loss, I can make it without the fast refresh, but the table view is huge and updating it completely each time isn't going to work :(
Any help or suggestions would be greatly appreciated,
Regards,
Brian

Well, basically, you can relatively easily find it out yourself.
First, there is a very useful script $ORACLE_HOME/rdbms/admin/utlxmv.sql
You should execute under the same account as you create materialized views like this
@?/rdbms/admin/utlxmvThen you are prepared to check, whether your mv is fast refresheable and if not - why.
SQL> create table new_dept as select * from dept
2 /
Table created.
SQL> -- Now create table emp with new join column of type varchar2
SQL> create table new_emp as
2 select e.*,d.dname
3 from emp e,dept d
4 where e.deptno=d.deptno
5 /
Table created.
SQL> create materialized view log on new_emp with rowid
2 /
Materialized view log created.
SQL> create materialized view log on new_dept with rowid
2 /
Materialized view log created.
SQL> begin
2          dbms_mview.explain_mview('select e.*,d.loc
3                  from new_emp e,new_dept d
4                  where substr(d.dname,1,10)=e.dname');
5 end;
6 /
PL/SQL procedure successfully completed.
SQL> select capability_name,possible,msgtxt
2 from mv_capabilities_table
3 where capability_name like '%FAST%'
4 /
CAPABILITY_NAME                PO MSGTXT
REFRESH_FAST                   N
REFRESH_FAST_AFTER_INSERT      N the SELECT list does not have the rowids
                                   of all the detail tables
REFRESH_FAST_AFTER_ONETAB_DML N see the reason why REFRESH_FAST_AFTER_IN
                                  SERT is disabled
REFRESH_FAST_AFTER_ANY_DML     N see the reason why REFRESH_FAST_AFTER_ON
                                  ETAB_DML is disabled
REFRESH_FAST_PCT               N PCT is not possible on any of the detail
                                   tables in the materialized view
SQL> rollback
2 /
Rollback complete.
SQL> -- Now we know - for materialized view rowid of all involved in join tables
SQL> -- should be in the select list to make possible fast refresh
SQL> -- of course they should get proper aliases. Yet one attempt
SQL> begin
2    dbms_mview.explain_mview('select e.*,e.rowid erow_id,d.loc,d.rowid drow_id
3      from new_emp e,new_dept d
4      where substr(d.dname,1,10)=e.dname');
5 end;
6 /
PL/SQL procedure successfully completed.
SQL> select capability_name,possible,msgtxt
2 from mv_capabilities_table
3 where capability_name like '%FAST%'
4 /
CAPABILITY_NAME                PO 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 materialized view
SQL> -- Mission successful - refresh_fast is possibleBest regards
Maxim

Materialized View and I_SNAP$ Indexes

Similar Messages

Maybe you are looking for