Discussion :

[orafrance]

Donc, maintenant, pour revenir au sujet, que faire pour voir le plan d'exécution (je n'ai pas tous les outils Oracle sur ma machine, seulement SQL plus worksheet et DBA Studio.

merci d'utiliser la recherche sur le site... SQL*Plus suffit

[nuke_y]

Sous SQL*Plus :

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
set echo off 
set pagesize 1000 
set feedback off 
set lines 15000 
col OPERATION format A45 
col TYPE_ACCES format A20 
col NOM_OBJET format A30 
col ORDRE format A8 
col ETAT format A20 
delete from plan_table where statement_id = 'X'; 
explain plan 
set statement_id = 'X' 
into plan_table for 
SELECT 1 FROM DUAL;
select LPAD(' ',2*(LEVEL-1))||operation      "OPERATION", 
   options               "TYPE_ACCES", 
   DECODE(TO_CHAR(id),'0','COST= '|| NVL(TO_CHAR(position),'Indefini'), object_name) "NOM_OBJET", 
   id || '-' || NVL(parent_id,0) || '-' || NVL(position,0)   "ORDRE", 
   ' COUT=' || COST ||','||'Card=' || CARDINALITY "Cout Op" 
From plan_table 
start with id = 0 
and statement_id = 'X' 
connect by prior id = parent_id 
and statement_id = 'X';

Et tu remplaces

Code :

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

SELECT 1 FROM DUAL;

Par ton code à toi

[remi4444]

La première chose à faire avant toute réécritrure est de passer les stats.

Code :

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

1
2
3
BEGIN
DBMS_STATS.GATHER_SCHEMA_STATS('ton_schema');
END;

Si ça n'a pas résolu, est-ce que tu peux donner la requête complète qui te pose un problème, avec en gros la volumétrie de toutes les tables impliquées ?

[nuke_y]

Oui alors les stats faut pas non plus se jeter dessus sans reflechir. Parce que SI l'application a été développée sans aucune stat, le fait d'en mettre risque de tout chambouler -> effets de bords catastrophiques.

Et je sais de quoi je parle, c'est du vécu...


Après je suis d'accord qu'il faudrait TOUJOURS passer les stats, et ce dès la phase de développement (et en tenir compte à la conception).

[Oz-WereWolf]

Ah.

Je ne pensais pas que mettre les stats en place maintenant pouvait causer des problèmes !

En effet, c'est à considérer.

J'essaierai de tester ça en local avant tout !

[remi4444]

Oui alors les stats faut pas non plus se jeter dessus sans reflechir. Parce que SI l'application a été développée sans aucune stat, le fait d'en mettre risque de tout chambouler -> effets de bords catastrophiques.

Et je sais de quoi je parle, c'est du vécu...


Après je suis d'accord qu'il faudrait TOUJOURS passer les stats, et ce dès la phase de développement (et en tenir compte à la conception).

Certes... mais statistiquement , il y a quand même plus à espérer d'améliorations que de dégradations, mais tout ce teste évidemment...
Lorsque ces effets de bords se produisent, il vaut mieux plutôt pousser les stats plus loin en mettant de histogrammes sur les colonnes date et les colonnes où les données ont une répartition très hétérogène (Exemple: Des 0 sur les 3/4 des lignes et d'autre valeurs très distinctes sur le quart restant)

[nuke_y]

C'est vrai. Statistiquement j'ai 9 requêtes sur 10 qui se sont améliorées et 1 sur 10 qui m'a sauté à la tronche.

M'enfin ça fait toujours bizarre

Et pour les histogrammes, j'ai toujours pas pu en discuter avec mon DBA, faudra que je le fasse.

[orafrance]

attention aux histogrammes :

1°) ne pas les faire sur toutes les colonnes (sinon gare au temps d'analyse)
2°) c'est source de bug

[remi4444]

bon, laissez le quand meme tester avec de simples stats avant de lui faire peur comme ça...

[Oz-WereWolf]

Trop tard, je suis pétrifié !

[nuke_y]

attention aux histogrammes :

1°) ne pas les faire sur toutes les colonnes (sinon gare au temps d'analyse)
2°) c'est source de bug

De bug ?? De VRAI bug ? Du genre que ça sort une valeur au lieu d'une autre ?

[remi4444]

De bug ?? De VRAI bug ? Du genre que ça sort une valeur au lieu d'une autre ?

Et aller!... vous allez finir par me détruire toute crédibilité, depuis le temps que je millite pour les passages de stats dans toutes les boites ou j'interviens...

[nuke_y]

Promis si les histogrammes améliorent les choses chez nous je viendrais te poster un bisou

[orafrance]

De bug ?? De VRAI bug ? Du genre que ça sort une valeur au lieu d'une autre ?

ben ora-600 il me semble ou problème de perf voir mauvais résultat... à confirmer avec Metalink évidemment

Remi le calcul des stats c'est en général très bon mais gare au paramètre d'estimate et aux colonnes choisies dans les histos

[Yorglaa]

Bonsoir,
j'arrive un peu tard dans le débat, mais concernant le problème de base :

Code :

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

1
2
WHERE date_debut <= SYSDATE()
AND (date_fin IS NULL OR date_fin >= SYSDATE())

j'essayerais ceci :

Code :

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

1
2
WHERE date_debut <= SYSDATE
AND NVL(date_fin, SYSDATE) >= SYSDATE

[Oz-WereWolf]

La fonction NVL est interressante.

