deletion of rows in materialized view

Hi all

I have a question!

If the main table rows are deleted on which a materialized view exists at a remote site, then the corresponding rows from the materialized view will also be deleted when updating?

Appreciate your help

IM

That is right.

Tags: Database

Similar Questions

ORA-00600: internal error when delete masters lines in a materialized view

I have a view, materialized in 11g 2 on Redhat 5, defined as

CREATE MATERIALIZED VIEW mv_idty
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
select IDTY_NAME_FIRST,IDTY_NAME_MIDDLE,IDTY_NAME_LAST,IDTY_NAME_SUFFIX,IDTY_SSN,
  IDTY_DR_LIC_NUM,IDTY_DR_LIC_STA,x.person_id,i.rowid i_rowid,x.rowid x_rowid
  from idty i,person_x_idty x where x.idty_id=i.idty_id;

I deleted a few lines of the masters and error tables

13:58:48 SQL> delete idty where  idty_id like 'test_row%' ;

7 rows deleted.

13:58:52 SQL> commit;
commit
*
ERROR at line 1:
ORA-12008: error in materialized view refresh path 
ORA-00600: internal error code, arguments: [kkzfrfajv_markdml-1], [], [], [], [], [], [], [], [], [], [], []

I have other materialized views and they all delete OK master. It's the simplest but is a problem. Help!

Published by: user13148231 on August 11, 2010 17:45

Hello
Please check this metalink note

* ORA-600 [Kkzfrfajv_markdml-1] [ID 743766.1] *.

Thank you

Is it possible to limit registration of deletion in the MATERIALIZED VIEW UPDATE?
Hello
I have materialized view can be updated and I want to just limit the functionality of record deletion on this point of view.
that is, the user should update the view but not able to delete the records.

Is it possible if yes then please describe the steps.

Kind regards
Kam.
If your point of view materialzed is editable, write a trigger and throw an exception on delete.

for triggers on views materialzed see...

http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:672989600346945045

Materialized Oracle view | Deleting records, Oracle materialized view
One question reg Materialized views.

If as part of the interview of the Source database, we remove some (older) recordings, the materialized view will also be updated with the deletion?

I believe that the answer is Yes. In this case make sure that deletion is not the case?

Is there anyway that we'll stop MView update to delete records that is inserted once even if we remove the same records in the source DB?
This is a common scenario, especially with materialized views that summarizes the detail data where you want to keep the summary but not the detail, and it is discussed in the documentation.

The technique is to make the MV refresh on request, delete the data in the detail tables and the CONSIDER_FRESH procedure to prevent the changes propagating to the MV. You will probably find it in the docs by searching on DBMS_MView.Consider_Fresh. There are a few caveats to note, in my opinion.

Delete the materialized view

Hello
in 9i Linux I should let drop materialized view log emp schema SCOTT. How to do this?
I tried but

SQL> select object_name from dba_objects where object_type='MATERIALIZED VIEW' and owner='SCOTT';

OBJECT_NAME
--------------------------------------------------------------------------------
EMP_SNAPSHOT

SQL> drop materialized view log emp;
drop materialized view log emp
                           *
ERROR at line 1:
ORA-00969: missing ON keyword

Thank you.

Hello

Try this:

drop materialized view log on emp;

"emp" here is the masterpiece.

Hope this helps.
Best regards
Jean Valentine

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.

Insert the data in materialized views at the Table

Hello
We have a problem in which some incorrect data has been loaded for tables.
Users now are pointing to the materialized views and data access using synonyms.
Is it possible to insert data from a view, materialized at the tables?
Kind regards
VN

Hello

As sb92075 has said, we can insert in the table of the materialized view.

Test below data:

SQL > select * from t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL > create mv_t1 view materialized in select * from t1;

Materialized view created.

SQL > select * from mv_t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL > insert into t1 values(8,'BBB',22,'NY');

1 line of creation.

SQL > select * from mv_t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL > select * from t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

NEW YORK 8 22 BBB

8 selected lines.

SQL > commit;

Validation complete.

