Discussion :

[Darkcristal]

Bonjour,

j'ai une base avec presque 5000 tables qui a été construite pendant plus de 10 ans. Malheureusement une grande partie ne sont plus utilisées mais je ne sais pas les identifier pour faire du ménage.

Est ce qu'il existe une méthode fiable pour identifier les tables non accédées en SELECT/INSERT/UPDATE/DELETE ?

J'ai trouvé la colonne last_user_update de la table dm_db_index_usage_stats mais ca semble ne prendre en compte que les UPDATE, DELETE et INSERT ? ce qui est déjà pas mal !

Comment identifier des tables qui ne sont utilisées qu'en SELECT ? est ce que la date de dernière utilisation de la table peut être trouvée ?


Merci pour votre aide

[al1_24]

Le moyen le plus efficace :
Renommer la table (voire la supprimer si on est sûr de la sauvegarde) et attendre les retours des utilisateurs / applications.
Si personne ne réagit, c'est que la table n'est plus utilisée.

[escartefigue]

On peut aussi analyser les dépendances grâce au catalogue relationnel.

Les dates de dernières mises à jour ne sont évidemment pas un critère suffisant, je pense notamment aux tables de typologies (codes devises, code pays, codes langues...) qui sont rarement mises à jour, mais pour autant souvent utilisées.
L'utilisation des index n'est pas non plus un critère suffisant, les tables de quelques lignes (typologies aussi, mais pas seulement) pouvant faire l'objet de table scan.
Et enfin, certaines tables ne sont peut être utilisées que par des traitements annuels ou à la demande.

Donc la prudence s'impose.

[Michel.Priori]

J'ai trouvé la colonne last_user_update de la table dm_db_index_usage_stats mais ca semble ne prendre en compte que les UPDATE, DELETE et INSERT ? ce qui est déjà pas mal !
Comment identifier des tables qui ne sont utilisées qu'en SELECT ? est ce que la date de dernière utilisation de la table peut être trouvée ?

Bonjour, la doc est ici : https://learn.microsoft.com/fr-fr/sq...l-server-ver16

Il est vrai qu'il n'y a rien de specifique à propos des SELECT
Pour autant "scan", "lookup", et "seek" sont aussi utilisés lors des lectures

LA question reste : est-ce que toutes les tables sont cluster ?

[SQLpro]

SCAN, LOOKUP, SEEK sont utilisés aussi bien par les SELECT que INSERT, UPDATE DELETE... La requête suivante va donner les accès les plus récents :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
WITH 
T0 AS
(
SELECT object_id, 
       COALESCE(MAX(LEAST(last_user_seek, last_user_scan, last_user_lookup)),
	   (SELECT sqlserver_start_time FROM sys.dm_os_sys_info)) AS LAST_ACCESS   
FROM   sys.dm_db_index_usage_stats
GROUP  BY object_id
)
SELECT s.name AS TABLE_SCHEMA, o.name AS TABLE_NAME, o.type_desc AS TABLE_TYPE, 
       LAST_ACCESS
FROM   T0  
       JOIN sys.objects AS o
	      ON T0.object_id = o.object_id
	   JOIN sys.schemas AS s
	      ON o.schema_id = s.schema_id;

Mais ATTENTION : ce sont des statistiques depuis le redémarrage du serveur. une table peut n'être utilisée qu'une fois par moi, voir par an !!!

A +

[escartefigue]

Mais ATTENTION : ce sont des statistiques depuis le redémarrage du serveur. une table peut n'être utilisée qu'une fois par moi, voir par an !!!

Une fois par moi(s) et une fois par toi, chacun son tour
Plus sérieusement, comme je l'indiquai plus haut, le souci est que certaines requêtes font du tablescan et donc sans passer par des index : cas des tables très peu volumineuses par exemple ou d'index non discriminants.
En ce cas, consulter la table dm_db_index_usage_stats n'est d'aucun secours.

[SQLpro]

...
Plus sérieusement, comme je l'indiquai plus haut, le souci est que certaines requêtes font du tablescan et donc sans passer par des index : cas des tables très peu volumineuses par exemple ou d'index non discriminants.
En ce cas, consulter la table dm_db_index_usage_stats n'est d'aucun secours.

Si car SQL Server considère qu'une table est un index. Donc même si la table n'est pas organisée en clustered, elle sera utilisée en HEAP et l'index d'id 0 c'est la table en HEAP...

Donc, oui, cette vue rassemble tout...

A +