Prob of materialized view

Hi all


I have problem with Mview when you perform dml operations.

I'm trying to insert or update on the materialized view, then I am getting below error.

ORA-01732: operation non-legal data manipulation on this point of view

Please can you me cant we do on the materialized view dml operations?

My version of DB is 10g.
DESC SUNITHA;

Name     Null?     Type
NAME          VARCHAR2(10)
ID     NOT NULL     NUMBER(2)
create  MATERIALIZED  view maview as select * from sunitha;
I'm trying to insert into maview
insert into maview values('c',4);

ORA-01732: data manipulation operation not legal on this view
Please notify.


Thank you
Miriam.

Here is an excerpt of the document.

Updatable Materialized Views

You can make a materialized view updatable during creation by including the FOR UPDATE
clause or enabling the equivalent option in the Replication Management tool. For changes
made to an updatable materialized view to be pushed back to the master during refresh,
the updatable materialized view must belong to a materialized view group.

Updatable materialized views enable you to decrease the load on master sites because users
can make changes to the data at the materialized view site. The following is an example of
an updatable materialized view:

CREATE MATERIALIZED VIEW hr.departments FOR UPDATE AS
  SELECT * FROM [email protected];

The following statement creates a materialized view group:

BEGIN
   DBMS_REPCAT.CREATE_MVIEW_REPGROUP (
      gname => 'hr_repg',
      master => 'orc1.world',
      propagation_mode => 'ASYNCHRONOUS');
END;
/

The following statement adds the hr.departments materialized view to the materialized
view group, making the materialized view updatable:

BEGIN
   DBMS_REPCAT.CREATE_MVIEW_REPOBJECT (
      gname => 'hr_repg',
      sname => 'hr',
      oname => 'departments',
      type => 'SNAPSHOT',
      min_communication => TRUE);
END;

/

You can also use the Replication Management tool to create a materialized view group
and add a materialized view to it.

Tags: Database

Similar Questions

  • PX Deq Credit: send blkd hang while the materialized view Refresh

    Hi all

    When we are materialized view refreshing. It takes more than 2.30 minutes. Initially, it took 1.40 minutes.

    We use parallel and base are partitioned. When I checked the tkprof report I see a lot of insert query expects especially PX Deq Credit: send blkd event. When I check the ASH report that I find not just any question about MV was running but always refresh MV was going on


    TKPROF: Release 11.2.0.1.0 - Development on Wed Jun 5 16:27:29 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Sort options: exeela  prsela  fchela  
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************


EXPLAIN PLAN option disabled.
********************************************************************************

SQL ID: 2x210q5g30m4t
Plan Hash: 2058446196
INSERT /*+ BYPASS_RECURSIVE_CHECK APPEND  */ INTO 
  "APPS"."GL_BAL_MV" SELECT * FROM 
  GL_BAL_V


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 175     (recursive depth: 1)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  LOAD AS SELECT  (cr=0 pr=0 pw=0 time=0 us)
      0   PX COORDINATOR  (cr=0 pr=0 pw=0 time=0 us)
      0    PX SEND QC (RANDOM) :TQ10003 (cr=0 pr=0 pw=0 time=0 us cost=1041298 size=389555904 card=2028937)
78448967     HASH JOIN BUFFERED (cr=0 pr=1158765 pw=1158765 time=276842112 us cost=1041298 size=389555904 card=2028937)
 410944      BUFFER SORT (cr=0 pr=0 pw=0 time=492466 us)
 410944       PX RECEIVE  (cr=0 pr=0 pw=0 time=34526636 us cost=64715 size=147944250 card=1643825)
      0        PX SEND HASH :TQ10001 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0         PARTITION RANGE ALL PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
      0          TABLE ACCESS FULL GL_CODE_COMBINATIONS PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=64715 size=147944250 card=1643825)
