Regd FAST refresh option in a Materialized view

Hi All,
I am using a pipeline function in which I am creating a table of records and a few cursors to fetch data from various tables.
Now this PL/SQL table is being used to construct a Materialized view.
Creation of Materialized view is happening fine but not with FAST refresh option. It gives an error " Cannot create a FAST refresh Materialized view from a complex query."
The query which I have used for the view creation is
CREATE MATERIALIZED VIEW CUSTOM.ABC
PCTFREE 0
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT A.Number,
A.Guarantors_Number,
A.Guarantors_Name,
A.Personal_Garantee_PCNT,
A.Company, LG.Source_System,
A.Type_of_Info,
A.File_Gen_Date,
A.Periodicity
FROM
TABLE(CUSTOM.CDM_LG_PACK_PF.CDM_LG_FUNC) A;
where CDM_LG_PACK_PF is the package and CDM_LG_FUNC is the pipeline function I have written to fetch all the records.
Please help me on how can I do a FAST refresh on this materialized view.
Thanks in advance,
Gaurav

Welcome to the forum!
FAST refresh doesn't mean that the operation is fast (time wise), it means it's an incremental refresh.
If you have a complex query, you can't use a FAST refresh - that's what the exception tells you.

Similar Messages

Issue with MV fast refresh off of an materialized

I have a materialized view that does not have a primary key (I am NOT allowed to change this).
So I created a materialized view log using rowid. I am trying to create another materialized view that fast refreshes off of this materialized view. I get the following error. any way to make this work?
1 create materialized view my_mv
2 build immediate
3 refresh fast
4 with rowid
5* as select * from owner.my_orig_mv
SQLPLUS> /
as select * from owner.my_orig_mv
ERROR at line 5:
ORA-12053: this is not a valid nested materialized view

thank you for the doc, but I am confused. The first thing it says is that I need to use a rowid to refresh which is what I am doing. I don't know why this won't fast refresh.
the first materialized view is not a join view or complex. it is a straight select from a table.
Edited by: user11990507 on Dec 8, 2009 7:13 AM

Problem when try to get the next refresh date of a materialized view

I have a materialized view set to auto refresh(e.g hourly), I need to query this date and display in the report. I create a procedure which return the NEXT_DATE from the ALL_REFRESH_CHILDREN table, the procedure and the view all in schema HK3XDDB.
If I login as sys, dba in the sql plus and query the procedure, it return the next date, but if I login as normal user which has permission to execute all procedures, it didn't return anything, so I change ALL_REFRESH_CHILDREN to USER_REFRESH_CHILDREN, still no luck. But the details from the USER_MVIEWS can be returned, just won't return anything in the REFRESH one. How to query the next date out?
Another strange thing is, if I login as sys dba, it return the next date, but if I use a select next_date into statement in the procedure it will throw a data not found error.
I stuck here for several hours just can't figure it out, any suggestions are welcome,
Cheers

Thank you for the reply. It's same with USER_REFRESH_CHILDREN, I can get the result when I run the procedure in SQL PLUS login as sys dba, but if I run the procedure using normal user which has permission to run any procedure, then nothing return. It might be a permission problem but I just can't figure out why.
Let me explain in detailed:
Schema HKXDDB, this schema has procedure TestProcedure, in the procedure, I have two ref cursor return, one is for select * from USER_JOBs (or from USER_REFRESH_CHILDREN, I have tried both), one is for select * From USER_MVIEWS, this schema has the materialized view. User HKDWUser has permission to run any procedures, so when this user run the TestProcedure which is own by HKXDDB, the cursor that select from USER_MVIEWS can return results which are materialized views owned by HKXDDB, but the cursor that select form USER_JOBS or USER_REFRESH_CHILDREN always return no rows.
Any permission I need to assign to HKDWUSER to get the jobs or fresh group that owned by HKXDDB?
Cheers

Fast Refresh using two non-primary key tables

Hi,
I have a materialized view based on two tables with an outer join clause. Both the tables do not have a primary key so I had created materialized view log with row-id on each of them but still I am not able to bring out the fast refresh option for the materialized view. My question is can I have a fast refresh option for materialized view built from two tables without primary keys and having an outer join clause????. If possible please send me some sample scripts for quicker understanding.
Thanks and Regards,
Sudhakar

