Skip to Main Content
  • Questions
  • Locking issues on Table A with FKs on table X while a procedure inserts records in table B with FKs on table X too

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Peter.

Asked: January 16, 2017 - 9:56 am UTC

Last updated: January 18, 2017 - 12:37 am UTC

Version: 11.2.0.3

Viewed 1000+ times

You Asked

Hello,

we use oracle 11.2.0.3 and following topic i would like to discuss here:

Setup like this:

Table A (partitioned) with an article column and FK defined to masterdata (article) keytable X

Table B also with article column and FK defined to masterdata (article) keytable X

keytable X is referenced by table A and B

Procedure proc (aggregation program) running and inserting new records in Table B.
While procedure running, there are active locks on keytable X in Mode 3.

Now the problem. Another procedure proc2 started and want to lock table A (partition in exclusive mod nowait).
This failed with error: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

I've narrowed down the problem.
Disabling the FK on Table A before running proc2 do not help. Error message also occur.
Disabling the FKs on Table B before running proc2 helps and proc2 runs fine.

I can reproduce this problem very easy. While running proc, i'm not able to enable/create any addional FK on any Table
which references also keytable X

Question: is this really a normal and expected behaviour?

Thanks a lot in advance

and Chris said...

You're going to need to share your test case. I can't reproduce it on 11.2.0.4:

Setup:

create table t1 (
  x int primary key
);
create table t2 (
  x int references t1(x)
);
create table t3 (
  x int references t1(x)
) partition by range (x) (
  partition p0 values less than (11)
);

insert into t1 values (1);
commit;


In session 1:

SQL> insert into t2 values (1);

1 row created.


In session 2:

SQL> lock table t3 partition for (1) in exclusive mode;

Table(s) Locked.

SQL> insert into t3 values (1);

1 row created.


You can see that both sessions have an SX lock on the parent, T1:

select * from dba_dml_locks;

SESSION_ID  OWNER  NAME  MODE_HELD   MODE_REQUESTED  LAST_CONVERT  BLOCKING_OTHERS  
96          CHRIS  T1    Row-X (SX)  None            588           Not Blocking     
96          CHRIS  T2    Row-X (SX)  None            589           Not Blocking     
47          CHRIS  T3    Row-X (SX)  None            348           Not Blocking     
47          CHRIS  T3    Exclusive   None            348           Not Blocking     
47          CHRIS  T1    Row-X (SX)  None            219           Not Blocking

Rating

  (5 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Peter Autenrieth, January 16, 2017 - 12:31 pm UTC

Hi Chris,

thanks for the fast response.

The force the issue of my question.
I used your setup objects.

Just create an insert in session 1, no commit!:

insert into t2 values (2);

in second session, please try to create a foreign key constraint like this

ALTER TABLE T3 ADD
CONSTRAINT testcase
FOREIGN KEY (X)
REFERENCES T1 (X)
ENABLE
VALIDATE;


i get the mentioned ORA-00054


Chris Saxon
January 16, 2017 - 2:04 pm UTC

Peter Autenrieth, January 16, 2017 - 12:53 pm UTC

to be more precise. T2 and T3 are partitioned

----------
--- init
------------

create table t1 (
x int primary key
);

create table t2 (
x int references t1(x)
) partition by range (x) (
partition p0 values less than (11)
);

create table t3 (
x int references t1(x)
) partition by range (x) (
partition p0 values less than (11)
);

insert into t1 values (1);
insert into t1 values (2);
insert into t1 values (3);

commit;

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

--session 1
insert into t2 values (1);

-- no commit;

/*
select * from dba_dml_locks;


212 AUTENRIP T1 Row-X (SX) None 132 Not Blocking
212 AUTENRIP T2 Row-X (SX) None 132 Not Blocking
212 AUTENRIP T2 Row-X (SX) None 132 Not Blocking
*/

-- session 2

ALTER TABLE T3 ADD
CONSTRAINT testcase
FOREIGN KEY (X)
REFERENCES T1 (X)
ENABLE
VALIDATE;

--> ORA-00054

with this simplified setup i'm not able to force the ORA-00054 by locking table or table partition from t3

humm

ghassan, January 16, 2017 - 1:56 pm UTC

fortunately you got this error;
you are in session 2 doing a ddl ! unless it is defferable this must warn you within this error !


Peter Autenrieth, January 16, 2017 - 3:04 pm UTC

Thanks, you are right...i have to provide my simplified setup which reflects our env and the problem.

we receive the error at locking table partition...unfortunately with the provided setup i can't reproduce it myself

LOCK TABLE T3 PARTITION (P0) IN EXCLUSIVE MODE NOWAIT


i'll provide more information
Chris Saxon
January 16, 2017 - 5:38 pm UTC

Send us the test case and we'll look at it

solved

Peter Autenrieth, January 17, 2017 - 3:42 pm UTC

hello again,

after i debugged our live system in detail i was able to find the root cause of the described problem.
setup in view words is like this

normale agg. programm runs an hours. destination table has several FK contraints

another program, service programm running in parallel. this procedure should enable table compression on partition level. what is happening there is...
"lock" source table...i thought, or at least the trown exception told us the resourcy busy error
in fact the error is not thrown here...i cause later by creating at temp. table (script gathered by ddl metadata) which also includes foreign keys to the same tables as aggregation procedure fill up.
in other words, your hint regarding the locks by DDL comands is the solution/root cause here.

Thanks a lot
Connor McDonald
January 18, 2017 - 12:37 am UTC

thank you for taking to time to get back to us

More to Explore

VLDB

If you are new to partitioning, check out Connor McDonald's introduction series here.

VLDB

Documentation set on VLDB and Partitioning.