Problème de TABLE ACCESS FULL

**elitost** · 24/09/2004, 09h01

Bonjour,

Je dois effectuer un update sur une table , et cet update est un update avec jointure, mais les temps de traitements sont super longs et je me pose des question, notamment sur ce bout de requete qui participe à la mise à jour :

Code :

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

1
2
3
4
5
6
7
8
SELECT   MAX (TO_NUMBER (fait_meteo.fm_heure)) fm_heure,
         dim_station_meteo.gm_code_gdf,
         dw.fait_meteo.dt_id
    FROM dw.fait_meteo, dw.dim_station_meteo
   WHERE ((dim_station_meteo.gm_id = fait_meteo.gm_id))
     AND dim_station_meteo.gm_code_gdf = 95
     AND fait_meteo.dt_id = 1340
GROUP BY dim_station_meteo.gm_code_gdf, dw.fait_meteo.dt_id

J'ai volontairement filtré sur une date ( le 1340 ) et un code ( le 95 ).
Quand je regarde l'explain plan j'ai :

Code :

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

1
2
3
4
5
6
7
Operation	Object Name	Rows	Bytes	Cost	Object Node	In/Out	PStart	PStop
 
SELECT STATEMENT Optimizer Mode=CHOOSE		1  	 	7  	 	      	             	 
  SORT GROUP BY NOSORT		1  	90  	7  	 	      	             	 
    NESTED LOOPS		5  	450  	7  	 	      	             	 
      TABLE ACCESS FULL	DW.DIM_STATION_METEO	1  	42  	1  	 	      	             	 
      INDEX RANGE SCAN	DW.FAIT_METEO_IN	146  	6 K	6

On voit un TABLE ACCESS FULL, sachant que dans les indexes je n'ai que des PK sur fait_meteo.gm_id et dw.fait_meteo.fm_id ( pas de FK sur le gm_id, ni rien d'autre ) je me demande si il est normal d'avoir ce TABLE ACCESS FULL ?

Comment remédier à ce TABLE ACCESS FULL ?

Merci d'avance,

**orafrance** · 24/09/2004, 09h27

un index sur gm_code_gdf sera peut-être intéressant

**elitost** · 24/09/2004, 10h50

Et je peux poser un index sur la table, juste le temps de mon traitement et le retirer ensuite sans dommage pour les données ?

**orafrance** · 24/09/2004, 11h08

aucun intérêt de faire ça puisque la création d'un index est une phase très pénalisante pour les perfs

**SheikYerbouti** · 24/09/2004, 11h34

C'est le principe du NESTED LOOP que de fonctionner avec une boucle sur un FULL TABLE SCAN

**elitost** · 24/09/2004, 13h40

la création d'un index est une phase très pénalisante pour les perfs

Pourquoi donc ?

C'est le principe du NESTED LOOP que de fonctionner avec une boucle sur un FULL TABLE SCAN

Peut tu être plus explicite ?

Merci d'avance

**SheikYerbouti** · 24/09/2004, 13h46

Lorsque 2 tables sont jointe par NESTED LOOP, il y en a donc une qui boucle sur une autre. Le principe est donc de faire une TABLE ACCESS FULL sur l'une, et le résultat (chaque ligne) sert à parcourir l'autre (par INDEX SCAN).

Le but consiste à boucler sur la plus petite table.

Mais d'une façon générale, il faut arrêter d'envoyer le FULL TABLE SCAN au bûcher systématiquement. Il existe des tas de cas de figure ou Oracle détermine (souvent à raison) qu'il est moins goumand de faire une TABLE ACCESS FULL qu'un passage par le ou les indexes.

**orafrance** · 24/09/2004, 13h50

Envoyé par elitost

la création d'un index est une phase très pénalisante pour les perfs

Pourquoi donc ?

Parce qu'Oracle est obligé de parcourir toute la table pour écrire l'index, c'est donc complétement absurde de faire cette opération pour éviter un full scan

**elitost** · 24/09/2004, 17h29

Mais, est il possible de :
1) Créer le ou les indexes sur la table ( même si ça prend du temps )
2) Executer ma requete dans un contexte amélioré ( par le ou les indexes )
3) Supprimer le ou les indexes et le tout sans altérations pour les données de la ou les table(s) impactée(s) ????

Le but consiste à boucler sur la plus petite table.

Cela sous entend il qu'il faut optimiser ses requêtes dans leur ecriture ? Comme par exemple dans les jointures, placer la plus petite table avant l'autre ?

Remerci d'avance

**Yorglaa** · 24/09/2004, 19h00

Envoyé par elitost

Cela sous entend il qu'il faut optimiser ses requêtes dans leur ecriture ? Comme par exemple dans les jointures, placer la plus petite table avant l'autre ?

tout dépend du mode d'optimisation utilisé par ta base de données... si elle est en mode RULE alors oui tu dois optimiser l'écriture de la requête, en mode CHOOSE, l'optimiseur s'en sort (devrait s'en sortir) tout seul...

mais au vu de ton premier Post, ta base est en mode CHOOSE...

**elitost** · 24/09/2004, 19h30

Comment savoir en quel mode est ma base ?

**Yorglaa** · 24/09/2004, 22h44

c'est marqué sur l'explain plan que tu as mis sur ton premier Post...

Code :

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

SELECT STATEMENT Optimizer Mode=CHOOSE

sinon ça doit être visible dans une vue système, mais je ne sais plus laquelle et je ne peux pas tester pour le moment... désolé...

mais il me semble que ça doit être v$instance ou bien v$database (à vérifier)

**elitost** · 25/09/2004, 11h05

ok, merci.

Donc si j'ai bien compris, on peut forcer une optimisation, mais si on choisit la mauvaise on peut plomber la requête ?

**Yorglaa** · 25/09/2004, 12h24

exact...
mais tu as le choix de spécifier le mode d'optimisation pour toute la base dans le fichier init.ora, paramètre

Code :

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

OPTIMIZER_MODE=CHOOSE ou RULE

et s'il n'est pas renseigné explicitement alors ta base est en mode CHOOSE.

l'autre solution consiste à laisser ta base dans un mode spécifique mais à "forcer" certaines requêtes à utiliser l'autre mode, pour le cas où elles auraient été écrites spécifiquement pour l'autre mode... tu peux faire ça avec les hints

Code :

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