Possible reasons of a lock

Question

Hello, All,
hope you'll give me some advise which would explain the behaviour I have and guide me how to fix it.
First about the DB and application itself. We use 11.2 and there are several clients using OCCI as an interface.
One process (A) initiates a long transaction (could be few hours) which inserts records into some linked tables (3-4 tables).
Another process (B) performs polling of the DB based on the timestamp reading the data which were recently inserted into those tables where process A writes to. The issue is that process B hangs for quite the whole duration of that long operation which is being performed by process A. As soon as process A completes writing to all those tables (last commit issued) process B reads all new data and starts operating fast as usual.
What I also noticed it that process B may even hang on the SELECT made from a table which is not being modified by the process A.
I suspect there is some lock happening somewhere but what I also noticed is that when this issue happens (process B is hanging) I am able to run the same query that hangs in process B from another host using SQLDeveloper and it runs extremely fast as usual. So I started thinking there might be some issue with how we use connections from OCCI. Since if there is a lock then why it only locks SELECTs from one connection/session but not from the others?
Separate question (that's how I tried to make the behavior better) - is this a proper way to reduce the amount of data commited per transacton if I do something like this in a long lasting procedure:
create procedure X ()
as
declare i number := 0;
begin
for rc in (select id from table) loop -- start long operation using the list of records
[process the single record] -- inserts into several (3-4) related tables
i := i + 1;
if mod (i, 50000) = 0 then -- commit after every 50000 records processed
commit;
end if
end loop;
end;
Thank you very much for your help,
Max

Answer 1

Max Afanasiev wrote:
Hello, All,
hope you'll give me some advise which would explain the behaviour I have and guide me how to fix it.
First about the DB and application itself. We use 11.2 and there are several clients using OCCI as an interface.
One process (A) initiates a long transaction (could be few hours) which inserts records into some linked tables (3-4 tables).
Another process (B) performs polling of the DB based on the timestamp reading the data which were recently inserted into those tables where process A writes to. The issue is that process B hangs for quite the whole duration of that long operation which is being performed by process A. As soon as process A completes writing to all those tables (last commit issued) process B reads all new data and starts operating fast as usual.
What I also noticed it that process B may even hang on the SELECT made from a table which is not being modified by the process A.
I suspect there is some lock happening somewhere but what I also noticed is that when this issue happens (process B is hanging) I am able to run the same query that hangs in process B from another host using SQLDeveloper and it runs extremely fast as usual. So I started thinking there might be some issue with how we use connections from OCCI. Since if there is a lock then why it only locks SELECTs from one connection/session but not from the others?
Separate question (that's how I tried to make the behavior better) - is this a proper way to reduce the amount of data commited per transacton if I do something like this in a long lasting procedure:
create procedure X ()
as
declare i number := 0;
begin
for rc in (select id from table) loop -- start long operation using the list of records
[process the single record] -- inserts into several (3-4) related tables
i := i + 1;
if mod (i, 50000) = 0 then -- commit after every 50000 records processed
commit;
end if
end loop;
end;
Thank you very much for your help,
MaxIt is bad implementation to COMMIT inside LOOP.
Doing so increases the chances that an ORA-01555 (Snapshot Too Old) error will be thrown.