Discussion :

[cornnery]

Bonjour à tous ,

pour faire du ménage dans une base je souhaiterais savoir s'il existe une requête qui peut nous renvoyer la dernière date d'utilisation des objets de la base (Table, index) .

Merci

[Marc Musette]

En ce qui concerne les tables, cela me semble être une question à poser au responsable de l'application ; en tant que DBA, je m'imagine mal dropper une table car celle-ci n'est plus utilisée depuis 6 mois (celle-ci n'est peut-être utilisée que pour un job de clotûre comptable annuel ...)


pour les indexes, c'est autre chose car il s'agit là d'objet créés à des fins de performance et donc sous le contrôle du dba.

Code :

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

ALTER INDEX my_index_i MONITORING USAGE;

après un certain temps (qui dépend de ton application - je dirais une semaine minimum) :

Code :

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

ALTER INDEX my_index_i NOMONITORING USAGE;

et ensuite tu peux vérifier si l'index est utilisé au cours de cette période via :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT index_name,
       table_name,
       monitoring,
       used,
       start_monitoring,
       end_monitoring
FROM   v$object_usage
WHERE  index_name = 'MY_INDEX_I'
ORDER BY index_name;

[Mohamed.Houri]

En ce qui concerne les tables, cela me semble être une question à poser au responsable de l'application ; en tant que DBA, je m'imagine mal dropper une table car celle-ci n'est plus utilisée depuis 6 mois (celle-ci n'est peut-être utilisée que pour un job de clotûre comptable annuel ...)


pour les indexes, c'est autre chose car il s'agit là d'objet créés à des fins de performance et donc sous le contrôle du dba.

Code :

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

ALTER INDEX my_index_i MONITORING USAGE;

après un certain temps (qui dépend de ton application - je dirais une semaine minimum) :

Code :

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

ALTER INDEX my_index_i NOMONITORING USAGE;

et ensuite tu peux vérifier si l'index est utilisé au cours de cette période via :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT index_name,
       table_name,
       monitoring,
       used,
       start_monitoring,
       end_monitoring
FROM   v$object_usage
WHERE  index_name = 'MY_INDEX_I'
ORDER BY index_name;

C'est exactement la réponse qu'il fallait avec la nuance suivante: un index couvrant une contrainte d'intégrité (FK) lorsqu'il est monitoré, peut-être montré comme non utilisé alors qu'il l'est activement. Je pense tout particulièrement au comportement d'Oracle lorsqu'on supprime un enregistrement d'une table mère ayant un enregistrement dans une table fille. Afin d'éviter de "locker" toute la table, Oracle utilise l'index sur la FK. Et bien figurez-vous que cette utilisation n'est pas reportée comme telle

ask tom

richard foote

Je vous laisse deviner la catastrophe qui peut être causée par la suppression de ce type d'indexes.

Je ne connais que cette unique situation où le monitoring de l'utilisation des indexes est faussement reportée. Ceci dit, pour les autres indexes qui pourraient être reportés comme non utilisés, je pencherai plutôt, tout dépend également de la version d'Oracle, de les rendre invisibles dans un premier temps et de voir le comportement de l'application avant de passer à l'étape de la suppression.

De plus, souvent dans des applications, je rencontre ce que j’appelle des indexes redondants c'est à dire des indexes du type i1(a,b,c) et i2(a,b) ; même dans cette situation je réfléchirai plusieurs fois avant de supprimer l'index i2(a,b) qui est couvert par l'index i1(a,b,c) car en effet, il se pourrait que le clustering factor de i2 soit meilleur que celui de i1(a,b,c) rendant donc la désirabilité de i1 par le CBO pas aussi attractive que celle de l’index i2 et, donc, en l'absence de i2, le CBO pencherai pour un FULL table scan au lieu de l'utilisation de l'index i1

Ce sont là quelques réflexions sur la suppression des indexes qu'il faut manier avec beaucoup de précaution.

[Heaven93]

bonsoir,

je vous conseille de regarder le nombre d'utilisation des indexes par les diverses requêtes en interrogeant la table dba_hist_sql_plan, ceci avec des statistiques à jour sur les objets car l'optimiser pourrait ne pas choisir un plan d'exécution optimal si ces dernièresi ne sont pas assez précises.
il faut que la période d'observation soit représentative car certains batches ne les utiliseront pas quotidiennement.
pour les tables, si elles existent, il parait difficile d'en supprimer. une table non utilisée peut être une table de référence qui ne bouge pas beaucoup. et attention aux contraintes d'intégrité.

[Marc Musette]

Effectivement les foreign key indexes ne sont pas rapportés ... merci d'avoir insister sur ce pont qui effectivement serait catastrophique dans certains cas.

pour ce qui est du clustering factor, si l'index i2 n'est pas utilisé ... à quoi bon le garder...

[Rei Ichido]

Peut-être que l'index i2 n'est lui-même utilisé que pour un

job de clotûre comptable annuel

?

Et dans ce cas là, ça serait dommage de voir le temps de traitement du batch annuel très important dépasser le temps admissible et donc tomber en erreur ...

Faire du monitoring, oui, dropper automatiquement sans se demander à quoi peut servir l'index, non.