Discussion :

[hkhan]

Bonjour !
La base (9i en test et 8.1.7 en prod pour le moment) sur laquelle je travaille a été développée en externe, et je voudrais voir quels index sont utilisés, mais surtout, en faire le compte

j'ai mis :

Code :

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

Alter index NOMINDEX  monitoring usage ;

sur chacun de mes index. (et apres la table object_usage est mise à jour quand un index est utilisé)

Pour le compte du nb d'utilistion des index, le pb est soulevé plusieurs fois dans le forum, mais pas de solutions

Donc j'en cherche une :p
J'ai essayé d'appliquer un trigger sur la table sys.object_usage sur l'update de la colonne FLAGS. Mais on ne peut pas appliquer de triggers sur une table system (pas taper suis débutant :p).

Je pense Activer/désactiver le Monitoring Usage sur les index toutes les X min/heures.... (et ainsi remettre FLAGS à 0)... mais ca me parait pas génial


quelqu'un a t'il une meilleure idée ? une autre solution, sachant que ce qui m'interesse c'est de compter les index


D'avance merci :p

[SheikYerbouti]

Une façon pragmatique de lister les indexes est d'interroger la vue DBA_INDEXES.

Concernant le monitoring, il va de soi que vous devez avoir l'assurance que l'intégralité des ordres SQL de votre application a bien été exécutée pendant la période de traçage.

[hkhan]

Une façon pragmatique de lister les indexes est d'interroger la vue DBA_INDEXES.

Oups
je me suis mal exprimé dans ma dernière phrase je voulais écrire :

sachant que ce qui m'interesse c'est de compter le nb d'utilisation des index

