! Materialized View log VS Trigger to trace table changes !

Hi All
I have to trace changes on couple tables and only those changes then send to other system.
What do you think is better solution to create a Status table and update it via trigger.
I saw that MV log can be used for such purpose, but I am not able to create a MV logging on more than one table.
Or is there any other more effective way to trace changes on table?
Thanks a lot
Martin

It sounds like you should be looking at something like Change Data Capture (CDC). You could also create materialized view logs on each table where you wanted to track changes, create appropriate materialized views on the remote database, and consume the data there. It really depends on what exactly you want to do with the changes you're tracking.
Justin

Similar Messages

  • 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

  • ORA-12096: error in materialized view log

    Hi All,
    I had created a fast refresh materialized view. Log was also created.
    Now i dropped the mv and the logs.
    But now every time i update or insert into this customer table i get error message.
    ORA-12096: error in materialized view log on Customer
    ORA-00942: table or view does not exist
    There are entries in the DBA_MVIEW_LOGS for customer table.
    Please suggest.

    Hi,
    What database version are you on?
    And do you have access to Metalink/My Oracle Support?
    Found this, by the way:
    ORA-12096: error in materialized view log on <table>
    If problems occur when you try to access a log file for a materialized view, the system issues an ORA-12096 error message which is followed by the actual error. If the ORA-12096 error message is accompanied by an ORA-00942 message, the problem may be due to an online reorganization that was only partially undone. In this case, you can drop the log file for the materialized view manually (after you have verified that it is no longer required):
    DROP MATERIALIZED VIEW LOG ON <table>;
    Edited by: hoek on Jul 29, 2009 2:15 PM

  • SELECT PRIVILEGES required on Materialized View Logs

    Hi,
    I have a scenario where in Base table exists in one database and Materialized View on other.
    The Materialized View is created with FAST REFRESH option.
    I have created Materialized View Log in database where master table exists.
    Also I have given Select priv on master table to the user(where MV is created).
    I want to know how will i Grant SELECT PRIV on Materialized View Log so that FAST refresh happens.
    Both databases are Oracle 10g R2.
    I have read following on oracle site:
    The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
    Please tell me the command to GRANT SELECT to the user who has created MV.
    Thank You,
    Niranjan.

    Hi,
    The privileges required to create a materialized view should be granted directly rather than through a role
    To create a materialized view in your own schema:
    1- Grant CREATE MATERIALIZED VIEW system privilege and either the CREATE TABLE or CREATE ANY TABLE system privilege.
    2-You must also have access to any master tables of the materialized view that you do not own, either through a SELECT object privilege on each of the tables or through the SELECT ANY
    TABLE system privilege.
    To create a materialized view in another user's schema:
    1-You must have the CREATE ANY MATERIALIZED VIEW system privilege.
    2-The owner of the materialized view must have the CREATE TABLE system privilege. The owner must also have access to any master tables of the materialized view that the schema owner does not own (for example, if the master tables are on a remote database) and to any materialized view logs defined on those master tables, either through a SELECT object privilege on each of the tables or through the SELECT ANY TABLE system privilege.
    To create a refresh-on-commit materialized view (ON COMMIT REFRESH clause), in addition to the preceding privileges, you must have the ON COMMIT REFRESH object privilege on any master tables that you do not own or you must have the ON COMMIT REFRESH system privilege.
    see this link
    http://download.oracle.com/docs/cd/B12037_01/server.101/b10759/statements_6002.htm

  • Can I create index on Materialized view log

    Hello
    The ADDM suggest me to create index on some fields of my materialized view log , I don't know does it cause any problem ? Is it safe ? have you done it before ?
    thanks

    Actually you can do it since materialized view log is in fact a table.
    SQL> create table t(x int primary key);
    Table created.
    SQL> create materialized view log  on t;
    Materialized view log created.
    SQL> select segment_name, segment_type from user_segments;
    SEGMENT_NAME
    SEGMENT_TYPE
    MLOG$_T
    TABLE
    T
    TABLE
    SYS_C004857
    INDEX
    SQL> desc mlog$_t;
    Name                                      Null?    Type
    X                                                  NUMBER
    SNAPTIME$$                                         DATE
    DMLTYPE$$                                          VARCHAR2(1)
    OLD_NEW$$                                          VARCHAR2(1)
    CHANGE_VECTOR$$                                    RAW(255)
    SQL> create index i on mlog$_t(x);
    Index created.However I don't know if this is really supported and makes sense.

  • 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

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

  • Materialized View Log table with sequence

    I have a materialized view log in Database A..a very simple one...similar to "create materialized view log on t WITH PRIMARY KEY"...The primary key is a composite key of 2 columns...Description of the mlog table looks like this...
    desc mlog$_t
    emp_ctr NUMBER
    emp_date DATE
    SNAPTIME$$ DATE
    DMLTYPE$$ VARCHAR2(1)
    OLD_NEW$$ VARCHAR2(1)
    CHANGE_VECTOR$$ RAW(255)
    The Materialized view is in database B...again a simple one...no aggregation...This gets refreshed on demand manually evey week. The records that get accumulated in the MLOG every week is ~ 300K..The manual refresh used to finish in about 20mins but since last week it is running for ever. Upon reviewing the contents of MLOG I noticed that it contained a mixture of inserts and updates. I'm not sure if the MLOG contanied only inserts in the past when the MV used to refresh very quickly...Based on the documentation, Oracle recommends creating MLOGS with "sequence" whenever inserts/updates/deleted are expected. I'm planning to drop and recreate the MLOG with sequence with the hope that this would fix the slow refresh issue...Appreciate if you could let me know your thoughs...
    I'm also planning to trace the session to get some wait event statistics to find out the reason for the slow refresh...

    There are a few reasons why refreshes slow down over time.
    1. Is the log table being cleared out after a refresh? If not, you may have another mview (maybe even one that doesn't exist any more) registered against this log. When this happens, the log table never stops growing.
    2. How big is the segment occupied by the table? If it has grown very large at some time in the past (e.g., because refresh was delayed), then when the refresh does a FTS on the log it will scan the whole segment - even if only a few rows are present.
    3. It may help to add an index to the PK columns, and another to SNAPTIME$$. Without them, the refresh will FTS the log. For a big segment, that can take a long time.
    -- Phil

  • ORA-12096: error in materialized view log on a table

    Hi while updating a table getting below error
    ORA-12096: error in materialized view log on "FII"."FII_GL_JE_SUMMARY_B"
    What might be the problem.
    Thanks.

    might be table definition has changed, you may need to drop the mview log and recreate it.

  • Truncate table and materialized view log

    I user oracle 10 R2
    I have a table and on that table a materialized view log.
    I execute in a pl/sql procedure:
    1) execute immediate('drop materialized view log on tab1');
    then:
    2) execute immediate('truncate table tab1');
    3) Now I insert a lot of records in tab1
    4) execute immediate('create materialized view log on tab1 WITH rowid INCLUDING NEW VALUES');
    When I create the materialized view log I recieved this message:
    ora32321: refresh fast on tab2 unsupported after detail table truncate
    Why?

    Refresh fast after truncate operation on container table is not supported, regardless the container table is or is not partitioned.
    Perform a refresh complete.
    ORA-32321 :
    Cause:     A detail table has been truncated and no materialized view
         supports fast refersh after a detail table has been truncated
    Action:     Use REFRESH COMPLETE. Note: you can determine why your
         materialized view does not support fast refresh after TRUNCATE
         using the DBMS_MVIEW.EXPLAIN_MV() API.

  • Will Materialized view log reduces the performance of DML statements on the master table

    Hi all,
    I need to refresh a on demand fast refresh Materialized view in Oracle 11GR2. For this purpose I created a Materialized view log on the table (Non partitioned) in which records will be inserted @ rate of 5000/day as follows.
    CREATE MATERIALIZED VIEW LOG ON NOTES NOLOGGING WITH PRIMARY KEY INCLUDING NEW VALUES;
    This table already has 20L records and adding this Mview log will reduce the DML performance on the table ?
    Please guide me on this.

    Having the base table maintain a materialised view log will have an impact on the speed of DML statements - they are doing extra work, which will take extra time. A more sensible question would be to ask whether it will have a significant impact, to which the answer is almost certainly "no".
    5000 records inserted a day is nothing. Adding a view log to the heap really shouldn't cause any trouble at all - but ultimately only your own testing can establish that.

  • Performance consequences to adding materialized view logs to tables?

    I am writing a very complex query for a client of our transactional database system and this will require the creation of a materialized viewbecause all attempts at tuning to make performance acceptable have failed.
    I want to enable fast refresh of the MVIEW but I am confused regarding the consequences of the addition of adding materialized view logs to the base tables.
    Some of the tables are large and involved in alot of transactions and I am wondering if the performance of INSERT/UPDATES will be seriously affected by the presence of an mview log.
    This may be a simple question to answer but I was unable to find a clear cut answer in the literature.
    Thanks for any answers!!
    Chris Mills
    Biotechnology Data Management Consultant

    Last time i looked into this there were three cases to consider
    If you're doing conventional row-by-row DML then the impact is just one insert into a heap table per row modified.
    If you are modifying a high number of rows using bulk-binds then the overhead is very severe because modifying 1,000 rows on the base table causes 1,000 non-bulk bound inserts into the log table.
    Direct path inserts have extremely low overhead because the MV log is not touched. Instead, the range of new rowids added is logged in ALL_SUMDELTA
    http://oraclesponge.wordpress.com/2005/09/15/optimizing-materialized-views-part-ii-the-direct-path-insert-enhancement/

  • 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 log update question

    Hi, I am running into a question regarding mview - not sure if it should behave that way or I didn't use it right.
    I have two base tables, sales and customers (drived from nested materialized view example in oracle doc):
    CREATE TABLE sales
    cust_ID VARCHAR2(32 BYTE) NOT NULL,
    amount_sold NUMBER,
    TEMP VARCHAR2(100 BYTE),
    CONSTRAINT sales_pk PRIMARY KEY (cust_id)
    CREATE TABLE customers
    cust_ID VARCHAR2(32 BYTE) NOT NULL,
    CUST_LAST_NAME VARCHAR2(100 BYTE),
    TEMP VARCHAR2(100 BYTE),
    CONSTRAINT cust_pk PRIMARY KEY (cust_id)
    CREATE MATERIALIZED VIEW LOG ON sales
    WITH ROWID (cust_id, amount_sold);
    CREATE MATERIALIZED VIEW LOG ON customers
    WITH ROWID (cust_id, cust_last_name);
    Then I create a fast refresh materialized view based on them:
    CREATE MATERIALIZED VIEW join_sales_cust
    REFRESH FAST ON DEMAND AS
    SELECT c.cust_id, c.cust_last_name, s.amount_sold, s.rowid srid, c.rowid crid
    FROM sales s, customers c
    WHERE s.cust_id = c.cust_id;
    Since this materialized view only invole cust_id and amount_sold from sales and cust_id and last_name from customers table, I do not want to trigger materialized view log entry if the TEMP column value gets updated. So follow update shouldn't trigger mlog:
    update sales set TEMP='TEMP2' where cust_id=1
    but this update should:
    update sales set amount_sold=3 where cust_id=1
    What I am seeing happenning is any update on the base table will triger mlog entried regardless whether the column is involed in the materialized view or not.
    Can someone please confirm if this is the correct behavior and whether there is a way to accomplish what I wanted to do?
    Thank you!
    Edited by: user3933488 on Jan 8, 2010 12:53 PM

    You created the materialized view logs with some columns, which is not necessary when creating a join MV on top of them. You can happily skip those in your MV log definition. And then it becomes clear that those columns are not involved in the decision whether a MV log needs to be updated or not. Everything that happens to the base table gets recorded. The "WITH ROWID" and "INCLUDING NEW VALUES" and the column list only specify WHAT should be recorded when something changed.
    Regards,
    Rob.

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

Maybe you are looking for