SQL > select * from mv_t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL > delete from t1;

8 deleted rows.

SQL > select * from mv_t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL > insert into t1 select * from mv_t1;

7 lines were created.

SQL > select * from t1;

CITY OF AMOUNT ID COMMENTS

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

1 XXX 28 Chicago

2 AAA LAS 25

3 YYY 25 NY

4 35 Texas XXX

5 XXX 55 Arlington

6 56 Chicago YYY

7 XXX 66 NY

7 selected lines.

SQL >

Overhead of triggers VS materialized view log files
If I need to log UPDTEs, insertions and deletions on a table - is there a difference in charge through newspapers vs MV triggers?

Thank you
You said that MV newspaper is slightly more effective than a trigger. I'm curious to know why. How they work differently under the hood?

If the essence of the debate is only why MV newspaper is more effective than the trigger that I think that Justin has stressed that is below good technical points

1. you don't have to order at the PL/SQL engine.
2. you also write the binary data that you will put in the newspapers of recovery instead of column-level data.
And below the text in the documentation:

Trigger internal for the materialized view log

When changes are made to the master table or master materialized with DML view, 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 id of the object or both, as well as the values for the other columns in the materialized view log. It is an intern AFTER trigger LINE that runs automatically when you create a journal of materialized to view table main target or master materialized view. It inserts a line in the materialized view log, whenever an INSERT, UPDATE, or DELETE statement modifies data in the table. This trigger is always the last to fire.

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

3 trigger, i.e. we are coding for the track changes, newspaper MV i.e. tool/technology, which is provided by Oracle itself; So certainly "we are not that much able to write code that is equal to or better than the Oracle itself right?

Feature of MV's trigger INSTEAD of, but under the hood, with close to internal components of Oracle.

Concerning
Girish Sharma

ORA-12052: is unable to fast refresh materialized view string.string

Hello

I try to create the same xx and xx, after creating a newspaper, I get this error. Follow my structure:

create table PEDIDO
(
  NR_PEDIDO        NUMBER not null,
  DESCRICAO_PEDIDO VARCHAR2(10)
);

alter table PEDIDO
  add constraint PEDIDO_PK primary key (NR_PEDIDO);

create table ITEM_PEDIDO
(
  NR_PEDIDO  NUMBER not null,
  NR_PRODUTO VARCHAR2(10) not null
);
alter table ITEM_PEDIDO
  add constraint ITEM_PK primary key (NR_PEDIDO, NR_PRODUTO);
alter table ITEM_PEDIDO
  add constraint PEDIDO_ITEM_FK foreign key (NR_PEDIDO)
  references PEDIDO (NR_PEDIDO) on delete cascade;

create index INDEX_ITEM_PEDIDO on ITEM_PEDIDO (NR_PEDIDO);

insert into pedido
values (1, 'A');

insert into pedido
values (2, 'B');

insert into item_pedido
values (1, 'X');

insert into item_pedido
values (1, 'Z');

insert into item_pedido
values (2, 'X');

commit;

When you try to create, I get the error ORA-12052:

drop materialized view log on pedido;
drop materialized view log on item_pedido;

create materialized view log on pedido;
create materialized view log on item_pedido;

create materialized view mv_pedido_item
refresh fast as
select pe.nr_pedido, pe.descricao_pedido, ip.nr_produto
  from pedido pe, item_pedido ip where pe.nr_pedido = ip.nr_pedido;

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0

Hello Luiz,

Thank you for provding test cases.

SQL> drop materialized view log on pedido;
Materialized View log dropped.
SQL> drop materialized view log on item_pedido;
Materialized View log dropped.
SQL> create materialized view log on pedido
  with rowid;
Materialized View log created.
SQL> create materialized view log on item_pedido
  with rowid;
Materialized View log created.
SQL> create materialized view mv_pedido_item
refresh fast as
select pe.nr_pedido, pe.descricao_pedido, ip.nr_produto, pe.rowid pe_rowid, ip.rowid ip_rowid
  from pedido pe, item_pedido ip where pe.nr_pedido = ip.nr_pedido;
