l'ordre des lignes dans un Select

Version imprimable

03/10/2006, 08h42
comment_ca

l'ordre des lignes dans un Select

Salut a tous.
J'ai une question fondamentale dont je ne suis pas sur de la reponse :

-quand j'execute un select qui fait un full scan d'une table (sans where ni order by) est ce que oracle est obligé de me donner les lignes dans l'ordre ou ils etaient saisies ?
03/10/2006, 09h03
Oraman

je dirai plutôt tel qu'il exsiste dans la table
03/10/2006, 09h09
LeoAnderson

Sans order by , ça veut dire que Oracle vous retourne les lignes comme ça lui chante, dans l'ordre qu'il veut lui ! (le RowId qui correspond assez souvent à l'ordre de saisie, sauf si il y a des moves, des redéfinitions online, ...)

si ça ne vous convient pas, mettez un order by.
03/10/2006, 09h10
comment_ca

tu peux expliquer plus en detail ce veux dire tel qu'ils existent dans la table ?
03/10/2006, 09h56
Xo

j'aime bien cette citation ;)

Citation:

Envoyé par SQlPro

Une table est un sac de bille

cf 5. Le dernier...
03/10/2006, 10h50
comment_ca

SQlPro a écrit :
Une table est un sac de bille

Donc si je comprends bien Xo si j'ai une table , même sans faire de delete ou de move je peux avoir a chaque fois un ordre aléatoire
03/10/2006, 15h58
remi4444

Il faut bien que tu comprennes que l'ordre n'est pas une information stockée dans oracle. L'ordre n'est qu'une caractéristique de restitution.
03/10/2006, 16h20
LeoAnderson

Citation:

Envoyé par comment_ca

SQlPro a écrit :
Une table est un sac de bille

Donc si je comprends bien Xo si j'ai une table , même sans faire de delete ou de move je peux avoir a chaque fois un ordre aléatoire

pas aléatoire, mais certaines opérations d'administration peuvent le modifier, c'est la raison pour laquelle ON NE PEUT PAS SE FIER A UN ORDRE SI ORDER BY N'EST PAS SPECIFIE
03/10/2006, 19h04
laurentschneider

parfois aléatoire, par exemple lors d'un accès parallèle à la table, cela peut dépendre de la charge du serveur, des statistiques, du plan en shared pool et du pendule de ma grand-mère :aie:
03/10/2006, 19h11
comment_ca

C'est bien ce ke je pensais mais j'en etais pas si sur.Merci pour vos reponses :D
04/10/2006, 08h15
LeoAnderson

Citation:

Envoyé par laurentschneider

parfois aléatoire, par exemple lors d'un accès parallèle à la table, cela peut dépendre de la charge du serveur, des statistiques, du plan en shared pool et du pendule de ma grand-mère :aie:

Peux-tu détailler, stp ? c'est super intérêssant !

si tu fait un select sur ta table avec 2 threads parallel, l'ordre final sera une juxtaposition des 2 requêtes "filles" ?
04/10/2006, 08h48
comment_ca

Non je fais pas d'ordre select en parallèle c un select normal qui ne contient ni where ni order by.

on va dire que j'ai une table t1(c1,c2,c3,c4,c5)
j'ai une clé primaire composée de c1,c2,c3 dont forcèment un index sur ces 3 colonnes.Il y'a un contrôle au niveau de la saisie qui empèche par exemple l'element 2 d'être inséré après l'element 3 ce qui fais que mes enregistrements sont insérés dans l'ordre.

Le paramètre optimizer_mode=choose.

quand je fais un select * from t1; ça veux dire normalement qu'il va faire un full scan sans passer par l'index le truc est que les lignes sont parfois affichées dans l'ordre et parfois non.
04/10/2006, 09h08
LeoAnderson

Citation:

Envoyé par comment_ca

Non je fais pas d'ordre select en parallèle c un select normal qui ne contient ni where ni order by.

ma question s'adressait à Laurent pour savoir comment exactement quand on est en exécution parallèle, l'aléatoire peut apparaitre ! ;-)

pour votre problème, on a répondu : si vous voulez un ordre fiable, faites un order by !
05/10/2006, 10h21
remi4444

De toutes façons, Oracle ne garanti rien, ne spécifie rien dans ce sens, on peut toujours essayer de constater le résultat mais ce ne sera qu'une "règle" empirique sans aucune garantie....
05/10/2006, 11h07
LeoAnderson

non, mais si l'exemple de Laurent permet de mieux comprendre comment marche le parallélisme, ce serait dommage de se priver de l'explication ! ;-)

mais il est évident que si l'on souhaite un ordre, on utilise systématiquement ORDER BY !

en cas de parallelisme, rien ne permet de savoir quel thread aura fini en premier. Rien de tel qu'une petite démo :)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 SQL> create table t05 (empno number, sal number) partition by list (empno) ( partition values (1) , partition values (2) , partition values (3), partition values (4) ) parallel 4; Table created. SQL> insert into t05 values (1,1000); 1 row created. SQL> insert into t05 values (2,1000); 1 row created. SQL> insert into t05 values (3,1000); 1 row created. SQL> insert into t05 values (4,1000); 1 row created. SQL> select /*+ PARALLEL(4) */ empno from t05; EMPNO ---------- 3 2 1 4 SQL> select /*+ PARALLEL(4) */ empno from t05; EMPNO ---------- 4 1 3 2
mais ce n'est qu'un exemple. Il y a beaucoup d'autres conditions qui peuvent influencer sur l'ordre des lignes, entre autres le row chaining, les index, les index descendants, les tables IOT, les tables HASH CLUSTER, les tables SINGLE HASH CLUSTER SORTED, les LOBs, et bien d'autres encore que je ne mentionne pas. Même si on se limite au "TABLE ACCESS FULL", rien n'est encore joué...