Améliorer les indexes

Version imprimable

20/05/2009, 13h45
Thomf

Améliorer les indexes

Bonjour,

J'ai 2 tables identiques sous oracle 8 (bientot 10i) et j'ai amélioré les indexes comme ci-joint mais ça n'a rien fait de plus. Si l'amélioration n'apporte rien, faut-il voir du côté de l'applicatif sachant que les tables ne sont pas énormes (8.000 et 30.000 enregistrements). A noter que l'applicatif comporte beaucoup de triggers dont je suppose l'inutilité de certaines jointures.

Dans mon cas, j'ai juste augmenté l'initial de 160 à 450k et le next de 8 à 64k.
Est-ce la bonne démarche ?

Le problème est que je peux moins agir sur l'applicatif que sur la table.

Merci d'avance
20/05/2009, 13h58
Pomalaix

Citation:

Envoyé par Thomf

Est-ce la bonne démarche ?

Difficile de juger de la réponse quand on ne connaît pas la question !
Quel est votre problème ? Que cherchez-vous à faire ?
20/05/2009, 14h45
Thomf

Citation:

Envoyé par Pomalaix

Difficile de juger de la réponse quand on ne connaît pas la question !
Quel est votre problème ? Que cherchez-vous à faire ?

Pour être plus précis:

Avant l'initial était à 160k et ça ramait pas mal quand il s'agissait d'avoir une réponse sur une saisie d'un champ par l'utilisateur. Presque 30 secondes parfois. J'ai augmenté l'initial à 450k sur un indexe unique ainsi que sur d'autres indexes ou je passais de 360 à 750 soit le double de taille. Or le résultat est quasiment le même. Aussi, sans avoir à toucher l'applicatif, comment pourrait je faire pour améliorer la performance de mes indexes ?
Dois-je augmenter le maxextents également pour se faire ou bien faut-il que j'y mette la sauce en passant mon indexe principal de 450 à 2M ?

Merci d'avance.
20/05/2009, 15h00
orafrance

la taille du initial n'a que très peu d'incidence sur les perfs surtout si les blocks lu sont dans les extents suivants.

M'est avis que tu n'as absolument rien compris à la signification de ces paramètres : http://oracle.developpez.com/guide/a...lespaces/#L1.2

Qu'est-ce qui te dis que le problème vient du stockage de l'index et pas de sa définition ou même de la requête ?
20/05/2009, 15h09
Pomalaix

Ma voiture fait du bruit en roulant.
J'ai mis des coups de marteau sur le pot d'échappement mais ça n'a pas l'air d'améliorer grand chose.
Et pour cause, le sifflement vient simplement de la vitre mal fermée.

Commencez par un diagnostic pour essayer de savoir d'où proviennent vos lenteurs.
Pour ça il faut nous fournir votre requête ainsi que son plan d'exécution.
20/05/2009, 15h16
13thFloor

La modification du stockage des index n'aurait de sens que si des buffer busy waits étaient constatés sur les segments d'index.
Tes problèmes de performances doivent venir d'ailleurs : applicatif (requête), statistiques (version 8 !!).

Si réellement les index sont en cause, tu peux toujours :
- les rebuilder pour gagner très légèrement en IO lors des scan
- les recréer en reverse (pas sur que ce soit possible en 8.0) s'il y a contention

Mais face à une mauvaise sélectivité d'un index, rend-le unusable pour vérifier la pertinence d'un full table scan ou l'utilisation d'un autre index.

Est-ce un select ou une mise à jour (update/delete) qui pose problème ?
Que fait la requête : accès par index ou autre ?
20/05/2009, 15h30
Thomf

A Pomaleix et Orafrance,

Concernant nos tablespaces ils sont bien divisés, l'un pour les données, l'autre pour les indexes. Là dessus pas de problème. Je peux également mettre mes indexes dans un des tablespaces qui soit moins occupé au niveau taille car nous avons 2 tablespaces d'indexes dont l'un est plein au 3/4 et l'autre à 50% seulement.
Quand aux extents je ne les augmente en général quand il y a l'anomalie oracle appropriée, pas avant.
Pour ce qui est de la requête je sais qu'en suprimmant une table inutile, ça me ferait gagner énormement en performance mais pour ça je dois attendre un feu vert avant de toucher quoique que ce soit.
Sinon j'avais idée d'exporter la table, de la droper et de la réimporter, qu'en pensez-vous ?
20/05/2009, 15h35
Thomf