78448967      PX RECEIVE  (cr=0 pr=0 pw=0 time=2453949696 us cost=976582 size=395060280 card=3873140)
      0       PX SEND HASH :TQ10002 (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0        HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=976582 size=395060280 card=3873140)
      0         BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0          PX RECEIVE  (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0           PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0            HASH JOIN  (cr=0 pr=0 pw=0 time=0 us cost=32 size=133920 card=2480)
      0             TABLE ACCESS FULL GL_SETS_OF_BOOKS (cr=0 pr=0 pw=0 time=0 us cost=7 size=108 card=6)
      0             TABLE ACCESS FULL GL_PERIODS (cr=0 pr=0 pw=0 time=0 us cost=24 size=44640 card=1240)
      0         PX BLOCK ITERATOR PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)
      0          TABLE ACCESS FULL GL_BALANCES PARTITION: 1 39 (cr=0 pr=0 pw=0 time=0 us cost=976550 size=30099548160 card=627073920)


Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.16          0.17
  PX Deq Credit: send blkd                  1061004        1.99       5084.61
  PX Deq: Table Q Normal                     250856        2.00       2306.87
  asynch descriptor resize                        1        0.00          0.00
  Disk file operations I/O                       10        0.23          0.26
  direct path write temp                       3608        1.20        958.39
  latch free                                     26        0.02          0.19
  PX qref latch                             7647924        0.05         11.85
  direct path read temp                         578        0.43         35.19
  PX Deq Credit: need buffer                   4037        0.08          5.84



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.47          0.75
  PX Deq: Slave Session Stats                     1        0.15          0.15


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

Misses in library cache during parse: 0

Elapsed times include waiting on following events:
  Event waited on                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  PX Deq: Execution Msg                           3        0.16          0.17
  PX Deq Credit: send blkd                  1061004        1.99       5084.61
  PX Deq: Table Q Normal                     250856        2.00       2306.87
  asynch descriptor resize                        1        0.00          0.00
  Disk file operations I/O                       10        0.23          0.26
  direct path write temp                       3608        1.20        958.39
  latch free                                     26        0.02          0.19
  PX qref latch                             7647924        0.05         11.85
  direct path read temp                         578        0.43         35.19
  PX Deq Credit: need buffer                   4037        0.08          5.84

    1  user  SQL statements in session.
    0  internal SQL statements in session.
    1  SQL statements in session.
    0  statements EXPLAINed in this session.