Materialized view created.

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
1 row selected.

Concerning
Peter

Materialized view Questions PLZ HELP!
Hi all

How to check the time required for a materialized view to run at a given time.
My point of view materialized is a full refresh that runs automatically at 03:00.

(a) I interviewed dba_jobs and dba_mview_refresh_times and matched the last_date and last_refresh to find the total time. How can I know that 80 JOBS matches my opinion MVIEW_UNION in a much easier way?

SQL > select job, last_date, order dba_jobs total_time in last_date;
WORK LAST_DATE TOTAL_TIME
---------- ----------------- ----------
80 05/05/10 03:00:02 5255

SQL > select name, last_refresh from dba_mview_refresh_times where owner
NAME LAST_REFRESH
------------------------------ -----------------
MVIEW_UNION 05/05/10 03:00:02

(b) also is total_time time it took the request to run today at 03:00, that is to say he started at 03:00 and ended at all about 4:45(3+5255_msec) or is it the time it has taken since the day wherever it has been planned in dba_jobs (IE back of 1 week)

(c) also my dosent table source contain all indexes and I created indexes on the materialized view, I want to know if the full update will recreate the indxes.

Thanks in advance,
Kind regards
Index on the MV are independent of indexes on the tables in the source.

The "container" for a MV is a table. Therefore, indexes can be created on this topic.
A FULL refreshment made with ATOMIC_REFRESH set to FALSE would be a TRUNCATE and INSERT APPEND. The index may be updated at the end.
A FULL refreshment made with ATOMIC_REFRESH set to TRUE would be a DELETE and INSERT. This, as it is, has notable requirements of Undo (and redo). Index, if any, would also add many more requirements Undo (and redo) and updating.
A QUICK update is an UPDATE or INSERT. Again, the presence of indexes can have an impact. If the discount is small (ie. the proportion of the updates/news lines is low compared with the lines already present in the MV), then the index can be kept because they are (the overhead of recreating the index i would exceed overload time and undo/redo of the DML with the present indices). However, if the QUICK updates/inserts many rows update, a strategy of DROP and CREATE better index.

Hemant K Collette
http://hemantoracledba.blogspot.com

Instead of trigger on a Materialized view?
Hello

We write INSTEAD OF trigger on the materialized view?

Piyush
peeyushgehlot wrote:
When we refresh materialized, view view full is truncated and new records get inserted, it is on the books and we can do service work, but when the incremental refresh is done, this trigger will run I don't know.

I'm not sure that I am. A complete refresh will cause insert triggers (line level and the table, before and after) fire for each row of the materialized view. An additional update will cause insert, update, and delete triggers (line level and the table, before and after) in the fire for each changed row. It may be of course, updates that do not actually change the data depending on how one defines the materialized view, and how changes should be handled.

Justin

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!

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

What is the desertion of orderly materialized view with MLOG$.

I have 11.2.4.0 Oracle enterprise edition.
I want to remove completely the MATERIALIZED view and MATERIALIZED view logs.

I need to do this on a production of databases.

It's the right order?
Thank you.

You can drop the materialized view log first, then the materialized views.

Because when you drop a materialized view log is therefore more available to fast refresh, however, it is available to rewrite, so drop materialized view log first, then materialized views. Additional information provided below may help Doc Oracle.

If you delete a simple materialized view that is the least recently refreshed materialized view of a main table, then the database automatically purges the materialized master table see only connect the required lines to refresh the materialized view has fallen.

If you delete a materialized view that was created on a predefined table, then the database removes the materialized view, and table preconstruitse returns to his identity in a table.

When you delete a master table, the database does not automatically drop the materialized views based on the table. However, the database returns an error when it tries to refresh materialized view based on a main table that has been abandoned.

If you delete a materialized view, then all the compiled queries that have been rewritten to use the materialized view will be invalidated and recompiled automatically. If the materialized view was preconstruitse on a table, then the table is not deleted, but it can no longer be maintained by the materialized view refresh mechanism.

deletion of rows in materialized view

Similar Questions

Maybe you are looking for