Discussion :

[Thomf]

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

[Pomalaix]

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 ?

[Thomf]

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.

[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 ?

[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.

[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 ?

[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 ?

[Thomf]

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.

[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.

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

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 ?

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

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

[orafrance]

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

[Thomf]

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

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

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.

[Thomf]

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

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

[orafrance]

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

C'est faux

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

Avoir plusieurs solutions c'est bien... mais si t'as pas UN problème c'est inutile

[orafrance]

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

[Thomf]

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.