index ralentit requete

Bonjour a tous,

Structure de ma base :

3 tables :

client, prestataire, planning

2 jointures :

client <- planning (clé secondaire dans planning)

prestataire <- planning (clé secondaire dans planning)

champs table planning :

identifiant auto, heure debut, heure fin, date debut, date fin, lien prestataire, lien client

5 index :

lien prestataire
lien client
date debut
date fin
identifiant auto (index automatique sur la clé primaire)

requete de test et temps d'execution :

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006'; (environ 4 sec)

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006' order by planning identifiant; (environ 20 sec)

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006' order by [n'importe quel champs]; (environ 20 sec)

Si je supprime les 2 index sur date debut et date fin,
requete de test et temps d'execution :

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006'; (environ 4 sec)

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006' order by planning identifiant; (environ 4 sec)

select * from planning where date debut>='01/01/2006' and date fin<='31/12/2006' order by [n'importe quel champs]; (environ 4 sec)

A quoi ce problème de lenteur est-il du ?

Sachant que je ne peut pas supprimer les index sur les champs en questions car il me font réellement gagner du temps sur l'exectution de certaines editions et certaines requetes.

Que puis-je faire ?

D'avance merci.

Essaye de faire un explain plan pour comprendre la différence entre les 2 analyses (avec ou sans index).

De plus tu peux esssayé de spécifier par un hint la non utilisation des index

Code:

---

1 2	select /*+ NO_INDEX(<table_name> <index_name> <index_name>) */ * from ....

---

L'optimiseur fonctionne en mode cost ou rule ?

Salut,

Je ne connaissais pas la commande Explain plan, après quelques recherche j'ai trouvé comment l'utiliser.

Le résultat est assez étonnant.

Résultat de la requete "SELECT * from planning where date debut>='01/01/2006' and date fin<='12/31/2006' order by date identifiant auto;"

Code:

---

1 2 3 4 5

Résultat avec index : sel1 SELECT STATEMENT sel1 SORT ORDER BY sel1 TABLE ACCESS BY INDEX ROWID sel1 INDEX RANGE SCAN

---

Code:

---

1 2 3 4 5

Résultat sans index : sel2 SELECT STATEMENT sel2 TABLE ACCESS BY INDEX ROWID sel2 INDEX RANGE SCAN

---

Je suis surpris de voir qu'il n'y a pas d'étapes ORDER BY sans les index.

Je ne suis pas sur de comprendre le résultat et loin, très loin de voir ce que je pourrai faire pour résoudre le problème.

Quelqu'un peut m'aider grâce a ces résultats ?

Merci d'avance.

Merci d'utiliser les balises conformément aux régles du forum... là c'est illisible :?

Désolé c'est corrigé.

J'espère que cette fois c'est correct.

en effet, c'est étrange... c'est EXACTEMENT la même requête, tu es sûr ?

tu es dans quelle version ? Les stats sont calculées comment ? Quel est la valeur de SORT_AREA_SIZE ?

Je confirme c'est exactement la même requête.

La version d'oracle c'est de l'oracle 8.

Les stats c'est tout simplement le temps de réalisation de la requete données par mon requêteur. (Benthic Golden32) Avec des tests sur plusieurs machine.

Le SORT_AREA_SIZE a pour valeur 65536.

Je sais pas si ces infos t'aide a comprendre moi pas des masses je fais des allé retour sur le net et pour le moment rien. Je continu mes recherche et je reste preneur de toutes informations.

Merci beaucoup pour votre aide.

je parle des stats collectées par ANALYZE... à moins que optimizer_mode soit RULE.

optimizer_mode a pour valeur CHOOSE, ce qui me parait etrange puisque sur les site et livre que j'ai consulté normalement CHOOSE est réservé a la variable optimizer_goal. Je n'ai pas de champs optimizer_goal !

En ce qui concerne les stats pour ANALYZE, je ne connaissais pas ANALYZE.
Pour moi il n'y avait pas d'analyze effectuer sur cette base.
J'ai essayé d'en effectuer ce n'est pas concluant.

Je ne sais pas si mes réponses te fournissent des éléments, en tout cas encore merci pour ton aide.

Pour ma part je continu toujourrs mes recherche et test.

Si tu peux encore m'aider merci.

pour lancer les analyse sur une table :"table1" voici la commande

Code:

---

Analyze Table table1 Compute Statistics;

---

Tes plans d'exécutions n'ont pas l'air complet, en particulier il n'y a pas le nom des index sur lesquels portent les range-scan. Et franchement je reste perplexe quand à la non-présence de "SORT" dans le plan d'une requête de tri....

Il se peut fort bien que l'optimiseur choisisse de passer par l'index de la colonne date_debut par défaut parceque tu fais une clause where dessus alors que le critère que tu donnes ne soit pas discriminant du tout, il fait donc des acces à l'index pour rien.
En gros on compte que l'index est valable pour une requête quand le resultat obtenu ramène moins d'1/4 des données. Si le resultat ramène toute la table, le temps sera 4 fois plus long que de faire un acces "FULL"

Oracle n'étant pas au courant en temps réel de l'ensemble de la répartition des données (si ça se calculer de manière permanante, toutes les ressources seraient consacrées à ça...) il faut lui lancer manuellement une procédure pour analyser cette répartition de données. Pour ces problèmes de colonnes de dates (dont les valeurs évoluent dans le temps) il faut pousser l'analyse particulièrement et lui faire régulièrement mettre à jour un histogramme afin que l'optimiseur pré-juge de la pertinance de l'utilisation d'un index en fonction du critère.

Pour faire créer un histogramme sur toutes les colonnes indexées de ta table:

Code:

---

analyze table planning compute statistics for all indexed columns

---

Autre chose, si ta requête est destinée à ramener tous ses resultats d'un seul coup, alors utilise le HINT /*+ ALL_ROWS */

ex:

Code:

---

1 2 3

select /*+ ALL_ROWS */ * from planning where date debut>='01/01/2006' and date fin<='31/12/2006' order by planning identifiant;

---

Avant la réponde de remi4444, j'avais utilisé le code suivant :

Code:

---

1 2	analyze table *** compute statistics; analyze index *** compute statistics;

---

Pour les table et index concerné mais aucun résultat.

La j'ai utilisé ceci (le code fourni par remi4444) :

Code:

---

analyze table planning compute statistics for all indexed columns

---

Sur plusieurs tables concernées par ma requete (client...)

Le temps d'execution est toujours le meme. (lent)

Je ne comprend pas ce qui justifie une tel différence entre 2 bases ayant la meme structure, pourquoi sur cette base en particulier j'ai ce probleme franchement je suis dépassé.

Mrci de votre aide.
Franchement si quelqu'un a une idée je suis preneur.

Pour ma part je continu mes recherches aussi infructueuses soit-elle puisque je doit absolument trouver la solution.

Encore merci.

Citation:

---

Envoyé par Oraman

pour lancer les analyse sur une table :"table1" voici la commande

Code:

---

Analyze Table table1 Compute Statistics;

---

---

DBMS_STATS depuis la 8i ;)

