Sorting

This queston came up on the Oracle newsgroup a few days ago:

I have a table (call it policy) with three columns a, b and c. The table has two rows, with column c having value zero for both rows. I run the following query

select * from policy order by c;

As both the rows have a value of zero, the result should be sorted ascending by rowid, but I see the opposite;  viz. the result set is sorted descending by rowid.

Is that an issue with the version of 10g server, I am using or is it some settings of the Oracle server?

Various people replied to say that you should never assume any ordering beyond the order you explicitly state in the order by clause. But the question does raise a couple of interesting points.

Let’s start by running the test (it’s not hard to write up a test case, so why not do so when you ask the question). The following is good enough – and I’ve appended the output of the query when running on 10.2.0.1:

drop table t1;
create table t1 (a number, b number, c number);        

insert into t1 values(1,1,0);
insert into t1 values(1,1,0);        

commit;        

select t1.*, t1.rowid from t1 order by c;
         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAATncAAGAAABSKAAB
         1          1          0 AAATncAAGAAABSKAAA        

2 rows selected.

Sure enough, the results are in the “wrong” order.

So what do you do next ? The first couple of ideas are: add a third, fourth and fifth row to see if the “descending order” observation is accurate; then try running the test on a different version of Oracle.

Here’s the output from 10.2.0.1, after adding more and more rows:

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAATncAAGAAABSKAAA
         1          1          0 AAATncAAGAAABSKAAC
         1          1          0 AAATncAAGAAABSKAAB       

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAATncAAGAAABSKAAA
         1          1          0 AAATncAAGAAABSKAAD
         1          1          0 AAATncAAGAAABSKAAC
         1          1          0 AAATncAAGAAABSKAAB       

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAATncAAGAAABSKAAA
         1          1          0 AAATncAAGAAABSKAAB
         1          1          0 AAATncAAGAAABSKAAE
         1          1          0 AAATncAAGAAABSKAAD
         1          1          0 AAATncAAGAAABSKAAC

The results are NOT in descending order of rowid – it just looks that way in the very first case.

But here’s the output from the same test running on 9.2.0.8:

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAALJkAAJAAABIKAAA
         1          1          0 AAALJkAAJAAABIKAAB      

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAALJkAAJAAABIKAAA
         1          1          0 AAALJkAAJAAABIKAAB
         1          1          0 AAALJkAAJAAABIKAAC      

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAALJkAAJAAABIKAAA
         1          1          0 AAALJkAAJAAABIKAAB
         1          1          0 AAALJkAAJAAABIKAAC
         1          1          0 AAALJkAAJAAABIKAAD      

         A          B          C ROWID
---------- ---------- ---------- ------------------
         1          1          0 AAALJkAAJAAABIKAAA
         1          1          0 AAALJkAAJAAABIKAAB
         1          1          0 AAALJkAAJAAABIKAAC
         1          1          0 AAALJkAAJAAABIKAAD
         1          1          0 AAALJkAAJAAABIKAAE

So is seems more likely that there is a sorting effect (possibly accidental) on rowids in 9.2.0.8.

The Answer

Oracle introduced a new sorting algorithm (sometimes known as the Version 2 sort, which is how it is labelled in the 10032 trace) in 10.2.

The previous algorithm was effectively building an in-memory index on the incoming data using a balanced binary tree and seeking to the righ (i.e. optimised towards data that appeared in the correct order and keeping such data in the order of appearance – hence the apparent sorting of rowids in our example in 9i).

The CPU and memory overheads for this algorithm are a bit fierce for large sorts, so the new algorithm does something completely different (possibly based on a variant of the heapsort, though it isn’t actually a heapsort) which is more efficient on memory and CPU. It has the side-effect though, of re-ordering incoming rows even when the data is not arriving out of order.

Someone who knew their sorting algorithms really well might even be able to infer the algorithm Oracle was using by extending the test case and watching the rowids re-ordering themselves as the result set grows. But I’m not going to volunteer for that task.

If you want to disable the new sorting mechanism, there is a hidden parameter to affect it. As usual, you shouldn’t use hidden parameters without first receiving confirmation from Oracle support that you need to, but the relevant parameter is: _newsort_enabled, which defaults to true in 10g.