J'ai la situation suivante.
J'ai RAC. Sur les deux nœuds, il y a les verrous.
SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS
1 102 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFA958 5f4bzdg49fdxq ACTIVE
2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EFAC98 5f4bzdg49fdxq ACTIVE
SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS
1 155 SQL*Net message from client MYUSER 136971 MyTABLEIMAGES_IDPK 4hw85z8absbjc INACTIVE
SID EVENT USERNAME BLOCKING_SESSION ROW_WAIT_OBJ# OBJECT_NAME LOCKWAIT SQL_ID STATUS
1 65 enq: TX - row lock contention MYUSER 155 137033 FactTABLE1V 0000000810EF9B58 1mznc2z75ksdx ACTIVE
2 111 enq: TX - row lock contention MYUSER 155 136972 TABLE1V 0000000810EF9818 5f4bzdg49fdxq ACTIVE
SID EVENT USERNAME ROW_WAIT_OBJ# OBJECT_NAME SQL_ID STATUS
1 155 SQL*Net message from client MYUSER 127176 MYTableLOG INACTIVE
create or replace procedure ACTIONProcedureDELETE
(
p_ID NUMBER
)
is
cursor oldval is select r.id,r.sessionstatus
from MyTABLEIMAGES r where r.idparent=p_ID;
begin
update actionmyTableblock r set r.status='False' where ID=p_ID;
for oldvalItem in oldval loop
if oldvalItem.Sessionstatus='True' then
update MyTABLEIMAGES r set r.sessionstatus='False' where r.id=oldvalItem.Id;
else
update MyTABLEIMAGES r set r.sessionstatus='True' where r.id=oldvalItem.Id;
end if;
end loop;
end ACTIONProcedureDELETE;
Comme vous pouvez le voir, la session de blocage est INACTIVE mais toujours verrouillable.
Si je select v$sql_bind_capture
il n'y a pas de valeur pour VALUE_STRING
pour bloquer la session sql_id
.
Je peux deviner qu'il n'y a pas de commit/rollback mais le développeur de l'application dit "J'ai tout ok, j'ai écrit un commit là où c'est nécessaire"
Veuillez aider.
Requete v$transaction
sur chaque nœud pour voir les sessions non validées:
SELECT t.start_time, s.sid, s.serial#, s.username, s.status,s.schemaname, s.osuser
, s.process, s.machine, s.terminal, s.program, s.module
, to_char(s.logon_time,'DD/MON/YY HH24:MI:SS') logon_time
FROM v$transaction t, v$session s
WHERE s.saddr = t.ses_addr
ORDER BY start_time;
Vous pouvez éviter les conflits de verrouillage de ligne en vous assurant que la ligne est disponible pour la mise à jour au préalable avec un SELECT FOR UPDATE
et soit WAIT X
ou NOWAIT
, par exemple:
create or replace procedure ACTIONProcedureDELETE (p_ID NUMBER)
is
cursor oldval is select r.id,r.sessionstatus
from MyTABLEIMAGES r where r.idparent=p_ID FOR UPDATE NOWAIT;
l_id NUMBER;
begin
select id into l_id from actionmyTableblock where ID=p_ID
FOR UPDATE of status NOWAIT;
update actionmyTableblock r set r.status='False' where ID=p_ID;
for oldvalItem in oldval loop
if oldvalItem.Sessionstatus='True' then
update MyTABLEIMAGES r set r.sessionstatus='False' where r.id=oldvalItem.Id;
else
update MyTABLEIMAGES r set r.sessionstatus='True' where r.id=oldvalItem.Id;
end if;
end loop;
end ACTIONProcedureDELETE;
Si la ligne est verrouillée, vous recevrez un ORA-00054 qui est dans la plupart des cas préférable à une attente indéfinie.
vous pouvez utiliser le sélecteur pour la mise à jour, verrouillé, ce qui est plus élégant et plus sûr