Materialized views vs triggers

Hello everyone
We have to sync some fields in a table in one schema to another table in another schema. 'After insert' triggers had an issue since it will update the dest. table even if the transaction has been rolled back in the master table. Metalink's workaround is to use a package and 3 triggers but Are materialized views better solution for this case? If not, what is the most suitable solution?
Thanks in advance

'After insert' triggers had an issue since it will update the dest. table even if the transaction has been rolled back in the master table.That wouldn't happen with a normal trigger. A Trigger is part of the triggering DML. If the DML is rolled-back, changes/inserts etc by the trigger are also rolled back. The exception is when the Trigger is defined to use an AUTONOMOUS TRANSACTION. That would cause the trigger's changes to be independent of the triggering DML.
Can you check the code of the trigger ?
Hemant K Chitale

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

  • Triggers on Materialized View Fast Refresh

    Hello all!
    I have a Materialized View defined as below:
    CREATE MATERIALIZED VIEW mxsvativi
    BUILD IMMEDIATE
    REFRESH FAST ON COMMIT
    WITH PRIMARY KEY
    AS
    SELECT codativ, TRIM (ramo) AS ramo, percdesc FROM tbativi;And, on this MV, I have a trigger declared as:
    CREATE OR REPLACE TRIGGER TK_SYNC_FV_MXSATIVI
    BEFORE DELETE OR INSERT OR UPDATE
    OF CODATIV
      ,RAMO
      ,PERCDESC
    ON MXSVATIVI
    REFERENCING NEW AS NEW OLD AS OLD
    FOR EACH ROW
    DECLARE
       voper     NUMBER;                                --Operation
    BEGIN
       IF INSERTING
       THEN
          voper := 0;
       ELSIF UPDATING
       THEN
          voper := 1;
       ELSIF DELETING
       THEN
          voper := 2;
       END IF;
       --Save voper to a tblOperLog
    END;This trigger should save some data on a table called tblOperLog, based on the operation that is being performed on the MV (Insert, Delete or Update).
    I´ve tested this on Oracle 10G and also on Oracle 11G (11.1). On these, when we perform a Update on the parent table (on this eg, TBATIVI) the trigger TK_SYNC_FV_MXSATIVI records an Update Operation on the table tblOperLog. But, on a Oracle 11G 11.2.0.2.0 is logging a Delete and a Insert for each update that is done.
    Does anybody know how could I force the proccess that updates the MV to emits an update instead of a delete/insert?
    Thanks a lot!

    Are you doing an incremental refresh of the materialized view? Or are you doing a full refresh?
    Is the materialized view in 11.2 fast refreshable? Perhaps you're missing a materialized view log or missing some data from the materialized view log.
    In general, I'd be wary of trying to use a trigger on a materialized view to log changes to a table since there are no guarantees that the materialized view is always going to be incrementally refreshed nor that the refresh is always going to happen in exactly the same way.
    Justin

  • How to get Materialized View to ignore unused columns in source table

    When updating a column in a source table, records are generated in the corresponding materialized view log table. This happens even if the column being updated is not used in any MV that references the source table. That could be OK, so long as those updates are ignored. However they are not ignored, so when the MV is fast refreshed, I find it can take over a minute, even though no changes are required or made. Is there some way of configuring the materialized view log such that the materialized view refresh ignores these updates ?
    So for examle if I have table TEST:
    CREATE table test (
    d_id NUMBER(10) PRIMARY KEY,
    d_name VARCHAR2(100),
    d_desc VARCHAR2(256)
    This has an MV log MLOG$_TEST:
    CREATE MATERIALIZED VIEW LOG ON TEST with rowid, sequence, primary key;
    CREATE MATERIALIZED VIEW test_mv
    refresh fast on demand
    as
    select d_id, d_name
    from test;
    INSERT 200,000 records
    exec dbms_mview.refresh('TEST_MV','f');
    update test set d_desc = upper(d_desc) ;
    exec dbms_mview.refresh('TEST_MV','f'); -- This takes 37 seconds, yet no changes are required.
    Oracle 10g/11g

    I would love to hear a positive answer to this question - I have the exact same issue :-)
    In the "old" days (version 8 I think it was) populating the materialized view logs was done by Oracle auto-creating triggers on the base table. A "trick" could then make that trigger become "FOR UPDATE OF <used_column_list>". Now-a-days it has been internalized so such "triggers" are not visible and modifiable by us mere mortals.
    I have not found a way to explicitly tell Oracle "only populate MV log for updates of these columns." I think the underlying reason is that the MV log potentially could be used for several different materialized views at possibly several different target databases. So to be safe that the MV log can be used for any MV created in the future - Oracle always populates MV log at any update (I think.)
    One way around the problem is to migrate to STREAMS replication rather than materialized views - but it seems to me like swatting a fly with a bowling ball...
    One thing to be aware of: Once the MV log has been "bloated" with a lot of unneccessary logging, you may perhaps see that all your FAST REFRESHes afterwards becomes slow - even after the one that checked all the 200000 unneccessary updates. We have seen that it can happen that Oracle decides on full table scanning the MV log when it does a fast refresh - which usually makes sense. But after a "bloat" has happened, the high water mark of the MV log is now unnaturally high, which can make the full table scan slow by scanning a lot of empty blocks.
    We have a nightly job that checks each MV log if it is empty. If it is empty, it locks the MV log and locks the base table, checks for emptiness again, and truncates the MV log if it is still empty, before finally unlocking the tables. That way if an update during the day has happened to bloat the MV log, all the empty space in the MV log will be reclaimed at night.
    But I hope someone can answer both you and me with a better solution ;-)

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

  • Trigger on a materialized view

    i have a materialized view on a prebuilt table..
    is it possible to write after triggers on the table?
    regards
    raj

    check a last updated column in the materialised view after a refresh..
    and collect those rows and process those as :new rows....
    but i need to keep on checking if the materialized view is refreshed or not.....You would need to use a job to repeatedly check the MVIEW for any rows which have been updated since the last time the job ran. You would need some form of log to record the time your job used to make that check. It is a bit clunky, but if you read Tom Kyte's article you'll understand why triggers don't work.
    An alternative approach would be to have the source tables which feed the MVIEW also trigger whatever additional processing it is that you require. But this would work only in a handful of situations.
    Is this related to other question about Java Stored Procedures?
    Cheers, APC
    blog: http://radiofreetooting.blogspot.com

  • Materialized views  not updating

    I'm having trouble with getting a materialized view with fast refresh to update. I'm working between two schemas and have the global query rewrite privilege for both users. I've run the catrep.sql script to make sure it had been run and find that it has a lot of packages that don't compile, which I guess is expected as I'm not using Advanced Replication. I think the problem is that I can't get the dbms_snapshot package to compile so can't even update the view manually. Is there another script I need to run to make the materialized views work? Some other privilege or variable?
    I've granted permissions on tables, views, materialized views, triggers, and snapshots to both users.
    The log does get entries but never sends them to the views.
    I have a base table and a log on the table in schema 1.
    I have a materialized view in schema 2:
    create materialized view log on schema1.document
    tablespace app_mview
    with primary key
    ( list columns needed);
    create materialized view schema2.doc_mv
    pctfree 0
    tablespace app_mview
    storage (initial 128k next 128k pctincrease 0)
    refresh fast
    start with sysdate
    next sysdate + 1/1440
    as select * from schema1.document
    Does anyone know where my problem might be?
    thanks for any help

    I have temporary parameters, not in itit.ora but echoing the job_queue_processes is 10, job_queue_interval is 60.
    a sho err returns no errors.
    earlier I did not get anything new in dba_errors when trying to compile. Since I've rerun the catrep.sql I'm getting pls-00201 - identifier must be declared for a lot of dbms_snap, sys.dbms_alert, dbms_reputil2 etc. (package, package body, and trigger types) That is why I think there must be another script that should be run that I don't know about.
    I can't do a full refresh because the dbms_snapshot package will not compile. I believe it's possible that both full and fast will work once I get the dbms_snapshot package working.
    thanks for your help
    pat

  • Trigger on materialized view

    i have a materialized view that is getting refreshed fast upon commit. i created an after insert trigger that for each new row on the view, inserts
    a row in a certain table. is this safe to do?

    No, it's not safe to do so.
    It was explained that Oracle does not guarantee how the changes are applied to the materialized view and in which order. Moreover the mechanism of the refresh could potentially change between releases. Also there were numerous bugs reported for the triggers created on MV container table.
    If you have access to Oracle Metalink look for the article [ID 67424.1].
    Good luck.
    Edited by: Max Seleznev on Dec 10, 2012 2:32 PM

  • Materialized View and AND/OR

    I am really in need of some help as I am having trouble refreshing this materialized view. Basically the code below if triggered by executing the SQL manually will pull the correct records which is somewhere in the 970 unique record range.
    Having known that the SQL worked we created a materialized view that would refresh every day at 3 AM so that we could send this file to an external vendor. However the materialized view that references this SQL when it refreshes pulls in some 100,000 unique records incorrectly.
    After testing over and over I have identified that the refresh seems to be bypassing the "AND/OR" statment that I have setup to look at:
    (AND ((CURRENT_DATE - msp_loan_d.next_payment_due_date) >= 58 AND msp_property_d.property_alpha_state_code <> 'NC'
    OR ((CURRENT_DATE - msp_loan_d.next_payment_due_date) >= 45 AND msp_property_d.property_alpha_state_code = 'NC')).
    Any ideas on this one and maybe I need to rewrite the SQL? Not sure why the materialized view would interpret the SQL any differently.
    SELECT DISTINCT msp_loan_d.loan_number, TRUNC (CURRENT_DATE - msp_loan_d.next_payment_due_date ,0) AS DPD,
    TO_DATE (msp_user_defined_d.user_07_position_field_1a, 'MMDDYY') AS Demand_Date,
    MSP_BORROWER_D.MORTGAGOR_EXPANDED_FIRST_NAME,
    MSP_BORROWER_D.MORTGAGOR_EXPANDED_MIDDLE_NAME, MSP_BORROWER_D.MORTGAGOR_EXPANDED_LAST_NAME,
    MSP_BORROWER_D.CO_MRTGR_EXPANDED_FIRST_NAME, MSP_BORROWER_D.CO_MRTGR_EXPANDED_MIDDLE_NAME,
    MSP_BORROWER_D.CO_MRTGR_EXPANDED_LAST_NAME,
    MSP_BORROWER_D.BILLING_ADDRESS_LINE_4, MSP_BORROWER_D.BILLING_CITY_NAME,
    MSP_BORROWER_D.BILLING_STATE, MSP_BORROWER_D.BILLING_ZIP_CODE, MSP_PROPERTY_D.PROPERTY_STREET_ADDRESS, MSP_PROPERTY_D.CITY_NAME,
    MSP_PROPERTY_D.PROPERTY_ALPHA_STATE_CODE, MSP_PROPERTY_D.PROPERTY_ZIP_CODE, msp_loan_d.next_payment_due_date,
    CO.ADL_CO_BORR_UNFORMATTED_NAME_1 AS "ADDITIONAL COBORROWER",
    CO.ADL_CO_BORR_STREET, CO.ADL_CO_BORR_CITY, CO.ADL_CO_BORR_STATE, CO.ADL_CO_BORR_ZIP_CODE,
    MSP_LOAN_D.Investor_ID, msp_loan_d.first_principal_balance, msp_loan_d.last_full_payment_date, MSP_ORIGINAL_LOAN_D.ORIGINAL_MORTGAGE_AMOUNT,
    MSP_LOAN_D.TOTAL_MONTHLY_PAYMENT, MSP_DELINQUENCY_D.DELINQUENT_PAYMENT_COUNT, MSP_DELINQUENCY_D.DELINQUENT_PAYMENT_BALANCE,
    MSP_LOAN_D.ACCRUED_LATE_CHARGE_AMOUNT, MSP_LOAN_D.NSF_FEE_BALANCE, MSP_CORPORATE_ACCOUNTING_D.RECOVER_CORP_ADVANCE_BALANCE,
    MSP_LOAN_D.SUSPENSE_BALANCE, MSP_ORIGINAL_LOAN_D.NOTE_DATE As "ORIGINATION DATE", MSP_LOAN_D.LOAN_TERM AS "LOAN TERM",
    add_months(msp_loan_d.next_payment_due_date,-1) AS "DUE DATE OF LAST PAYMENT", MSP_USER_DEFINED_D.USER_20_POSITION_FIELD_2A AS "ORIGINATOR",
    NJCLERK.payee_address_line_1, NJCLERK.payee_address_line_2, NJCLERK.payee_address_line_3,
    NJCLERK.payee_address_line_4, NJCLERK.payee_address_zip_code
    FROM me589mgr.msp_loan_d@infodb,
    me589mgr.msp_property_d@infodb,
    me589mgr.msp_user_defined_d@infodb,
    me589mgr.msp_borrower_d@infodb,
    ME589MGR.MSP_ORIGINAL_LOAN_D@infodb,
    ME589MGR.MSP_DELINQUENCY_D@infodb,
    ME589MGR.MSP_CORPORATE_ACCOUNTING_D@infodb,
    (SELECT DISTINCT LOAN_NUMBER, Hi_TYPE, LO_TYPE
    FROM ME589MGR.MSP_LOAN_D@infodb
    WHERE HI_TYPE = 3
    AND LO_TYPE = 8) UNSECURED,
    (SELECT DISTINCT msp_bankruptcy_d.loan_number
    From ME589MGR.MSP_BANKRUPTCY_D@infodb
    Where BKR_STATUS_CODE = 'A') BKLOAN,
    (SELECT DISTINCT MSP_ADDITIONAL_CO_BORROWER_D.LOAN_NUMBER,
    ADL_CO_BORR_UNFORMATTED_NAME_1, ADL_CO_BORR_STREET, ADL_CO_BORR_CITY,
    ADL_CO_BORR_STATE, ADL_CO_BORR_ZIP_CODE
    FROM ME589MGR.MSP_ADDITIONAL_CO_BORROWER_D@infodb
    WHERE ADL_CO_BORR_THIRD_PARTY_FLAG = 'N'
    AND ADL_CO_BORR_SEQUENCE = '1') CO,
    (SELECT
    msp_tax_d.loan_number,
    msp_payee_d.payee_address_line_1, msp_payee_d.payee_address_line_2,
    msp_payee_d.payee_address_line_3, msp_payee_d.payee_address_line_4,
    msp_payee_d.payee_address_zip_code,
    ROW_NUMBER() OVER (PARTITION BY msp_tax_d.loan_number ORDER BY msp_tax_d.tax_key_sequence_number DESC) AS ROW_ORDER
    FROM me589mgr.msp_tax_d@infodb,
    me589mgr.msp_payee_d@infodb,
    me589mgr.msp_property_d@infodb
    WHERE msp_tax_d.tax_key_sequence_number = 1
    AND msp_tax_d.tax_payee_code = msp_payee_d.payee_id
    AND msp_property_d.property_alpha_state_code = 'NJ'
    AND msp_tax_d.loan_number = msp_property_d.loan_number) NJCLERK
    WHERE ( msp_loan_d.loan_number = UNSECURED.LOAN_NUMBER (+)
    AND UNSECURED.LOAN_NUMBER IS NULL
    AND msp_loan_d.loan_number = BKLOAN.LOAN_NUMBER (+)
    AND BKLOAN.LOAN_NUMBER IS NULL
    AND msp_loan_d.loan_number = MSP_ORIGINAL_LOAN_D.LOAN_NUMBER (+)
    AND msp_loan_d.loan_number = MSP_DELINQUENCY_D.LOAN_NUMBER (+)
    AND msp_loan_d.loan_number = MSP_CORPORATE_ACCOUNTING_D.LOAN_NUMBER (+)
    AND msp_loan_d.loan_number = msp_user_defined_d.loan_number (+)
    AND msp_loan_d.loan_number = msp_property_d.loan_number (+)
    AND msp_loan_d.loan_number = msp_borrower_d.loan_number (+)
    AND msp_loan_d.loan_number = CO.LOAN_NUMBER (+))
    AND ((CURRENT_DATE - msp_loan_d.next_payment_due_date) >= 58 AND msp_property_d.property_alpha_state_code <> 'NC'
    OR ((CURRENT_DATE - msp_loan_d.next_payment_due_date) >= 45 AND msp_property_d.property_alpha_state_code = 'NC'))
    AND (msp_loan_d.first_principal_balance > 0
    AND msp_loan_d.man_code NOT IN ('U' , 'D', 'Y' ,'B', 'F', 'L', 'G', 'I','M', 'O', 'R', 'X', 'Y', 'W', 'T', 'Q', 'Z')
    AND msp_property_d.property_alpha_state_code NOT IN ('WA','NM','MA','MD','NY','PA')
    AND msp_loan_d.loan_number = NJCLERK.LOAN_NUMBER (+)
    AND msp_loan_d.PROCESS_STOP_CODE NOT IN ('1', '2', '8', 'A', 'B', 'C', 'D', 'E', 'F', 'H', 'J', 'R', '9', 'K', 'O', 'U', 'V', 'X'))
    AND (msp_loan_d.last_full_payment_date >= TO_DATE (msp_user_defined_d.user_07_position_field_1a, 'MMDDYY')
    OR (msp_user_defined_d.user_07_position_field_1a IS NULL))

    Hi,
    I don't think AND/OR has anything to do with your problem. The issue seems to be how to write outer joins.
    You have an outer join to msp_user_defined_d:
    AND msp_loan_d.loan_number = msp_user_defined_d.loan_number(+)But here you have an inner join to same table:
    AND (     msp_loan_d.last_full_payment_date >= TO_DATE (msp_user_defined_d.user_07_position_field_1a, 'MMDDYY')
           OR (msp_user_defined_d.user_07_position_field_1a IS NULL)
        )It looks like you need to change this into:
    (If you hit ORA-01719: outer join operator {noformat}(+){noformat} not allowed in operand of OR or IN , you may have to rewrite accordingly)
    AND (     msp_loan_d.last_full_payment_date >= TO_DATE (msp_user_defined_d.user_07_position_field_1a(+), 'MMDDYY')
           OR (msp_user_defined_d.user_07_position_field_1a IS NULL)
        )If true, it makes me wonder. Did you test your query alone, did it produce the correct resultset?
    Regards
    Peter

  • How to refresh materialized view by trigger

    hi,
    im having a problem in refreshing materialized view through a trigger.
    CREATE OR REPLACE TRIGGER L_TRG_MARC_TEST
    BEFORE DELETE OR INSERT OR UPDATE ON MARC_BOOK_B_ENG
    BEGIN
    DBMS_MVIEW.REFRESH('TITLE_ENG_MV','C','',TRUE,FALSE,0,0,0,TRUE);
    END;
    Trigger created.
    SQL> DELETE FROM MARC_BOOK_B_ENG;
    DELETE FROM MARC_BOOK_B_ENG
    ERROR at line 1:
    ORA-04092: cannot COMMIT in a trigger
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 849
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 832
    ORA-06512: at "LIBQAL1.L_TRG_MARC_TEST", line 2
    ORA-04088: error during execution of trigger 'LIBQAL1.L_TRG_MARC_TEST'
    plz tell me how to refresh materialized view thru trigger,,and what is wrong in above mentioned situation.
    Regards

    DBMS_MVIEW.REFRESH implicitly commits. COMMIT is not permitted in triggers, as you can see, unless you use AUTONOMOUS_TRANSACTION.
    Try
    CREATE OR REPLACE TRIGGER L_TRG_MARC_TEST
    BEFORE DELETE OR INSERT OR UPDATE ON MARC_BOOK_B_ENG
    DECLARE
    PRAGMA AUTONOMOUS_TRANSACTION;
    BEGIN
    DBMS_MVIEW.REFRESH('TITLE_ENG_MV','C','',TRUE,FALSE,0,0,0,TRUE);
    END;

  • Updatable materialized view- error with CREATE_SNAPSHOT_REPGROUP

    I'm trying to create an updatable materialized view from the replication administrators account (REPADMIN). I use the assistant and in the third step (after creating the replication group and the materialized view), when the materialized view is going to be added to the group, I got this error:
    ERROR in line 1:
    ORA-01403: No data found
    ORA-06512: in "SYS.DBMS_REPCAT_SNA_UTL", line 5927
    ORA-06512: in "SYS.DBMS_REPCAT_SNA", line 82
    ORA-06512: in "SYS.DBMS_REPCAT", line 1332
    ORA-06512: in "SYS.DBMS_REPCAT", line 1307
    ORA-06512: in line 2
    I have also tried to use the command file that the assistant generates (I add below), and the error is triggered within the CREATE_SNAPSHOT_REPOBJECT procedure.
    Has anybody any idea to resolve the problem?
    Thanks in advance
    BEGIN
    DBMS_REPCAT.CREATE_SNAPSHOT_REPGROUP(
    gname => '"MYGROUP"',
    master => 'DB.DOMAIN.COM',
    propagation_mode => 'ASYNCHRONOUS');
    END;
    CREATE SNAPSHOT "MYUSER"."MYTABLE"
    REFRESH COMPLETE WITH ROWID
    FOR UPDATE
    AS SELECT "COD", "NAME" FROM
    "MYUSER"."MYTABLE"@DB.DOMAIN.COM c
    BEGIN
    DBMS_REFRESH.ADD(
    name => '"MYUSER"."REF3"',
    list => '"MYUSER"."MYTABLE"',
    lax => TRUE);
    END;
    BEGIN
    DBMS_REPCAT.CREATE_SNAPSHOT_REPOBJECT(
    gname => '"MYGROUP"',
    sname => '"MYUSER"',
    oname => '"MYTABLE"',
    type => 'SNAPSHOT',
    min_communication => FALSE);
    END;

    Hello,
    These days I have had some problems with my forum-account and I haven't been able to connect and reply.
    Regarding to your doubt, the name of refresh group was correct, and as I see, the problem can't be related to the refresh group.
    While the problem with my account was resolved, I created two new databases (*) and the problem within the materialized view process is disappeared. I suppose that my first original databases were degraded, but I don't know where.
    (*) of course, I could do that because I use Oracle in an academy institution, not for production, thank God
    Anyway, for now I will give up here. Thanks for your help.
    Regards,

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

  • Trouble with Materialized View

    Hello,
    I'm in need of some help enforcing data integrity using a materialized view. In my example, each system may consist of three types of components and this is modeled using supertype/subtype relationships. I'm trying to enforce that, for a given system, a component cannot reside in more than one component table. For example, given System 1, if Component A exists in the mobile_components table, it cannot be inserted into the desktop_components table for System 1. Rather than using triggers, I'm attempting to use a materialized view with unique constraint to enforce this rule based on the example from Tom Kyte's "The Trouble With Triggers" article http://www.oracle.com/technetwork/issue-archive/2008/08-sep/o58asktom-101055.html. However, I can't seem to get it to work as it gives me ORA-12054: Cannot set the ON COMMIT refresh attribute.  I'm using UNION ALL, and I know that can be tricky, but I can't figure out what rules I'm breaking.  I have the necessary privileges.  Oracle 11g.  Can anyone help?
    Thanks,
    Mark
    create table systems (
    sys_id number,
    sys_name varchar2(100),
    constraint sys_pk primary key (sys_id),
    constraint sys_uk unique (sys_name));
    insert into systems values (1,'System 1');
    insert into systems values (2,'System 2');
    create table mobile_components (
    mo_comp_id number,
    mo_comp_name varchar2(100),
    mo_comp_sys_id number,
    constraint mo_pk primary key (mo_comp_id),
    constraint mo_uk unique (mo_comp_name, mo_comp_sys_id),
    constraint mo_fk foreign key (mo_comp_sys_id) references systems (sys_id));
    insert into mobile_components values (1,'Component A',1);
    insert into mobile_components values (2,'Component A',2);
    create table desktop_components (
    de_comp_id number,
    de_comp_name varchar2(100),
    de_comp_sys_id number,
    constraint de_pk primary key (de_comp_id),
    constraint de_uk unique (de_comp_name, de_comp_sys_id),
    constraint de_fk foreign key (de_comp_sys_id) references systems (sys_id));
    insert into desktop_components values (1,'Component B',1);
    insert into desktop_components values (2,'Component B',2);
    create table internet_components (
    in_comp_id number,
    in_comp_name varchar2(100),
    in_comp_sys_id number,
    constraint in_pk primary key (in_comp_id),
    constraint in_uk unique (in_comp_name, in_comp_sys_id),
    constraint in_fk foreign key (in_comp_sys_id_ references systems (sys_id));
    insert into internet_components values (1,'Component C',1);
    insert into internet_components values (2,'Component C',2);
    create materialized view log on mobile_components with rowid;
    create materialized view log on desktop_components with rowid;
    create materialized view log on internet_components with rowid;
    create materialized view mv_components
    refresh fast on commit with rowid as
    select rowid as row_id, mo_comp_id as comp_id, mo_comp_name as comp_name
    from mobile_components
    union all
    select rowid, de_comp_id, de_comp_name
    from desktop_components
    union all
    select rowid, in_comp_id, in_comp_name
    from internet_components;
    alter table mv_components add constraint mv_comp_uk unique (comp_id, comp_name);

    You need a marker column to distinguish which of your queries you union, that data came from:
    e.g.
    create materialized view mv_components 
    refresh fast on commit with rowid as 
    select 'a' marker,rowid as row_id, mo_comp_id as comp_id, mo_comp_name as comp_name 
    from mobile_components 
    union all 
    select 'b',rowid, de_comp_id, de_comp_name 
    from desktop_components 
    union all 
    select 'c', rowid, in_comp_id, in_comp_name 
    from internet_components;

  • Custom Materialized View

    Hi
    I am ha query regarding Materialized View .
    Materialized View Query :
    select * from emp@db1 where salary in ('1000','3000');
    Scenario :
    In the DB2 (Target DB) :
    create materialized view emp_mv
    refresh force on demand
    as
    select * from emp@db1 where salary in ('1000','3000');
    Replication works fine .
    In DB1 (Source DB) :
    Update emp set salary=2000 where salary=1000 and empno=123;
    Now in the DB2 (where my MV is located) , i want the existing record (salary=1000) to be still there and the new record (salary=2000) should not be present for empno=123
    In DB1 (Source DB) :
    Update emp set salary=3000 where salary=2000 and empno=123;
    Now in the DB2 (where my MV is located) , i want the previous record (salary=1000) to be still there and the new record (salary=3000) should also be present for empno=123 (Now there should be tow records)
    Is it possible ?
    Any pointers is appreciated !
    Thanks

    A Materialized View is designed (intended) to give you a copy of data as the data exists in the source. If that row (with the pre-delete image) does not exist in the source, it should not exist in the MV.
    How would you distinguish between the two images of the row at the MV site ? Which one is the "older" one and which is the "newer" one ? You'd have to write custom methods (tags, timestamps etc) to differentiate between the two rows.
    A Materialized View is a generic solution. You cannot customize.
    You have to define your own custom table (with the additional tagging methods) and your own procedures to replicate the two images of the same row. That is one of the uses of triggers. Before the row is updated, copy the preupdate image of the row (with additional column(s) for tagging the change) out to another table.
    The "custom" MV can then be defined as a UNION of the two tables, the "master" table and the "audit trail" table.
    You'll have to consider how you will handle DELETEs as well.
    Hemant K Chitale

  • Insted of trigger on Materialized view?

    Hi,
    Can we write insted of trigger on materialized view?
    Piyush

    peeyushgehlot wrote:
    When we do full refresh on materialized view, view gets truncated and new records get inserted, that's is on books and we can do job according, but when incremental refresh is done, what trigger will perform i am not sure.I'm not sure that I follow. A full refresh will cause insert triggers (row and table level, before and after) to fire for every row in the materialized view. An incremental refresh will cause insert, update, and delete triggers (row and table level, before and after) to fire for every row that is modified. There may, of course, be updates that don't actually change the data depending on how the materialized view is defined and how the changes need to be processed.
    Justin

Maybe you are looking for