Je travaille sur un entrepôt de données. J'ai des tables avec jusqu'à 200 millions d'enregistrements. Certaines de ces tables ont environ 20+ index (je ne peux pas expliquer pourquoi ils ont été créés en premier lieu). Cela rend le travail de maintenance de ces index trop pénible et a un impact direct sur le travail d'importation DWH en termes de performances et d'exécution.
Comment trouver les index les moins utilisés sur chaque table? (afin de s'en débarrasser)
sql-server
ssms
Ben Dhaou musulman
la source
la source
sys.dm_db_index_usage_stats
fournit ces informations.Réponses:
Essayez ce script, il m'a aidé dans le passé:
http://blog.sqlauthority.com/2011/01/04/sql-server-2008-unused-index-script-download/
la source
J'ai trouvé que le script BlitzIndex gratuit de Brent Ozar Unlimited (écrit par Kendra Little) est le meilleur moyen d'isoler les index non utilisés (ainsi que les index qui peuvent être ajoutés, les index qui dupliquent le travail d'autres index, etc.)
http://www.brentozar.com/blitzindex/
Il vous indiquera le nombre de fois où un index a été lu depuis la dernière réinitialisation du nombre de statistiques (ou si un index a été créé / recréé).
Il me semble me rappeler que Brent Ozar a déclaré lors d'une webémission qu'une bonne règle empirique n'est pas plus de 10 index pour une table qui est lue souvent, 20 pour les tables qui sont des données statiques / historiques / archivées qui ne changeront pas fréquemment.
Si vous rencontrez toujours des problèmes avec la vitesse d'importation, y a-t-il un moment où la base de données n'est pas activement interrogée (c'est peut-être en dehors des heures de bureau). Il peut être avantageux de supprimer l'index, d'importer les données, puis de réappliquer les index. (Les statistiques seront bien sûr réinitialisées.) La raison en est que les index seront mis à jour au fur et à mesure que chaque enregistrement entre, les pages seront réorganisées et cela prend du temps et des E / S disque. La construction des index après nécessite une seule analyse de la table.
Aucune règle stricte et rapide, vous devrez peut-être expérimenter cela en fonction des types d'index et des données impliquées. Les index doivent être régulièrement revus à mesure que les besoins / requêtes changent.
la source
Essaye ça:
Raj
la source
J'ai ajouté la dernière date et le dernier code utilisé pour passer à la requête de Raj.
la source