I was able to create a fast-refreshable MV, on tables without any PK. Unfortunately, I can't complete all the steps since my setup is a multi-master advanced replication (which ABSOLUTELY requires the tables to have PK's). Here are anyway the steps I took. Note that ORA102 is my (definition) master site, and MVDB is my MV site. The tables were created under user HR, and my master group is called "hr_repg". Here are my steps:
HR on ora102 >create table countries_no_pk as select * from countries;
Table created.
HR on ora102 >create table regions_no_pk as select * from regions;
Table created.
HR on ora102 >create materialized view log on countries_no_pk with rowid;
Materialized view log created.
HR on ora102 >create materialized view log on regions_no_pk with rowid;
Materialized view log created.
REPADMIN on ora102 >exec dbms_repcat.suspend_master_activity('hr_repg')
PL/SQL procedure successfully completed.
Elapsed: 00:00:02.68
REPADMIN on ora102 >BEGIN
2 DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
3 gname => 'hr_repg',
4 type => 'TABLE',
5 oname => 'countries_no_pk',
6 sname => 'hr',
7 use_existing_object => TRUE,
8 copy_rows => FALSE);
9 END;
10 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:05.19
REPADMIN on ora102 >set timing off
REPADMIN on ora102 >BEGIN
2 DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
3 gname => 'hr_repg',
4 type => 'TABLE',
5 oname => 'regions_no_pk',
6 sname => 'hr',
7 use_existing_object => TRUE,
8 copy_rows => FALSE);
9 END;
10 /
PL/SQL procedure successfully completed.
(note that you ABSOLUTELY need the rowid's in your select statement for an MV with joins):
MVIEWADMIN on mvdb >CREATE MATERIALIZED VIEW hr.complex_mv refresh fast as
2 select c.rowid "C_ROW_ID", r.rowid "R_ROW_ID", c.COUNTRY_ID, c.COUNTRY_NAME,
3 c.REGION_ID, r.REGION_NAME from hr.regions_no_pk@ora102 r, hr.countries_no_pk@ora102 c
4 where c.region_id = r.region_id (+);
Materialized view created.
MVIEWADMIN on mvdb >BEGIN
2 DBMS_REPCAT.CREATE_MVIEW_REPOBJECT (
3 gname => 'hr_repg',
4 sname => 'hr',
5 oname => 'complex_mv',
6 type => 'SNAPSHOT',
7 min_communication => TRUE);
8 END;
9 /
PL/SQL procedure successfully completed.
REPADMIN on ora102 >BEGIN
2 DBMS_REPCAT.GENERATE_REPLICATION_SUPPORT (
3 sname => 'hr',
4 oname => 'countries_no_pk',
5 type => 'TABLE',
6 min_communication => TRUE);
7 END;
8 /
PL/SQL procedure successfully completed.
(wait when the entries in DBA_REPCATLOG is empty)
REPADMIN on ora102 >exec dbms_repcat.resume_master_activity('hr_repg')
Hope that can help you. If that doesn't work, tell us where it bombs.
Daniel

Create a fast refresh materialized view with partitioned primary index

Hi,
I have a materialized view that is based on a table with primary key.
I want to create a materialized view with a partitioned primary index . do you have any way of doing it?
I tried to create a materialized view with rowid and then I created a partitioned primary index on it.
It did not work as what I expected. I could not perform a fast refresh on it. the materialized view can only complete refresh
thank you

Hi,
Here is some info from the Oracle Documentation.
http://download.oracle.com/docs/cd/E11882_01/server.112/e10706/repmview.htm
http://download.oracle.com/docs/cd/E11882_01/server.112/e10810/basicmv.htm
Determining the Fast Refresh Capabilities of a Materialized View
http://download.oracle.com/docs/cd/E11882_01/server.112/e10706/repmview.htm#BABEDIAH
Regards,

Enabling materialized view for fast refresh method

In AWM when i select refresh method as FAST and enable the materialized view, am getting the below error:
"Refresh method fast requires materialized view logs and a previously run complete refresh of the cube mv". i need this Fast refresh of a cube materialized view, so that it performs an incremental refresh and re-aggregation of only changed rows in the source table.
can anyone help me on this??

If you want the cube to hold data even after it has been deleted from the relational table, then you should disable the MV on the cube.
Synchronization with the source table is determined by the default "cube script".
<li>CLEAR, LOAD, SOLVE : This will synchronize your cube with the source table. It is a requirement for MVs.
<li>LOAD, SOLVE: This will allow your cube to contain data even after it has been removed from the source table. It sounds like you want this.
Cube builds can be "incremental" in one of two ways.
(1) You can have an "incremental LOAD" if the source table contains only the changed rows or if you use MV "FAST" or "PCT" refresh. Since you can't use MVs, you would need a source table with only the changed rows.
(2) You will have an "incremental SOLVE" (a.k.a. "incremental aggregation") if there is no "CLEAR VALUES" or "CLEAR AGGREGATES" step and various other conditions hold.
To force a "complete LOAD" with an "incremental SOLVE" you should have all rows in your source table and run the following build script.
LOAD, SOLVE You could also run "CLEAR LEAVES, LOAD, SOLVE" to synchronize the cube with the table.
To force an "incremental LOAD" with a "complete SOLVE" you make the source table contains only the changed rows and the run the following:
CLEAR AGGREGATES, LOAD, SOLVEor
LOAD, CLEAR AGGREGATES, SOLVEFinally, if you want both LOAD and SOLVE to be incremental you make the source table contains only the changed rows and the run the following:
LOAD, SOLVE

Materialized view fast refresh hang

I create many materialized views in one refresh group,but during the fast refresh ,I find the materialized view sometimes hang on db file sequential reads,from v$active_session_history,I find the session read one block more then two hours( db file sequential reads happens on one block more then two hours),If I kill the refresh job,then it will refresh well.
I think it seems a bug,but I don't find match case on metalink.
DB version:10.2.0.3

If you query V$SESSION or V$SESSION_WAIT do you see SEQ# increasing ? What does the STATE column show ?
If SEQ# isn't increasing and the STATE has changed to anything other than WAITING, then the wait reported is a previous wait, not a current wait.
Can you show the SQL queries you used to monitor the session and the outputs of those queries ?
For a FAST REFRESH, you should also be able to monitor V$TRANSACTION.USED_UREC to see if the INSERTs into the target MV are growing while the Refresh is running.
Hemant K Chitale

Materialized view takes long to refresh

On Oracle 11g2, I created a materialized view fast refresh on commit CREATE MATERIALIZED VIEW mv_case
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+)
and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
create index idx_mv_case_pid on mv_case(jperson_id);
ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
create index idx_mv_case_p_rowid on mv_case(p_rowid);
create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
create index idx_mv_case_c_rowid on mv_case(c_rowid);
create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
create index idx_mv_case_cc_rowid on mv_case(cc_row_id); I inserted one single row into one of the master table
insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */
MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
MAS$0.ROWID
FROM ( SELECT MAS$.ROWID RID$ , MAS$.* FROM QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN
          (SELECT /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$
           FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN) MAS$0, JCASE AS OF SNAPSHOT(:B_SCN) MAS$2,
JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN) MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN) MAS$4
WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+)
AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+)
AND MAS$2.JCASE_ID=JV$.JCASE_ID(+)
AND MAS$2.JCASE_ID=MAS$0.JCASE_ID)
AND NOT EXISTS (
    SELECT 1 FROM QAPF.MV_CASE SNA2$
    WHERE (SNA2$.P_ROWID = MAS$4.ROWID)
    AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL )
    AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL )
    AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL )
    AND JV$.RID$ IS NULL)