Citation:

Envoyé par 13thFloor

La modification du stockage des index n'aurait de sens que si des buffer busy waits étaient constatés sur les segments d'index.
Tes problèmes de performances doivent venir d'ailleurs : applicatif (requête), statistiques (version 8 !!).

Si réellement les index sont en cause, tu peux toujours :
- les rebuilder pour gagner très légèrement en IO lors des scan
- les recréer en reverse (pas sur que ce soit possible en 8.0) s'il y a contention

Mais face à une mauvaise sélectivité d'un index, rend-le unusable pour vérifier la pertinence d'un full table scan ou l'utilisation d'un autre index.

Est-ce un select ou une mise à jour (update/delete) qui pose problème ?
Que fait la requête : accès par index ou autre ?

13thFloor,

Je suis en oracle 8 donc je ne peux agir de la façon reverse.

Le problème se pose juste suite à un select (plusieurs triggers de controle). Pas de problème sur les autres applications mais uniquement sur celle-ci ce qui me conforte dans l'idée de l'alléger un maximum.
20/05/2009, 15h36
orafrance

Citation:

Envoyé par Thomf

Concernant nos tablespaces ils sont bien divisés, l'un pour les données, l'autre pour les indexes. Là dessus pas de problème.

C'est pas plus un problème de ne pas les séparer :mrgreen:

Citation:

Envoyé par Thomf

Je peux également mettre mes indexes dans un des tablespaces qui soit moins occupé au niveau taille car nous avons 2 tablespaces d'indexes dont l'un est plein au 3/4 et l'autre à 50% seulement.

Est-ce à dire que tu penses que les performances sont meilleures quand le tablespace est moins remplie ? 8O

Citation:

Envoyé par Thomf

Sinon j'avais idée d'exporter la table, de la droper et de la réimporter, qu'en pensez-vous ?

Ca peut marcher (c'est ce qu'on appelle une réorganisation)... ou pas :mouarf:

Il n'y a pas de magie... soit tu trouves la source du problème et applique la solution ad hoc, soit tu cherches dans tous les sens et tu risques fort de t'épuiser avant de trouver la bonne solution :?
20/05/2009, 15h38
orafrance

Citation:

Envoyé par Thomf

Le problème se pose juste suite à un select (plusieurs triggers de controle).

Il n'y a pas de trigger qui se déclenche sur SELECT :aie:
20/05/2009, 15h52
Thomf

Citation:

Envoyé par orafrance

Est-ce à dire que tu penses que les performances sont meilleures quand le tablespace est moins remplie ? 8O

Oui je le pense mais je n'ai jamais essayé.

Citation:

Envoyé par orafrance

Il n'y a pas de magie... soit tu trouves la source du problème et applique la solution ad hoc, soit tu cherches dans tous les sens et tu risques fort de t'épuiser avant de trouver la bonne solution :?

J'essaye de me faire une idée d'après plusieurs solutions possibles mais rassures-toi je ne tourne pas en rond. :roll:
20/05/2009, 15h53
Thomf

Citation:

Envoyé par orafrance

Il n'y a pas de trigger qui se déclenche sur SELECT :aie:

L'inverse, excuses-moi: un trigger contenant un ou plusieurs select (tout le monde peut se tromper).
20/05/2009, 16h00
orafrance

Citation:

Envoyé par Thomf

Oui je le pense mais je n'ai jamais essayé.

C'est faux :mrgreen:

Citation:

Envoyé par Thomf

J'essaye de me faire une idée d'après plusieurs solutions possibles mais rassures-toi je ne tourne pas en rond. :roll:

Avoir plusieurs solutions c'est bien... mais si t'as pas UN problème c'est inutile :mouarf:
20/05/2009, 16h00
orafrance

Citation:

Envoyé par Thomf

L'inverse, excuses-moi: un trigger contenant un ou plusieurs select (tout le monde peut se tromper).

Ca n'a donc aucune incidence sur les performances d'un SELECT sur la table... CQFD ;)
20/05/2009, 16h18
Thomf

Citation:

Envoyé par orafrance

Ca n'a donc aucune incidence sur les performances d'un SELECT sur la table... CQFD ;)

Quand je parlais de triggers de controle je voulais dire autant de select à l'interieur de chaque trigger pour le même champ.
En espérant avoir résolu ce petit problème à mon retour de vacances après avoir modifié le select défaillant dans l'applicatif. :merci: