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

Similar Messages

  • 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

  • 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

  • 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

  • Setting DBMS_METADATA.GET_DDL Output for Materialized Views

    Hi all.
    My Oracle version is 10g.
    I'm extracting the DDL of all the objects from database using the DBMS_METADATA package. I'm using SET_TRANSFORM_PARAM to configure the output because I need a simple sql code, without information about tablespaces, storage and segment attributes. Everything works fine except when I'm working with mviews object types. I can't remove the information about tablespace, storage or segment attributes for materialized views.
    I would like to know if there's a related issue about it. Or there's something missing in my code?
    I tried to specify the object type as another parameter on DBMS_METADATA.SET_TRANSFORM_PARAM but don't work too.
    The only transform parameter that works fine with Materialized Views is the SQLTERMINATOR.
    See how I have done:
    declare
    vDDL clob;
    begin
    dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'STORAGE', FALSE);
    dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'TABLESPACE', FALSE);
    dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'SEGMENT_ATTRIBUTES', FALSE);
    dbms_metadata.set_transform_param (DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR',TRUE);
    select dbms_metadata.get_ddl ('MATERIALIZED_VIEW', 'MV_STO020', 'HIS117_CHECK') into vDDL FROM DUAL;
    dbms_output.put_line (vDDL);
    end;
    and how the output is:
    CREATE MATERIALIZED VIEW "HIS117_CHECK"."MV_STO020"
    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 "TS_HIS117"
    BUILD IMMEDIATE
    USING INDEX
    REFRESH FORCE ON DEMAND
    WITH PRIMARY KEY USING DEFAULT LOCAL ROLLBACK SEGMENT
    DISABLE QUERY REWRITE
    AS SELECT
    STO020_MOVEMENT_LOG_ID STO020_MOVEMENT_LOG_ID
    , STO020_QUANTITY STO020_QUANTITY
    , STO020_DATE STO020_DATE
    , STO020_BEFORE_BALANCE STO020_BEFORE_BALANCE
    , STO011_PRODUCT_MOVEMENT_ID STO011_PRODUCT_MOVEMENT_ID
    , ADM082_PRODUCT_ID ADM082_PRODUCT_ID
    , ADM089_PRODUCT_PRESENTATION_ID ADM089_PRODUCT_PRESENTATION_ID
    , STO010_MOVEMENT_TYPE_ID STO010_MOVEMENT_TYPE_ID
    , STO001_STOCK_ID STO001_STOCK_ID
    , STO001_TARGET_STOCK_ID STO001_TARGET_STOCK_ID
    , STO003_PRODUCT_LOT_ID STO003_PRODUCT_LOT_ID
    , SYS010_USER_ID SYS010_USER_ID
    , EIR001_MPI EIR001_MPI
    , ADM056_MEDICAL_ATTENTION_ID ADM056_MEDICAL_ATTENTION_ID
    , ADM094_USE_UNIT_ID ADM094_USE_UNIT_ID
    FROM
    STO020_MOVEMENT_LOG;
    Thank you in advanced!
    Edited by: lucporto on 28/08/2012 07:26

    Right. I found this way but I consider this just a quick fix, because I think there should be a better way to do this.
    create table t_clob (c_long);
    declare
    p clob;
    begin
    delete from t_clob;
    execute immediate 'insert into t_clob (select to_lob(query) from dba_mviews where owner = :1 and mview_name = :2)'
    USING 'HIS117', 'MV_STO020';
    select 'CREATE MATERIALIZED VIEW MV_STO020' || chr(10) ||
    'REFRESH ON DEMAND' || chr(10) || 'AS' || CHR(10) || mv.c_long
    into p
    from t_clob mv;
    dbms_output.put_line(p);
    end;
    Thanks all.

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

  • Query against materialized view awful after refresh of Mview

    We have a materialized view defined to refresh complete daily at 5am. YOu can run queries against the MV alone or joining it to other tables. Results come back in 2 or 3 seconds. Once the MView refreshes at 5am - those same queries now take 15 minutes or even more sometimes to complete. WHY IS THIS HAPPENING?? Help anyone?

    okay this is better... sorry...
    this is the GOOD EXPLAIN PLAN:
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                      
    | Id  | Operation                         |  Name             | Rows  | Bytes | Cost  |                                                                                                                                                                                                
    |   0 | SELECT STATEMENT                  |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   1 |  SORT AGGREGATE                   |                   |     1 |   127 |       |                                                                                                                                                                                                
    |   2 |   NESTED LOOPS                    |                   |     1 |   127 |  1665 |                                                                                                                                                                                                
    |   3 |    NESTED LOOPS                   |                   |     1 |   113 |  1664 |                                                                                                                                                                                                
    |   4 |     NESTED LOOPS                  |                   |     1 |    99 |  1663 |                                                                                                                                                                                                
    |   5 |      NESTED LOOPS                 |                   |     1 |    88 |  1662 |                                                                                                                                                                                                
    |*  6 |       HASH JOIN ANTI              |                   |     1 |    70 |  1661 |                                                                                                                                                                                                
    |*  7 |        TABLE ACCESS BY INDEX ROWID| CONTACT           |  3815 |   201K|  1534 |                                                                                                                                                                                                
    |   8 |         AND-EQUAL                 |                   |       |       |       |                                                                                                                                                                                                
    |*  9 |          INDEX RANGE SCAN         | IDX_CNT__C_STATE  |       |       |       |                                                                                                                                                                                                
    |* 10 |          INDEX RANGE SCAN         | IDX_CNT__STATUS   |       |       |       |                                                                                                                                                                                                
    |  11 |        INDEX FAST FULL SCAN       | PK_RPP            | 69277 |  1082K|   120 |                                                                                                                                                                                                
    |* 12 |       TABLE ACCESS BY INDEX ROWID | REP_PROFILE       |     1 |    18 |     1 |                                                                                                                                                                                                
    |* 13 |        INDEX UNIQUE SCAN          | PK_C19            |     1 |       |       |                                                                                                                                                                                                
    |* 14 |      INDEX UNIQUE SCAN            | PK_B01            |     1 |    11 |       |                                                                                                                                                                                                
    |* 15 |     INDEX UNIQUE SCAN             | PK_B02            |     1 |    14 |       |                                                                                                                                                                                                
    |* 16 |    INDEX UNIQUE SCAN              | PK_RCN            |     1 |    14 |       |                                                                                                                                                                                                
    Predicate Information (identified by operation id):                                                                                                                                                                                                                                    
       6 - access("B"."CONTACT_ID"="RPP"."PARTNERSHIP_ID")                                                                                                                                                                                                                                 
       7 - filter("B"."C_STATE"='GA' AND "B"."C_LAST"<>'Name Unknown' AND                                                                                                                                                                                                                  
                  "B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
       9 - access("B"."C_STATE"='GA')                                                                                                                                                                                                                                                      
      10 - access("B"."STATUS"='Confirmed')                                                                                                                                                                                                                                                
      12 - filter("C19"."TERR1"='46')                                                                                                                                                                                                                                                      
      13 - access("B"."CONTACT_ID"="C19"."CONTACT_ID")                                                                                                                                                                                                                                     
      14 - access("B"."FIRM_ID"="B01"."FIRM_ID")                                                                                                                                                                                                                                           
      15 - access("B"."OFFICE_ID"="B02"."OFFICE_ID")                                                                                                                                                                                                                                       
      16 - access("B"."CONTACT_ID"="RCN"."CONTACT_ID")                                                                                                                                                                                                                                     
    Note: cpu costing is off                                                                                                                                                                                                                                                               
    38 rows selected.

  • Refreshing materialized view fails

    Hi,
    I'm trying to refresh a materialized view. I've set up everything according to the documentation but when I try to do a refresh of the MV I get an end-of-file on communication channel. I know there is not a single cause of this error but maybe someone has an idea. The statement is:
    CALL DBMS_MVIEW.REFRESH ('ismart_user.psis_images', '?');
    The output of sql*plus:
    list => 'ismart_user.psis_images',
    ERROR at line 3:
    ORA-03113: end-of-file on communication channel
    The mv table is defined as:
    PSIS_IMAGE_ID NOT NULL NUMBER
    PSIS_IMAGE ORDSYS.ORDIMAGE
    PSIS_THUMBNAIL ORDSYS.ORDIMAGE
    PSIS_IMAGE_NAME VARCHAR2(50)
    PSIS_IMAGE_WIDTH NUMBER
    PSIS_IMAGE_HEIGHTN NUMBER
    There are about 50 other table (also with ORDSYS.ORDIMAGE columns) which don't give any problem, only this single table. (FYI: the table is empty).
    What can be the cause of the end-of-file on comm channel error?

    There are many reasons for this error. I suggest you check for related docs on Metalink.

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

  • Creating a Materialized View Log After the Data has been instered

    Hi,
    I am trying to create a method of replication from Oracle to MySQL using the Materialized View Log table.
    This has been done before and works quite well, the only problem is that I am trying to impliment the log after the table has been created and populated and wish to push all the existing data through the log file...
    Does anyone know if it is possible to refresh the Materialized View Log and not a Materialized View.
    The way the replication is intended to work is:
    Oracle> Data inserted into table
    Oracle> writes the vector data to the MVL
    Script> Monitors the MVL and can see the changes being made to the Oracle Table
    Script> Updates MySQL with the data and removes the rows from the MVL
    MySQL is then used with other unix systems
    Currently we export the data from the table using Triggers and a cronjob running every x minute to check for changes in the TriggerTables
    Many thanks for your time on this, I have been checking for almost a whole working day and not found the answer to this problem.

    Thats what I thought, the MVL will only read data that has changed since it was created and wont have the option to load in all the data as though it was made before the table was created.
    From what I have read, the MVL is quicker than a Trigger and I have some free code that prooved to work from a MVL using it as a reference to know what records to update. There is not that much to a MVL, a record ID and type of update, New, Update or Delete.
    I think what I will have to do is work on a the same principle for the MVL but use a Trigger as this way we can do a full reload if required at any point.
    Many thanks for your help.

  • Materialized view on a Partitioned Table (Data through Exchange Partition)

    Hello,
    We have a scenario to create a MV on a Partitioned Table which get data through Exchange Partition strategy. Obviously, with exchange partition snap shot logs are not updated and FAST refreshes are not possible. Also, this partitioned table being a 450 million rows, COMPLETE refresh is not an option for us.
    I would like to know the alternatives for this approach,
    Any suggestions would be appreciated,
    thank you

    From your post it seems that you are trying to create a fast refresh view (as you are creating MV log). There are limitations on fast refresh which is documented in the oracle documentation.
    http://docs.oracle.com/cd/B28359_01/server.111/b28313/basicmv.htm#i1007028
    If you are not planning to do a fast refresh then as already mentioned by Solomon it is a valid approach used in multiple scenarios.
    Thanks,
    Jayadeep

  • Create materialized view failed!

    I want to create a mv from a table which does not contain primary key constraint,but failed. why?
    SQL> Create Table tb_test01
    2 (
    3 Id Number,
    4 Name Varchar2(1024)
    5 );
    Table created.
    SQL>
    SQL> Create Materialized View Log On tb_test01
    2 With Sequence,Rowid(Id,Name)
    3 Including New Values;
    Materialized view log created.
    SQL> Create Materialized View mv_tb_test01
    2 Refresh Fast On Commit
    3 As
    4 Select * From tb_test01;
    Select * From tb_test01
    ERROR at line 4:
    ORA-00604: error occurred at recursive SQL level 1
    ORA-06502: PL/SQL: numeric or value error
    ORA-06512: at line 7
    ORA-12014: table 'TB_TEST01' does not contain a primary key constraint

    12014, 00000, "table '%s' does not contain a primary key constraint"
    // *Cause:  The CREATE MATERIALIZED VIEW LOG command was issued with the
    //          WITH PRIMARY KEY option and the master table did not contain
    //          a primary key constraint or the constraint was disabled.
    // *Action: Reissue the command using only the WITH ROWID option, create a
    //          primary key constraint on the master table, or enable an existing
    //          primary key constraint.

  • Create materialized View fails with "table or view does not exist"

    DB: 10.2.0.4
    OS: Win 2003
    Hi,
    Here in my tests, i have 2 databases (A(source) and B(backup)), and i am trying to create an mview in database B to replicate data from one test table from database A, only for test purpose. I'm getting the error "table or view does not exist" when i try to create a mview with REFRESH FAST. Here is my code:
    CREATE MATERIALIZED VIEW TESTES.TAB_TESTES_REPLIC_MVIEW_02
    REFRESH FAST
    START WITH TO_DATE('21/02/2012 18:50:00', 'DD/MM/YYYY HH24:MI:SS')
    NEXT SYSDATE + 1/24/60
    WITH PRIMARY KEY
    AS SELECT REGISTRO1,
    REGISTRO2
    FROM TESTES.TAB_TESTES_REPLIC_MVIEW_02@DB_LINK_ORA10;
    The dblink is workig fine(dblink user has select privilege on TESTES.TAB_TESTES_REPLIC_MVIEW_02), and i have created the mview log on database A.
    Where is my mistake.
    Thanks a lot.
    Edited by: Fabricio_Jorge on 21/02/2012 19:06

    I found the solution.
    I had to grant SELECT on the mview log. The name is avaiable in DBA_MVIEW_LOGS

  • Fast refersh materialized view having group by in it's select query

    Hi,
    Can any one please tell me from which version of Oracle we can create a fast refresh materialized materialized view having group by in it's select query.
    Regards,
    Koushik

    i dont know from which version this feature is started but I know that
    in 9i it works and we implemented for DWH projects

Maybe you are looking for

  • Issue while loading the library files(".so" or ".sl") using JNI

    Hi, We are loading the c library files using system.load during the init phase of servlet. While loading the application for the first time everything goes smooth and application behaves as expected. We are facing the below issue when we try restarti

  • Free good flow in return sales order

    Hi all I have a question that is how to make the free good item(TANN in order and RENN in returns) flow automatically in the return sales order along with the REN items. Does it involve item category proposal in copy control for billing document to s

  • Oracle sql developer 1.0.0.15 error

    i have aproblem in sql developer when i tried to make new gallery ....when select file>new>filter by >all item and highlight Database Objects there is no Data Mining PL/SQL Package option. i need it to work because iam using oracle data miner 10.2.0.

  • Unix system() system call in Java

    Hi, system() call in Unix is very helpfull when you need to implement a piece of code that is already implemented in an exsiting utility. Is there a way to achive a similar functionality? To put it in simpler words - is there a way, in Java, to call

  • How to create a generic TYPES?

    hello! what i try to do is following eg: when i call my function the user has the possibility to check the flag "show_button = 'X', and exports a table when this flag is checked i want to display an icon in the first row of this table, so i need to e