Problème de tri sur une PRIMARY KEY [Résolu]

[dudu92]

Bonjour,

J'ai un problème que je ne 'arrive pas à résoudre.
Sur Oracle 9.2.0.1.0, j'ai une table comme suit :

Code :

1
2
3
   ID_DEFINITION_CARTE : NUMBER(10)
   ID_TYPE_CARTE : NUMBER(10)
   LIBELLE : VARCHAR2(35)

Il existe une clef primaire sur la 1ère colonne, et un index non unique sur la 2ème colonne.

Lorsque je passe la requete suivante :

Code :

SELECT id_definition_carte, id_type_carte, libelle FROM definition_carte WHERE id_type_carte = 2;

J'obtiens le résultat ci-dessous :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ID_DEFINITION_CARTE ID_TYPE_CARTE LIBELLE
------------------- ------------- -----------------------------------
               2029             2 SENS
              28045             2 PAYS
                 17             2 NUMERO RELEVE
                 18             2 NUMERO CARTE
                 19             2 NOM
                 20             2 PRENOM
                 21             2 DATE ACHAT
                 22             2 CODE OPERATION
                 23             2 MONTANT TTC
                 24             2 RAISON SOCIALE
                 25             2 NATURE VENTE
                 26             2 LOCALISATION
                 27             2 DEVISE
                 28             2 MONTANT DEVISE
 
14 ligne(s) sÚlectionnÚe(s).

Le résultat n'est pas trié selon la colonne ID_DEFINITION_CARTE, qui est pourtant la clef primaire.

Je pensais que les clef primaire était triée automatiquement ?

Voilà les paramètres du serveur :

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
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   AMERICAN
NLS_TERRITORY                  AMERICA
NLS_CURRENCY                   $
NLS_ISO_CURRENCY               AMERICA
NLS_NUMERIC_CHARACTERS         .,
NLS_CHARACTERSET               WE8MSWIN1252
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD-MON-RR
NLS_DATE_LANGUAGE              AMERICAN
NLS_SORT                       BINARY
NLS_TIME_FORMAT                HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY              $
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
NLS_NCHAR_CHARACTERSET         AL16UTF16
NLS_RDBMS_VERSION              9.2.0.3.0
 
20 ligne(s) sÚlectionnÚe(s).

et les paramètres de la session :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SQL> SELECT * FROM NLS_SESSION_PARAMETERS;
 
PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_LANGUAGE                   FRENCH
NLS_TERRITORY                  FRANCE
NLS_CURRENCY                   Ç
NLS_ISO_CURRENCY               FRANCE
NLS_NUMERIC_CHARACTERS         ,.
NLS_CALENDAR                   GREGORIAN
NLS_DATE_FORMAT                DD/MM/RR
NLS_DATE_LANGUAGE              FRENCH
NLS_SORT                       FRENCH
NLS_TIME_FORMAT                HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT           DD/MM/RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT             HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT        DD/MM/RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY              Ç
NLS_COMP                       BINARY
NLS_LENGTH_SEMANTICS           BYTE
NLS_NCHAR_CONV_EXCP            FALSE
 
17 ligne(s) sÚlectionnÚe(s).

Il se trouve que sur une copie de cet même schema, tout est OK.
Il semble de plus que les nouveaux enregistrements soient ajoutés en haut et non en bas comme attendu.


Merci de votre aide...

[Garuda]

je n'ai jamais entendu dire que les enregistrements étaient triés sur la PK !
Faire un order by dans la requête.
Mais ou est le pb ??

[dudu92]

Envoyé par Garuda

je n'ai jamais entendu dire que les enregistrements étaient triés sur la PK !
Faire un order by dans la requête.
Mais ou est le pb ??

Pourtant, cela semble être le cas dans MS SQL Serveur.
Sous Oracle, j'ai toujours vu le dernier enregistrement se mettre à la fin dans mes SELECT.
Avec une PK, il me semble qu'il y a un index qui se crée automatiquement, ce qui fait que c'était trié automatiquement aussi.

