Nice solution! I don’t think that I would have come up with that solution if I continued to work on this problem.

Let’s test with 2 sessions to see what happens.
Session 1:

select t1.c1
from   (select rowid rd
        from   t1
        order  by c1 asc) x
,      t1
where  t1.rowid = x.rd
and    rownum <= 5
for update of t1.c1;
 
  C1
----
   1
   2
   3
   4
   5

That worked.

Session 2:

SET AUTOTRACE ON
 
select t1.c1
from   (select rowid rd
        from   t1
        order  by c1 desc) x
,      t1
where  t1.rowid = x.rd
and    rownum <= 5
for update of t1.c1;
 
   C1
-----
10000
 9999
 9998
 9997
 9996
 
Execution Plan
----------------------------------------------------------
Plan hash value: 3858600555
 
---------------------------------------------------------------------------------------
| Id  | Operation                      | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |      |     5 |   185 |     6   (0)| 00:00:01 |
|   1 |  FOR UPDATE                    |      |       |       |            |          |
|   2 |   BUFFER SORT                  |      |       |       |            |          |
|*  3 |    COUNT STOPKEY               |      |       |       |            |          |
|   4 |     NESTED LOOPS               |      |     5 |   185 |     6   (0)| 00:00:01 |
|   5 |      VIEW                      |      | 11610 |   136K|     1   (0)| 00:00:01 |
|   6 |       SORT ORDER BY            |      | 11610 |   283K|   147  (11)| 00:00:01 |
|   7 |        TABLE ACCESS FULL       | T1   | 11610 |   283K|   137   (5)| 00:00:01 |
|   8 |      TABLE ACCESS BY USER ROWID| T1   |     1 |    25 |     1   (0)| 00:00:01 |
---------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter(ROWNUM<=5)
 
Note
-----
   - dynamic sampling used for this statement (level=2)

That also worked, and without Session 1 blocking Session 2.

I started wondering if there could not be a hidden problem… if the order of the rows within the “Top 5″ really is important, are we actually relying on an implicit sort order? Let’s test.
Session 2:

select /*+ LEADING(T1) */ t1.c1
from   (select rowid rd
        from   t1
        order  by c1 desc) x
,      t1
where  t1.rowid = x.rd
and    rownum <= 5
for update of t1.c1;
 
   C1
-----
10000
 9999
 9998
 9997
 9996
 
Execution Plan
----------------------------------------------------------
Plan hash value: 397963150
 
--------------------------------------------------------------------------------
| Id  | Operation               | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |      |     5 |   185 |   288  (10)| 00:00:01 |
|   1 |  FOR UPDATE             |      |       |       |            |          |
|   2 |   BUFFER SORT           |      |       |       |            |          |
|*  3 |    COUNT STOPKEY        |      |       |       |            |          |
|*  4 |     HASH JOIN           |      | 11610 |   419K|   288  (10)| 00:00:01 |
|   5 |      TABLE ACCESS FULL  | T1   | 11610 |   283K|   137   (5)| 00:00:01 |
|   6 |      VIEW               |      | 11610 |   136K|   147  (11)| 00:00:01 |
|   7 |       SORT ORDER BY     |      | 11610 |   283K|   147  (11)| 00:00:01 |
|   8 |        TABLE ACCESS FULL| T1   | 11610 |   283K|   137   (5)| 00:00:01 |
--------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter(ROWNUM<=5)
   4 - access("T1".ROWID="X"."RD")
 
Note
-----
   - dynamic sampling used for this statement (level=2)

The expected rows were still returned in the expected sort order – interesting. However, notice that the Nested Loops operation changed to a Hash Join – might this still be a problem?

One more try without a LEADING hint, but changing the inline view to retrieve the top 9,999 rows sorted in descending order.
Session 2:

select t1.c1
from   (select rowid rd
        from   t1
        order  by c1 desc) x
,      t1
where  t1.rowid = x.rd
and    rownum <= 9999
for update of t1.c1;
 
    C1
------
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
...
  9994
  9995
  9996
  9997
  9998
  9999
 
9999 rows selected.
 
Execution Plan
----------------------------------------------------------
Plan hash value: 4115059001

