Refresh of a materialized view

Hi All!
I have a materialized view defined like:
CREATE MATERIALIZED VIEW v_ship_info_new
PCTFREE 5 PCTUSED 60
TABLESPACE DATA_BIG
STORAGE
INITIAL 32768K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
USING INDEX STORAGE (INITIAL 2M NEXT 500K)
REFRESH START WITH ROUND(SYSDATE + 1) + 08/24
NEXT ROUND(SYSDATE + 2) + 08/24
AS
SELECT .....
The view was created on Sep.-13-2005. I expected that the view will be refreshed today at 08:00 AM, but the last_ddl_time in user_objects is Sep.-18-2005 and the data in the view is also from Sep.-18-2005. There is no time filter in SELECT statement. The view should shows a result of left outer join of two tables.
Any idea?
Thanks,
Andrej

Andrej,
You should consider the NEXT interval relative to the last materialized view refresh. Reading your materialized view definition it results that:
- the materialized view was refreshed for the first time on 14-sep at 8:00 am (START WITH ROUND(SYSDATE + 1) + 08/24)
- the materialized view is then refreshed on 16-sep at 8:00 am, 18-sep at 8:00 am (ROUND(SYSDATE + 2) + 08/24)
Considering you have specified the START WITH clause in your command, the NEXT date should be considered starting from the timestamp of the last refresh and not from the moment of the materialized view creation.
Regards,
Adi