[Garuda]

Jamais entendu parler de ca.
Quand bien même, je me repête, OU est le problème.

[dudu92]

Envoyé par Garuda

Jamais entendu parler de ca.
Quand bien même, je me repête, OU est le problème.

Le problème est que le programme ne fait pas d'order by sur les colonnes qui devrait être triées, car il y a une PK et un index.
Je n'ai pas la main sur le programme pour forcer le tri.

Du coup, ce programme fonctionne très bien sur plusieurs bases, mais pose problème sur de nouvelle base.

J'ai l'impression qu'un paramètre a été modifiée dans la base depuis, mais je ne vois pas lequel (je ne suis pas DBA en plus).

[McM]

L'ordre d'affichage sans ORDER BY n'a jamais été celui de la pk.
C'est toujours dans l'ordre que l'Optimiseur choisit. (L'ordre dans lequel les lignes sont lues)
Si la table n'est pas accédée par l'index de la PK, il n'y a aucune raison qu'il trie tout seul les données dans l'ordre de la PK (et heureusement, sinon ça boufferait de la mémoire et de l'IO pour du tri non voulu).

Imagine : Tu fais un Table access Full sur une table
Si tu devais trier les données dans l'ordre de la PK, il faudrait aller lire en plus l'index de la PK, puis les trier en mémoire

Pour nous : Ce qui s'est passé lorsque ma boite a changé les bases en mode CHOOSE (ils étaient en Choose sans stat : Equivalent au mode RULE).
Habitués à faire des SELECT sur des petites tables avec le début de la pk sans tri. ex

Code :

SELECT pk1, pk2, col3 FROM MATABLE WHERE pk1 = 'SOCIETE1'

Le mode rule prend l'index de la PK automatiquement => Tri implicite dans l'ordre de lecture de l'index de la PK
Quand on est passé en CHOOSE : optimiseur : Pas besoin de lire l'index de la PK => Table access full => "Tri" dans l'ordre de lecture = Tri différent

[dudu92]

Envoyé par McM

Pour nous : Ce qui s'est passé lorsque ma boite a changé les bases en mode CHOOSE (ils étaient en Choose sans stat : Equivalent au mode RULE).
Habitués à faire des SELECT sur des petites tables avec le début de la pk sans tri. ex

Code :

SELECT pk1, pk2, col3 FROM MATABLE WHERE pk1 = 'SOCIETE1'

Le mode rule prend l'index de la PK automatiquement => Tri implicite dans l'ordre de lecture de l'index de la PK
Quand on est passé en CHOOSE : optimiseur : Pas besoin de lire l'index de la PK => Table access full => "Tri" dans l'ordre de lecture = Tri différent

Pour ce qui est de l'optimisation, je suis tout à fait d'accord avec toi.
Pour ce qui est du mode CHOOSE ou RULE, je vais regarder sur la base comment c'est mis.
Je cherche comment on peut trouver ça, et je reviens

[Garuda]

Est ce que tu as changé de version (8.1=>9) ?
Ne serais-ce pas du au fait qu'il n'ya plus d'optimisation 'RULES' en 9 ?

[McM]

Mode de la base :

Code :

1
2
3
SELECT value
FROM v$parameter
WHERE name = 'optimizer_mode'

Depuis la 9 en effet, il n'y a plus de mode RULE au niveau de la base.
Mais s'il n'y a pas de stats pour les tables de la requete, Oracle utilise alors le mode RULE pour la requete.

[dudu92]

Envoyé par McM

Mode de la base :

Code :

Depuis la 9 en effet, il n'y a plus de mode RULE au niveau de la base.
Mais s'il n'y a pas de stats pour les tables de la requete, Oracle utilise alors le mode RULE pour la requete.

Merci à tous les 2.
Effectivement, le serveur est en mode CHOOSE.
Je vais demandé à ce qu'on fasse un test en mode RULE.
Et puis remonter l'info au développement pour faire des tri sur les PK.