********************************************************************************
Trace file: CHDFCI_p001_43384918_PARALLEL.trc
Trace file compatibility: 11.1.0.7
Sort options: exeela  prsela  fchela  
       1  session in tracefile.
       1  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       1  SQL statements in trace file.
       1  unique SQL statements in trace file.
 8986825  lines in trace file.
    9372  elapsed seconds in trace file.
    When I checked the ASH report during this period. I don't see anything related to MV running.
    I use parallel degree 8 to GL_BALANCES.
    Please suggest.

    Sarah wrote:
    Hi all

    When we are materialized view refreshing. It takes more than 2.30 minutes. Initially, it took 1.40 minutes.

    You are showing much more than 2.30 minutes in this result tkprof - did you mean hours?

    We use parallel and base are partitioned. When I checked the tkprof report I see a lot of insert query expects especially PX Deq Credit: send blkd event.

    In your case, it seems as if the "PX Deq Credit: send blkd" is an inactive waiting (despite comments in the manual, which is not always true).
    Plan execution tells you that you are not loading in the GL_BAL_MV at the same time (even if you select it in parallel). This means a single process must collect all the data of all the slaves of PX to insert it, so anytime 7 slaves will wait for you "PX Deq Credit: send blkd" while the eighth sends data to the query Coordinator to write to the table. (The timeout on these waiting 2 seconds - which is consistent with the max wait the values you see.)

    If you can ensure that the MV and its index is declared as parallel, and you can enable parallel DML for updating, you may find that things go a lot faster.

    When I check the ASH report that I find not just any question about MV was running but always refresh MV was going on

    Ash can be a bit flakey with some of its reports in 11.2.0.1 - perhaps you were simply unlucky.

    >

    call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1    362.20    9372.04    1158765          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2    362.20    9372.04    1158765          0          0           0

    It is possible, moreover, that your plan has changed over time - there are a couple of "HASH JOIN TAMPONNÉE" in the plan, which means that the table "probe" the hash join arrives on the assembling process and is dumped to disk (if it does not fit in memory) to be reread and joined. This can consume a lot of IO and the time - as seen by the "pr = 1158765 pw = 1158765" on line 4 of your plan. It is possible that a previous plan has used a method of dissemination for the table of 'building' avoid this overload - but that the optimizer has switched plans as all data has increased.

    Concerning
    Jonathan Lewis

    Published by: Jonathan Lewis on June 5, 2013 16:20 (formatting)

  • Create table works, create materialized view only - long column names?

    Hello.

    I have no probs creating a table as well: -.
    CREATE TABLE blah
    (
    DEVICE_ID
    )
    in select
    "Device_ID" AS DEVICE_ID
    "of"sum" Device"@ed_link_3
    where "Device_ID" < 5;


    But when I try to create a materialized view:
    Blah1 CREATE MATERIALIZED VIEW
    (
    DEVICE_ID
    )
    < various materialized view parms >
    in select
    "Device_ID" AS DEVICE_ID
    "of"sum" Device"@ed_link_3
    where "Device_ID" < 5;

    It fails with errors: -.
    ORA-04052: error occurred when searching to the top of the remote object Aggregate.Device@ED_LINK_3
    ORA-01948: length of the name of the identifier (31) exceeds maximum (30)

    Is there a way to get around this?
    Is the problem with the columns of the remote table of device, which I do NOT need to import to have column names that are longer than 30 characters?

    For now, I want only the Device_ID column which is a simple 9 characters long.

    Oh, and the remote database is MySQL.
    I'm uncomfortable with the < parms of materialized view > as they work fine when I choose a different remote table with only short column names.

    Thank you.

    To my knowledge, you have the option
    (a) create view (with shortened column names or only with desired columns if they are already less than 30 char limit) side of mysql
    (b) use dbms_passthrough to force the analysis to be done on mysql (as in the example provided by SY here use dbms_passthrough to create a view )
    However, I prefer to stick to one), because with dbms_passtrhough, you retrieve row by row.

    Best regards

    Maxim

  • ORA-12028: type of materialized view is not supported by the main site

    Hi guys!

    We face a problem these days about the materialized view.

    We have upgraded database version 9.2.0.7 directly to 10.2.0.5 (RHEL4 x 86) on the same host. Database uses the driver dg4odbc to connect with remote SQL Server 2012 through data binding called MIKSERI. Our developer team would like to have replicated SQL server table data side Oracle using the materialized view.

    They created Materialized view, but it is not at all to refresh the data. I tried to study a little bit, and whenever I try to change the view anyway I hit error:

    ORA-12028: view type is not supported by the master site materialized @ 'MIKSERI '.

    ORA-06512: at line 22

    I looked at the solutions proposed and discovered that it is maybe the compatible database parameter, so I changed from previous 9.2.0.0.0 to 10.2.0.1.0 but still no luck. Just to emphasize this database is of course different clone of production to a different database, with db name retained and other parameters, but on another host computer and listening port. I even try to change global name, but still no luck.

    Main problem is that refresh the work does not at all. To be more precise, we have created MV on the side of the Oracle and FULL Refresh should be done every 3 minutes. MV uses HS db link to the sql server database.

    During the creation of MV, we can see currently given to sql server, but the problem is that we cannot do MV to refresh every 3 minutes. When I try to change MV and put the refresh interval I get above error.

    Any kind of help would be greatly appreciated,

    Thank you

    I found the reason why my MV update jobs failed, job_queue_processes parameter was equal to 0. I change this setting and now works fine.

    Thank you for your time!

  • What is the best way to change a column type in the materialized view?

    Hello my dear friends,.

    I want to change a column type in a materialized view. VARCHAR2 NUMBER, so what do you recommend? What is the best way to do it?

    Thank you

    You can not change the data type of the column while there are data in the MV, so you might as well give up and recreate the MV with a TO_CHAR() around the column in question in the application of MV to get the data exactly as you want (be sure to include an appropriate format mask). That said, I'm fighting to think reasonable grounds to make such a change.

  • A drop materialized view error

    I tried to drop two materialized views (I want to drop one and the other as a test to make sure that the behavior was consistent) with SQL Developer today, using the GUI, not the window of SQL command. When I did this, Developer SQL with these MVs among the tables, he tried to run a 'DROP TABLE' rather than a 'DROP MATERIALIZED VIEW' statement and an ugly error message came up with that and of course she didn't. Is this a bug that needs to be addressed? Or maybe that it is already identified and addressed in a future version?

    Earl

    Looks like you're down the underlying table, not the materialized view.   If you have a my_mv of materialized view, there is also a table called my_mv.

    You must drop the materialized since the Materialized View node in Object Explorer view.

  • Materialized views Refresh method and refresh option

    Hi Experts,

    According to the docs, If the MV contains the following, MV is considered complex. I wonder is there any view data dictionary that indicates the type of MV? Because is very easy to the candidate a complex type mv. Because many queries contains the properties below.

    http://docs.Oracle.com/CD/B28359_01/server.111/b28326/repmview.htm#i52501

    http://docs.Oracle.com/CD/B28359_01/server.111/b28313/basicmv.htm

    Specifically, a materialized view is considered complex if the materialized view definition query contains:

    • A CONNECT BY clause
    • An INTERSECT , MINUS , or UNION ALL operation
    • he DISTINCT or UNIQUE keyword
    • In some cases, an aggregate function, although it is possible to have an aggregation function in the query definition and always have a simple materialized view
    • In some cases, joins other than those in a subquery, although it is possible to have joins in the definition to interrogate and still have a simple materialized view
    • In some cases, a UNION operation


    After that I kept going to read that I learned that when a VM is created, the refresh mode is specified according to the type of the MV. That means, using ON-DEMAND refresh mode is widespread. The documentation mentions that there isa also refresh option. My question is, is it possible to specify

    ON REQUEST and FAST together?

    Also, what are the differences between FULL and FAST. Ends truncate the table and fill it up again?

    ON COMMIT

    Refresh product automatically when a transaction which changed one of the paintings of the materialized view's retail is committed. This can be specified as the materialized view is quickly updatable (in other words, not complex). The ON COMMIT privilege is required to use this mode.

    ON DEMAND

    Refresh occurs when a user manually executes one of the procedures available refresh contained in the DBMS_MVIEW package ( REFRESH , REFRESH_ALL_MVIEWS , REFRESH_DEPENDENT ).

    COMPLETE

    Refreshes and recalculating the materialized view query definition.

    FAST

    Applies incremental changes to refresh the materialized view using the information recorded in the papers of the materialized view, or an SQL * Loader direct-path access or a partition maintenance operation.

    FORCE

    Applies FAST update if possible; otherwise, it applies COMPLETE Refresh.

    NEVER

    Indicates that the materialized view will not be updated with updating mechanisms.

    Select * from version of v$.

    Oracle Database 11 g Release 11.2.0.4.0 - 64 bit Production

    Thank you

    Çaglar wrote:

    ...

    Also, what are the differences between FULL and FAST. Ends truncate the table and fill it up again?

    ...

    Thank you

    I just want to answer the truncated question. Seems that nobody covered that yet.

    Answer: It depends.

    If you do a full refresh, then the default is to use ATOMIC_REFRESH = TRUE.

    This means that the update is done via an insert, delete , and ... Select.

    You can change it to ATOMIC_REFRESH = FALSE (parameter dbms_mview.refresh).

    This means that is a TRUNCATE and insert a ... Select with APPEND peak (path direct insert).

    Refresh if Atomic = FALSE is considerably faster than the default. Also way less Archives of newspapers are written.

    The downside is however that, during the update the MV is empty, is no longer an atomar operation!

    See also Oracle documentation: http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_mview.htm#i997194

  • What is 'Table of container' in materialized views

    Hello

    What is meant by ' Container Table ' in materialized views?

    "Materialized view" (MV) is, in fact, a table, rather than a view.

    The term MV is used of the 9i database. In the 7 and 8 databases is the term 'snapshot' (to make things more complicated, the MV concept appeared in the 8i database, but in the context of the data warehouse).

    When you create a MV, for example. using the:

    Create materialized view emp_mv

    full refresh on demand

    as select empno, ename from EMP

    /

    you have, in fact, have created two objects in the data dictionary:

    Select object_name, object_type

    from user_objects

    where object_name = 'EMP_MV. '

    order by 1, 2;

    OBJECT_NAME OBJECT_TYPE

    --------------------- -------------------

    MATERIALIZED VIEW EMP_MV

    EMP_MV TABLE

    You can remove MV and a table of container:

    drop materialized view emp_mv;

    or you can delete only MV, preserving a table containing:

    Let fall the materialized view emp_mv maintain the table;

    Kind regards

    Zlatko

  • What is materialized views named?

    Hi there;

    When I read the documentation below, I met a sentence.

    http://docs.Oracle.com/database/121/DWHSG/basicmv.htm#i1007299

    Materialized views with subqueries or views named in the DE clause can be fast refreshed as points of view can be completely merged.

    What is the point of view named? Thanks in advance.

    Hello

    Named views are normal views created by running ' create view abc as select... from...» ».

    Kind regards

    Bashar

  • MATERIALIZED View Log Index Tablespace

    Is anyone aware of the syntax or a framework to be able to specify the index of a materialized view of the journal storage space?

    We chunk our objects by tablespace - index, tables, CLOB.

    Creating a materialized view log and specifying the storage space in which it should be created created the mv log in the correct location, but the index that is created uses the default tablespace for the user.

    And Yes, I Googled it. LMGTFY

    create materialized view log on MY_TEST tablespace my_tablespace ;


    select table_name, tablespace_name
  from user_tables
 where table_name like 'MLOG%';

    TABLE-NAMETABLESPACE_NAME
    MLOG$ _MY_TESTMY_TABLESPACE

    select table_name, index_name, tablespace_name
  from user_indexes
 where table_name like 'MLOG%';

    TABLE-NAMEINDEX_NAMETABLESPACE_NAME
    MLOG$ _MY_TESTI_MLOG$ _MY_TESTUSERS

    I found these documents:

    Index on MLOG$ (materialized view Log): difference in behavior between 11.2.0.3 and 11.2.0.4 (Doc ID 1959657.1)

    Materialized View Log (Mlog$) Index not created in its default Tablespace (Doc ID 1959658.1)

    I guess you are running 11.2.0.4, right?

    In previous versions, no index has been created automatically for the journal of MV.

    Kind regards

    Bashar

  • What is a materialized view?

    If I read oradocs on flashback instructions table and it mentions

    When you delete a table, all the newspapers view materialized, defined on the table are also deleted, but are not placed in the Recycle Bin. Therefore, the materialized view logs cannot be flashed back as well as the table

    (http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9012.htm#SQLRF01802)


    then I went to oradocs for the view materialized and read the first half logs.

    http://docs.Oracle.com/CD/B19306_01/server.102/b14200/statements_6003.htm

    Now, I know what makes a materialzed view log.

    is a materialized view as a point of view however... ?

    No, it isn't.

    A materialized view is basically a query with its 'materialized' or stored in a table results. A MV can be used by Oracle in a manner transparent re - write a query to be faster.

  • Problem with a complete refresh materialized view when using rownum

    Hi all

    I had a problem with rownum when complete using Refresh

    I use rownum when you create the materialized view, and this is the generation properly. But the question was when I even refreshing, rownum was not get sorted in ascending order.

    anyone encountered this scenario

    rownum is determined as the line came out, also "order by rownum" does absolutely nothing.

    http://docs.Oracle.com/CD/B19306_01/server.102/b14200/pseudocolumns009.htm

  • effect of pump or etl data on the materialized view logs

    Hi, we are mobile/upgrading an instance of 10g to 12 c, where one materialized view logs and expect to do one of the following:

    (1) extract/import the meta, only using data pump data and move data using an etl tool

    (2) comprehensive database extract/import using the data pump in

    are there questions that we must be aware of when the displacement of these with either scenario materialized view logs?

    Thanks for any information you can provide.

    > are there questions that we should be aware of when the displacement of these materialized view logs with either scenario?

    No problem

  • Trigger on the materialized view

    Hello

    I have the scenario based (Database 11 g):

    There is a view materialized (PERSON), which contains the ID and NAME fields. This MV is update daily with a fast refresh.

    I have a second array (NAMES), with ID and NORM_NAME. This table contains the name of the person, without special characters.

    For example, for recording / * 1 BJORN * / in the PERSON table

    I would check * 1 BJORN * / in table NAMES.


    Problem is how to fill the NAME table after the filling of the materialized view.

    I used a trigger AFTER INSERT or update, as described below, but even if I update the master table (for this purpose, update the MV), I have only to trigger inserts.


    Is there a way to implement a trigger "after update" on a materialized view, or do I need another approach?


    /*


    create or replace TRIGGER TRG_TESTE_MV

    AFTER INSERT OR UPDATE ON THE PERSON

    REFERENCING OLD AS OLD AGAIN AS NEW

    FOR EACH LINE

    BEGIN

    IF THE INSERTION

    INSERT THE NAMES

    VALUES

    (: NEW.id,:NEW.NAME);

    END IF;

    IF THE UPDATE CAN

    UPDATE OF NAMES

    SET NAME =: NEW.NAME WHERE ID =: NEW.id;

    END IF;

    END;

    */

    Thanks for any help

    Your trigger fires, but I doubted that you will be satisfied with the results. You really need to understand how to refresh process works before you begin creating triggers of MV:

    SQL > create table emp1 in select * from EMP
    2.

    Table created.

    SQL > create materialized view emp1 with rowid journal
    2.

    Materialized view log that is created.

    SQL > create materialized view emp1_mv
    2 fast refresh
    3 on request
    4 with rowid
    5 as
    6 select * from emp1
    7.

    Materialized view created.

    SQL > create or replace
    trigger 2 emp1_mv_biudr
    3 before inserting
    4 or update
    5 or delete
    6 on emp1_mv
    7 for each line
    Start 8
    9 insert then dbms_output.put_line ('INSERT' |: new.ename); end if;
    10 if the deletion then dbms_output.put_line ('REMOVE' |: old.ename); end if;
    11 end;
    12.

    Trigger created.

    SQL > insert
    2 in emp1 (empno, ename, sal)
    3 values(1,'X',1000)
    4.

    1 line of creation.

    SQL > validation
    2.

    Validation complete.

    SQL > set serveroutput on
    SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
    INSERTION OF X

    PL/SQL procedure successfully completed.

    SQL > update emp1
    2 set sal = sal + 1
    3 where ename ('King', 'JONES')
    4.

    2 lines to date.

    SQL > validation
    2.

    Validation complete.

    SQL > set serveroutput on
    SQL > exec dbms_mview.refresh ('emp1_mv', 'f');
    INSERTION OF JONES
    INSERTION OF KING

    PL/SQL procedure successfully completed.

    SQL > delete emp1
    2 where in ename ('ALLEN', 'SMITH')
    3.

    2 deleted rows.

    SQL > validation
    2.

    Validation complete.

    SQL > set serveroutput on
    SQL > exec dbms_mview.refresh ('emp1_mv', 'f');

    PL/SQL procedure successfully completed.

    SQL >

    As you can see, refresh MV updates ever. Results update underlying table to remove/insert in MV. That's why your trigger will not give the results that you expected.

    SY.

  • Materialized view automatically refresh? If the updating of the means how?

    Materialized view refresh automatically? If the updating of the means how?

    It is expected is not to ask questions of the basic documentation.

    Refresh Options

    When you define a materialized view, you can specify three update options: how to refresh, what kind of update and can trust constraints be used. If not specified, default values are considered as ON DEMAND , FORCE , and ENFORCED forced respectively.

    The two execution modes are ON COMMIT and ON DEMAND . According to the materialized view, you create, some options may be unavailable. Update modes are described in table 8-4 .

    Table 8-4 Modes of discount

    Refresh the Mode Description

    ON COMMIT

    Refresh product automatically when a transaction which changed one of the paintings of the materialized view's retail is committed. This can be specified as the materialized view is quickly updatable (in other words, no complex). The ON COMMIT privilege is required to use this mode.

    ON DEMAND

    Refresh occurs when a user manually executes one of the procedures available refresh contained in the DBMS_MVIEW package ( REFRESH , REFRESH_ALL_MVIEWS , REFRESH_DEPENDENT ).

    http://docs.Oracle.com/CD/B28359_01/server.111/b28313/basicmv.htm#i1006193

Maybe you are looking for