Refresh Mviews

hi all,
I have few Materialized views that are dependent on one another..
ex: mv1, mv2, mv3..
I wrote code that will submit jobs to refresh all 3 views at the same time...
but it should be in the order mv1, mv2, mv3..
well, i can loop through it in that order...
then what's the problem?
which table should i look up to make sure that the mview has refreshed successfully..
i am assuming it is not the "all_scheduler_jobs" coz it just says that the job is submitted successfully...
correct me if i am wrong..
and could any one help me out of this..
thank you

I think i need to rephrase my question..
how to refresh nested materialized views...
and i think i found the answer in my book....
in DBMS_MVIEW.REFRESH procedure..
need to set the nested parameter to TRUE...
thanks for looking at my question.... and answer too..
please let me know if i am wrong...
thank you

Similar Messages

  • Fast Refresh mview performance

    Hi,
    I'm actually facing with Fast Refresh Mview performace problems and i would like to know what is the possible improvments for the fast refresh procedure:
    - base table is 1 500 000 000 rows partitions by day , subparttion by has (4)
    - mlog partition by hash (4) with indexes on pk and snaptime
    - mview partition by day subpartition by hash (4)
    10 000 000 insertions / day in base table/mlog
    What improvment or indexes can i add to improve fast refresh ?
    Thanks for help

    Hi,
    Which DB version are you using?
    Did you have a look at the MV refresh via Partition Change Tracking (PCT)?
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/advmv.htm#sthref575
    If it's possible to use PCT, it would probably improve a lot the performance of the refresh of your MV.
    Regards
    Maurice

  • Refreshing mview is hanging after a database level gather stats

    hi guys,
    can you please help me identify the root cause of this issue.
    the scenario is this:
    1. we have a scheduled unix job that will refresh an mview everyday, from tuesday to saturdays.
    2. database maintenance being done during weekends (sundays), gathering stats at a database level.
    3. the refresh mview unix job apparently is hanging every tuesdays.
    4. our workaround is to kill the job, request for a schema gather stats, then re-run the job. and voila, refresh mview will be successful then.
    5. and the rest of the weekdays until saturdays, refresh mview is having no problems.
    we already identified during testing that the scenario where the refresh mview is failing is when after we are gathering stats in a database level.
    during gather stats in a schema level, refresh mview is successful.
    can you please help me understand why we are failing refreshing mview after we gather stats in the database level??
    we are using oracle 9i
    the creation of the mview goes something like below:
    create materialized view hanging_mview
    build deferred
    refresh on demand
    query rewrite disabled
    appreciate all your help.
    thanks a lot in advance.

    1. we have a scheduled unix job that will refresh an mview everyday, from tuesday to saturdays.
    2. database maintenance being done during weekends (sundays), gathering stats at a database level.
    3. the refresh mview unix job apparently is hanging every tuesdays.
    4. our workaround is to kill the job, request for a schema gather stats, then re-run the job. and voila, refresh mview will be successful then.
    5. and the rest of the weekdays until saturdays, refresh mview is having no problems.
    You know Tuesday's MV refresh "hangs".
    You don't know why it does not complete.
    You desire solution so that it does complete.
    You don't really know what is is doing on Tuesdays, but hope automagical solution will be offered here.
    The ONLY way I know how to possibly get some clues is SQL_TRACE.
    Only after knowing where time is being spent will you have a chance to take corrective action.
    The ball is in your court.
    Enjoy your mystery!

  • Fast Refreshable MVIEW

    Trying to create a fast refresh materialized view based on a simple join of two tables over a database link oracle gives a 'COMPLEX QUERY' error (ORA-12015).
    Logging on the origin tables should be ok as creating the MVIEW based on the same select but in the database where the origin tables are poses no problem. The logging tables are created based on primary key and include rowid.
    The select on which the MVIEW should be created is someting like:
    select
    tab1.rowidn id1,
    tab2.rowidn id2,
    tab1.key_idn key1,
    tab2.key_idn key2
    from table1@other_db tabl,table2@other_db tab2
    where tab1.key_idn = tab2.key_idn)
    Does this mean it is impossible to create a fast refresh materialized view over a database link when a join condition is involved?

    Replace the ANSI Joins with Conventional Joins.
    Change this :
    SELECT * FROM V_FIRST VF
    LEFT JOIN R4
    ON VF.ID=R4.ID
    LEFT JOIN R5
    ON  VF.ID=R5.IDto this :
    SELECT VF.* FROM V_FIRST VF, R4, R5
    WHERE  VF.ID=R4.ID
    AND  VF.ID=R5.IDHemant K Chitale

  • Fast refreshable mviews vs. cdc

    im currently working on a new data warehouse environment. i need to create an ods schema for each of the operational systems in my warehouse.
    i've looked at two of 10gR2 prefered technologies for this task:
    fast refreshable materialized view and change data capture.
    i would to know what is the difference between this two approaches.
    in my understanding, there both cause a performance overhead and require some amount of additional work on each dml operations. in addition , there both work on the method of capturing changes from a table and applying them on a target database.
    the only difference i could think of is that cdc capture changes from the redo log so that commit time on the operational system wont be affected (as much as it would when logging a dml operation in a mview log).

    dba_snapshot_refresh_times or dba_mview_refresh_times would help.
    select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
    This will work only if the refresh is scheduled to run through job queue.

  • Error when try to Fast Refresh Mview ......

    Guys d u have an idea .....
    why when I running job that fast refresh an mview.
    I alwayas got error :
    ORA-12008: error in materialized view refresh path
    ORA-01555: snapshot too old: rollback segment number 2268 with name
    "_SYSSMU2268$" too small
    undo_management set to AUTO.
    undo tablespace has enough space.
    I have mview log on master database.
    regards,
    indrajati

    damorgan's request for more information is completele relevant.
    However, "Snapshot to old" is often due to insufficient rollback/undo space. What happens (grossly simplified) is that when re-reading stored data the database finds it has been overwritten and raises the error. The suggested fix is usually to increase rollback/undo space.

  • How much time My FAST refreshable MVIEWS taken to refresh in last refresh?

    How to find the DURATION of last FAST refresh of MVIEWS?
    Refresh duration will vary depends on data change on base table. I would like to find the duration of last refresh

    dba_snapshot_refresh_times or dba_mview_refresh_times would help.
    select job, last_date last_refresh, next_date next_refresh, total_time,what from dba_jobs where what like '%dbms_refresh%'
    This will work only if the refresh is scheduled to run through job queue.

  • Fast refresh Mview

    hi
    plz tell me why am not able to create a Fast refresh materialized View
    SQL> CONNECT SCHEMA1/SCHEMA@HOST;
    Connected.
    SQL> CREATE MATERIALIZED VIEW LOG ON COMPANY WITH PRIMARY KEY;
    Materialized view log created.
    SQL> CREATE MATERIALIZED VIEW LOG ON EMPLOYEE WITH PRIMARY KEY;
    Materialized view log created.
    SQL> GRANT SELECT ON MLOG$_COMPANY TO SCHEMAREP;
    Grant succeeded.
    SQL> GRANT SELECT ON MLOG$_EMPLOYEE TO SCHEMAREP;
    Grant succeeded.
    SQL> CONNECT SCHEMAREP/REPORTS@HOST;
    Connected.
    SQL>
    SQL> CREATE MATERIALIZED VIEW mview_1
    2 REFRESH fast on DEMAND
    3 AS
    4 SELECT EMPLOYEE.EMPLOYEE_num
    5 FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
    6 WHERE COMPANY.COMPANY_ID=EMPLOYEE.COMPANY_ID;
    FROM schema1.COMPANY company,schema1.EMPLOYEE EMPLOYEE
    ERROR at line 5:
    ORA-12052: cannot fast refresh materialized view SCHEMAREP.MVIEW_1
    SQL>

    You would be able to answer yourself your question, if you
    a) read the restrictions for fast refresheable materialized view at
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#sthref537
    b) make you familiar with the packaged procedure dbms_mview.explain_mview
    Best regards
    Maxim

  • Fast refreshable Mview question.

    Hi All,
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    PL/SQL Release 11.1.0.7.0 - Production
    "CORE     11.1.0.7.0     Production"
    TNS for Linux: Version 11.1.0.7.0 - Production
    NLSRTL Version 11.1.0.7.0 - Production
    Can't we make a Fast refresh materialized view which has UNIONALL operator on REMOTE DATA BASE..?
    REMOTEDB: R
    TARGETDB:T
    Note: all these tables are in Remote DB(R) and I want to create a Mat view on Target DB (T).
    create or replace view V_FIRST
    As
    select * from R1
    UNION ALL
    select * from R2
    UNION ALL
    select * from R3Now i am creating a Fast refresh Mat view
    CREATE MATERIALIZED VIEW REMOTE_MV
    REFRESH FAST ON DEMAND AS
    SELECT * FROM V_FIRST VF
    LEFT JOIN R4
    ON VF.ID=R4.ID
    LEFT JOIN R5
    ON  VF.ID=R5.IDHere i am getting error can not create a fast refreshable mat view on a complex query.
    I think we can create a fast refreshable Mat view which has UNION ALL operator... I don't know about remote tables.
    How to achieve this... with out splitting the Mat view ?. Is there any way..?
    Appreciate your help.
    Thanks,
    Mike

    Replace the ANSI Joins with Conventional Joins.
    Change this :
    SELECT * FROM V_FIRST VF
    LEFT JOIN R4
    ON VF.ID=R4.ID
    LEFT JOIN R5
    ON  VF.ID=R5.IDto this :
    SELECT VF.* FROM V_FIRST VF, R4, R5
    WHERE  VF.ID=R4.ID
    AND  VF.ID=R5.IDHemant K Chitale

  • Refresh MVIEW fails

    When trying to refresh a materializes view in Oracle 9.2 shown error occurs:
    FEHLER in Zeile 1:
    ORA-04068: existing state of packages has been discarded
    ORA-04063: package body "SYS.DBMS_DEFER_SYS" has errors
    ORA-06508: PL/SQL: could not find program unit being called
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Line 794
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Line 851
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Line 832
    ORA-06512: in Line 1
    This is how the m. view has been created:
    In Oracle8 this works, i Oracle9 not, why?
    create materialized view log
    on testtable WITH PRIMARY KEY;
    create materialized view testview
    refresh fast start with sysdate next sysdate+1
    as select * from testtable
    execute dbms_snapshot.refresh('testview','F');
    Any help is appreciated
    Adriane

    Hi.
    This is because you did not created a snapshot, but a materialized view.
    I suggest you to try with the dbms_refresh package to refresh your materialized view instead of using dbms_snapshot, please let me know the results
    Best regards

  • Refreshing mview inside SP

    I have a materialized view XYZ which i want to refresh complete by the following command in side an sp.
    DBMS_MVIEW.REFRESH('XYZ','C');
    Now i have located the command just before the exception block.There are certain reasons which compelled me to refresh it like this only.My sp is getting invoked from application through jdbc thin client.Now this technique is working in some database and failing in some others.I need to identify the cause.
    I appreciate any suggestion towards this.

    Now this technique is working in some database and failing in some others.I need to identify the cause.And what error handling, logging do you have in place to help your investigations?
    Cheers, APC

  • Problem with MVIEW Refresh

    Hi all,
    I am facing the following problem while refreshing MVIEWS.
    ORA-12008: error in materialized view refresh path
    ORA-03113: end-of-file on communication channel.
    I am using the following method to refresh.
    dbms_mview.REFRESH ('Mview_Name',
    'C',
    TRUE,
    FALSE,
    0,
    0,
    0,
    TRUE
    The script for creating MVIEW is as follows:-
    CREATE MATERIALIZED VIEW gb_ghx_orgs_a
    PCTFREE 5 PCTUSED 60
    TABLESPACE TableSpace_Name
    STORAGE (INITIAL 250k NEXT 250k)
    REFRESH COMPLETE WITH ROWID
    START WITH SYSDATE
    AS
    SELECT Statement;
    can any body help.
    Thanks

    What version of database do you have? what client version are you connecting from?
    ORA-03113 may required you to contact Oracle Support.
    SQL> CREATE MATERIALIZED VIEW gb_ghx_orgs_a
      2  PCTFREE 5 PCTUSED 60
      3  TABLESPACE KKISHORE
      4  STORAGE (INITIAL 250k NEXT 250k)
      5  REFRESH COMPLETE WITH ROWID
      6  START WITH SYSDATE
      7  AS
      8  select * from scott.emp
      9  /
    Materialized view created.
    SQL> begin
      2      dbms_mview.REFRESH ('gb_ghx_orgs_a',
      3      'C',
      4      '',
      5      TRUE,
      6      FALSE,
      7      0,
      8      0,
      9      0,
    10      TRUE
    11      );
    12  end ;
    13  /
    PL/SQL procedure successfully completed.
    SQL> disconnect
    Disconnected from Oracle9i Enterprise Edition Release 9.2.0.3.0 - Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.3.0 - Production
    SQL>

  • Different subpartitioning schemes for mviews and PCT-refresh

    It appears that I can have a table RANGE-partitioned by some field (DATE) and LIST-subpartitioned by another field (let's call it subfield2). Then I create materialized view (mview) based on that table, RANGE-partitioned by the same DATE field, but subpartitioned by another field (subfield1, logically parent of subfield2). Then I create another mview, again RANGE-partitioned by the same DATE field, but not subpartitioned at all.
    PCT-refresh (dbms_mview.refresh('mview_name', 'P')) works fine, producing correct results. But I wonder if subpartitioning is taken into account when refreshing mviews. My suspicion is that only primary partitioning is taken into account, and primary partitions are refreshed as a whole, even if only one or few subpartitions have been modified in a table. Are my assumptions correct?
    Another question - can I preserve partitions in mview if dropping them in underlying table? Table stores raw data, and legacy partitions may be dropped to free up some space. But mviews which store data aggregated on some levels may need to preserve data either longer than in raw table, or forever. I could not find a way of achieving this - when I drop a partition from a table on which mviews are built, and refresh mviews - data from dropped partitions of a table is gone from mviews, even though partitions of mviews are not deleted.

    It appears that I can have a table RANGE-partitioned by some field (DATE) and LIST-subpartitioned by another field (let's call it subfield2). Then I create materialized view (mview) based on that table, RANGE-partitioned by the same DATE field, but subpartitioned by another field (subfield1, logically parent of subfield2). Then I create another mview, again RANGE-partitioned by the same DATE field, but not subpartitioned at all.
    PCT-refresh (dbms_mview.refresh('mview_name', 'P')) works fine, producing correct results. But I wonder if subpartitioning is taken into account when refreshing mviews. My suspicion is that only primary partitioning is taken into account, and primary partitions are refreshed as a whole, even if only one or few subpartitions have been modified in a table. Are my assumptions correct?
    Another question - can I preserve partitions in mview if dropping them in underlying table? Table stores raw data, and legacy partitions may be dropped to free up some space. But mviews which store data aggregated on some levels may need to preserve data either longer than in raw table, or forever. I could not find a way of achieving this - when I drop a partition from a table on which mviews are built, and refresh mviews - data from dropped partitions of a table is gone from mviews, even though partitions of mviews are not deleted.

  • Refresh Fast option in Materialize view

    Dear All,
    We have oracle 10g On windows.
    We have database A having SCOTT schema and tables Emp and Dept.
    I have another database B having TEST schema and this schema does not have any objects (Moto is to create mview on this database).
    We have created DB LINK between TEST schema to SCOTT schema and planning to create materialize view in TEST schema.
    Now I am confuse....
    1) I am creating mview in TEST schema and i want to refresh mview increamentally. I search on internet and found only if you want to use FAST REFRESH then you must have to create log table for the base table.
    --Query is
    1)  I am creating mview in TEST schema and my base tables are in SCOTT schema on different database. Where should i create log table(on SCOTT SCHEMA or TEST schema).
    2) Does this log tables will occupy more space or log table will truncate after refresh of mview.
    3) For using incremental refresh i need to use +REFRESH FORCE+ option or anything else.
    4) If log table will not truncate then it will occupy more space so is there anything that we can come up out of this situation.Thanks..

    1) You should create log in Scott Schema
    2)
    Managing Materialized View Log Space
    Oracle automatically tracks which rows in a materialized view log have been used during the refreshes of materialized views, and purges these rows from the log so that the log does not grow endlessly. Because multiple simple materialized views can use the same materialized view log, rows already used to refresh one materialized view might still be needed to refresh another materialized view. Oracle does not delete rows from the log until all materialized views have used them.
    For example, suppose two materialized views were created against the customers table in a master site. Oracle refreshes the customers materialized view at the spdb1 database. However, the server that manages the master table and associated materialized view log does not purge the materialized view log rows used during the refresh of this materialized view until the customers materialized view at the spdb2 database also refreshes using these rows.
    Because Oracle must wait for all dependent materialized views to refresh before purging rows from a materialized view log, unwanted situations can occur that cause a materialized view log to grow indefinitely when multiple materialized views are based on the same master table or master materialized view.
    For example, such situations can occur when more than one materialized view is based on a master table or master materialized view and one of the following conditions is true:
    One materialized view is not configured for automatic refreshes and has not been manually refreshed for a long time.
    One materialized view has an infrequent refresh interval, such as every year (365 days).
    A network failure has prevented an automatic refresh of one or more of the materialized views based on the master table or master materialized view.
    A network or site failure has prevented a master table or master materialized view from becoming aware that a materialized view has been dropped.
    Note:
    If you purge or TRUNCATE a materialized view log before a materialized view has refreshed the changes that were deleted, then the materialized view must perform a complete refresh.
    Purging Rows from a Materialized View Log
    Always try to keep a materialized view log as small as possible to minimize the database space that it uses. To remove rows from a materialized view log and make space for newer log records, you can perform one of the following actions:
    Refresh the materialized views associated with the log so that Oracle can purge rows from the materialized view log.
    Manually purge records in the log by deleting rows required only by the nth least recently refreshed materialized views.
    To manually purge rows from a materialized view log, execute the PURGE_LOG procedure of the DBMS_MVIEW package at the database that contains the log. For example, to purge entries from the materialized view log of the customers table that are necessary only for the least recently refreshed materialized view, execute the following procedure:
    3) REFRESH FAST
    4) See step 2

  • Regarding error in fast refresh for Materialized

    ORA-12015: cannot create a fast refresh materialized view from a complex query
    CREATE MATERIALIZED VIEW CRESTELVIEWSDEV510.MVCONTENTHISTORY
    TABLESPACE CRESTELVIEWSDEV510
    NOCACHE
    LOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    REFRESH FAST
    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;
    while creation time of this Materialized I have receive above error ORA-12015
    I have also crated log with Primary on all base tables and index on column that is in where clause.
    Kindly provide solution .
    I want to create this MV with FAST Refresh.
    Regards,
    nayana chavda.

    What's your Oracle version?
    The error is pretty self explanatory. You can not build fast refresh MView with complex query.
    check Oracle document,
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14226/repmview.htm#BABEEHGJ
    To be fast refreshed, the defining query for a materialized view must observe certain restrictions. If you require a materialized view whose defining query is more general and cannot observe the restrictions, then the materialized view is complex and cannot be fast refreshed.
    ...

Maybe you are looking for