Locking and blocking - puzzlement.

Question

I have a table - relatively simple
CREATE TABLE Sysstat
M_Time     DATE,
Usr_pct    NUMBER(10, 0),
Sys_pct    NUMBER(10, 0),
<a few more NUMBER(10, 0) deleted...
CONSTRAINT Sysstat_PK PRIMARY KEY (M_Time)
);Issue (From an SQLPlus session) the command DELETE FROM Sysstat - but do not COMMIT.
Go to SQLDeveloper - and (try to) do the following
INSERT INTO Sysstat
SELECT ROUND(TO_DATE  (Sysstat_ext.M_Time, 'DD-MM HH24:MI:SS'), 'MI') AS "Measurement Time",
       ROUND(TO_NUMBER(Sysstat_ext.Usr_pct),    0) AS "% Usr",
       <fields deleted>
FROM Sysstat_ext
COMMIT;The SQLDeveloper session completely hangs - forever* (at least 20 mins at this stage).
As I understood matters with Oracle there were three possibilities.
1) PK violation. The SQLDeveloper session "sees" that there are still records in Sysstat (changes
are uncommitted as far as he's concerned), but there is a PK violation in the data to
be inserted anyway, so the SQLDeveloper session should tell the user Sysstat_PK violation.... error...
2) No potential PK violation. The SQLDeveloper session doesn't know whether the SQL*Plus
session will commit its deletions or not, therefore the SQLDeveloper session commits and Oracle keeps track of the
necessary chains of pointers internally and/or when the SQL*Plus session tries to commit, it's accepted or refused
depending on whether this will cause other issues (FK violation for example)
or
3) Oracle knows that there's a deadlock and after a certain period (configurable?) rolls back the SQLDeveloper session
and informs the user.
Could some kind soul explain to me what, exactly, is going on - and why my reasoning is so obviously erroneous.
I have been looking at Kyte's architecture book, so maybe a concrete example (I've never deadlocked Oracle
before) would help clarify the concepts for me.
Paul...

Answer 1

Paulie wrote:
>
Could some kind soul explain to me what, exactly, is going on - and why my reasoning is so obviously erroneous.
I have been looking at Kyte's architecture book, so maybe a concrete example (I've never deadlocked Oracle
before) would help clarify the concepts for me.I've now read a bit about mutexes in Oracle - not that I understood all of it.
no deadlock is occuring.Well, what else should one call a session that is blocked indefinitely? Is there another
computer science term for this phenomenon?
I suspect a Mutex wait is the cause.OK - so, some sort of device to "regulate concurrent access to a shared resource". That's fine.
The blogs and websites which discuss this seem to be a propeller-head's wet dream with obscure X$_Blah
table configs and Totallyunknown_even_to_Oracle_Support parameters being bandied about like there's
no tomorrow.
What I would like to know is a bit more prosaic (and perhaps a level less technically sophisticated).
Is my reading of Oracle's Locking/Latching/Multi-User behaviour correct in what I wrote originally, i.e.
Scenarios:
1) PK violation. The SQLDeveloper session "sees" that there are still records in Sysstat (deletion
is uncommitted as far as he's concerned), but there is a PK violation in the data to
be inserted anyway, so the SQLDeveloper session should tell the user Sysstat_PK violation.... error...
no change to database - SQLDev user informed
2) No potential PK violation. The SQLDeveloper session doesn't know whether the SQL*Plus
session will commit its deletions or not, therefore the SQLDeveloper session commits and Oracle keeps track of the
necessary chains of pointers internally and/or when the SQL*Plus session tries to commit, it's accepted or refused
depending on whether this will cause other issues (FK violation for example)
or
3) Oracle knows that there's a deadlock and after a certain period (configurable?) rolls back the SQLDeveloper session
and informs the user.
Or am I still competely at sea with what Oracle is about? I was of the understanding that whatever* happened,
you should never have a situation where a session hangs indefinitely, due to Oracle's system
of multi-version concurrency - basically, I'm asking what is going on here and how does it
fit with my current* (and obviously mistaken) understanding of how Oracle works.
Thanks for your input so far.
Paul...A basic truism exist for Oracle.
Readers do not block writers & writers do not block readers!
What you fail to recognize is that your test case has two WRITERS; both are doing DML!
two sessions want to change same resource & to maintain data consistency & integrity
the changes must be serialized. One must complete before the second can proceed.
Oracle utilizes Interested Transaction List (ITL) to maintain block level data consistency.
SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid sess,
id1, id2, lmode, request, type
FROM V$LOCK
WHERE (id1, id2, type) IN
(SELECT id1, id2, type FROM V$LOCK WHERE request>0)
ORDER BY id1, request
/