Materialized view rows deletion

Hi all,
I have a question!
If the rows in master table are deleted on which a materialized view exist on a remote site, then the corresponding rows from materialized view will also be deleted on refresh?
Appreciate your help
IM

Great, so it means the total number of rows in master table and total number of rows in materialized view will remain same on refresh.
Thanks!
Edited by: user6885664 on Feb 26, 2012 8:29 PM

Similar Messages

  • Need help on tuning materialized view refresh

    Hi All,
    I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
    I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
    Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
    While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
    CREATE MATERIALIZED VIEW apps.BAL_PART
    REFRESH FAST ON DEMAND
    ENABLE QUERY REWRITE as
    SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
    GL.GL_PERIOD.ROWID C4,
    "GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
    "GL"."GL_BALANCES21"."CURRENCY_CODE" ,
    "GL"."GL_BALANCES21"."PERIOD_NUM" ,
    "GL"."GL_BALANCES21"."PERIOD_YEAR" ,
    "GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
    "GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
    "GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
    "GL"."GL_PERIODS"."PERIOD_NAME" ,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
    NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
    NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
    FROM GL.GL_CODE_COMBINATIONS21,
    GL.GL_BALANCES21,
    GL.GL_SETS_OF_BOOKS,
    GL.GL_PERIODS
    WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
    AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
    AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
    AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
    AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
    AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
    AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
    and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
    DELETE FROM "APPS"."apps.BAL_PART" SNA$
    WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT 
      CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
      "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1  17759.00  171782.99  159422121    1267371 2564144739           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2  17759.00  171782.99  159422121    1267371 2564144739           0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: ALL_ROWS
    Parsing user id: 175  (APPS)   (recursive depth: 1)
    Rows     Row Source Operation
          0  DELETE  apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
    193128740   NESTED LOOPS  (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
          3    SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
         24     TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
    193128740    INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
    error during execute of EXPLAIN PLAN statement
    ORA-08187: snapshot expression not allowed here
    parse error offset: 314
    Elapsed times include waiting on following events:
      Event waited on                             Times   Max. Wait  Total Waited
      ----------------------------------------   Waited  ----------  ------------
      db file sequential read                   159520897        2.12     144415.96
      latch: cache buffers chains                   134        0.06          0.68
      latch: undo global data                        33        0.02          0.15
      latch: object queue header operation          521        0.02          0.53
      log file switch (private strand flush incomplete)
                                                    532        0.31         28.26
      resmgr:cpu quantum                            155        1.40         13.49
      resmgr:internal state change                   25        0.11          2.21
      latch free                                     10        0.00          0.00
      latch: cache buffers lru chain                  4        0.00          0.00
      rdbms ipc reply                               489        0.02          0.54
      reliable message                              587        0.00          0.56
      latch: row cache objects                        3        0.00          0.00
    ********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
    I want to do the fast refresh. Tables rows details below.
    SQL> select count(*) from gl.gl_code_combinations21;
    COUNT(*)
    3075255
    SQL> select count(*) from gl.GL_PERIODS;
    COUNT(*)
    1160
    SQL> select count(*) from gl.gl_balances21;
    COUNT(*)
    477613527
    SQL> select count(*) from gl.gl_sets_of_books;
    COUNT(*)
    6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
    select count(*) from apps.BAL_PART group by C3;
    C3 is the rowid which is present in create materialized statement.
    COUNT(*)
    292927011
    210215
    69330
    184406971
    Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
    Please assist me in improving refresh of materialized view using fast refresh.
    Thanks and Regards,
    Edited by: user646034 on Feb 23, 2013 11:13 PM
    Edited by: user646034 on Feb 23, 2013 11:19 PM
    Edited by: user646034 on Feb 23, 2013 11:46 PM
    Edited by: user646034 on Feb 25, 2013 11:46 AM

    Hi
    The below explain without index and with index.
    /* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART                                                                                                                                                                                                                                                                                                                                                                                                                
    " SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE  */ * FROM (SELECT                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
    CHARTOROWID("MAS$"."M_ROW$$") RID$     FROM                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
    "GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$"   WHERE "MAS$".SNAPTIME$$ > :B_ST1                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    ) AS OF SNAPSHOT(:B_SCN) MAS$)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         
    Plan hash value: 2704021294                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | Id  | Operation            | Name                          | E-Rows |E-Bytes| Cost (%CPU)| E-Time   |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   0 | DELETE STATEMENT     |                               |        |       |   339K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   1 |  DELETE              | BAL_PART                          |        |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   2 |   NESTED LOOPS       |                               |      1 |   168 |   339K  (1)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   3 |    SORT UNIQUE       |                               |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   4 |     TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS        |      1 |   138 |     2   (0)| 00:02:31 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    |   5 |    INDEX RANGE SCAN  | C3BOOKS                       |    110M|  3164M|   339K  (0)|999:59:59 |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
    If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
    |   0 | DELETE STATEMENT       |                               |        |       |  9743K(100)|          |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
    |   1 |  DELETE                | BAL_PART                          |       |            |          |                                                                                                                                                                                                                                                                                                                                                                                                     

  • User_catalog - object listed as both 'TABLE' and 'MATERIALIZED VIEW'

    SELECT * FROM USER_CATALOG ORDER BY OBJECT_NAME
    returns ...
    OBJECT_NAME              OBJECT_TYPE       
    BLOBBY                   SYNONYM           
    BONUS                    TABLE             
    DEPT                     TABLE             
    EMP                      TABLE             
    EMPLOYEES                SYNONYM           
    EMPWITHDEPT              MATERIALIZED VIEW 
    EMPWITHDEPT              TABLE             
                             ^^^^^^^^^^^^Any ideas to show only the 'MATERIALIZED VIEW' row for the above query?
    Thanks in advance,
    Mike Norman

    So, I would need some sort of logic to
    check if the OBJECT_NAME from user_objects
    is present in user_snapshots print 'MATERIALIZED VIEW'
    otherwise take the OBJECT_TYPE from user_objects -
    some sort of DECODE?

  • Result of materialized views

    Hi,
    I have created a materialized view, making a complete refresh ervery day at 1am.
    It's possible that a query on this mview at refresh time will be empty will the query execute before and after the refresh wont be empty.
    (The refresh will take about 60 Minutes to complete.)
    Thanks.
    regards,
    Rainers

    When you do a complete refresh a materialized view, Oracle deletes the old data and inserts the new data in a single transaction. Queries will never see the materialized view as empty-- the will see the old data until the refresh finishes, at which point they will see the new data.
    Justin
    Distributed Database Consulting, Inc.
    http://www.ddbcinc.com/askDDBC

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

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

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

  • Query against materialized view from stored procedure brings back empty row

    I have a stored procedure that runs a query against a materialized view. When I run the query outside the SP it works just fine. When I change the MV to a table name, the SP works. When I change it back to the MV i get an empty row. Any ideas? The code is below:
    PROCEDURE getAuth     (p_naid        IN  NUMBER,
                             p_scope       IN VARCHAR2,
                             o_xml_data    OUT SYS_REFCURSOR
                             ) IS
      BEGIN
        IF p_scope = 'Approved' THEN
          OPEN o_xml_data FOR
            SELECT naid,
                   p_naid,
                   auth_type,
                   xml_data
            FROM some_mv
            WHERE naid = p_naid;   
          RETURN;
          CLOSE o_xml_data;
    ... the rest of the procedure ...

    does procedure contain EXCEPTION handler?
    if so, then remove, delete & eliminate EXCEPTION handler (at least during testing & debugging)

  • Materialized Views: how can I find the number of updates, inserts, delete

    We are using Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod.
    In a materialized view, with fast incremental refresh, done after every 5 minutes automatically, I want to store in a logging table the number of rows inserted,updated and deleted in the materialized view by that refresh.
    One option is to create a job that should read the materialized view log table just before the refresh and store the required information in the logging table. But this information may not be accurate.
    Is there any other way to collect this information for each refresh?

    Use auditing, or an before insert/update/delete trigger, that updates a counter
    I hate myself for giving this advice, because it will bring you problems, with the MV update/refresh speed, table lock contention on the log-table....
    Be carefull !!
    Why not use auditing on the source table and why does anyone wants to know the number of changes??
    Regards
    FJFranken

  • Oracle Materialized View | Deletion of Records, Oracle Materialized View

    One question reg Materialized views.
    If as part of housekeeping of the Source database we delete some records (older records), will the materialized view also be updated with the deletion?
    I believe the answer is yes. In that case can we ensure that this delete does not happen?
    Is there anyway we can prevent MView refresh from deleting the records that is once inserted even if we delete the same records in source DB?

    This is a common scenario, particularly with materialised views that summarise detail data where you want to keep the summary but not the detail, and it is addressed in the documentation.
    The technique is to make the MV refresh on demand, delete the data from the detail tables, and use the CONSIDER_FRESH procedure to prevent the changes propagating to the MV. You'll probably find it in the docs by searching on DBMS_MView.Consider_Fresh. There are a few warnings to note I think.

  • Multi-row Delete (MRD) on a view?

    All,
    I created a tabular form on a view, using an instead of trigger to encapsulate the logic for the data manipulations. Works great--until someone checks a row and hits the delete button, at which point APEX throws this error:
    ORA-20001: Error in multi row delete operation: row= 107970-18527, ORA-06502: PL/SQL: numeric or value error: character to number conversion error,
    Error     multi row operation failedAs far as I can tell, it's not even getting to the trigger; I commented out the body of the instead of delete trigger (replacing it with null), and I'm still getting the same error. I have no validations or processes on the page at this point.
    The underlying data of the view requires three columns for a unique identifier, so I've concatenated two of them together as an extra column in the view (creating a varchar2 column), and told the MRD to use the calculated column and the third column as the primary key columns. But even using two of the three numeric columns (tweaking the trigger to use a hard-coded value for the third) as an ID fails miserably.
    Any idea what's going on?
    Thanks,
    -David
    (In case it makes a difference, we're on APEX 4.0.1.)

    Hi David,
    This might help:
    http://oraclequirks.blogspot.com/2011/07/ora-20001-error-in-multi-row-delete.html
    Hope it helps!
    Regards,
    Kiran

  • Delete material view transaction MM06

    Hi gurus
    For error has been opened costing1 and costin2  material view for a material.
    Is there any way to delete only two material views?
    I have used transaction MM06 but deletes the material at plant level. Using transaction MM74 the modification should
    have to be effected but i don't know to use MM74.
    Can you help me?
    Thanks in advance

    it is not possible to delete views, deletion is only possible at organisation level. Costing is just a part of plant organisation, the fields are stored in table MARC.
    if the material was not in use, then you can archive the plant level only with SARA (object MM_MATNR) after you have flagged the plant level for deletion in MM06.
    then you can recreate the plant level without the unwanted views.
    For archiving of individual org levels, you may have to implement an OSS note

  • Whats the purpose of materialized view log?whats create view log with rowi

    Why we create materialized view log ?????whats the use???
    what do you mean by "create view log with rowid"
    Regards
    Gagan

    A materialized view log stores the change vectors made to a particular table in order to allow materialized views that reference that table to be incrementally refreshed rather than re-materializing the data every time. It's a much more efficient way to refresh a materialized view.
    WITH ROWID specifies that the materialized view log should store the ROWID of a row with the change vector, which is one way of identifying which row(s) in the materialized view should be updated by which change vector. You can also use the primary key value for this.
    Justin

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

  • 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

  • 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

  • BEST WAY TO REFRESH A MATERIALIZED VIEW

    Hi, I have a Materialized View that was created after two Base Tables, Table A is a Dynamic Table, this means that it have Insert's, update's and delete's, and a Table B that is a Fixed Table, this means that this table do not change over time (it's a Date's Table). The size of the Table related to the Materialized View is to big (120 millions rows) so the refresh has to be very efficient in order to not affect the Data Base performance.
    I was thinking on a Fast Refresh mode but It would not work because the log created on the B table is not usefull, the thing is that I created the two materialized view log's (Tables A and B) and when I execute the dbms_mview.refresh(list =>'MV', method => 'F')+ sentence I got the error
    cannot use rowid column from materialized view log on "Table B" ... remember that this table don't change over time ...
    I need to mantain the Materialized view up to date, but do not know how ... Please Help !!!!!

    The Materialized View name is test_sitedate2
    The Table B name is GCO01.FV_DATES .... is a Fixed Table ... do not change over time ...
    The Code of the MV is
    CREATE MATERIALIZED VIEW TEST_SITEDATE2
    REFRESH FORCE ON DEMAND
    AS
    SELECT site_id, date_stamp
    FROM gco01.fv_site, gco01.fv_dates
    where fv_dates.date_stamp >= fv_site.start_date
    and fv_dates.date_stamp >= to_date('01/03/2010', 'dd/mm/yyyy')
    and fv_dates.date_stamp < to_date('01/04/2010', 'dd/mm/yyyy');
    Each table gco01.fv_site and gco01.fv_dates have it's materiallized view log created
    The error is ....
    SQL> execute dbms_mview.refresh(list =>'test_sitedate2', method => 'F');
    begin dbms_mview.refresh(list =>'test_sitedate2', method => 'F'); end;
    ORA-12032: cannot use rowid column from materialized view log on "GCO01"."FV_DATES"
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2429
    ORA-06512: at line 1
    Thank's

Maybe you are looking for