Discussion :

[comment_ca]

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 ?

[Oraman]

je dirai plutôt tel qu'il exsiste dans la table

[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.

[comment_ca]

tu peux expliquer plus en detail ce veux dire tel qu'ils existent dans la table ?

[Xo]

j'aime bien cette citation

Une table est un sac de bille

cf 5. Le dernier...

[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

[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.

[LeoAnderson]

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

[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

[comment_ca]

C'est bien ce ke je pensais mais j'en etais pas si sur.Merci pour vos reponses

[LeoAnderson]

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

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" ?

[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.

[LeoAnderson]

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 !

[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....

[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 !

[laurentschneider]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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é...