Discussion :

[Robinson8171]

Bonjour à tous

J'utilise ORACLE 9i.
J'ai une table que je remplis avec un million de lignes. Sur cette table, je n'ai pas créé (encore d'index) ni fait d'analyse.
Je crée ensuite un index (sans analyse).
Lorsque j'exécute une requête devant prendre l'index (pas de doute possible), elle ne le prend pas.
Je supprime l'index puis le recrée (avec le même script), là, la requête prend l'index.

Petit détail : à aucun moment, je n'ai analysé la table ou l'index.
Je ne souhaite pas faire d'analyse des objets (je suis dans le cadre d'une étude qui cherche à valider l'intérêt d'une analyse systématique des objets).

Pourquoi le premier index n'est-il pas "correct" ?

[LeoAnderson]

sans code ni explain plan, il va être difficile de répondre

[orafrance]

Petit détail : à aucun moment, je n'ai analysé la table ou l'index.
Je ne souhaite pas faire d'analyse des objets (je suis dans le cadre d'une étude qui cherche à valider l'intérêt d'une analyse systématique des objets).

donc tu es en mode RULE donc l'ordre des tables et des colonnes est important... évidemment ce genre de pratique est à proscrire, Oracle n'appréciant guère le mélange avec et sans stats

[Robinson8171]

donc tu es en mode RULE donc l'ordre des tables et des colonnes est important... évidemment ce genre de pratique est à proscrire, Oracle n'appréciant guère le mélange avec et sans stats

Non, je suis en mode CHOOSE et je travaille SANS aucune analyse.

[orafrance]

donc tu es en RULE

pas de stats = RBO... si ton appli n'impose pas ce mode c'est une très mauvaise idée

[mnitu]

donc tu es en RULE

pas de stats = RBO... si ton appli n'impose pas ce mode c'est une très mauvaise idée

En 9I je ne pense pas que c'est vrai
Comment faites-vous pour savoir que votre requête ne prends pas l'index ?

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
 
SQL> alter session set optimizer_mode=CHOOSE;
 
Session modifiée.
 
SQL> set autotrace traceonly explain
SQL> create table titi as select * from big_table;
 
Table créée.
 
SQL> create index ix_titi on titi (owner, object_name);
 
Index créé.
 
SQL> select * from titi where owner='MNI';
 
Plan d'exécution
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'TITI'
   2    1     INDEX (RANGE SCAN) OF 'IX_TITI' (NON-UNIQUE)
 
 
 
SQL>

[mnitu]

En 9I je ne pense pas que c'est vrai
Non mais quelle connerie j'ai dit

CHOOSE
The optimizer chooses between a cost-based approach and a rule-based approach, depending on whether statistics are available. This is the default value.

If the data dictionary contains statistics for at least one of the accessed tables, then the optimizer uses a cost-based approach and optimizes with a goal of best throughput.
If the data dictionary contains only some statistics, then the cost-based approach is still used, but the optimizer must guess the statistics for the subjects without any statistics. This can result in suboptimal execution plans.
If the data dictionary contains no statistics for any of the accessed tables, then the optimizer uses a rule-based approach.

[orafrance]

En 9I je ne pense pas que c'est vrai

Je ne raconte pas toujours n'importe quoi

http://download.oracle.com/docs/cd/B...mops.htm#38218

CHOOSE


The optimizer chooses between a cost-based approach and a rule-based approach, depending on whether statistics are available. This is the default value.

* If the data dictionary contains statistics for at least one of the accessed tables, then the optimizer uses a cost-based approach and optimizes with a goal of best throughput.
* If the data dictionary contains only some statistics, then the cost-based approach is still used, but the optimizer must guess the statistics for the subjects without any statistics. This can result in suboptimal execution plans.
* If the data dictionary contains no statistics for any of the accessed tables, then the optimizer uses a rule-based approach.

CHOOSE sans stats = RULE... sauf éventuellement avec l'autosampling mais j'en suis même pas sûr

Edit : argh... grillé

[Robinson8171]

Je vois ce que tu veux me dire, mais j'ai (pardon) un peu de mal à tout saisir.
Lorsque j'exécute ma requête (select en jointure que ma table et sur une autre de 15 millions de lignes), j'ai le plan d'exécution suivant :
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop

SELECT STATEMENT Optimizer Mode=CHOOSE 522 K 13391
SORT ORDER BY 522 K 42 M 13391
MERGE JOIN 522 K 42 M 6320
SORT JOIN 14 M 576 M 42
PARTITION RANGE ALL 1 17
INDEX FULL SCAN HB_ETOIL_IN.IX_DWR_F_ELM_PASSAGE_TP_PK 14 M 576 M 42 1 17
SORT JOIN 840 K 34 M 6278
TABLE ACCESS FULL HB_ETOIL_IN.TT_F_ELM_PASSAGE_TP 840 K 34 M 2

La table incriminée est TT_F_ELM_PASSAGE_TP (1 millions de lignes).

L'explain plan indique bien que le mode est CHOOSE... d'où mon incompréhension