Sinon, ce que je comptais faire :
1- creer une table perso qui contiendra 2 colonnes : le nom des index et une autre colonne : Compteur (à 0 au départ)
2- lancer le monitoring sur tous les index pendant un certain temps (pas encore déterminé).
3- à la fin de laps de temps, parcourir ma table sys.object_usage sur la colonne FLAGS (1 ligne avec la valeur 1, correspond à un index utilisé au moins une fois (et c'est ce Au Moins qui me gène)).
4- stopper le monitoring
5- mettre à jour la table perso sur les index avec la valeur 1 dans la colonen FLAGS de la table object_usage (par un incrément de la colonne Compteur).
6- relancer le monitoring (donc mise à 0 des colonnes FLAGS de la table object_usage)
7- retour à l'étape 3 et ainsi de suite


2 gros pb :
- dans mon fameux laps de temps, je sais pas si un index a été utilisé x fois, la colonne FLAGS de la table object_usage se met à jour à la 1ère utilisation de l'index
- à mon avis spas top pour les perf de tracer de cette façon :p

voila, j'espère avoir été plus clair, donc si qlq un a une meilleure solution à me communiquer...

[SheikYerbouti]

Quel est le réel interêt intrinsèque de savoir COMBIEN de fois un index est utilisé ?

Le fait de savoir s'il est ou n'est pas utilisé ne suffit pas ?

[hkhan]

si sur une période de trace d'une semaine, mon index est utilisé qu'une seule fois, peut etre est il inutile (je dis peut etre :p)

Mais peut être que je me trompe c'est juste une information que je voulais connaitre

Mais vous avez raison, déjà de savoir qu'un index n'est pas du tout utilisé c'est pas mal

[thomasjcj]

Pourquoi as tu besoin de savoir combien de fois un index est utilisé?
L'essentiel a mon avis c'est surtout de savoir ceux qui ne sont pas utilisés et dans ce cas la vue V$OBJECT_USAGE rempli bien son role.
Un index s'il est utilisé, meme rarement (et la tout depend des requetes, leurs frequence...) est justifé non ?

Ok on s'est croise, au moins on est d'accord avec sheik...

[Yorglaa]

bonjour,
puisqu'on parle de ça je saisis la balle au bond...

est-ce que l'usage du monitoring via

Code :

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

alter table/index monitoring usage;

est lourd en terme de performances ?

[orafrance]

lourd non, mais forcément impactant... comme les traces

[Pomalaix]

Tout ce qu'on peut faire avec le MONITORING USAGE, c'est dire : j'ai utilisé cet index au moins une fois, je le garde, sinon je le vire.
Ce faisant, on risque de conserver des index dont l'utilisation est très marginale, et qui impactent négativement les performances.

Si par exemple on a 3 index sur la table des factures, un sur le code client, un sur la date et un sur le montant, et qu'on se rend compte qu'en une semaine, on utilisé l'index sur le code client 1000 fois et celui sur le montant 3 fois, on peut en conclure que l'utilisation de l'index sur le montant est exceptionnelle, et qu'il vaut peut-être mieux le supprimer.

Pour moi, il y a un véritable besoin d'une information quantitative sur l'usage des index, que le MONITORING USAGE est effectivement incapable de fournir.

[LeoAnderson]

A mon humble avis, il est préférable de faire une première passe afin de déterminer les indexes qui ne sont JAMAIS utilisés.

Et une fois le "gros oeuvre" fait, on peut envisager les finitions avec l'aspect quantitatif de l'utilisation de tel ou tel index !

[lalystar]

Attention,

Je me place dans le cas d'Oracle 8i, sous 9i il doit y avoir le même genre de pb mais dans une moindre mesure.

Certains indexes peuvent avoir été posés non pour optimiser des jointures mais pour éviter de bloquer des sessions.

Quand on a une table enfant qui référence une table parent et que la clé étrangère n'est pas indexée dans la table enfant car on ne fait jamais de jointure entre ces deux tables (par ex. on a une table de nomenclature SEXE(sexe_id, sexe_lib)), dans ce cas la suppression d'une ligne dans la table parent ou la modification de la clé primaire dans la table parent pose un verrou (je ne sais plus de quel type) sur la table enfant, ce qui fait qu'une session peut se retrouver bloquée voire deux sessions faire un deadlock.

Code :

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

1
2
3
4
5
6
7
8
9
10
 
create table sexe(sexe_id char(1), sexe_lib varchar2(20));
insert into sexe values('M', 'Masculin');
insert into sexe values('F', 'Feminin');
insert into sexe values('?', 'Inconnu');
alter table sexe add constraint pk_sexe primary key (sexe_id);
create table pers (nom varchar2(20), sexe_id char(1) references sexe);
insert into pers values('ALPHA', 'M');
insert into pers values('BETA', 'F');
commit;

Maintenant dans la première session, on supprime une ligne de la table parent qui est SEXE :

Code :

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

1
2
 
delete sexe where sexe_id = '?';

Et dans une deuxième session on essaie de modifier une ligne de la table enfant :

Code :

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

1
2
 
update PERS set nom = nom || '_';

La deuxième session est bloquée.

Sous Oracle 8i le verrou sur la table enfant dure jusqu'à la fin de la transaction tandis que sous Oracle 9i il dure le temps de l'update/delete sur la table parent.

Moralité : même si un index n'est pas utilisé, ca ne veut pas dire qu'il est inutile.

Laly.

Cf.
http://osi.oracle.com/~tkyte/unindex/index.html

[/code]

[rouardg]

Pour information, le monitoring d'index semble à première vue une fonctionnalité intéressante à mettre en oeuvre pour savoir si un index a été utilisé ou non.

Par contre, méfiance. En effet, il faut savoir qu'il n'y a pas que l'utilisation d'un index au sein d'une requête SQL qui bascule le flag USED à YES dans la vue V$OBJECT_USAGE.

Il y a aussi toutes les opérations de "maintenance", comme déplacer un index, le reconstruire ou lancer les statistiques via le package DBMS_STATS...

Donc pour utiliser le monitoring, essayer de le faire sur des plages où il n'y ait pas de telles opérations.