Et ESTIMATE plutôt que COMPUTE peut suffire :)

Citation:

---

Envoyé par gg14bis

Je ne comprend pas ce qui justifie une tel différence entre 2 bases ayant la meme structure, pourquoi sur cette base en particulier j'ai ce probleme franchement je suis dépassé.

---

les paramétres et versions sont exactement identiques ?

Citation:

---

Envoyé par gg14bis

Je ne comprend pas ce qui justifie une tel différence entre 2 bases ayant la meme structure, pourquoi sur cette base en particulier j'ai ce probleme franchement je suis dépassé.

---

Les problèmes d'optimisations sont souvent très délicats et long à résoudre.
Tes 2 bases ont la même structure, mais ont-elles aussi les mêmes données ?

- Je persiste à te dire que les plans d'exécution que tu as donnés ne sont pas complets. Il manque la colonne ou on vois sur quels objets portent les étapes et en particulier le nom de l'index sur lequel portent les "range scan".

- Combien de lignes te ramène ta requête ?

- Avec quoi mesure-tu le temps d'éxécution ? (attention au temps indiqué par toad dans la barre d'état, il ne te donne le temps que des 20 1iere lignes ramenées dans sa grille...)

- Ce qui est important en plus du temps, c'est le nombre de lectures effectuées. Pour les voir apparaitre il faut faire "set autotrace on" dans un sqlplus ou l'onglet "auto trace" de toad. (attention le fait d'activer cette option ralenti le temps total de ta requête, faut pas s'affoler pour ça...)