--------------------------------------------------------------------------------
| Id  | Operation               | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT        |      |  9999 |   605K|   269  (10)| 00:00:01 |
|   1 |  FOR UPDATE             |      |       |       |            |          |
|   2 |   BUFFER SORT           |      |       |       |            |          |
|*  3 |    COUNT STOPKEY        |      |       |       |            |          |
|*  4 |     HASH JOIN           |      | 11610 |   702K|   269  (10)| 00:00:01 |
|   5 |      VIEW               |      | 11610 |   136K|   147  (11)| 00:00:01 |
|   6 |       SORT ORDER BY     |      | 11610 |   283K|   147  (11)| 00:00:01 |
|   7 |        TABLE ACCESS FULL| T1   | 11610 |   283K|   137   (5)| 00:00:01 |
|   8 |      TABLE ACCESS FULL  | T1   | 11610 |   283K|   118   (5)| 00:00:01 |
--------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   3 - filter(ROWNUM<=9999)
   4 - access("T1".ROWID="X"."RD")
 
Note
-----
   - dynamic sampling used for this statement (level=2)

I don’t know if that qualifies as a bug in Oracle Database, but not only is the order not in descending order, but we lost the row with C1 value 10000 – we ended up with the *bottom* 9,999 rather than the *top* 9,999.

I think that your suggestion is still a very good one.

select t1.col1
from   (select rowid rd
        from   t1
        order  by col1 asc) x
,      t1
where  t1.rowid = x.rd
and    rownum <= 5
for update of t1.col1;

I think you were trying to demonstrate an easy way to show that if you don’t pay attention to order it is trivial to get deadlocks. Don’t be confident your pair of random updates won’t ever deadlock because they didn’t once. That just demotes your test to one that won’t always deadlock. I suspect your earlier test had some additional wrinkle (or was on a different data set) if it consistently deadlocked.

Of course there are plenty of ways to intentionally generate deadlocks consistently. The goal of avoiding deadlocks is a bit trickier and Charles’ demonstration of a way to influence the order of locking as of current releases is useful toward that goal.

For now it seems a very useful technique. Like any other detail of current physical access method and order, it may change in the future. Unlike eschewing an order by in V5 when you had the matching group by because you knew order only had a sort based aggregation and it actually completely re-sorted the result set, Charles’ process won’t break your query if the order of acquiring locks changes in the future due to some change in the access order. It will just lose its current positive effect on avoiding deadlocks. And while hash aggregation methods for group by were well understood computer science just waiting to reach a positive tradeoff for advantages versus cost of implementation and testing, acquiring locks in order when there is an order in place and supported by an index seems solid as long as parallel access methods are not considered. (And multiple threads of parallel DML against the same objects is just asking for trouble as far as deadlocks go. I suggest you either run one thread as parallel as you need or as many threads as you need each not parallel rather than multiple threads somewhat less in parallel.)

I’m referring to just a plain SELECT … FOR UPDATE ORDER BY DBMS_RANDOM.VALUE. Some time ago I easily got deadlock in such a case with 2 sessions running the same statement. But I can’t reproduce it now, so maybe I’m wrong.

Thank you for the compliment and the very useful comments related to avoiding deadlocks.

On an unrelated side note, I wondered how Oracle Database would handle a Top-N type query with a FOR UPDATE clause – would it have to revisit the table’s blocks to lock just the rows that were to be returned, or would it lock all of the rows in the table as the rows were read from the blocks? I adjusted the first SELECT FOR UPDATE query so that without the FOR UPDATE clause it would only return the first 5 rows when sorted by column C1. I then added a FOR UPDATE clause:

 
SELECT
  *
FROM
  (SELECT
    C1,
    C2
  FROM
    T1
  WHERE
    MOD(C1,100)=0
  ORDER BY
    C1)
WHERE
  ROWNUM<=5
FOR UPDATE;
 
  (SELECT
  *
ERROR at line 4:
ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.

It looks like the programmers anticipated this particular problem, but that is a bit of an incorrect/vague error message description.

I think that you have a good suggestion, but I am having trouble putting together a full picture of what you are suggesting (I have a feeling that your comment ties in with Mark’s comment below). Are you describing a situation where the resultset of a SQL statement like this:

SELECT
  C1,
  C2
FROM
  T1
ORDER BY
  DBMS_RANDOM.VALUE;

(Note in the above that the FOR UPDATE clause is not specified.) Would be used in a loop to update the rows one at a time in table T1? I could see this arrangement resulting in a deadlock if two sessions perform the action at roughly the same time. A related side note: if an ORDER BY clause is not specified, it could very well be the case that the rows for two sessions will be returned in different sort orders if the execution plans were not identical for the same SQL statement executed by the two sessions, and I suspect that could lead to the same problem described above with the ORDER BY DBMS_RANDOM.VALUE.

Please let me know if I completely missed the point.

Any other ideas for a demonstration of the order in which rows are locked when a SELECT FOR UPDATE is used?

Easiest way I know is to run two order by dbms_random.value for update statements; high chances are there’ll be a deadlock.