Je vais chercher pour voir si je peux l'utiliser via Hibernate.

[remi4444]

mais pourquoi tu veux pas donner l'ensemble de ta requête ???
Tant que tu te focalise sur ce point de détail, j'ai peur que tu passes à coté de l'essentiel...

[Oz-WereWolf]

La requête fait partie du code source de mon entreprise.

J'ai déjà modifié les noms de table et de champ pour qu'ils ne puissent rien me reprocher.

Je bosse dans un environnement où les sensibilités sont tellement exacerbées que s'ils aprennent que je balance leurs sources sur le net, je vais me faire lyncher.

Je sais, c'est nul et stupide mais le choix ne m'appartient pas.

Je verrai demain en cours d'après midi si je peux chopper la requête pour la "reformater" et la diffuser.

Le second souci est que le domaine de gestion qui utilise cette requête est relativement touffu et que je ne me sens pas de vous pondre 4 pages de règles de gestion pour expliquer pourquoi et comment la requête a été faite comme ça ou ce que contiennent les différentes tables et pourquoi.

J'essaierai de résumer ça demain, mais c'est pas gagné.

[remi4444]

ok... si je te dis ça, c'est parcequ'à mon avis la clause sur les dates que tu as au départ est tout à fait correcte.
A priori, je la préfère au nvl et autres astuces. D'autre part le fait qu'elle filtre 3000 lignes sur 8000 montre qu'en soit, il n'y a rien à améliorer de ce coté là car ramener 3000 trucs sur 8000 machins ne te prendras pas plus qu'une demi seconde. Si en mettant un nvl, ou en remplissant les null améliore les temps, alors c'est qu'il y a un effet de bord sur le plan d'exécution global. Ca veux donc dire que l'optimiseur est dans un état de choix instable, en gros qu'il hésite entre plusieurs "mauvaises solutions". En ne te focalisant que sur cette clause que tu as posté tu ne fais que donner un petit coup de pouce au hasard d'un coté ou de l'autre des choix de l'optimiseur mais sans avoir compris la cause réelle de cette instabilité qui est le vrai problème. Donc ce qui risque de se produire, c'est qu'aujourd'hui tu fasses une bidouille qui influence l'optimiseur dans un sens, mais cette meme bidouille peut tres bien s'avérer pénalisante plus tard (ex: en faisant porter une clause sur un calcul de colonne, on s'interdit le passage par index). Toute la problématique se trouve dans le choix du plan d'exécution que fait oracle, et ce choix dépends de toutes les forces en présences (volumetrie des tables, index, stats sur la selectivité des colonnes etc...). C'est pourquoi la seule action "générale" qu'on peut te conseiller est le passage de stats (car les stats sont un élément essentiel pour le choix de l'optimiseur). Mais pour ce qui est du conseil sur l'utilisation de tes comparaisons de dates, on n'aura aucune valeur ajoutée par rapport à tes tests empiriques.

[Oz-WereWolf]

Bon, alors, voici la requête complète après avoir changé quelques noms ( ).

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
select distinct immat.IMM_NUM as col_0_0_,
		      immat.IMM_DAT_DEPART as col_1_0_,
		      immat.IMM_ID as col_2_0_,
		      etatcivilp1_.ETC_NOMUSU as col_3_0_,
		      etatcivilp1_.ETC_NOMPAT as col_4_0_,
		      etatcivilp1_.ETC_PSEUDO as col_5_0_,
		      etatcivilp1_.ETC_PRENOM as col_6_0_,
		      etatcivilp1_.ETC_DAT_NAISSANCE as col_7_0_
from IM_IMMATRICULATION immat,
	EC_ETATCIVIL etatcivilp1_,
	IM_SERVICE immservi2_
where immat.ETC_ID=etatcivilp1_.ETC_ID
and immat.ETS_COD='LYON'
and immat.IMM_NUM='100755'
and (immat.IMM_DAT_DEPART is null or immat.IMM_DAT_DEPART>=SYSDATE)
and immservi2_.IMS_FLG_NEUTRE=0
and immservi2_.IMM_ID=immat.IMM_ID
and immservi2_.ETS_COD=immat.ETS_COD
order by immat.IMM_NUM asc

Les indexes :
IM_IMMATRICULATION : 4 indexes dont :
i_01 : IMM_NUM
i_02 : ETS_COD, IMM_NUM
i_04 : ETS_COD, IMM_DAT_DEPART

IM_SERVICE : 4 indexes dont :
i_03 : IMM_ID, IMS_FLG_NEUTRE, IMS_DAT_DEBUT

La volumétrie :
IM IMMATRICULATION : 8000 enregistrements
IM_SERVICE : plus de 20 000 enregistrements.
EC_ETATCIVIL : autour de 8000 enregistrements aussi.

Le domaine d'application :
La table IM_IMMATRICULATION regroupe les immatriculations de personnes travaillant dans un groupe ainsi que les données relatives à ce groupe (de départ, matricule, etc...). Cette table contient un champ ETS_COD qui correspond à l'établissement auquel est rattaché la personne
La table EC_ETATCIVIL contient l'état civil des personnes. Elle a été mise à part car une même personne peut être à la fois référencée dans la table des immatriculations et d'autres. D'autres personnes ne seront pas dans les immatriculations. Certaines auront deux immatriculations distinctes dans deux établissements différents.
La table IM_SERVICE donne l'historique des services auquel sont, ont été ou seront rattaché les personnes (via leur immatriculation).

Voilà.

Est-ce plus parlant ?