There’s not a lot that can be said, really.

What I’d like to see is a little more detail of why it can happen – are there any features like “number of columns in a multi-column sort”, “critical byte length of the things being sorted”, “some aspect of number of concurrent sorts” – and so on.

There has to be something more than “it happens at random”, or they wouldn’t be able to fix it. (And if it is a bug that means it can seem to happen at random I’d like to know that too).

I’ll try to build a test case if I have time tonight.

However, would you care to comment on the Bug ?

drop table p purge;
drop table c purge;
create table p (c1 varchar2(10));

insert into p values(‘C001′);
insert into p values(‘T001′);

create index idx$p on p(c1);

create table c (c1 varchar2(10), c2 number);

insert into c values(‘C001′, 1);
insert into c values(‘C001′, 2);
insert into c values(‘C001′, 3);

insert into c values(‘T001′, 3);
insert into c values(‘T001′, 2);
insert into c values(‘T001′, 1);

create index idx$c on c(c1, c2);

select p.c1, c.c2
from p, c
where p.c1 = c.c1
order by 1
/

– From 8i: c2 shown in the inserted order
C1 C2
———-
C001 1
C001 2
C001 3
T001 3
T001 2
T001 1

– From 10g: c2 shown in the “asc” order
C1 C2
———-
C001 1
C001 2
C001 3
T001 1
T001 2
T001 3

Acutally, the query shows the same with or without “order by” clause in both 8i and 10gR2.

Any apparent ordering that has not been specified is simply a side-effect of implementation, and is therefore neither right nor wrong.

10.1 shows the old behaviour because the new sort (like the new hash group by) was introduced in 10.2

Also , For same data if you use nvl(c,0) in the order by clause, than again some glitch in sorting.