On commit restriction on materialized view.

Hello friends,
I am creating one materialized view which needs to be refreshed on commit, While creating that MV, i am getting error stating "On commit is not allowed for that.."
I have studied oracle documentations for the same.
The only restriction the document is saying is that, the Query for MV should not contain object type.
The query for which i am creating MV doesn't contain any object type.
Please friends,if you know, suggest me the document link stating the restrictions on use of "on commit" clause with create materialize view statement.
Regards,
Dipali.

There are many restrictions on MV especially with refresh fast on commit clause, refer the below link,(for oracle 10g R2)
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#i1007007
sbs

Similar Messages

  • On commit fast refreshable materialized view does not update

    ... but instead it deletes and inserts. And I would like it to perform an update, so we can add a database trigger to call a webservice. But it's crucial that we call the "update webservice" when it updates.
    This is an Oracle 10.2.0.4 database.
    Output of my problem-reproducing-case:
    First creation of a small instrumentation setup:
    SQL> create table logtable
      2  ( id   number
      3  , time timestamp
      4  , text varchar2(100)
      5  )
      6  /
    Tabel is aangemaakt.
    SQL> create sequence log_seq cache 100
      2  /
    Reeks is aangemaakt.
    SQL> create procedure add_log_message (p_text in varchar2)
      2  is
      3    pragma autonomous_transaction;
      4  begin
      5    insert into logtable
      6    values (log_seq.nextval,systimestamp,p_text);
      7    commit;
      8  end;
      9  /
    Procedure is aangemaakt.Two tables with full blown materialized view logs defined on them:
    SQL> create table t1 (id,ean)
      2  as
      3   select level
      4        , to_char(trunc(dbms_random.value(0,999999999999999999)))
      5     from dual
      6  connect by level <= 10
      7  /
    Tabel is aangemaakt.
    SQL> alter table t1 add primary key (id)
      2  /
    Tabel is gewijzigd.
    SQL> create materialized view log on t1 with sequence, rowid (id,ean) including new values
      2  /
    Gematerialiseerde viewlog is aangemaakt.
    SQL> create table t2 (id,t1_id,value)
      2  as
      3   select level
      4        , level * 2
      5        , trunc(dbms_random.value(1,100))
      6     from dual
      7  connect by level <= 5
      8  /
    Tabel is aangemaakt.
    SQL> alter table t2 add primary key (id)
      2  /
    Tabel is gewijzigd.
    SQL> alter table t2 add foreign key (t1_id) references t1(id)
      2  /
    Tabel is gewijzigd.
    SQL> create materialized view log on t2 with sequence, rowid (id,t1_id,value) including new values
      2  /
    Gematerialiseerde viewlog is aangemaakt.And the materialized view itself, containing an outer join. And on that materialized view there is a trigger that logs the action performed (I, U or D):
    SQL> create materialized view mv refresh fast on commit
      2  as
      3  select t1.rowid t1_rowid
      4       , t2.rowid t2_rowid
      5       , t1.id    t1_id
      6       , t1.ean   ean
      7       , t2.id    t2_id
      8       , t2.value value
      9    from t1
    10       , t2
    11   where t1.id = t2.t1_id (+)
    12     and t1.ean is not null
    13  /
    Gematerialiseerde view is aangemaakt.
    SQL> create trigger mv_trg_ariud
      2  after insert or update or delete on mv
      3  for each row
      4  begin
      5    add_log_message
      6    ( case
      7        when inserting then 'I'
      8        when updating then 'U'
      9        when deleting then 'D'
    10      end
    11    );
    12  end;
    13  /
    Trigger is aangemaakt.
    SQL> select * from mv
      2  /
    T1_ROWID           T2_ROWID                T1_ID EAN                                           T2_ID      VALUE
    AAFwMeAChAABamIAAA                             1 360432237186591962
    AAFwMeAChAABamIAAB AAFwMhAChAABamaAAA          2 706465424496730795                                1         77
    AAFwMeAChAABamIAAC                             3 678961199378791568
    AAFwMeAChAABamIAAD AAFwMhAChAABamaAAB          4 351418443524585979                                2         35
    AAFwMeAChAABamIAAE                             5 610374519804201714
    AAFwMeAChAABamIAAF AAFwMhAChAABamaAAC          6 798782716740397566                                3         33
    AAFwMeAChAABamIAAG                             7 909989471290455410
    AAFwMeAChAABamIAAH AAFwMhAChAABamaAAD          8 670698835550268126                                4         69
    AAFwMeAChAABamIAAI                             9 746290195605805530
    AAFwMeAChAABamIAAJ AAFwMhAChAABamaAAE         10 157491298211132413                                5         82
    10 rijen zijn geselecteerd.Now we add a new t1 row, which leads to an extra row in the mv on commit time:
    SQL> insert into t1 values (11, '999999999999999999')
      2  /
    1 rij is aangemaakt.
    SQL> commit
      2  /
    Commit is voltooid.
    SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      2    from logtable
      3   order by id
      4  /
    LOG
    I         11:39:47.817225
    1 rij is geselecteerd.
    SQL> select * from mv where ean = '999999999999999999'
      2  /
    T1_ROWID           T2_ROWID                T1_ID EAN                                           T2_ID      VALUE
    AAFwMeAChAABamJAAA                            11 999999999999999999
    1 rij is geselecteerd.As expected. Now insert a record in t2, which should lead to an update of the materialized view:
    SQL> insert into t2 values (11,11,1)
      2  /
    1 rij is aangemaakt.
    SQL> commit
      2  /
    Commit is voltooid.
    SQL> select * from mv where ean = '999999999999999999'
      2  /
    T1_ROWID           T2_ROWID                T1_ID EAN                                           T2_ID      VALUE
    AAFwMeAChAABamJAAA AAFwMhAChAABambAAA         11 999999999999999999                               11          1
    1 rij is geselecteerd.
    SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      2    from logtable
      3   order by id
      4  /
    LOG
    I         11:39:47.817225
    D         11:39:47.992824
    I         11:39:48.015072
    3 rijen zijn geselecteerd.But it doesn't: apparently it has inserted a row and deleted a row. Let's do a normal update:
    SQL> update t2 set value = 2 where id = 11
      2  /
    1 rij is bijgewerkt.
    SQL> commit
      2  /
    Commit is voltooid.
    SQL> select * from mv where ean = '999999999999999999'
      2  /
    T1_ROWID           T2_ROWID                T1_ID EAN                                           T2_ID      VALUE
    AAFwMeAChAABamJAAA AAFwMhAChAABambAAA         11 999999999999999999                               11          2
    1 rij is geselecteerd.
    SQL> select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      2    from logtable
      3   order by id
      4  /
    LOG
    I         11:39:47.817225
    D         11:39:47.992824
    I         11:39:48.015072
    D         11:39:48.142621
    I         11:39:48.168553
    5 rijen zijn geselecteerd.And again: a delete and an insert.
    Does anybody know if I can change this behaviour and let the mv perform an update?
    In another materialized view (not shown here) containing aggregates, I've seen that it performs an update. But using this "join" mv, it does not.
    Here is the script, if you want to try it on your own database:
    create table logtable
    ( id   number
    , time timestamp
    , text varchar2(100)
    create sequence log_seq cache 100
    create procedure add_log_message (p_text in varchar2)
    is
      pragma autonomous_transaction;
    begin
      insert into logtable
      values (log_seq.nextval,systimestamp,p_text);
      commit;
    end;
    create table t1 (id,ean)
    as
    select level
          , to_char(trunc(dbms_random.value(0,999999999999999999)))
       from dual
    connect by level <= 10
    alter table t1 add primary key (id)
    create materialized view log on t1 with sequence, rowid (id,ean) including new values
    create table t2 (id,t1_id,value)
    as
    select level
          , level * 2
          , trunc(dbms_random.value(1,100))
       from dual
    connect by level <= 5
    alter table t2 add primary key (id)
    alter table t2 add foreign key (t1_id) references t1(id)
    create materialized view log on t2 with sequence, rowid (id,t1_id,value) including new values
    create materialized view mv refresh fast on commit
    as
    select t1.rowid t1_rowid
         , t2.rowid t2_rowid
         , t1.id    t1_id
         , t1.ean   ean
         , t2.id    t2_id
         , t2.value value
      from t1
         , t2
    where t1.id = t2.t1_id (+)
       and t1.ean is not null
    create trigger mv_trg_ariud
    after insert or update or delete on mv
    for each row
    begin
      add_log_message
      ( case
          when inserting then 'I'
          when updating then 'U'
          when deleting then 'D'
        end
    end;
    select * from mv
    insert into t1 values (11, '999999999999999999')
    commit
    select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      from logtable
    order by id
    select * from mv where ean = '999999999999999999'
    insert into t2 values (11,11,1)
    commit
    select * from mv where ean = '999999999999999999'
    select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      from logtable
    order by id
    update t2 set value = 2 where id = 11
    commit
    select * from mv where ean = '999999999999999999'
    select rpad(text,10) || to_char(time,'hh24:mi:ss.ff6') log
      from logtable
    order by id
    set echo off
    drop materialized view mv
    drop table t2 purge
    drop table t1 purge
    drop procedure add_log_message
    drop sequence log_seq
    drop table logtable purge
    /Regards,
    Rob.
    Edited by: Rob van Wijk on 7-mrt-2009 9:49
    bump

    Rob,
    here's what Tom says about this:
    seems dangerous as there is nothing stopping Oracle from performing an "update" of a materialized
    view as a DELETE+INSERT.  For you see, the internals of how materialized views are maintained are
    "internal" and subject to change (so even if documented - so what, you cannot control the "how" of
    materialized view refreshes)
    ...It is from 2006 though ...things might have changed ;)

  • Materialized view with tables in different schemas

    Hello,
    I want to create a materialized view with a table from a different schema in the SELECT statement. For materialized view I would like to apply the "REFRESH COMPLETE ON COMMIT" option.
    Here the code:
    CREATE MATERIALIZED VIEW S1.MV_EXAMPLE
    TABLESPACE TS1
    PCTFREE 0
    BUILD IMMEDIATE
    REFRESH COMPLETE ON COMMIT
    AS
    SELECT T.COLUMN1 COLUMN
    FROM S2.TABLE1 T
    I can't execute this SQL because I get an "insufficient privileges" error to this table:
    FROM S2.TABLE1 T
    FEHLER in Zeile 9:
    ORA-01031: Insufficient privileges
    User S1 has the following privileges:
    CREATE SESSION
    CREATE SNAPSHOT
    CREATE TABLE
    CREATE QUERY REWRITE
    SELECT ANY TABLE
    User S2 has the following privileges:
    CREATE SESSION
    CREATE SNAPSHOT
    CREATE TABLE
    CREATE QUERY REWRITE
    ALTER ANY SNAPSHOT
    Which privileges are missing?
    Thanks, Mathias

    Thanks Kamal for your answer!
    S1 has the grant select directly. But I solveld the problem. The system privilege "ON COMMIT REFRESH" was missing for S1. This has to be set if any of the tables are outside the owner's schema of the materialized view (ORACLE documentation - Data Warehouse Guide).
    But one thing is not clear to me yet and the ORACLE documentation doesn't give me an answer. I can set the refresh-attribute ON COMMIT on a materialized view containing only joins when a group by clause is set. If the group by clause is missing I can't! Why?
    Regards, Mathias

  • 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

  • Constraint in Materialized View misbehave

    Enviroment
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    s.o : windows 7. on laptop Intel core i7.
    create table product_type
    ( product_type_id varchar2(3) constraint product_type_pk primary key,
    product_type_name varchar2(100) constraint product_type_name_nn not null,
    move_inv varchar2(1) default 'Y' constraint product_type_move_inv_nn not null,
    generate_abc varchar2(1) default 'N' constraint product_type_generate_abc_nn not null,
    constraint product_type_move_inv_check check (move_inv in ('Y','N')),
    constraint product_type_gen_abc_check check (generate_abc in ('Y','N'))
    create table product_class
    ( product_type_id varchar2(3) constraint product_class_type_id_nn not null,
    product_class_id varchar2(3) constraint product_class_id_nn not null,
    product_class_name varchar2(50) constraint product_class_name_nn not null,
    inv_negative varchar2(1) default 'N' constraint product_class_inv_negative_nn not null,
    constraint product_class_pk primary key (product_type_id,product_class_id),
    constraint product_class_by_product_type foreign key (product_type_id) references product_type(product_type_id),
    constraint product_class_inv_negative_chk check (inv_negative in ('Y','N'))
    create materialized view log on product_type with rowid, primary key , sequence (move_inv) including new values;
    create materialized view log on product_class with rowid, primary key , sequence (inv_negative) including new values;
    create materialized view prd_type_val_prd_class
    refresh fast on commit as
    select count(*) tot_rows
    from product_type pt
    join product_class pc
    on ( pt.product_type_id = pc.product_type_id )
    where pt.move_inv = 'N' and pc.inv_negative = 'Y';
    alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check( tot_rows < 1 );
    -- sentence 1, expected to works
    insert into product_type values('SAR','FARMA','N','N');
    commit; --- WORKS fine.
    -- sentence 2, expected to works
    insert into product_class values('SAR','LIQ','LIQUID' ,'N');
    commit; --- WORKS fine
    -- sentence 3, expected to fail due materialized view constraint
    insert into product_class values('SAR','CAP','CAPSULES','Y');
    commit; ---> SHOW the materialized view constraint Error FINE!!!!!!
    update product_type set move_inv = 'Y'; -- Update product type to allow sentence 3 to be ok
    commit; ---> works fine
    --- Re execute sentence 3 ----> success FINE!
    ---sentence 4, WORKS unexpected. --- it suppose to show the error, due materialized view constraint as did in sentence 3 (first try)
    update product_type set move_inv = 'N';
    commit; --- WORKS :( since this point ON the materialized view constraint error is show no More.... :(
    insert into product_class values('SAR','TAB','TABLETS','Y');
    commit;
    insert into product_class values('SAR','ABC','ABCZXY','Y');
    commit;
    select count(*) tot_rows
    from product_type pt
    join product_class pc
    on ( pt.product_type_id = pc.product_type_id )
    where pt.move_inv = 'N' and pc.inv_negative = 'Y';
    tot_rows
    3
    Any Idea why is this not working as expected??? maybe I'm missing something or is this a glitch???? hope is not.
    thank you

    luis,
    I don't understand why your mv failed, but I tried it in a way I would do it, using an empty MV rather than one with a single rwos with 0 in it. i.e.:
    create materialized view prd_type_val_prd_class
    refresh fast on commit
    as
    select pt.product_type_id
          ,pc.product_type_id pc_bc_product_type_id
          ,pc.product_class_id
          ,pc.rowid pc_row_id
          ,pt.rowid pt_row_id
    from product_type pt
       , product_class pc
    where pt.bc_product_type_id = pc.bc_product_type_id
    AND  pt.move_inv = 'N' and pc.inv_negative = 'Y';and changed the constraint to keep it empty:
    alter table prd_type_val_prd_class add constraint rows_in_prd_type_val_prd_class check(1=0);Is it seemed to pass all your tests

  • Adding a field to materialized view

    I have a materialized view called DEVICE which gets it's data from a table called device in another database (asset3). A new field was added to the device table in the asset3 database. In order to add that field to the materialized view, will I need to drop the materialized view and recreate it or can I run an alter command to add the field?
    SQL> select MVIEW_NAME,QUERY from DBA_MVIEWS where OWNER='DWH' and MVIEW_NAME='DEVICE';
    MVIEW_NAME
    QUERY
    DEVICE
    select * from device@asset3Thanks
    Ravi

    You have to recreate materialized Views
    Example(REFRESH FAST ON COMMIT):
    SQL> CREATE MATERIALIZED VIEW LOG ON B with rowid;
    SQL> CREATE MATERIALIZED VIEW MV_B REFRESH FAST ON COMMIT with rowid AS select * from B;
    SQL> alter table B add k number;
    SQL> ALTER MATERIALIZED VIEW LOG ON B add (k);
    SQL> drop MATERIALIZED VIEW MV_B;
    SQ> CREATE MATERIALIZED VIEW MV_B REFRESH FAST ON COMMIT with rowid AS select * from B;Edited by: Surachart (HunterX) on Jun 17, 2009 11:11 PM

  • Materialized view - REFRESH FAST ON COMMIT - UNION ALL

    In a materialized view which uses REFRESH FAST ON COMMIT to update the data, how many UNION ALL can be used.
    I am asking this question because my materialized view works fine when there are only 2 SELECT statement (1 UNION ALL).
    Thank you.

    In a materialized view which uses REFRESH FAST ON COMMIT to update the data, how many UNION ALL can be used.As far as I remember you can have 64K UNIONized selects.
    I am asking this question because my materialized view works fine when there are only 2 SELECT statement (1 UNION ALL).Post SQL that does not work.

  • Materialized View with Joins

    Dear Dev/DBAs,
    I have the following scenario:
    SQL> CREATE TABLE T1 (ID NUMBER(3),NAME VARCHAR2(10));
    SQL> CREATE TABLE T2 (ID NUMBER(3),NAME VARCHAR2(10));
    The T1 contains records having the ID num from 10 to 80 and the T2 having the ID from 90 to 170
    SQL> SELECT * FROM T1 JOIN ALL SELECT * FROM T2
    It give all records in the 2 tables.
    I'm planning to create a materialized view (like CREATE MATERIALIZED VIEW V_TAB REFRESH ON COMMIT AS SELECT * FROM T1 JOIN ALL SELECT * FROM T2) and it seems i can't do with the error ORA-12054, further the oracle documentation says that materialized view can only be used with a simple join.
    Do you have another solution??
    Note that the materialized views can be used to improve queries.
    Thank you in advance

    Straight from the link I posted:
    *Restrictions on Fast Refresh on Materialized Views with UNION ALL*Materialized views with the UNION ALL set operator support the REFRESH FAST option if the following conditions are satisfied:
    * The defining query must have the UNION ALL operator at the top level.
    The UNION ALL operator cannot be embedded inside a subquery, with one exception: The UNION ALL can be in a subquery in the FROM clause provided the defining query is of the form SELECT * FROM (view or subquery with UNION ALL) as in the following example:
    CREATE VIEW view_with_unionall AS
    (SELECT c.rowid crid, c.cust_id, 2 umarker
    FROM customers c WHERE c.cust_last_name = 'Smith'
    UNION ALL
    SELECT c.rowid crid, c.cust_id, 3 umarker
    FROM customers c WHERE c.cust_last_name = 'Jones');
    CREATE MATERIALIZED VIEW unionall_inside_view_mv
    REFRESH FAST ON DEMAND AS
    SELECT * FROM view_with_unionall;
    Note that the view view_with_unionall satisfies the requirements for fast refresh.
    * Each query block in the UNION ALL query must satisfy the requirements of a fast refreshable materialized view with aggregates or a fast refreshable materialized view with joins.
    The appropriate materialized view logs must be created on the tables as required for the corresponding type of fast refreshable materialized view.
    Note that the Oracle Database also allows the special case of a single table materialized view with joins only provided the ROWID column has been included in the SELECT list and in the materialized view log. This is shown in the defining query of the view view_with_unionall.
    * The SELECT list of each query must include a maintenance column, called a UNION ALL marker. The UNION ALL column must have a distinct constant numeric or string value in each UNION ALL branch. Further, the marker column must appear in the same ordinal position in the SELECT list of each query block.
    * Some features such as outer joins, insert-only aggregate materialized view queries and remote tables are not supported for materialized views with UNION ALL.
    * Partiton Change Tracking (PCT)-based refresh is not supported for UNION ALL materialized views.
    * The compatibility initialization parameter must be set to 9.2.0 or higher to create a fast refreshable materialized view with UNION ALL.

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

  • Materialized View creation with REFRESH FAST

    Hello ,
    Please see below case,
    TABLE A1(partitioned range+list)
    COLUMN C1  -- Primary key
    COLUMN C2  -- NUMBER
    TABLE D1
    COLUMN C1 -- PRIMARY KEY
    created MV log as below
    CREATE MATERIALIzED VIEW LOG ON A1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    CREATE MATERIALIzED VIEW LOG ON D1 WITH ROWID,PRIMARY KEY INCLUDING NEW VALUES;
    Trying to create MV like below:
    CREATE MATERILIZED VIEW mv1test
                                    REFRESH FAST ON COMMIT
    AS
    Select
    FROM A1,
                            D1
                    WHERE A1.C1 = D1.CI
    AND A1.C2 IS NOT NULL;
    It gives below error message:
    ORA-12052: cannot fast refresh materialized view schema.mv1test
    12052. 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.
    However ,as discussed in earlier thread i checked all general restrictions of the 'Refresh fast' approach for join.
    Restrictions on Fast Refresh on Materialized Views with Joins Only
    Defining queries for materialized views with joins only and no aggregates have the following restrictions on fast refresh:
    1) They cannot have GROUPBY clauses or aggregates.
    2) Rowids of all the tables in the FROM list must appear in the SELECT list of the query.
    3)Materialized view logs must exist with rowids for all the base tables in the FROM list of the query.
    4)You cannot create a fast refreshable materialized view from multiple tables with simple joins that include an object type column in the SELECTstatement.
    As per above restrictions ,
    1) Group by clause is not present
    2)i do not understand 2nd point , i have added a1.rowid  and d1.rowid in  select statement of MV, but got same error.
    3) observed same as 2nd point.
    4)we have CLOB column in select list. Tried removing this column but got same error.
    Please do let me know any workaround on this.
    Thanks in advanced ..
    PM

    Basic Materialized Views show how to analyse MVs using dbms_mview. I'm not sure about creating MVs on partitioned tables, that partition maintenance might cause problems

  • Problem creating materialized view

    OK, I'm totally new in using materialized views.
    I'm trying to create one and to make it refreshed on commit
    CREATE MATERIALIZED VIEW VK_CLIENT  build immediate refresh fast on commit AS
      select c1.code,
    c1.fiche fiche_1,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', 'M. et Mme', c1.lnte ), c1.lnte ) lnte_1,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', 
    decode( c1.lnte, 'M.', c1.libe, c7.libe ), c1.libe ), c1.libe ) libe_1,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', 
    decode( c1.lnte, 'M.', substr( c1.libe, 1, c1.lgnom ), substr( c7.libe, 1, c7.lgnom ) ), substr( c1.libe, 1, c1.lgnom ) ), substr( c1.libe, 1, c1.lgnom ) ) nom_1,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', 
    decode( c1.lnte, 'M.', initcap( substr( c1.libe, c1.lgnom + 2 ) ), initcap( substr( c7.libe, c7.lgnom + 2 ) ) ), initcap( substr( c1.libe, c1.lgnom + 2 ) ) ), initcap( substr( c1.libe, c1.lgnom + 2 ) ) ) prenom_1,
    decode( c1.sfam, '04', decode( c7.sfam, '04', decode( c1.lnte, 'Mlle', 'Mme', c1.lnte ), c1.lnte ), c1.lnte ) lnte_1_bis,
    c1.libe libe_1_bis,
    substr( c1.libe, 1, c1.lgnom ) nom_1_bis,
    initcap( substr( c1.libe, c1.lgnom + 2 ) ) prenom_1_bis,
    c1.sfam sfam_1,
    c1.dnai dnai_1,
    decode( to_char( c1.dnai, 'dd' ), '01', '1er', 
    decode( substr( to_char( c1.dnai, 'dd' ), 1, 1 ), 0, substr( to_char( c1.dnai, 'dd' ), 2 ), to_char( c1.dnai, 'dd' ) ) ) || ' ' || 
    rtrim( to_char( c1.dnai, 'month', 'nls_date_language = french' ) ) || to_char( c1.dnai, ' yyyy' ) dnai_fr_1,
    c1.horsfoyer horsfoyer_1,
    decode( c1.lnte, 'Mlle', 'f', 'Mme', 'f', 'M.', 'm' ) accord_1,
    c7.fiche fiche_7,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', null, c7.lnte ), c7.lnte ) lnte_7,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', null, c7.libe ), c7.libe ) libe_7,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', null, substr( c7.libe, 1, c7.lgnom ) ), substr( c7.libe, 1, c7.lgnom ) ) nom_7,
    decode( c1.sfam, '04', 
    decode( c7.sfam, '04', null, initcap( substr( c7.libe, c7.lgnom + 2 ) ) ), initcap( substr( c7.libe, c7.lgnom + 2 ) ) ) prenom_7,
    decode( c7.sfam, '04', decode( c1.sfam, '04', decode( c7.lnte, 'Mlle', 'Mme', c7.lnte ), c7.lnte ), c7.lnte ) lnte_7_bis,
    c7.libe libe_7_bis,
    substr( c7.libe, 1, c7.lgnom ) nom_7_bis,
    initcap( substr( c7.libe, c7.lgnom + 2 ) ) prenom_7_bis,
    c7.sfam sfam_7,
    c7.dnai dnai_7,
    decode( to_char( c7.dnai, 'dd' ), '01', '1er', 
    decode( substr( to_char( c7.dnai, 'dd' ), 1, 1 ), 0, substr( to_char( c7.dnai, 'dd' ), 2 ), to_char( c7.dnai, 'dd' ) ) ) || ' ' || 
    rtrim( to_char( c7.dnai, 'month', 'nls_date_language = french' ) ) || to_char( c7.dnai, ' yyyy' ) dnai_fr_7,
    decode( c7.lnte, 'Mlle', 'f', 'Mme', 'f', 'M.', 'm' ) accord_7,
    initcap( decode( instr( lower( c1.adr1 ), 'log' ), '1', c1.adr2, decode( instr( lower( c1.adr1 ), 'bât' ), '1', c1.adr2, c1.adr1 ) ) ) adr1,
    initcap( decode( decode( instr( lower( c1.adr1 ), 'log' ), '1', c1.adr2, decode( instr( lower( c1.adr1 ), 'bât' ), '1', c1.adr2, c1.adr1 ) ), c1.adr2, null, 
    decode( instr( lower( c1.adr2 ), 'log' ), '1', c1.adr3, decode( instr( lower( c1.adr2 ), 'bât' ), '1', c1.adr3, c1.adr2 ) ) ) ) adr2,
    initcap( decode( instr( lower( c1.adr3 ), 'log' ), '1', null, decode( instr( lower( c1.adr3 ), 'bât' ), '1', null, c1.adr3 ) ) ) adr3,
    c1.ptt,
    c1.lcom,
    decode( c7.fiche, null, decode( c1.lnte, 'Mme', 'Madame', 'Mlle', 'Mademoiselle', 'M.', 'Monsieur', 'Monsieur' ),
    decode( nvl( c1.sfam, '07' ), '04', 
    decode( nvl( c7.sfam, '07' ), '04', 'Madame, Monsieur', 
    decode( c1.lnte, 
    'Mme', decode( c7.lnte, 'Mme', 'Mesdames', 'Mlle', 'Madame, Mademoiselle', 'M.', 'Madame, Monsieur', 'Madame, Monsieur' ), 
    'Mlle', decode( c7.lnte, 'Mme', 'Madame, Mademoiselle', 'Mlle', 'Mesdemoiselles', 'M.', 'Mademoiselle, Monsieur', 'Mademoiselle, Monsieur' ),
    'M.', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
    '. ', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
    decode( c1.lnte,
    'Mme', decode( c7.lnte, 'Mme', 'Mesdames', 'Mlle', 'Madame, Mademoiselle', 'M.', 'Madame, Monsieur', 'Madame, Monsieur' ),
    'Mlle', decode( c7.lnte, 'Mme', 'Madame, Mademoiselle', 'Mlle', 'Mesdemoiselles', 'M.', 'Mademoiselle, Monsieur', 'Mademoiselle, Monsieur' ),
    'M.', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
    '. ', decode( c7.lnte, 'Mme', 'Madame, Monsieur', 'Mlle', 'Mademoiselle, Monsieur', 'M.', 'Mesieurs', 'Mesieurs' ),
    '-' ) ) ) lnte_long,
    decode( c1.cfam, null, c7.cfam, c1.cfam ) cfam,
    decode( c1.cfam, null, c7.allo, c1.allo ) allo,
    decode( c1.sexe, 'm', decode( c7.sexe, null, 'ms', 'm', 'mp', 'f', 'mp' ), 'f', decode( c7.sexe, null, 'fs', 'm', 'mp', 'f', 'fp' ), '-' ) accord,
    c9.fiche fiche_9,
    c9.lnte lnte_9,
    c9.libe libe_9,
    substr( c9.libe, 1, c9.lgnom ) nom_9,
    initcap( substr( c9.libe, c9.lgnom + 2 ) ) prenom_9,
    initcap( decode( instr( lower( c9.adr1 ), 'log' ), '1', c9.adr2, decode( instr( lower( c9.adr1 ), 'bât' ), '1', c9.adr2, c9.adr1 ) ) ) adr1_9,
    initcap( decode( decode( instr( lower( c9.adr1 ), 'log' ), '1', c9.adr2, decode( instr( lower( c9.adr1 ), 'bât' ), '1', c9.adr2, c9.adr1 ) ), c9.adr2, null, 
    decode( instr( lower( c9.adr2 ), 'log' ), '1', c9.adr3, decode( instr( lower( c9.adr2 ), 'bât' ), '1', c9.adr3, c9.adr2 ) ) ) ) adr2_9,
    initcap( decode( instr( lower( c9.adr3 ), 'log' ), '1', null, decode( instr( lower( c9.adr3 ), 'bât' ), '1', null, c9.adr3 ) ) ) adr3_9,
    c9.ptt ptt_9,
    c9.lcom lcom_9,
    decode( c9.lnte, 'Mlle' , 'Mademoiselle', 'Mme', 'Madame', 'M.', 'Monsieur', 'M. et Mme', 'Madame, Monsieur', null ) lnte_long_9,
    decode( c9.sexe, 'm', 'ms', 'f', 'fs', null, null, '-' ) accord_9,
    no.nbocc
    from client c1,
    client c7, 
    client c9,
    select z.code code,
    count(*) nbocc
    from client z
    where to_char( sysdate, 'yyyymmdd' ) between to_char( z.cdeb, 'yyyymmdd' ) and to_char( nvl( z.cfin, sysdate ), 'yyyymmdd' )
    group by z.code
    ) no
    where c1.code = c7.code (+)
    and c1.role = '1'
    and c7.role (+) ='7'
    and nvl( c7.horsfoyer (+), 0 ) = '0'
    and to_char( nvl( c7.cfin (+), sysdate ), 'yyyymmdd' ) >= to_char( sysdate, 'yyyymmdd' )
    and c1.code = c9.code (+)
    and c9.role (+) = '9'
    and to_char( nvl( c9.cfin (+), sysdate ), 'yyyymmdd' ) >= to_char( sysdate, 'yyyymmdd' )
    and c9.lnte (+) not in ( '. ', 'Assoc.', 'Ste' )
    and c9.lcom (+) is not null
    and c1.code = no.code (+);when doing so, I'm getting a ORA-12054:
    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.
    When I create the materialized view with just CREATE MATERIALIZED VIEW "H6801_GL_00"."VK_CLIENT" AS
    it works but the refresh is only "ON DEMAND"...
    Can't find how and why it won't work...
    Edited by: MacFizz on Dec 17, 2009 3:22 PM

    You could try the DBMS_MVIEW.TUNE_MVIEW and check if you can modify you materialized view or "refactor" it in a smaller, fast refreshable part that you could combine later to the sysdate/rownum part of it.
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/advisor.htm
    Explanation on restrictions of fast refresh:
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10706/repmview.htm
    Below there's an example of a fast refreshable mview, on creating the materialized view log and so on:
    http://download.oracle.com/docs/cd/E11882_01/server.112/e10592/statements_6002.htm#i2080820

  • Leave a distinct value in a materialized view on two tables

    Hi and thank you for reading,
    I have the following problem. I am creating a materialized view out of two tables, with "where a.id = b.id".
    The resulting materialized view list several values twice. For example, one customer name has several contact details and thus the customer name is listed several times. Now I would like to join each customer name with just ONE contact detail, how can I do that? (Even if I would loose some information while doing this).
    Thanks
    Evgeny

    Hi,
    You can do this
    SELECT   deptno, empno, ename, job, mgr, hiredate, sal, comm
        FROM emp_test
    ORDER BY deptno;
        DEPTNO      EMPNO ENAME      JOB              MGR HIREDATE          SAL       COMM
            10       7782 CLARK      MANAGER         7839 1981-06-09       2450          
            10       7839 KING       PRESIDENT            1981-11-17       5000          0
            10       7934 MILLER     CLERK           7782 1982-01-23       1300          
            20       7566 JONES      MANAGER         7839 1981-04-02       2975          
            20       7902 FORD       ANALYST         7566 1981-12-03       3000          
            20       7876 ADAMS      CLERK           7788 1987-05-23       1100          
            20       7369 SMITH      CLERK           7902 1980-12-17        800          
            20       7788 SCOTT      ANALYST         7566 1987-04-19       3000          
            30       7521 WARD       SALESMAN        7698 1981-02-22       1250        500
            30       7844 TURNER     SALESMAN        7698 1981-09-08       1500          
            30       7499 ALLEN      SALESMAN        7698 1981-02-20       1600        300
            30       7900 JAMES      CLERK           7698 1981-12-03        950          
            30       7698 BLAKE      MANAGER         7839 1981-05-01       2850          
            30       7654 MARTIN     SALESMAN        7698 1981-09-28       1250       1400
    14 rows selected.
    SELECT CASE
              WHEN ROW_NUMBER () OVER (PARTITION BY deptno ORDER BY empno) =
                                                                         1
                 THEN deptno
           END deptno,
           empno, ename, job, mgr, hiredate, sal, comm
      FROM emp_test;
        DEPTNO      EMPNO ENAME      JOB              MGR HIREDATE          SAL       COMM
            10       7782 CLARK      MANAGER         7839 1981-06-09       2450          
                     7839 KING       PRESIDENT            1981-11-17       5000          0
                     7934 MILLER     CLERK           7782 1982-01-23       1300          
            20       7369 SMITH      CLERK           7902 1980-12-17        800          
                     7566 JONES      MANAGER         7839 1981-04-02       2975          
                     7788 SCOTT      ANALYST         7566 1987-04-19       3000          
                     7876 ADAMS      CLERK           7788 1987-05-23       1100          
                     7902 FORD       ANALYST         7566 1981-12-03       3000          
            30       7499 ALLEN      SALESMAN        7698 1981-02-20       1600        300
                     7521 WARD       SALESMAN        7698 1981-02-22       1250        500
                     7654 MARTIN     SALESMAN        7698 1981-09-28       1250       1400
                     7698 BLAKE      MANAGER         7839 1981-05-01       2850          
                     7844 TURNER     SALESMAN        7698 1981-09-08       1500          
                     7900 JAMES      CLERK           7698 1981-12-03        950          
    14 rows selected.Edited by: Salim Chelabi on 2009-09-14 08:13

  • A bug when refreshing a materialized view?

    I am getting "ORA-00603: ORACLE server session terminated by fatal error" upon refresh of a materialized view. I've put together a test case to demonstrate the problem. Is it a bug?
    SQL*Plus: Release 10.1.0.3.0 - Production on Fri Jul 29 13:43:45 2005
    Copyright (c) 1982, 2004, Oracle.  All rights reserved.
    Connected to:
    Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.6.0 - Production
    [email protected]> create table t (
      2  id int primary key,
      3  t_name varchar2(10),
      4  t_date date
      5  );
    Table created.
    [email protected]> create materialized view log on t
      2    with rowid (t_name, id, t_date) including new values;
    Materialized view log created.
    [email protected]> create materialized view t_mv
      2   build immediate
      3   refresh fast
      4   on commit
      5  as
      6   select t_name, max(id) id, max(t_date) t_date, count(*)
      7     from t
      8    GROUP BY t_name;
    Materialized view created.
    [email protected]> create materialized view log on t_mv
      2    with rowid (id) including new values;
    Materialized view log created.
    [email protected]> create table v (
      2  id int primary key,
      3  t_id int references t(id) on delete cascade,
      4  v_name varchar2(10)
      5  );
    Table created.
    [email protected]> create materialized view log on v
      2    with rowid (v_name, t_id) including new values;
    Materialized view log created.
    [email protected]> create materialized view v_mv
      2   build immediate
      3   refresh fast
      4   on commit
      5  as
      6  select v.rowid rowid1, t_mv.rowid rowid2, v.v_name, v.t_id
      7  from v, t_mv
      8  where v.t_id = t_mv.id;
    Materialized view created.
    [email protected]> alter table v_mv
      2  add constraint v_mv_uk1 unique
      3  (
      4  v_name
      5  )
      6   enable
      7  ;
    Table altered.
    [email protected]> insert into t (id, t_name, t_date) values (1, 'A', sysdate);
    1 row created.
    [email protected]> insert into t (id, t_name, t_date) values (2, 'B', sysdate);
    1 row created.
    [email protected]> insert into t (id, t_name, t_date) values (3, 'A', sysdate);
    1 row created.
    [email protected]> insert into t (id, t_name, t_date) values (4, 'A', sysdate);
    1 row created.
    [email protected]> insert into t (id, t_name, t_date) values (5, 'B', sysdate);
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (1, 1, 'V_A_1');
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (2, 2, 'V_B_1');
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (3, 3, 'V_A_2');
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (4, 4, 'V_A_3');
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (5, 5, 'V_B_2');
    1 row created.
    [email protected]> commit;
    Commit complete.
    [email protected]> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
    1 row created.
    [email protected]> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
    1 row created.
    [email protected]> commit;
    commit
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-00001: unique constraint (FESA.V_MV_UK1) violated
    [email protected]> -- ORA-12008 is fine here: that's what was expected
    [email protected]> delete from t where id = 5;
    1 row deleted.
    [email protected]> commit;
    ERROR:
    ORA-03114: not connected to ORACLE
    commit
    ERROR at line 1:
    ORA-00603: ORACLE server session terminated by fatal errorWhy ORA-00603?
    Best regards,
    Maciej

    It may be a bug, or it may be a result of the dependencies between the materialized views. I don't have a 9.2.0.6 instance that I'm willing to trash to test this, but this is what I get on 9.2.0.1.
    If it is a bug they at least changed the behaviour of the bug in 9.2.0.6.
    I ran your script up to the first commit then did:
    SQL> SELECT * FROM t;
            ID T_NAME     T_DATE
             1 A          29-JUL-05
             2 B          29-JUL-05
             3 A          29-JUL-05
             4 A          29-JUL-05
             5 B          29-JUL-05
    SQL> SELECT * FROM t_mv;
    T_NAME             ID T_DATE      COUNT(*)
    A                   4 29-JUL-05          3
    B                   5 29-JUL-05          2
    SQL> SELECT * FROM v;
            ID       T_ID V_NAME
             1          1 V_A_1
             2          2 V_B_1
             3          3 V_A_2
             4          4 V_A_3
             5          5 V_B_2
    SQL> SELECT * FROM v_mv;
    no rows selectedHUH?? But:
    SQL> SELECT v.rowid rowid1, t_mv.rowid rowid2, v.v_name, v.t_id
      2  FROM v, t_mv
      3  WHERE v.t_id = t_mv.id;
    ROWID1             ROWID2             V_NAME           T_ID
    AAAH4QAAIAAAAl1AAD AAAH4MAAIAAAAlFAAA V_A_3               4
    AAAH4QAAIAAAAl1AAE AAAH4MAAIAAAAlFAAB V_B_2               5So, I tried:
    SQL> EXEC DBMS_MVIEW.REFRESH('V_MV');
    PL/SQL procedure successfully completed.
    SQL> SELECT * FROM v_mv;
    no rows selectedNow, this is confusing, so:
    SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
    PL/SQL procedure successfully completed.
    SQL> SELECT * FROM v_mv;
    ROWID1             ROWID2             V_NAME           T_ID
    AAAH4dAAIAAAAl1AAD AAAH4ZAAIAAAAlFAAA V_A_3               4
    AAAH4dAAIAAAAl1AAE AAAH4ZAAIAAAAlFAAB V_B_2               5So at least I've got something in the MV. Now, to continue your test:
    SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
    1 row created.
    SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
    1 row created.
    SQL> COMMIT;
    Commit complete.I also expected the error but no joy, and look at this:
    SQL> SELECT * FROM v_mv;
    ROWID1             ROWID2             V_NAME           T_ID
    AAAH4dAAIAAAAl1AAE AAAH4ZAAIAAAAlFAAB V_B_2               5Forcing the refresh on v_mv gets:
    SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
    BEGIN DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE'); END;
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-00001: unique constraint (OPS$ORACLE.V_MV_UK1) violatedVery strange! It gets better:
    SQL> DELETE FROM t WHERE id = 5;
    1 row deleted.
    SQL> commit;
    Commit complete.
    SQL> EXEC DBMS_MVIEW.REFRESH('V_MV', 'COMPLETE');
    PL/SQL procedure successfully completed.
    SQL> select * from v_mv;
    ROWID1             ROWID2             V_NAME           T_ID
    AAAH4dAAIAAAAl1AAF AAAH4ZAAIAAAAlFAAA V_B_2               6 But:
    SQL> SELECT * FROM t_mv;
    T_NAME             ID T_DATE      COUNT(*)
    A                   6 29-JUL-05          4
    B                   5 29-JUL-05          2
    SQL> SELECT * FROM t;
            ID T_NAME     T_DATE
             1 A          29-JUL-05
             2 B          29-JUL-05
             3 A          29-JUL-05
             4 A          29-JUL-05
             6 A          29-JUL-05Obvioulsy, something is not fast refreshing. So lets force it:
    SQL> EXEC DBMS_MVIEW.Refresh('T_MV', 'COMPLETE');
    PL/SQL procedure successfully completed.
    SQL> SELECT * FROM t_mv;
    T_NAME             ID T_DATE      COUNT(*)
    A                   6 29-JUL-05          4
    B                   2 29-JUL-05          1
    SQL> SELECT * FROM v_mv;
    ROWID1             ROWID2             V_NAME           T_ID
    AAAH4dAAIAAAAl1AAB AAAH4qAAIAAAAlEAAB V_B_1               2
    AAAH4dAAIAAAAl1AAF AAAH4qAAIAAAAlEAAA V_B_2               6Which looks right to me.
    Then, I blew everything away and did it allagain up to an including the inserts into t, then I inserted into v and commited. Now, both MV's were correct, so I did:
    SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
    1 row created.
    SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> SELECT * FROM t_mv;
    T_NAME             ID T_DATE      COUNT(*)
    A                   6 29-JUL-05          4
    B                   5 29-JUL-05          2Still strange, so blow it all away again insert into t commit, insert into v commit, then:
    SQL> insert into t (id, t_name, t_date) values (6, 'A', sysdate);
    1 row created.
    SQL> commit;
    Commit complete.
    SQL> insert into v (id, t_id, v_name) values (6, 6, 'V_B_2');
    1 row created.
    SQL> commit;
    commit
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-00001: unique constraint (OPS$ORACLE.V_MV_UK1) violatedAt least now it sees the error at commit time for v so lets try the delete:
    SQL> delete from t where id = 5;
    1 row deleted.
    SQL> commit;
    Commit complete.
    SQL> SELECT * FROM t_mv;
    T_NAME             ID T_DATE      COUNT(*)
    A                   6 29-JUL-05          4
    B                   5 29-JUL-05          2
    SQL> SELECT * FROM t;
            ID T_NAME     T_DATE
             1 A          29-JUL-05
             2 B          29-JUL-05
             3 A          29-JUL-05
             4 A          29-JUL-05
             6 A          29-JUL-05Still not actually refreshing somehow.
    I may play with this some more, it seems truly strange to me.
    John

  • ORA-00600: internal error when delete master rows in a materialized view

    I have a materialized view in 11g2 on Redhat 5, defined asCREATE MATERIALIZED VIEW mv_idty
    PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
    select IDTY_NAME_FIRST,IDTY_NAME_MIDDLE,IDTY_NAME_LAST,IDTY_NAME_SUFFIX,IDTY_SSN,
      IDTY_DR_LIC_NUM,IDTY_DR_LIC_STA,x.person_id,i.rowid i_rowid,x.rowid x_rowid
      from idty i,person_x_idty x where x.idty_id=i.idty_id; I deleted a few rows from the master tables and get error13:58:48 SQL> delete idty where  idty_id like 'test_row%' ;
    7 rows deleted.
    13:58:52 SQL> commit;
    commit
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-00600: internal error code, arguments: [kkzfrfajv_markdml-1], [], [], [], [], [], [], [], [], [], [], [] I have other materialized views and they all delete master OK. This is the simplest one but causes problem. HELP!
    Edited by: user13148231 on Aug 11, 2010 5:45 PM

    Checked note 743766.1. It is not 100% relevant as it is about import, but the query is usefulselect sowner, vname, mowner, master from sys.snap_reftime$It reveals the materialized view some how based on other schema.
    Recreate the materialized view. problem solved.

  • Issue with fast refresh on a materialized view

    Hi,
    Oracle DB version is 10.2.0.3
    We have a matierialized view created using this script. We have materialized view logs on these six tables.
    By default, it is set to ON COMMIT .
    When a batch job is run every morning (usually 100-200 records) we set it to ON DEMAND and then bring it back to ON COMMIT. It takes around 1-2 minutes.
    If the batch is unusually big, like say 100,000 it takes more than 5 hours to put it back on ON COMMIT. (We analyze the schema (GATHER STALE) before refreshing the MV.) Trace shows deletes taking a long time.
    When I see a big batch, I usually drop the view and recreate it with indexes (there is also a context index). Takes 30 mins to do the whole thing.
    I tried refreshing it COMPLETE when the num of rows is high but it still takes more than 2 hours..(I killed it)
    Is there any way to speed things up without dropping and recreating the MV ?
    thanks
    Mat view creation script:
    CREATE MATERIALIZED VIEW WCC_INTERNAL_SEARCH_M
    TABLESPACE ICV_TS_WCC_DATA
    NOCACHE
    LOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    REFRESH FAST ON COMMIT
    WITH ROWID
    AS
    SELECT orgname.ROWID orgname_rowid,
    cnt.ROWID cnt_rowid,
    locgrp.ROWID locgrp_rowid,
    cntry.ROWID cdcntry_rowid,
    addrgrp.ROWID addrgrp_rowid,
    addr.ROWID addr_rowid,
    cnt.cont_id cont_id,
    decode(cntry.name,'US',substr(addr.postal_code,1,5),addr.postal_code) postal_code,
    cntry.name country,
    UPPER(addr.addr_line_one) addr_line_one,
    UPPER(addr.addr_line_two) addr_line_two,
    UPPER(addr.addr_line_three) addr_line_three,
    UPPER(addr.CITY_NAME) city_name,
    UPPER(cnt.CONTACT_NAME) display_name,
    UPPER(orgname.ORG_NAME) org_name,
    addr.prov_state_tp_cd
    FROM orgname,
    contact cnt,
    locationgroup locgrp,
    cdcountrytp cntry,
    addressgroup addrgrp,
    address addr
    WHERE locgrp.cont_id = orgname.cont_id
    AND locgrp.cont_id = cnt.cont_id
    AND addrgrp.location_group_id = locgrp.location_group_id
    AND addr.country_tp_cd = cntry.country_tp_cd
    AND addr.address_id = addrgrp.address_id
    AND cnt.INACTIVATED_DT is null
    AND locgrp.END_DT is null
    AND orgname.END_DT is null
    AND cnt.person_org_code = 'O'
    AND cntry.lang_tp_cd = 100
    AND locgrp.member_ind = 'Y'
    AND locgrp.loc_group_tp_code = 'A'
    ORDER by org_name,city_name,postal_code,country;

    This is the script that creates the preferences and then the context index.
    exec ctx_ddl.create_preference('STEM_FUZZY_PREF', 'BASIC_WORDLIST');
    exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_MATCH','AUTO');
    exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_SCORE','60');
    exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','FUZZY_NUMRESULTS','100');
    exec ctx_ddl.set_attribute('STEM_FUZZY_PREF','STEMMER','AUTO');
    exec ctx_ddl.set_attribute('STEM_FUZZY_PREF', 'wildcard_maxterms',15000) ;
    exec ctx_ddl.create_preference('LEXTER_PREF', 'BASIC_LEXER');
    exec ctx_ddl.set_attribute('LEXTER_PREF','index_stems', 'ENGLISH');
    exec ctx_ddl.set_attribute('LEXTER_PREF','skipjoins',',''."+/-&');
    exec ctx_ddl.create_preference('ICV_WCC_INT_SEARCH_CTX_PREF', 'BASIC_STORAGE');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'I_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'K_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'N_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'I_INDEX_CLAUSE','tablespace ICV_TS_CTX_IDX compress 2');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'P_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
    exec ctx_ddl.set_attribute('ICV_WCC_INT_SEARCH_CTX_PREF', 'R_TABLE_CLAUSE','tablespace ICV_TS_CTX_IDX');
    CREATE INDEX WCC_INT_SEARCH_CTX_I1 ON WCC_INTERNAL_SEARCH_M
    (ORG_NAME)
    INDEXTYPE IS CTXSYS.CTXCAT
    PARAMETERS('Wordlist STEM_FUZZY_PREF
    LEXER LEXTER_PREF
    STORAGE ICV_WCC_INT_SEARCH_CTX_PREF');
    DB is 10.2.0.3

Maybe you are looking for