AND NOT EXISTS (
    SELECT 1 FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN) MAS_OUTER$
    WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL
    AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1     99.51     364.87     377012   17412972          1           0
Fetch        0      0.00       0.00          0          0          0           0
total        2     99.51     364.87     377012   17412972          1           0
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=17412968 pr=377012 pw=120527 time=0 us)
      0   FILTER (cr=17412968 pr=377012 pw=120527 time=0 us)
3363837    HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
      1     VIEW (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
      1      HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
11354346       TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
      1       TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
      1        INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
3363837     HASH JOIN (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
2994042      INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
3363837      HASH JOIN (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
3363837       HASH JOIN (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
3363837        TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
6586646        TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
6586635       TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
3363837    FILTER (cr=17148054 pr=96758 pw=0 time=0 us)
3363837     MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
32464070      INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
      0    FILTER (cr=0 pr=0 pw=0 time=0 us)
      0     NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
      0      TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
      0      INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)Questions:
1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
ORA-08187: snapshot expression not allowed here
08187. 00000 - "snapshot expression not allowed here"
*Cause:    A snapshot expression using AS OF was specified when not allowed.
*Action:   Do not use the AS OF clause
2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
ERROR at line 1:
ORA-00904: : invalid identifier
Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
Thanks for help.

sybrand_b wrote:
1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
This is pure speculation, of course, based on the absence of an error message.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+

Refresh groups to administer several materialized views?

Hi,
I had three materialized views in my database. They are used for decision support and access local data. Each one is completely refreshed at a distinct time during the night.
Now, application developers asked for more 3 materialized views. Although there is no need to guarantee referential integrity between the materialized views, it seems to me that the more efficient way to administer their refresh is by using a refresh group. Therefore, I am planning to create a refresh group with the 6 materialized views.
Is there another good way to administer refresh options of several materialized views?
Regards.

If the existing three materialized views are refreshed at distinct times during the night, I'm not sure what benefit there would be to putting the three into a single refresh group (and I'm ignoring what happens when you add the three new ones). You put multiple materialized views into a refresh group so that you can do a single refresh and so that the data is internally consistent. If you don't need the data to be consistent and you want the materialized views to be refreshed at different points in time, I'm not sure what benefit you'd derive from putting them in a refresh group.
Justin

ORA-12013 on Fast Refreshable view

Hi,
I'am trying to create an update mview but encoutering ORA-12013.
The problem is , if i comment for update clause in the create statment, the mview is correctly created :
create materialized view AGREGAT_MVNO_RC
build deferred
refresh
fast
on demand
with primary key
for update
enable query rewrite
as
SELECT
LIBELLE_MVNO,
PTA_ID,
TYPE_USAGE,
CODE_CHARGE,
TRUNC( DATE_DEBUT_PERIODE, 'MM') AS MOIS_DATE_DEBUT,
TRUNC( DATE_VALORISATION, 'MM') AS MOIS_VALORISATION,
SUM( MONTANT) AS MONTANT, COUNT( MONTANT) AS NB_MONTANT,
COUNT( *) AS NB_ENR
FROM
CHARGE_VALORISEE_RC
GROUP BY
LIBELLE_MVNO,
PTA_ID,
TYPE_USAGE,
CODE_CHARGE,
TRUNC( DATE_DEBUT_PERIODE, 'MM'),
TRUNC( DATE_VALORISATION, 'MM');
=>produce ORA-12013
create materialized view AGREGAT_MVNO_RC
build deferred
refresh
fast
on demand
with primary key
--for update
enable query rewrite
as
SELECT
LIBELLE_MVNO,
PTA_ID,
TYPE_USAGE,
CODE_CHARGE,
TRUNC( DATE_DEBUT_PERIODE, 'MM') AS MOIS_DATE_DEBUT,
TRUNC( DATE_VALORISATION, 'MM') AS MOIS_VALORISATION,
SUM( MONTANT) AS MONTANT, COUNT( MONTANT) AS NB_MONTANT,
COUNT( *) AS NB_ENR
FROM
CHARGE_VALORISEE_RC
GROUP BY
LIBELLE_MVNO,
PTA_ID,
TYPE_USAGE,
CODE_CHARGE,
TRUNC( DATE_DEBUT_PERIODE, 'MM'),
TRUNC( DATE_VALORISATION, 'MM');
=> No errors
i don't understand why ?
Evironment: 10.2.0.3 enterprise on hp-ux
Thanks for help

The error message description seems clear enough :
ORA-12013 : updatable materialized views must be simple enough to do fast refresh
Cause: The updatable materialized view query contained a join, subquery, union, connect by, order by, or group by caluse.
Action: Make the materialized view simpler. If a join is really needed, make multiple simple materialized views then put a view on top of them.
Nicolas.

Creation of Materialized View is taking Long Time

Hi All,
In the execution of PLSQL script, I am executing the following sequence.
First step I am creating the materialized view A, and Materialized view B using DB Links. In the same script as a part of second step I am creating one more materialized view with the combination of Materialized view A and Materialized view B and a table with DB links. But creating of this materialized view is taking 15 hours, I am using Refresh is COMPLETE. I am using a separate tablespace for this and it is Auto Extend Clause. Can any body tell me or suggest where exactly I had done the mistake.
Thanks,

pujakhetan wrote:
is this posiible to do fast refresh on above mentioned Materialized view ??
I dont have much information about restriction which exists for materialized view refresh .then consider to actually Read The Fine Manuals found at http://docs.oracle.com to obtain desired details

Problem with Materialized Views in 10g

Hi All,
I am creating a Materialized View like
CREATE MATERIALIZED VIEW mvname TABLESPACE SYSTEM BUILD IMMEDIATE REFRESH WITH ROWID FOR UPDATE AS ( SELECT a,b,c FROM table_a,table_b,table_c WHERE cond );
I am getting an error
SQL Error: ORA-12013: updatable materialized views must be simple enough to do fast refresh.
Can anyone tell what is the problem?
I have included rowid of all three tables in select clause.

Hi,
From Oracle Docs:
ORA-12013: updatable materialized views must be simple enough to do fast refresh
Cause: The updatable materialized view query contained a join, subquery, union, connect by, order by, or group by caluse.
Action: Make the materialized view simpler. If a join is really needed, make multiple simple materialized views then put a view on top of them.
Regards
K.Rajkumar

Materialized view log with multiple materialized views

DB: 9.2.0.8
Yes its old. I am not allowed to upgrade it.
I have a set of materialized views that are created off of 5 base tables. They do fast refreshes. So I have multiple materialized views for the same base table and same materialized view log.
1. how do materialized view logs manage multiple dependent materialized views?
2. How do I tell by looking at the materialized view log which rows have not been fast refresh for a specific materialized view?

As a starter for 10 try reading: Materialized View Refresh : Log Population and Purge (Doc ID 236233.1) on MOS.
Thanks
Paul

Fast Refresh on Materialized View With Join

Hi All,
i have created following Materialized View Logs and MV
on EMP and DEPT
CREATE MATERIALIZED VIEW LOG ON DEPT
WITH PRIMARY KEY,SEQUENCE
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW LOG ON EMP
WITH PRIMARY KEY,SEQUENCE
INCLUDING NEW VALUES;
CREATE MATERIALIZED VIEW EMP_MVW
TABLESPACE OSMIS_REPORT_DATA
REFRESH FAST ON COMMIT
AS
SELECT A.EMPNO,A.ENAME,A.DEPTNO,A.JOB,A.MGR,A.HIREDATE,A.SAL,A.COMM,B.DNAME,B.LOC
FROM EMP A,DEPT B
WHERE A.DEPTNO=B.DEPTNO
The Create MV Stmnt raised following error.
ERROR at line 6:
ORA-12052: cannot fast refresh materialized view SCOTT.EMP_MVW
I have tried the same with ROWID also,but same error
while creating MV.
Pls anyone give idea to Fast Refersh on MV with Joins
Thnks
Raj.G.
mail : [email protected]

Actually you can get Oracle to tell you why the view does not have the capabilities you want using the DBMS_MVIEW package. For example you could have done something like this...
Personal Oracle Database 10g Release 10.1.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> CREATE MATERIALIZED VIEW LOG ON dept
2    WITH PRIMARY KEY, SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON emp
2    WITH PRIMARY KEY,SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH FAST ON COMMIT
3 AS
4 SELECT a.empno, a.ename, a.deptno,
5         a.job, a.mgr, a.hiredate,
6         a.sal, a.comm, b.dname, b.loc
7 FROM   emp a,dept b
8 WHERE a.deptno = b.deptno;
FROM   emp a,dept b
ERROR at line 7:
ORA-12052: cannot fast refresh materialized view SCOTT.EMP_MVW
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH ON COMMIT -- remove the FAST to allow view to compile
3 AS
4 SELECT a.empno, a.ename, a.deptno,
5         a.job, a.mgr, a.hiredate,
6         a.sal, a.comm, b.dname, b.loc
7 FROM   emp a,dept b
8 WHERE a.deptno = b.deptno;
Materialized view created.
SQL> @\oracle\product\10.1.0\Db_1\RDBMS\ADMIN\utlxmv.sql -- create mv_capabilities_table
Table created.
SQL> EXEC DBMS_MVIEW.EXPLAIN_MVIEW ('EMP_MVW');
PL/SQL procedure successfully completed.
SQL> SELECT capability_name, possible, msgtxt
2 FROM   mv_capabilities_table
3 WHERE capability_name LIKE '%REFRESH_FAST_AFTER%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST_AFTER_INSERT      N the SELECT list does not have the rowids of all the detail tables
REFRESH_FAST_AFTER_INSERT      N mv log must have ROWID
REFRESH_FAST_AFTER_INSERT      N mv log must have ROWID
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
SQL> DROP MATERIALIZED VIEW LOG ON dept;
Materialized view log dropped.
SQL> DROP MATERIALIZED VIEW LOG ON emp;
Materialized view log dropped.
SQL> DROP MATERIALIZED VIEW emp_mvw;
Materialized view dropped.
SQL> CREATE MATERIALIZED VIEW LOG ON dept
2    WITH ROWID, SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW LOG ON emp
2    WITH ROWID,SEQUENCE
3      INCLUDING NEW VALUES;
Materialized view log created.
SQL> CREATE MATERIALIZED VIEW emp_mvw
2    REFRESH FAST ON COMMIT
3 AS
4 SELECT a.ROWID emp_rowid, b.ROWID dept_rowid,
5         a.empno, a.ename, a.deptno,
6         a.job, a.mgr, a.hiredate,
7       a.sal, a.comm, b.dname, b.loc
8 FROM   emp a,dept b
9 WHERE a.deptno = b.deptno;
Materialized view created.
SQL> DELETE mv_capabilities_table;
18 rows deleted.
SQL> EXEC DBMS_MVIEW.EXPLAIN_MVIEW ('EMP_MVW');
PL/SQL procedure successfully completed.
SQL> SELECT capability_name, possible, msgtxt
2 FROM   mv_capabilities_table
3 WHERE capability_name LIKE '%REFRESH_FAST_AFTER%';
CAPABILITY_NAME                P MSGTXT
REFRESH_FAST_AFTER_INSERT      Y
REFRESH_FAST_AFTER_ONETAB_DML Y
REFRESH_FAST_AFTER_ANY_DML     Y
SQL>

MATERIALIZED view on two tables with Fast Refresh

i Wanted to create MV on two tables with Fast refresh on commit.
I followed below steps
create materialized view log on t1 WITH PRIMARY KEY, rowid;
create materialized view log on t2 WITH PRIMARY KEY, rowid;
CREATE MATERIALIZED VIEW ETL_ENTITY_DIVISION_ASSO_MV
REFRESH fast ON commit
ENABLE QUERY REWRITE
AS
select A.ROWID B.ROWID,a.c1, DECODE(a.c1,'aaa','xxx','aaa') c2
from t1 A
join t2 b
on AB.c1= CD.c2;
i am getting below error.
Error report:
SQL Error: ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
12054. 00000 - "cannot set the ON COMMIT refresh attribute for the materialized view"
*Cause: The materialized view did not satisfy conditions for refresh at
commit time.
*Action: Specify only valid options.
Basically i want to take record in MV by joinig two tables and if both of the base tables will updated then record should reflect in materialised view.
Please do the needfull.

does the table support PCT? the other restrictions on joins look to be ok in your statement.
maybe try creating first with on demand instead of commit to see does it create.
http://docs.oracle.com/cd/B19306_01/server.102/b14223/basicmv.htm
>
Materialized Views Containing Only Joins
Some materialized views contain only joins and no aggregates, such as in Example 8-4, where a materialized view is created that joins the sales table to the times and customers tables. The advantage of creating this type of materialized view is that expensive joins will be precalculated.
Fast refresh for a materialized view containing only joins is possible after any type of DML to the base tables (direct-path or conventional INSERT, UPDATE, or DELETE).
A materialized view containing only joins can be defined to be refreshed ON COMMIT or ON DEMAND. If it is ON COMMIT, the refresh is performed at commit time of the transaction that does DML on the materialized view's detail table.
If you specify REFRESH FAST, Oracle performs further verification of the query definition to ensure that fast refresh can be performed if any of the detail tables change. These additional checks are:
A materialized view log must be present for each detail table unless the table supports PCT. Also, when a materialized view log is required, the ROWID column must be present in each materialized view log.
The rowids of all the detail tables must appear in the SELECT list of the materialized view query definition.
If some of these restrictions are not met, you can create the materialized view as REFRESH FORCE to take advantage of fast refresh when it is possible. If one of the tables did not meet all of the criteria, but the other tables did, the materialized view would still be fast refreshable with respect to the other tables for which all the criteria are met.

Regd FAST refresh option in a Materialized view

Similar Messages

Maybe you are looking for