Materialized view logs for Fast refreshes

Hi,
I created MV and MV logs on the base table/main table. I set the base table in NOLOGGING MODE. so ofcourse redo is not gonna generate during DML but i wanted to know that:
Will NOLOGGING effect the MV logs for fast refreshes?
I came up on conclusion that MV logs are nothing to do with Redo Logs and would have no impact on MV logs for fast refresh since i have set my all base table in NOLOGGING MODE.
Looking forward for expert opinion.
REGARDS,

Though I'm not an expert...
SQL> alter table emp nologging;
Table altered.
SQL> create materialized view log on emp;
Materialized view log created.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
EMP TABLE
BONUS TABLE
SALGRADE TABLE
RUPD$_EMP TABLE
MLOG$_EMP TABLE
SQL> insert into emp values(1000,'Matt','Test',100,sysdate,1000,1000,10,11,11);
1 row created.
SQL> select *From mlog$_emp;
EMPNO SNAPTIME$ D O
CHANGE_VECTOR$$
1000 01-JAN-00 I N
FEFF

Similar Messages

  • How to CREATE MATERIALIZED VIEW LOG (MV fast refresh) with some JOINS

    Hi @ all,
    i'm trying to create a MATERIALIZED VIEW LOG for a fast refresh of a MATERIALIZED VIEW.
    It works fine with a simple Request in the MATERIALIZED VIEW:
    CREATE MATERIALIZED VIEW MV_ZOTD43_P
    TABLESPACE GDII
    BUILD IMMEDIATE
    REFRESH FORCE AS
    SELECT * FROM ZOTD43_P;
    COMMIT;
    CREATE MATERIALIZED VIEW LOG ON ZOTD43_P
    TABLESPACE "GDII"
    WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;
    call DBMS_MVIEW.REFRESH('MV_ZOTD43_P', 'f');
    But when I use a complex SQL-Request with some JOINS (one of the Table with spatial Data) in the MATERIALIZED VIEW, I get an error:
    CREATE MATERIALIZED VIEW MV_TEST
    TABLESPACE GDII
    BUILD IMMEDIATE
    REFRESH FORCE AS
    SELECT lptd04_p.sst_nr AS sst_nr,
    lptd03_p.aaaa AS aaaa,
    lptd04_geom.geom as geom
    FROM lptd04_p lptd04_p
    JOIN lptd01_p lptd01_p ON lptd01_p.cre_nr = lptd04_p.sst_nr
    JOIN lptd04_geom ON lptd04_geom.sst_nr = lptd04_p.sst_nr
    JOIN lptd03_p lptd03_p ON lptd03_p.lief_nr = lptd04_p.lief_nr;
    COMMIT;
    CREATE MATERIALIZED VIEW LOG ON LPTD04_P
    TABLESPACE "GDII"
    WITH PRIMARY KEY, ROWID, SEQUENCE INCLUDING NEW VALUES;
    call DBMS_MVIEW.REFRESH('MV_TEST', 'f');
    Error report:
    SQL Error: ORA-12004: REFRESH FAST kann für Materialized View "GDI"."MV_GDI_SST_STAMM" nicht benutzt werden
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Zeile 2255
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Zeile 2461
    ORA-06512: in "SYS.DBMS_SNAPSHOT", Zeile 2430
    ORA-06512: in Zeile 1
    12004. 00000 - "REFRESH FAST cannot be used for materialized view \"%s\".\"%s\""
    *Cause:    The materialized view log does not exist or cannot be used. PCT
    refresh is also not enabled on the materialized view
    *Action:   Use just REFRESH, which will reinstantiate the entire table.
    If a materialized view log exists and the form of the materialized
    view allows the use of a materialized view log or PCT refresh is
    possible after a given set of changes, REFRESH FAST will
    be available starting the next time the materialized view is
    refreshed.
    Am I doing something wrong or is it not possible CREATE MATERIALIZED VIEW LOG when the MATERIALIZED VIEW got some JOINS?
    Regards,
    Greq

    Thanks for the link Alessandro ,
    the error seems something to do with the Column-Type SDO_GEOMETRY, so
    i create a new thread in the Spatial Discussion forum:
    FAST REFRESHing of Oracle Materialized Views containing SDO_GEOMETRY column
    Regards,
    Greq

  • Disabling Materialized View Logs for a session

    Hi all.
    I was wondering if it is possible to disable the fast refresh log for materialized views for just a given session. So for all other sessions except this one the log would be added to. I'm using 11g.
    In Oracle Database 11g, The Complete Reference on page 447 it states:
    "As of Oracle 11g, the capture of changes in materialized view logs can be disabled for an individual session while logging continues for changes made by other sessions". But no instructions are given
    Does anyone know how to do this? I have not been able to find the answer by looking around.
    Thanks!

    Yeah, I had saw that Oracle mentioned it here also: http://download.oracle.com/docs/cd/B28359_01/server.111/b28279/chapter1.htm#FEATURENO07197
    Any idea of what the code might look like? I've never had to alter an individual session for Oracle before.

  • INCLUDING NEW VALUES  in materialized view log

    CREATE MATERIALIZED VIEW products_mv
    REFRESH FAST ON COMMIT
    AS SELECT SUM(list_price - min_price), category_id
    FROM product_information
    GROUP BY category_id;
    Could anybody tell me why INCLUDING NEW VALUES are necessary in materialized view log for such an aggregate materialized view?
    Thanks,
    P.

    Answer depends on your need; do you need these values on your mv log -
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/basicmv.htm#sthref545
    Best regards.

  • Identifying updated column in materialized view logs

    Hi all,
    I created a materialized view log for a table with three columns(say colA,colB,colC). Is there any way to identify which column got updated among these three columns? through the entries in mat view logs?
    any inputs on this ll be of great help.
    Thanks in advance.
    gopi

    Can someone tell me about M_ROWS$$ column in Materialized view.
    I am in confucion.

  • Materialized view log timestamp

    I'm arranging materialized view logs for my developers that need to collect just the delta of some tables.
    I've created materialized view logs with option sequence so that they can have an additional ordering information.
    They are now asking me if there is an option for collecting even the transaction timestamp.
    I didn't find any thing better solution then adding a trigger on each mview log which writes sequence and timestamp on separate table.
    I don't want to use this additional triggers. Is there an option/workaround on mview logs to gather even this transaction timestamp?
    thanks in advance for your response,
    Max

    Ask your developers to add the TIMESTAMP column and trigger.

  • Overhead of Triggers VS Materialized View Logs

    If I need to log INSERTs, UPDTEs, and DELETEs on a table - is there a difference in the overhead of doing so via triggers vs MV logs?
    Thanks

    You said that MV log is marginally more efficient than a trigger. I am curious why. In what way do they work differently under the hood?If the essence of discussion is only why MV log is more efficient than trigger than I think Justin has pointed out below good technical points i.e.
    1.You don't have to pass control over to the PL/SQL engine.
    2.You're also writing the binary data that you'd put in the redo logs rather than column level data.
    And below text from docs :
    Internal Trigger for the Materialized View Log
    When changes are made to the master table or master materialized view using DML, an internal trigger records information about the affected rows in the materialized view log. This information includes the values of the primary key, rowid, or object id, or both, as well as the values of the other columns logged in the materialized view log. This is an internal AFTER ROW trigger that is automatically activated when you create a materialized view log for the target master table or master materialized view. It inserts a row into the materialized view log whenever an INSERT, UPDATE, or DELETE statement modifies the table's data. This trigger is always the last trigger to fire.http://docs.oracle.com/cd/B28359_01/server.111/b28326/repmview.htm#i30732
    3.Trigger i.e. we are coding to track the changes, MV log i.e. tool/technology which is provided by Oracle itself; so definately "We are not that much capable to write the code which is equal or more efficient than Oracle itself right ?"
    In fact, functionality of MV is Instead of Trigger, but under the cover, with near to Oracle's internals.
    Regards
    Girish Sharma

  • Materialized view (fast refresh mode) + Materialized view log on another DB

    Hi all,
    I created a materizalied view using this script :
    CREATE MATERIALIZED VIEW GIPS.DOSSIER_MEDICAL_MV2
    TABLESPACE GIPS_T
    NOCACHE
    NOLOGGING
    NOCOMPRESS
    NOPARALLEL
    BUILD IMMEDIATE
    USING INDEX
    TABLESPACE GIPS_I
    + REFRESH FAST ON DEMAND +
    START WITH TO_DATE('11-janv.-2011 16:00:00','dd-mon-yyyy hh24:mi:ss')
    NEXT sysdate (1/96)+
    AS
    SELECT N0_SEQ_BLOB_PDF,
    EXAM_ID,
    MPR,
    RSM,
    rub,
    date_deb,
    SPE,
    commentaire,
    SPR,
    MEP,
    MSJ,
    TTD,
    exam_type
    FROM DOSSIER_MEDICAL@dbdoc_lk
    WHERE DOSSIER_MEDICAL.EXAM_TYPE IN ('TELEM', 'SCANNER', 'EPPO_SECMED');
    So you can see I'm using a dblink in the select statement ( DBDOC_LK )
    On the DB referenced by this dblink, I created a materialized view log using this script :
    CREATE MATERIALIZED VIEW LOG ON "DOSMED"."DOSSIER_MEDICAL"
    TABLESPACE "DOC_T"
    WITH PRIMARY KEY
    INCLUDING NEW VALUES;
    The problem is that my materialized view has never refreshed since its creation ! and I don't understand why ?
    Can someone help me ?
    Thank you.

    The REFRESH schedule causes a job to be created for the execution of the Refresh. You should see this job in DBA_JOBS / USER_JOBS.
    The job would run only if the instance parameter JOB_QUEUE_PROCESSES is set to 1 or higher (the default is 0). This parameter can be modified dynamically with an ALTER SYSTEM command.
    Hemant K Chitale
    http://hemantoracledba.blogspot.com

  • Materialized View with Join for FAST Refresh

    Hi Gurus,
    Facing issues in MV with a simple join for FAST Refresh.
    2 sample Tables:
    1. employee
    empid integer PK
    empname varchar(50)
    deptid integer FK
    2. delta_employee
    empid integer PK
    empname varchar(50)
    deptid integer FK
    dmlflag varchar(2)
    watermark integer
    Code is as given below -
    CREATE MATERIALIZED VIEW LOG ON work.employee
    WITH SEQUENCE,rowid(empid)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW LOG ON work.delta_employee
    WITH SEQUENCE,rowid(empid)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW work.MVEmployee REFRESH force on
    demand with rowid AS
    select e.empid,e.empname,e.deptid,d.empid t1
    from work.employee e, work.delta_employee d
    where e.empid = d.empid;
    Able to perform Complete Refresh. Not able to use Fast Refresh for
    incremental refresh.
    Please help.
    Thanks,
    J Kumar

    Found a solution,
    As per oracle documentation rowid fileds should be included in the Select statement. Even though I included the rowid fields, empid in this case it still didnt work.
    The implementation of the rowid column should be included with tablename.rowid instead of the tablename.columnname !
    Modified script is as given below.
    CREATE MATERIALIZED VIEW WORK.MVEMPLOYEE
    REFRESH FORCE ON DEMAND
    WITH PRIMARY KEY
    AS
    select e.rowid "empid",d.rowid "t1" ,e.empname,e.deptid
    from work.employee e, work.delta_employee d
    where e.empid = d.empid;
    And It really WORKS

  • Enabling materialized view for fast refresh method

    In AWM when i select refresh method as FAST and enable the materialized view, am getting the below error:
    "Refresh method fast requires materialized view logs and a previously run complete refresh of the cube mv". i need this Fast refresh of a cube materialized view, so that it performs an incremental refresh and re-aggregation of only changed rows in the source table.
    can anyone help me on this??

    If you want the cube to hold data even after it has been deleted from the relational table, then you should disable the MV on the cube.
    Synchronization with the source table is determined by the default "cube script".
    <li>CLEAR, LOAD, SOLVE : This will synchronize your cube with the source table. It is a requirement for MVs.
    <li>LOAD, SOLVE: This will allow your cube to contain data even after it has been removed from the source table. It sounds like you want this.
    Cube builds can be "incremental" in one of two ways.
    (1) You can have an "incremental LOAD" if the source table contains only the changed rows or if you use MV "FAST" or "PCT" refresh. Since you can't use MVs, you would need a source table with only the changed rows.
    (2) You will have an "incremental SOLVE" (a.k.a. "incremental aggregation") if there is no "CLEAR VALUES" or "CLEAR AGGREGATES" step and various other conditions hold.
    To force a "complete LOAD" with an "incremental SOLVE" you should have all rows in your source table and run the following build script.
    LOAD, SOLVE You could also run "CLEAR LEAVES, LOAD, SOLVE" to synchronize the cube with the table.
    To force an "incremental LOAD" with a "complete SOLVE" you make the source table contains only the changed rows and the run the following:
    CLEAR AGGREGATES, LOAD, SOLVEor
    LOAD, CLEAR AGGREGATES, SOLVEFinally, if you want both LOAD and SOLVE to be incremental you make the source table contains only the changed rows and the run the following:
    LOAD, SOLVE

  • Is it possible to create materialized view log file for force refresh

    Is it possible to create materialized view log file for force refresh with join condition.
    Say for example:
    CREATE MATERIALIZED VIEW VU1
    REFRESH FORCE
    ON DEMAND
    AS
    SELECT e.employee_id, d.department_id from emp e and departments d
    where e.department_id = d.department_id;
    how can we create log file using 2 tables?
    Also am copying M.View result to new table. Is it possible to have the same values into the new table once the m.view get refreshed?

    You cannot create a record as a materialized view within the Application Designer.
    But there is workaround.
    Create the record as a table within the Application Designer. Don't build it.
    Inside your database, create the materialized with same name and columns as the record created previously.
    After that, you'll be able to work on that record as for all other within the Peoplesoft tools.
    But keep in mind do never build that object, that'll drop your materialized view and create a table instead.
    Same problem exists for partitioned tables, for function based-indexes and some other objects database vendor dependant. Same workaround is used.
    Nicolas.

  • Reg  ora-12034 materialized view log on younger than last refresh

    Hi,
    when i update my base table materialized view log shows the updated rows
    but when i refresh materialized view it wont show updated rows in materialized view and also there is no rows in materialzed log
    it shows error ora-12034: materialized view log on younger than last refresh
    cheers,

    FIX
    A complete refresh is required before the next fast refresh.
    Please run the process "Refresh Materialized Views"

  • Materialized View Log - Compress Clause for List Partition

    Hi All,
    In Syntax diagram it states that Compress Clause for List Partition of Materialized View Log is valid , but when we run any script with compress clause for list partition on Materialized view log then Database throws error as ORA-14020: this physical attribute may not be specified for a table partition
    So in any chance we can have the compress clause for the partition of materialized view log.
    Thanks in advance,
    Manu.

    The "CREATE MATERIALIZED VIEW LOG" syntax refers to the "Table Partitioning" section of the CREATE TABLE documentation.
    The "Table Partitioning" section refers to "table_partition_description" which then refers to "table_compression". "table_compression" then states that you can specify compression for entire table in the physical_properties clause and for range partition / list partition in the "table_partition_description". The Restrictions section on Table Compression says "You cannot define table compression explicitly for hash partitions or hash and list subpartitions" which implies that you can define partition for list partitions.
    Moreover, error 14020 lists valid options for Range or Composite Range and for Hash partitoins -- which implies that all other Table physical attributes are applicable for List partitions. (But then, is Compression a physical attribute -- it is really part of "physical properties" not "physical attributes").
    I think that the documentation isn't explicit enough and needs to be fixed.
    N.B : Referencing the 10.2 documentation.
    Hemant K Chitale
    Edited by: Hemant K Chitale on Feb 1, 2010 4:12 PM

  • Materialized view takes long to refresh

    On Oracle 11g2, I created a materialized view fast refresh on commit CREATE MATERIALIZED VIEW mv_case
    PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
    SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
      c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
      p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
    FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
    where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+)
      and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
    create index idx_mv_case_pid on mv_case(jperson_id);
    ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
    create index idx_mv_case_p_rowid on mv_case(p_rowid);
    create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
    create index idx_mv_case_c_rowid on mv_case(c_rowid);
    create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
    create index idx_mv_case_cc_rowid on mv_case(cc_row_id); I inserted one single row into one of the master table
    insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
    commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */
      MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
      MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
      MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
      MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
      MAS$0.ROWID
      FROM ( SELECT MAS$.ROWID RID$  ,  MAS$.*  FROM  QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN
              (SELECT  /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$
               FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
      JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN)  MAS$0, JCASE AS OF SNAPSHOT(:B_SCN)  MAS$2,
      JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN)  MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN)  MAS$4
      WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+)
      AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+)
      AND MAS$2.JCASE_ID=JV$.JCASE_ID(+)
      AND MAS$2.JCASE_ID=MAS$0.JCASE_ID)
      AND NOT EXISTS (
        SELECT 1 FROM QAPF.MV_CASE SNA2$
        WHERE (SNA2$.P_ROWID = MAS$4.ROWID)
        AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL )
        AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL )
        AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL )
        AND JV$.RID$ IS NULL)
      AND NOT EXISTS (
        SELECT 1  FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN)  MAS_OUTER$
        WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL
        AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
    call     count       cpu    elapsed       disk      query    current        rows
    Parse        1      0.00       0.00          0          0          0           0
    Execute      1     99.51     364.87     377012   17412972          1           0
    Fetch        0      0.00       0.00          0          0          0           0
    total        2     99.51     364.87     377012   17412972          1           0
    Rows     Row Source Operation
          0  LOAD TABLE CONVENTIONAL  (cr=17412968 pr=377012 pw=120527 time=0 us)
          0   FILTER  (cr=17412968 pr=377012 pw=120527 time=0 us)
    3363837    HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
          1     VIEW  (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
          1      HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
    11354346       TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
          1       TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
          1        INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
    3363837     HASH JOIN  (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
    2994042      INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
    3363837      HASH JOIN  (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
    3363837       HASH JOIN  (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
    3363837        TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
    6586646        TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
    6586635       TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
    3363837    FILTER  (cr=17148054 pr=96758 pw=0 time=0 us)
    3363837     MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
    32464070      INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
          0    FILTER  (cr=0 pr=0 pw=0 time=0 us)
          0     NESTED LOOPS  (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
          0      TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
          0      INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)Questions:
    1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
    select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
    ORA-08187: snapshot expression not allowed here
    08187. 00000 - "snapshot expression not allowed here"
    *Cause:    A snapshot expression using AS OF was specified when not allowed.
    *Action:   Do not use the AS OF clause
    2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
    create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
    ERROR at line 1:
    ORA-00904: : invalid identifier
    Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
    Thanks for help.

    sybrand_b wrote:
    1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
    As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
    I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
    I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
    This is pure speculation, of course, based on the absence of an error message.
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
    There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
    +"Science is more than a body of knowledge; it is a way of thinking"+
    +Carl Sagan+                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • Can't update master table when creating a materialized view log.

    Hi all,
    I am facing a very strange issue when trying to update a table on which I have created a materialized view log (to enable downstream fast refresh of MV's). The database I am working on is 10.2.0.4. Here is my issue:
    1. I can successfully update (via merge) a dimension table, call it TABLEA, with 100k updates. However when I create a materialized view log on TABLEA the merge statement hangs (I killed the query after leaving it to run for 8 hrs!). TABLEA has 11m records and has a number of indexes (bitmaps and btree) and constraints on it.
    2. I then create a copy of TABLEA, call it TABLEB and re-created all the indexes and constraints that exist on TABLEA. I created a materialzied view log on TABLEB and ran the same update....the merge completed in under 5min!
    The only difference between TABLEA and TABLEB is that the dimension TABLEA is referenced by a number of FACT tables (by FKs on the FACTS) however this surely should not cause a problem. I don't understand why the merge on TABLEA is not completing...even though it works fine on its copy TABLEB? I have tried rebuilding the indexes on TABLEA but this did not work.
    Any help or ideas on this would be most appreciated.
    Kind Regards
    Mitesh
    email: [email protected]

    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.

Maybe you are looking for