Discussion :

[othon_oda]

j'ai une requete qui prend des colone en faisant une jointure de la table sur elle meme mais avec le num de ligne < au num de ligne

quand je fais ma requete avec numlig<> numlig
ca s'execute et quand je fais numlig<numlig ca met 3 plombes a faire meme un semblant de debut d'execution

d'apres vous pourquoi?

[remi4444]

clauses différentes, plans d'exécutions différents, donc temps différents...

EDIT: Si la requete est très complexe, il peut y avoir un probème au niveau de l'optimiseur qui peut "dérayer" dans certaines conditions (je crois que c'est un bug oracle). Pour contourner, il faut baisser le nombre de permutations (optimizer_max_permutations)

Si tu veux des explications plus précises et des pistes d'amélioration, il faut que tu donnes beaucoup plus de précisions:

- la requete
- un ordre de grandeur du nombre de lignes ramenées
- l'état des lieu des tables impliquées (volumes, indexs)

d'autre part avant de commencer à analyser, il faut que tu ais passé les stats sur ton schéma

[othon_oda]

la volumetrie c'est 204000 lignes environ.

il s'agit d'une table dite temporaire : videe et rempli a chaque fois

elle a comme index : que la primary key dans laquel se trouve toutes les colonnes concerne dans la jointure (y compris le NUMLIG)

[NGasparotto]

Quelle est la requête ? Est-ce possible de poster ici l'explain plan de chaque requête ?
Qu'entends-tu par table temporaire ? De travail ou vraiment global temporary table ?
Il y a peut-être un problème de stats sur la table. Essaies de calculer les stats lorsque la table est "pleine", ou bien des les imposer comme si elle était "pleine".

Nicolas.

[othon_oda]

Alors,
La requete est faite par un ETL ( BODI ) et malheursement je n'ai pas la main sur les stats......
La question pricipale est :
A votre avis pkoi le < est si degrade par rapport au <>

[NGasparotto]

Le plan d'exécution t'aiderais à comprendre qu'il y a une différence.
Regardes ci-dessous :

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
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
SQL> create table myobjects as select * from all_objects;

Table created.

SQL> create index myindex on myobjects(object_id);

Index created.

SQL> exec dbms_stats.gather_table_stats(user,'MYOBJECTS');

PL/SQL procedure successfully completed.

SQL> explain plan for select * from myobjects where object_id != 10;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------

--------------------------------------------------------------------
| Id  | Operation            |  Name       | Rows  | Bytes | Cost  |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT     |             | 70857 |  6158K|    58 |
|*  1 |  TABLE ACCESS FULL   | MYOBJECTS   | 70857 |  6158K|    58 |
--------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("MYOBJECTS"."OBJECT_ID"<>10)

Note: cpu costing is off

14 rows selected.

SQL> explain plan for select * from myobjects where object_id < 10;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------

---------------------------------------------------------------------------
| Id  | Operation                   |  Name       | Rows  | Bytes | Cost  |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |             |     3 |   267 |     3 |
|   1 |  TABLE ACCESS BY INDEX ROWID| MYOBJECTS   |     3 |   267 |     3 |
|*  2 |   INDEX RANGE SCAN          | MYINDEX     |     3 |       |     2 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("MYOBJECTS"."OBJECT_ID"<10)

Note: cpu costing is off

15 rows selected.

SQL>

Pour juger de la qualité de ta requête et trouver une explication à tes temps de réponse il y a pas mal de paramètres qui doivent être pris en compte dont la sélectivité de ta clause WHERE, le nombre de valeur possible de ton index, ton optimizer, les stats, les indexes existants, etc, etc...
Le mieux serait tout de même d'avoir un plan d'exécution, sans quoi, impossible de poursuivre l'analyse, à mon sens.

Nicolas.

[othon_oda]

Merci a tous pour vos infos,

En fait, j'ai resolu mon probleme en changeant completement de maniere de faire, je n'ai donc plus besoin de faire ma requete initiale.

Cela ne repond pas a ma question sur la difference d'execution entre le < et le <>, mais je creuserai ce probleme plus tard quand j'aurais du temps pour reformuler la requete directement en SQL et regarder le 'explain plan'.

Merci encore a vous,

[remi4444]

Cela ne repond pas a ma question sur la difference d'execution entre le < et le <> ...

Il me semble que j'avais répondu. Etant donné que ce sont 2 opérateurs différents, la requête est différente, donc le plan d'exécution est différent.

A partir de là tout est possible, le plan choisi par le CBO pour le ">" n'est sans doute pas le meilleur et c'est là qu'il faut fouiller pour comprendre la cause de ce mauvais choix.

L'hypothèse la plus probable est que l'optimiseur a eu une mauvaise estimation de la sélectivité de la clause contentant ">". Il a donc probablement choisi de passer par un index, ce qui s'avère pénalisant pour les selectivités faibles.