Re: What is mutating table?

Answer
#1
A mutating table is a table that is currently being
modified by an update, delete, or insert statement. For
example, if your trigger contains a select statement or an
update statement referencing the table it is triggering off
of you will receive the error.
Another way this error can occur is if the trigger has
statements to change the primary, foreign or unique key
columns of the table the trigger is triggering off of.

Is This Answer Correct ? 30 Yes 1 No

3
Pavan_1981
Re: What is mutating table? Answer
#2
Mutating means that some one is trying to access the table
currently being held by some other non-committing
transaction(i.e. in Locked state)

Is This Answer Correct ? 5 Yes 16 No

0
Vivek Dubey

Re: What is mutating table? Answer

#3
Mutatation of table is a state of table when in
before /after update trigger table tries to update the same
table.As the call of update also calls same trigger then
the trigger will be called infinite times. then the table
will be mutating

Is This Answer Correct ? 14 Yes 0 No

0
Gopal
Re: What is mutating table? Answer
#4
Mutating" means "changing". A mutating table is a table
that is currently being modified by an update, delete, or
insert statement. When a trigger tries to reference a table
that is in state of flux (being changed), it is
considered "mutating", and raises an error since Oracle
should never return inconsistent data.

Another way this error can occur is if the trigger has

statements to change the primary, foreign or unique key
columns of the table off which it fires. If you must have
triggers on tables that have referential constraints, the
workaround is to enforce the referential integrity through
triggers as well.

Is This Answer Correct ? 8 Yes 1 No

0
Kiran
Re: What is mutating table? Answer
#5
A mutating table is a table that is currently being
modified by an UPDATE, DELETE, or INSERT statement, or it
is a table that might need to be updated by the effects of
a declarative DELETE CASCADE referential integrity
constraint. The restrictions on such a table apply only to
the session that issued the statement in progress.
For all row triggers, that were fired as the result of a
DELETE CASCADE, there are two important restrictions
regarding mutating tables. These restrictions prevent a
trigger from seeing an inconsistent set of data.
The SQL statements of a trigger cannot read from (query) or
modify a
mutating table of the triggering statement.

For eg:We have two tables "A" and "B". "A" is the master
table and "B" the detail table. We specified a foreign key
between "B" and "A" with the CASCADE DELETE option.

Here are the CREATE statements

drop table B;
drop table A;
create table A (
ida number not null,
vala varchar2(10),
primary key(ida));
create table B (
idb number,
valb varchar2(10),
foreign key (idb) references A (ida) on delete cascade)
/
create or replace trigger b_br
after delete on B
for each row
declare
n integer;
begin
select count(*) into n from A;
dbms_output.put_line('there are ' || n || ' rows in A');
dbms_output.put_line('after statment on B');
dbms_output.new_line;
end;
/
insert into A values(1,'Table A');
insert into A values(2,'Table A');
insert into B values(1,'Table B');
insert into B values(1,'Table B');
commit;
set serveroutput on;
delete from A where idA = 1;
ERROR at line 1:
ORA-04091: table SCOTT.A is mutating, trigger/function may
not see
ORA-06512: at "SCOTT.B_BR", line 4
ORA-04088: error during execution of trigger 'SCOTT.B_BR'
Notice that the SQL statement ( "select count(*) into n
from A" ) is run for the first row of the table, and then
the AFTER row trigger B_BR is fired. In turn, a statement
in the AFTER row trigger body attempts to query the
original table A. However, because the table A is mutating
due to the CASCADE DELETE foreign key, this query is not
allowed by Oracle. If attempted, a runtime error occurs,
the effects of the trigger body and triggering statement
are rolled back, and control is returned to the user or
application.
Solution: Use statement trigger instead of row trigger
If you delete the line "FOR EACH ROW" from the trigger
above, then the trigger becomes a statement trigger, the
table is not mutating when the trigger fires, and the
trigger does output the correct data.
SQL> delete from A where idA = 1;

there are 1 rows in A

after statment on B

1 row deleted.
SQL> select count(*) from B;

COUNT(*)
----------
0
(PS:It is not always possible to change the row trigger to
a statement trigger. This is just a way of avoiding a
mutating table error , there are many other ways by which
this can be acheived)
Cheers,
SAS

Is This Answer Correct ? 6 Yes 2 No

0
Swapnil Siriah
Re: What is mutating table? Answer
#6
All the above suggested point is fine but addition on it is
when you are going to use the aggregate function for same
table then also be the mutating table error will occur.

example:

create table t(x numner);

/

create or replace trigger t_af_trigg

before insert into t
for each row
declare
n integer;
begin
select count(*) into n from t;
dbms_output.put_line('there are ' || n || ' rows in t');
end;
/

insert into t values(1);

error:
ORA-04091: table MISC.T is mutating, trigger/function may
not see it
ORA-06512: at "MISC.T_AF_TRIGG", line 5
ORA-04088: error during execution of trigger 'MISC.T_AF_TRIGG'

This example value addition of Vivek's suggession

"Mutating means that some one is trying to access the table

currently being held by some other non-committing
transaction(i.e. in Locked state)"