Similar Messages

  • Peformance on complete refresh of a Materialized View

    We are currently doing a complete refresh of a materialized view (35 mil rows) on a monthly basis. My question is would it be faster to disable all the indexes prior to refresh? if so, should we enable the indexes or simply rebuild and which would be faster? Below is the package we are calling to refresh the MV. Also, our platform is Oracle 11g1 Rac on Solaris 10. Thanks.
    DBMS_MVIEW.REFRESH(MVIEW_NAME, 'C', ATOMIC_REFRESH => FALSE, PARALLELISM=>16);

    Trace it and see.
    With ATOMIC_REFRESH set to FALSE, Oracle would be doing a TRUNCATE. See if it does a Direct Path Insert. (It should be doing so).
    In which case, Index maintenance is deferred to the end.
    Yet, Oracle builds "temporary" index segments when doing the insert and merges them later.
    You might still get a performance benefit from setting the indexes to UNUSABLE (or DROPping them) and then doing a REBUID/CREATE with NOLOGGING and a different degree of Parallelism.
    You'd have to test it yourself and see what the difference is.
    Hemant K Chitale

  • Refresh Order Management Materialized Views errors out in R12.1.3

    Hi All -
    Refresh Order Management Materialized Views errors out in R12.1.3 when submitted with blank parameters. Please find below error details ..
    OEXITORDMV module: Refresh Order Management Materialized Views
    Current system time is 15-OCT-2012 11:30:29
    **Starts**15-OCT-2012 11:30:29
    ORACLE error 12008 in FDPSTP
    Cause: FDPSTP failed due to ORA-12008: error in materialized view refresh path
    ORA-01555: snapshot too old: rollback segment number 4 with name "_SYSSMU4_3768336236$" too small
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2566
    ORA
    Start of log messages from FND_FILE
    End of log messages from FND_FILE
    Thanks,

    Cause: FDPSTP failed due to ORA-12008: error in materialized view refresh path
    ORA-01555: snapshot too old: rollback segment number 4 with name "_SYSSMU4_3768336236$" too small
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2566Please see old threads for the ORA-015555 docs you need to refer to.
    https://forums.oracle.com/forums/search.jspa?threadID=&q=ORA-01555&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
    https://forums.oracle.com/forums/search.jspa?threadID=&q=ORA-01555+AND+Materialized+AND+View&objID=c3&dateRange=all&userID=&numResults=15&rankBy=10001
    Thanks,
    Hussein

  • 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

  • Refresh time for Materialized View

    Hi,
    I have created a materialized view and set it to refresh everyday at 4 am . When I check the status of the job , it shows the refresh timing between 20 mins to 4 hours . That means , some times it takes 20 mins to refresh , some times 40 , some time 2 hours and some times up to 4 hours. Any reason for the wide range ? Here is the query for the view.
    CREATE MATERIALIZED VIEW BDS_COST_CATEGORY_MV
      ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
      STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
      PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
      TABLESPACE "USERS"
      BUILD IMMEDIATE
      USING INDEX
      REFRESH COMPLETE ON DEMAND START WITH sysdate+0 NEXT ROUND(SYSDATE + 1) + 4/24
      USING DEFAULT LOCAL ROLLBACK SEGMENT
      DISABLE QUERY REWRITE
      AS    SELECT  AC.ACCOUNT_MANAGER, AC.ACCOUNT_NUMBER,
                    AC.ACCOUNT_NAME, DIV.DIVISION_NUMBER, ITEM.CODE_ID,
                    ITEM.CODE_NAME COST_CATEGORY_ITEM,
                    TO_NUMBER(TO_CHAR(AP.FIRST_DAY,'YYYY')) PERIOD_YEAR, 
                    AP.FIRST_DAY PERIOD,
                    SUM(NVL(AD.CURRENT_EXPENSE,0)) EXPENSE
            FROM ACCOUNTS AC, PERSONNEL AC_MGR, DIVISIONS DIV, ASR_HEADERS AH , ASR_DETAILS AD, CODES ITEM, CODES COSTCAT, ALL_PERIODS  AP,
                    CODES COST_ELEMENT, ACCOUNTING_BASE_GROUP ABG
            WHERE   AC.ACCOUNT_MANAGER = AC_MGR.PERSONNEL_ID
            AND     AC_MGR.DIVISION_ID = DIV.DIVISION_ID (+)
            AND     AC.ACCOUNT_ID = AH.ACCOUNT_ID
            AND     AH.ASR_HEADER_ID = AD.ASR_HEADER_ID
            AND     AH.PERIOD_ASR = AP.FISCAL_SYSTEM_PERIOD_CAL_YR_EQ||', '|| AP.FISCAL_YEAR
            AND     ABG.COST_ELEMENT_CAT_ITEM_ID = ITEM.CODE_ID 
            AND     COST_ELEMENT.CODE_ID = ABG.COST_ELEMENT_ID
            AND     AD.OBJECT_CODE = COST_ELEMENT.CODE_VALUE
            AND     ITEM.CODE_PARENT_ID = COSTCAT.CODE_ID
            AND     ( COSTCAT.CODE_NAME = 'BDS' OR ( COSTCAT.CODE_NAME = 'Base' AND ITEM.CODE_NAME = 'MTDC'))
            GROUP BY AC.ACCOUNT_MANAGER,AC.ACCOUNT_NUMBER, AC.ACCOUNT_NAME,
                     DIV.DIVISION_NUMBER, ITEM.CODE_ID, ITEM.CODE_NAME, 
                     TO_NUMBER(TO_CHAR(AP.FIRST_DAY,'YYYY')), AP.FIRST_DAY

    This appears to be a duplicate of Refreshing Materilized view. I replied on the other thread.
    Justin

  • Error while complete refresh of a materialized view

    Hi All,
    while refreshing a materialized view i m getting error
    SQL> exec dbms_snapshot.refresh('supplier','C');
    BEGIN dbms_snapshot.refresh('supplier','C'); END;
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-04030: out of process memory when trying to allocate bytes (,)
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 803
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 860
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 841
    ORA-06512: at line 1
    Please help me to resolve this error.
    Thank you in advance
    regards,
    Narendra

    Check Metalink Note:233869.1
    Thanks
    Chandra Pabba

  • Fast refresh of a materialized view works incorrect

    Hi All,
    I have created a MV using the sql below:
    create materialized view WLS
    refresh fast
    enable query rewrite
    as
    SELECT Employees.USER_NAME,
           Permissions.ROLE_NAME,
           Vouchers.VOUCHER_ID,
           EmployeeRoles.FROM_DATE,
           EmployeeRoles.TO_DATE,
           VoucherPatterns.rowid   ACC_VOUCHER_PATTERNS_ROW_ID,
           Vouchers.rowid          ACC_VOUCHERS_ROW_ID,
           Ledgers.rowid           ACC_LEDGERS_ROW_ID,
           Employees.rowid         BANK_EMPLOYEES_ROW_ID,
           IncExcUnits.rowid       INC_EXC_UNITS_ROW_ID,
           EmployeeRoles.rowid     BANK_EMPLOYEE_ROLES_ROW_ID,
           ParentRoles.rowid       PARENT_ROLES_ROW_ID,
           Roles.rowid             ROLES_ROW_ID,
           Permissions.rowid       PERMISSIONS_ROLES_ROW_ID,
           RolesMemberships.rowid  ROLES_MEMBERSHIPS_ROW_ID
      FROM ACC_VOUCHER_PATTERNS        VoucherPatterns,
           ACC_VOUCHERS                Vouchers,
           ACC_LEDGERS                 Ledgers,
           BANK_EMPLOYEES              Employees,
           BANK_EMPLOYEE_INC_EXC_UNITS IncExcUnits,
           BANK_EMPLOYEE_ROLES         EmployeeRoles,
           ROLES                       ParentRoles,
           ROLES                       Roles,
           ROLES                       Permissions,
           ROLES_MEMBERSHIPS           RolesMemberships
    WHERE Vouchers.TYPE_VOUCHER_PATTERN_FK =
           VoucherPatterns.VOUCHER_PATTERN_ID
       AND VoucherPatterns.CONFIRM_COUNT = 2
       AND Vouchers.STATE = 'ISU'
       AND Vouchers.LEDGER_FK = Ledgers.LEDGER_ID
       AND Employees.ID = IncExcUnits.BKEM_ID(+)
       AND (((IncExcUnits.INC_EXCLUD_TYPE IS NULL OR
           IncExcUnits.INC_EXCLUD_TYPE != 'EXC') AND
           Ledgers.ORGANIZATION_UNIT_FK = Employees.ORGU_ID) OR
           (Ledgers.ORGANIZATION_UNIT_FK = IncExcUnits.ORGU_ID AND
           IncExcUnits.INC_EXCLUD_TYPE = 'INC'))
       AND EmployeeRoles.BKEM_ID = Employees.ID
       AND ParentRoles.ID = EmployeeRoles.ROLS_ID
       AND ParentRoles.IS_PERMISSION = 'N'
       AND ParentRoles.ROLE_TYPE = 'ORG'
       AND ParentRoles.ID = Roles.ROLS_ID
       AND Roles.IS_PERMISSION = 'N'
       AND Roles.ROLE_TYPE = 'SYS'
       AND Permissions.IS_PERMISSION = 'Y'
       AND Permissions.ROLE_NAME = 'ACC_AccVoucherConfirm'
       AND Roles.ID = RolesMemberships.ROLS_ID
       AND Permissions.ID = RolesMemberships.ROLS_ID_MEMBER_OF;
    Then I have issued a SELECT * though it and that works fine.
    And then I've manipulated the data in some tables such that according to MV's WHERE clause it must return no rows.
    Intuitively before refreshing the MV it will return the data last placed on it,
    But it return the same data after issuing the following command in PL/SQL Developer:
    call dbms_mview.refresh(list => 'WLS', method => 'F');
    And unfortunately the following will correct it:
    call dbms_mview.refresh(list => 'WLS', method => 'C');
    Why the fast refresh of a fast refreshable MV does not work fine while its complete refresh works good?
    How ever after undoing made changes to those tables and issuing the fast refresh using the following command the MV will contain correct updated data:
    call dbms_mview.refresh(list => 'WLS', method => 'F');
    It seems that it has bug in deleting rows from Fast Refreshable MV but upserts work fine.
    I've tried to simulate the problem for a simpler query with simple tables containing some sample data but those don't have any problem.
    Please help me,
    Thanks

    Thanks Martin,
    Finally I've discovered one of possible several situations in which a MV fast refreshed incorrectly.
    This is happened when an OR condition exists among several AND conditions and at least one outer join symbol there exists!
    this is the scenario:
    -- create two sample tables
    create table t as select 1 a, 2 b from dual;
    create table j as select 1 a, 2 b from dual;
    -- defining primary keys
    alter table t add constraint tp primary key (a);
    alter table j add constraint jp primary key (a);
    -- creating MV Logs
    create materialized view log on t with primary key, rowid;
    create materialized view log on j with primary key, rowid;
    -- creating Fast Refresh MV with a sample query
    create materialized view mvt refresh fast enable query rewrite as
    select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
    and (t.b = j.b or t.a = t.b);
    -- select through MV, the MV returns correct data
    select * from mvt;
         A    B    TR                    JR
        1    2    AAAYwQAAEAAFhwzAAA    AAAYwRAAEAAFhw7AAA
    -- intentionally manipulate the data to the query returns no rows
    update j set a = 2;
    commit;
    -- query the select of MV
    select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
    and (t.b = j.b or t.a = t.b);
    -- returns now rows, The query rewrite does not work here!
    -- select through MV, the MV returns correct data because it has not refreshed yet!
    select * from mvt;
         A    B    TR                    JR
        1    2    AAAYwQAAEAAFhwzAAA    AAAYwRAAEAAFhw7AAA
    -- fast refreshing the mv and issuing select again
    call dbms_mview.refresh(list => 'MVT', method => 'F');
    select * from mvt;
         A    B        TR                    JR
        1    null    AAAYwuAAEAAFh2jAAA    null
    -- A change is occured but it is not correct, it must returns no rows!
    -- query the select of MV
    select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
    and (t.b = j.b or t.a = t.b);
         A    B        TR                    JR
        1    null    AAAYwuAAEAAFh2jAAA    null
    -- Query rewrite does work here! because appending a neutral "and 1=1" conditions will show the correct empty result:
    select t.a, j.b, t.rowid tr, j.rowid jr from t,j where t.a = j.a(+)
    and (t.b = j.b or t.a = t.b) and 1=1;
    -- returns no rows
    -- now complete refreshing the MV and achieving the correct result:
    call dbms_mview.refresh(list => 'MVT', method => 'C');
    select * from mvt;
    -- returns no rows
    Is this a BUG?
    Any suggestions?

  • Issue in Complete Refresh of a Materialized View

    Hello,
    We have an MV in the Datawarehouse that does a FAST REFRESH daily. Every Saturday, a COMPLETE REFRESH is done as part of the normal Database Activities. The Database is Oracle 9i. The MV contains a Join between a Dimension and Fact Table of a Datawarehouse and does a FAST REFRESH using the MV logs.
    However, last Sat, the COMPLETE REFRESH has failed. The DBA tried to run the script twice again but it failed on both occasions with an UNDO TABLESPACE error (ORA-30036). The DBA tried to extend the Tablespace; it did not help either.
    - Could this be linked to Tablespace allocations for the MV? Are there any specific steps that can be followed to resolve this?
    - Can the MV be dropped and re-created?
    Would appreciate a response on the same.
    Many Thanks,
    Ketan

    Hi Ketan,
    I guess this is probably because MV complete refresh performs "delete" from the MV and then insert. If the MV is large, it may fail on undo allocation.
    Please take a look at Re: materialized view refresh time!  Plz Help me! you can see the explanation, metalink note and the solution (how to perform truncate instead of delete).
    HTH
    Liron Amitzi
    Senior DBA consultant
    [www.dbsnaps.com]
    [www.orbiumsoftware.com]

  • About Refresh Error In Materialized view

    hi
    i have
    Oracle 9.2.0.1 at the windows server 2003
    i have created some materialized view to use in my one web application running on tomcat
    i have scheduling for refresh it using refresh utility available in oracle materialized view snapshot refresh
    but when its try to run state of refresh become unusable and table according to it
    remains empty
    when i try to do it manually it gives error log
    Ora-12008 error in materialized view refresh path
    ora-01114 io error writing block to file 201(block #2621321)
    ora-27069 skgfdisp:attmempt to do i/o beyond the range of file
    osd-04026 invalid parameter passed(OS 2621327)
    ora-01114 io error writing block to file 201(block#2621321)
    ora-27069 skgfdisp:attempt do i/o beyond the range of the file
    osd-04026 invalid parameter passed (OS 2621327)
    ora 06512 at "SYS.DBMS_SNAPSHOt",line 794
    ora 06512 at "SYS.DBMS_SNAPSHOt", line 851
    ora 06512 at "SYS.DBMS_SNAPSHOt", line 832
    ora 06512 at line 2
    even i could not understand this error
    one strange thing in this when i restart my server and try to refresh
    it is going to be refresh
    please help me

    I suspect one of your datafiles has exceeded the 4Gb windows limit. Your tablespace has probably been set to autoextend and this has created the problem. I am not sure what you can do at this point apart from recover from backup. I would open a TAR with Oracle Support as soon as possible to try and resolve this issue.
    Please note: This forum is for OLAP issues only. If you need more information I would try posting on the database forum.
    Keith Laker
    Oracle EMEA Consulting
    OLAP Blog: http://oracleOLAP.blogspot.com/
    OLAP Wiki: http://wiki.oracle.com/page/Oracle+OLAP+Option
    DM Blog: http://oracledmt.blogspot.com/
    OWB Blog : http://blogs.oracle.com/warehousebuilder/
    OWB Wiki : http://wiki.oracle.com/page/Oracle+Warehouse+Builder
    DW on OTN : http://www.oracle.com/technology/products/bi/db/11g/index.html

  • Refresh fails on materialized view with CLOB data type

    Hi,
    Hope somebody can help me with this issue.
    Some materialized views get status broken on refreshment, but only sometime. When I try to refresh them manually I get following message: "ORA-01400: cannot insert NULL into...". But I know for sure that there are no NULL values in the master table, MV and master tables are declared in the same way and all columns in master tables are NOT NULL columns. Another ting is that this error I get only on columns with data type CLOB.
    Please, help!
    /Julia

    hi,
    I cant upgrade to 11g.Also i cant change the table structure.
    Here is a sample of xmltype field content:
    RECID      XMLRECORD
    D00009999      <row id='D100009999'><c2>10000</c2><c3>xxxxx</c3><c5>xxxx..
    And i need to extract in the mv the data from c2, c3 and so on.
    Still waiting for a hint.
    Thank you.

  • Refresh FAST for Materialized View failed after Partition Operation

    Dear all,
    I have created a Materialized View having a simple join between a Dimension and Fact Table of a Datawarehouse. The MV is REFRESH FAST ON DEMAND.
    However, when a Partition Maintenance Operation (PMOP) was performed on the Master Tables, the MV failed to Refresh giving a ORA-32313 error.
    As suggested on one of the troubleshooting websites, we did a complete refresh of the MV and fixed it temporarily. However, I would like to know the exact cause for this and would like to have a permanent fix for the same.
    Can the DBA for this Database provide me the answers or are there some standard troubleshooting steps for the same?
    Please let me know.
    Best,
    Ketan

    Hello Maurice,
    Here are the answers to your questions.
    1) Database is Oracle 9i.
    2) We have a stored procedure to refresh the MV. The command is dbms_mview.refresh('SALES_FACT_MV','f'). It was working fine daily. Only after a PMOP was done on the Master Tables, it failed to refresh. We have also created indexes on some columns of the MV for performance improvement. We are getting a very good improvement.
    3) We have MV logs for both Master Tables to store the incremental values.
    4) We are not able to get the output from DBMS_MVIEW.EXPLAIN_MVIEW since this can be done only by the DBA. WIll update you once I have the info.
    5) Same as Point 2.
    Let me know if you need any further info.
    Thanks, Ketan

  • Refresh Frequency of Materialized Views

    Hi,
    We have a bunch of materialized views in our database. They are set to be refreshed once in 6 hours when they were created. But now we would like to stop the automatic refresh and make them manual.
    Is there a way to remove the refresh frequency on the materialized views so that they don't refresh automatically?
    Your help is much appreciated.
    Thanks.

    Hi,
    try to alter MV
    http://download.oracle.com/docs/cd/B13789_01/server.101/b10759/statements_2001.htm#CCHECCJB
    regards, michael

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

  • 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

  • Time taken to Refresh a Materialized View

    Hi,
    Can we somehow estimate the approximate time it takes to Fast Refresh a particular Materialized View?
    In my case it is REFRESH FAST ON DEMAND and it contains close to 65 Million Records. On a daily basis 40K records are updated/inserted in the Materialized View. Also MV Logs are created on the Master Tables.
    The query of the MV is a join between a Dimension and Fact Table of a Datawarehouse. Each Master Table contains close to 70 million records.
    Could you please let me know?
    Thanks, Ketan

    Hi Jignesh,
    Thanks for the reply.
    Actually what I would like to know is can we somehow estimate/forecast the Refresh Time before actually refreshing the MV.
    Currently, in my case I am testing in a Non-Production Environment where the two MV logs contain 65K and just 70 records respectively. The Records finally Inserted/Updated from the MV is just 50. The time to refresh is about 7 minutes.
    However, in the Production Environment, I am expecting close to 25-30K Inserts/Updates from the MV. So, I would like to know if we could PREDICT the approximate time required to Refresh a far larger dataset?
    For example, to refresh close to 100K records in the View Logs will it take a far greater time or just some additional time? Is the Refresh rate directly dependent on the Number of Records to be refreshed or it takes a standard time to Refresh irrespective of the No. of Records?
    Would appreciate your inputs on this.
    Thanks, Ketan

Maybe you are looking for