Discussion :

[pinocchio]

Bonjour,
Afin d'essayer d'améliorer une bdd 9i, on m'a demandé d'analiser les stats des index.
J'ai donc récupéré les colonnes distinct_keys, lf_rows, Most_repeated_key, Rows_per_key, Blks_gets_per_access car suite à une recherche de doc, j'ai crû comprendre que c'était les plus importantes.
Le problème est que je ne sais pas trop quoi faire avec. Je ne suis pas apte à savoir si l'index est correct ou non. Dans quel cas le supprimé ou le modifier.
Pourriez-vous m'aider ou m'indiquer où trouver des infos pour cela.
Merci d'avance
ps : Les commandes utilisés on été :

Code :

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

1
2
3
 
analyze index <nom_index> validate structure;
select name,distinct_keys, lf_rows, Most_repeated_key, Rows_per_key, Blks_gets_per_access from index_stats;

[pinocchio]

par exmple, j'obtiens comme donnée :

TABLE Nom Nb de clés distinctes Nb Clés nb max répétition nb moyen répétition Nb blocs nécessaire
TA AFFIC_FK 1431 1541 5 1,08 3,04
TAN RELATION_88_FK 22 10917 3290 496,23 250,61
TDE RELATION_137_FK 6 26840 22556 4473,33 2239,17

Je ne sais pas exploiter ces données mais 2239.17 pour relation_137_fk me semble énorme. Dans ces cas la quels sont les possiblités de correction, s'il vous plait?

[txouki]

oh la la pas facile la question!
LA question est plus de savoir si ta base est une base d'interrogation ou une base de traitement.
Les index sont tres utile si les rq ramame moins de 20% d'une table sinon
oracle est plus rapide en access full sur une table.
donc.
-1 definir le besoin utilisateur
-2 si besoin idx alors utiliser le dbms_stat

[pinocchio]

txouki,
Ma base est plus une base d'interrogation même si elle fait les deux.
Pour la quantité de données ramenées, il me semblait que si plus de 20%, alors les index de type bitmap étaient utile.
Qu'entends tu par

definir le besoin utilisateur

Merci

[lalystar]

Bonjour,


Les indexes sont aussi utiles s'ils permettent de répondre rapidement à une requête sans avoir besoin d'interroger directement la table sous-jacente.

par ex. si on regarde la table EMP de PK empno

alors select count(*) from EMP peut être répondu rapidement en faisant un fast full scan index de la PK si la table EMP est très volumineuse...

Laly.

[orafrance]

txouki,
Ma base est plus une base d'interrogation même si elle fait les deux.
Pour la quantité de données ramenées, il me semblait que si plus de 20%, alors les index de type bitmap étaient utile.
Qu'entends tu par

definir le besoin utilisateur

Merci

Surtout pas les bitmaps ne doivent être utilisés que pour les colonnes obligatoires et avec très peu de valeurs distincts, l'exemple idéal est le sexe

[thomasjcj]

TABLE Nom Nb de clés distinctes Nb Clés nb max répétition nb moyen répétition Nb blocs nécessaire
TA AFFIC_FK 1431 1541 5 1,08 3,04
TAN RELATION_88_FK 22 10917 3290 496,23 250,61
TDE RELATION_137_FK 6 26840 22556 4473,33 2239,17

Un index classique B Tree n'est interessant que si il est selectif. La selectivité maxiamle est atteinte lorsque l'on a une Clef primaire ou une colonne marquée UNIQUE ou toutes les clefs sont distinctes. Les clefs de l'index etant triees, une requete ciblee sur une clef sera tres performante. Dans ton cas, l'index TAN RELATION_88_FK comporte 22 clefs distinctes sur 10917 clef. Ca veut dire une tres faible selectivité. Dans le cas d'une FK comme ici, un index est de toutes facons recommandé. A priori un index bitmap serait plus adapté dans ce cas mais attention, le bitmap sont tres couteux des que la table est soumise a de frequents DML.

Sous 9i il y a la possibilité de tracer l'utilisation des Index. C'est assez basique comme fonction mais c'est mieux que rien, ca donne au moins la psossibilité de savoir si un index n'est jamais utilisé, auquel cas il peut etre effacé par ex :

Code :

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

ALTER INDEX index_name MONITORING USAGE;

et ensuite regarder dans la vue V$OBJECT_USAGE

[txouki]

j'entends par definir le besoin utilisateur, observer si les utilisateurs(ie les gens qui utilisent la base) utilisent bcp de requetes selectivives, volumetrie ramener.....

[pinocchio]

txouki

bcp de requetes selectivives, volumetrie ramener.....

Oui, bcp de requête sélective.

orafrance

Surtout pas les bitmaps ne doivent être utilisés que pour les colonnes obligatoires et avec très peu de valeurs distincts, l'exemple idéal est le sexe

on ne peut pas créer les bitmaps sur des champs possible à NULL?

[lalystar]

si les champs NULL sont indexés dans un index bitmap contrairement à un index B*Tree.


Laly.

[aline]

alors select count(*) from EMP peut être répondu rapidement en faisant un fast full scan index de la PK si la table EMP est très volumineuse...

Laly.

j'ai remarqué que quand je faisais ce type de requêtes, j'avais un fast full scan sur la pk suivi d'un tri du résultat.

exemple

Code :

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

1
2
3
4
 
SELECT STATEMENT, GOAL = CHOOSE
 SORT AGGREGATE
  INDEX FAST FULL SCAN ma_pk

Savez vous pourquoi Oracle n'applique pas ce type de fonction d'aggregation en même temps qu'il lit l'index (ce qui optimiserait surement pas mal)?

[txouki]

Place des index sur les colonnes presentent dans les clause where.
Bitmap ou btree?
Comme le rappel thomasjcj et orafrance cela va dependre
1- de la taille de la table (si trop petite elle monte en cache =>pas besoin d'index)
2-du nombre de cle distinctes / nombre de ligne de la colonne
si peu de cles distinctes=>bitmap sinon Btree
Et pour finaliser ne pas oblier d'analyser les index , pour cela tu peux utiliser le package dbms_stat.gather... en 9i il est performent et te permet de positionner des histogrammes si la repartition de tes cle n'est pas uniforme.
bon courage

[pinocchio]

Et tout ca a quoi a voir avec les blocs???

[thomasjcj]

c'est pas clair ta question....

[lalystar]

Et tout ca a quoi a voir avec les blocs???

de la taille de la table (si trop petite elle monte en cache =>pas besoin d'index)

Pour lire une clé dans un index Oracle lit quelques blocks (typiquement 3 ou 4) suivant la profondeur du B*Tree puis ensuite il lit un block pour accéder aux données de la ligne dans ta table.

Si la taille de la table est petite et ne fait que quelques blocks, Oracle préfère faire un full table scan de la table plutot que de passer par l'index.


Laly.

[pinocchio]

Juste une précision, si je change un ndex en bitmap car les clés sont répétés très souvent, le nombre de blocs lus sera réduit?
Merci

[lalystar]

Bonjour,

Oui le nombre de blocs sera fortement réduit étant donné que le nombre de bits nécessaires est théoriquement nb lignes table x nb valeur distinctes pour la colonne sur laquelle porte l'index bitmap.

D'ailleurs le fait qu'un index bitmap soit aussi "compact" pose des problèmes de contention lorsque la table est utilisée en OLTP (transactionnel).


Cordialement,

Laly.