Comment puis-je suivre les dépendances de la base de données?

Au fur et à mesure que les applications internes évoluent au fil des ans, vous constatez parfois qu'il existe un certain nombre de tables que les utilisateurs estiment ne plus être pertinentes et que vous souhaitez supprimer. Quelles sont les méthodes pratiques pour identifier les dépendances de base de données, à la fois dans l'environnement SQL et éventuellement dans des choses comme SSIS?

J'ai travaillé dans des endroits où des options assez brutales ont été prises, telles que:

• Supprimez d'abord, posez des questions plus tard (vous pouvez tuer une génération d'entrepôt de données s'il tente d'extraire une table qui n'existe plus)
• Supprimez d'abord les autorisations et attendez que les erreurs soient signalées (peut causer des bogues silencieux si l'échec n'est pas traité correctement)

J'apprécie que SQL Server soit fourni avec des outils permettant de suivre les dépendances au sein de cette instance, mais ceux-ci semblent présenter des difficultés si vous avez des bases de données sur différentes instances. Existe-t-il des options facilitant l’interrogation des dépendances, par exemple en répondant à des questions telles que "Où cette colonne est-elle utilisée?" avec des réponses telles que "Sur cet autre serveur dans cette procédure stockée" ou "Sur ce package SSIS"?

Il n'y a pas de moyen facile de faire cela. Les déclencheurs ne fonctionnent pas, car si vous sélectionnez dans une table, aucun déclencheur n'est déclenché. Le meilleur moyen que j’ai trouvé de faire cela est de laisser les développeurs suivre ce qu’ils utilisent. Quand quelque chose va être abandonné, vérifiez auprès de toutes les équipes de développement, et une fois que tout le monde a quitté, renommez l'objet. Ensuite, rien ne casse pendant un mois ou jusqu'à, l'objet peut être déposé en toute sécurité.

1. Code de recherche pour une utilisation avec sys.sql_modules.definition: est-il référencé? Ensuite...
2. Vérifier les autorisations: quel code client peut l'appeler? Ensuite...
3. Profiler

Ainsi:

• Pour une table sans référence ni autorisation, elle n'est pas utilisée.
• En l'absence de références et de certaines autorisations, exécutez le profileur pour voir l'utilisation
• Sans autorisations ni références, ajoutez une journalisation de l'utilisation

Ce que j'ai déjà fait est de faire de la table une vue masquant la table puis de la rendre mal performante: (Cross join lui-même, distinct). Vous ne le supprimez pas réellement, mais vous générez des délais d'attente ou des plaintes de clients ...

Un moyen rapide que j'ai utilisé par le passé (et cela dépend vraiment de la taille des tables, du nombre de performances d'index, etc.), consiste à ajouter un déclencheur, qui enregistre un horodatage lorsqu'une action est effectuée sur la table. Comme je l'ai dit, cela peut entraîner des problèmes de performances et doit donc être traité avec prudence. Veillez également à ce que votre table de journalisation n'utilise pas de champs d'identité, car cela risquerait de bousiller un ancien code qui utilise @@ IDENTITY. Bien sûr, cela peut simplement montrer qu'une fonctionnalité d'une application n'a pas été utilisée depuis un moment.

Il est très difficile de suivre les dépendances lorsque tout le code susceptible de frapper la base de données ne se trouve pas dans la base de données, c'est-à-dire des clients aléatoires interrogeant la base de données.

ÉDITER: pour aborder le point où une table ne peut pas avoir de déclencheurs SELECT, voici une autre option qui devrait fonctionner en supposant que vos tables possèdent des index (testés en 2008 uniquement).

SELECT          
    last_user_seek,
    last_user_scan,
    last_user_lookup,
    last_user_update
FROM
    sys.dm_db_index_usage_stats AS usage_stats
INNER JOIN
sys.tables AS tables ON tables.object_id = usage_stats.object_id
WHERE
    database_id = DB_ID() AND
    tables.name = 'mytable' 

mais notez que la table de statistiques d'utilisation est effacée lorsque le serveur est redémarré, déconnecté, etc. Vous devez donc configurer un travail pour collecter les données. Un peu de bidouille je sais.

Une méthode que j’avais utilisée par le passé était d’établir une liste de tables de candidats à supprimer, puis de les renommer et de rechercher les échecs.

Comment j'ai établi la liste était:

1. voir quelles tables ne sont pas utilisées dans les procédures stockées, les déclencheurs et les fonctions actuels

2. tables vides (zéro enregistrement);

3. tables non référencées (tables sans relations);

4. voir quelles tables n'étaient pas utilisées depuis le démarrage du serveur de base de données (DMV)

Après avoir construit la liste dans un fichier texte, j'ai créé un script de traitement par lots qui analysait nos fichiers .cs (nous n'avions que des projets .net) à partir du dossier de contrôle de version mappé local et voyait si ces tables étaient utilisées dans les fichiers .cs ( ne devrait pas arriver, mais bon .. j'ai eu des surprises). Si non, alors c'est clair, si oui, alors nous construisons une liste et donnons aux développeurs de vérifier si ce module est toujours utilisé.

En bref, les gars précédents ont raison, il n’ya pas de solution miracle.

La politique que j'implémente dans mon entreprise consiste à placer tout ce qui concerne SQL Server sous contrôle de source, dans un emplacement central.

• projets asp.net
• Projets SSRS
• Projets SSIS
• J'ai même scripté tous les objets de base de données dans un référentiel de toutes sortes.

Je ne l'ai pas encore configuré, mais je souhaite finalement mettre en place une sorte de mécanisme de recherche index / central que je pourrais utiliser pour rechercher des tables, des sprocs, etc. spécifiques. Nous sommes en fait un nouveau SQL Server Shop - conversion de FoxPro . Les anciens objets SQL ne posent donc pas encore beaucoup de problèmes, mais je prévois pour l'avenir.

Le problème que je vois avec l'approche de changement de nom / traçage est que certaines choses ne fonctionnent que chaque année, et même pas chaque année. Sans parler des différentes choses ad-hoc que les gens vous demandent d'écrire, puis demandez-les encore des mois ou des années plus tard.

Il existe divers outils et techniques à utiliser pour le suivi des dépendances, notamment:

Outils que je connais:

• Afficheur de dépendance SQL Server (mais peut poser des problèmes si sp using table a été créé avant la création de la table)
• Redgate SQL Dependency Tracker (via la réponse de @Eric Humphrey)
• Resharper (outil .net pouvant être utilisé pour rechercher des chemins d’appel, je pense qu’il peut être utilisé pour suivre où les appels SQL clés sont utilisés)

Les méthodes

• Recherches de code pour l'utilisation d'objets SQL (réplique cependant certains des outils ci-dessus)

• Regardez les statistiques d'utilisation (c'est-à-dire quand un objet SQL a été appelé pour la dernière fois), j'utilise le code SQL ci-dessous:

  SELECT 
      last_execution_time,   
      (SELECT TOP 1 
          SUBSTRING(s2.text,statement_start_offset / 2+1 , 
              ((CASE WHEN statement_end_offset = -1 THEN 
                  (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
              ELSE statement_end_offset END) - statement_start_offset) / 2+1)
      )  AS sql_statement,
      execution_count
  FROM sys.dm_exec_query_stats AS s1 
  CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
  WHERE 
      s2.text like '%[OBJECT NAME]%' 
      and last_execution_time > [DATE YOU CARE ABOUT]
  ORDER BY last_execution_time desc
  

Remarque : Le tableau de statistiques d'utilisation est effacé lorsque le serveur est redémarré, déconnecté, etc. Il vous faudra donc configurer un travail pour collecter les données. Un peu de bidouille je sais. (de @Miles D)

Des techniques

• Recherche de la dernière utilisation (voir les statistiques d'utilisation ci-dessus)
• Rechercher où il est utilisé (voir outils)
• Passez en revue l'utilisation du code avec les développeurs (via @MrDenny)
• Renommez l'objet (c'est-à-dire: post / prefix avec _toBeDropped) et surveillez les erreurs
• Modifier les autorisations et surveiller les erreurs
• Laisser un objet et prier

Il y a plusieurs années, j'ai essayé de créer un outil permettant de vérifier des informations similaires. La réponse de TL; DR est que j’ai trouvé qu’il était impossible de gérer les ressources disponibles à ce moment-là.

Où cette colonne est-elle utilisée?

Cette question se complique lorsque vous vous rendez compte qu'un certain nombre de requêtes, de vues et de procédures stockées utilisent select *la table dans laquelle réside la colonne. Ensuite, vous devez examiner les programmes qui utilisent ces résultats - vous avez donc besoin d'un analyseur / indexeur / analyseur capable de lire le code source qui peut être C #, Delphi, Java, VB, ASP (classique) et ainsi de suite, juste pour essayer de traquer toutes les références à cette colonne. Ensuite, vous devez analyser ces programmes pour essayer de déterminer si ce code est même appelé.

Ne gérera pas les références SQL, mais vous voudrez peut-être consulter SQL Dependency Tracker de Redgate . C'est un bel outil de visualisation.

Ce n'est pas vraiment une réponse à votre question, mais je pense que cela mérite d'être mentionné: c'est l'une des raisons pour lesquelles tous les systèmes en dehors de votre base de données devraient communiquer via des vues et des sprocs . Vous avez les scripts de construction pour ces fichiers dans des fichiers .sql interrogeables, de sorte que vous puissiez facilement voir si une table ou une colonne particulière est utilisée en externe.

Bien sûr, SSIS se connectera normalement directement aux tables, ce qui ne vous aidera probablement pas beaucoup pour le moment. Mais lorsque les développeurs se connectent à votre base de données et se plaignent de devoir vous attendre (ou quiconque joue le rôle de DBA) pour créer les vues et les sprocs dont ils ont besoin, vous pouvez leur dire: "Toute table ou colonne peut être supprimée ou renommée. I ' m seulement obligé de vous tenir au courant des modifications apportées aux vues et aux sprocs. " Et ils doivent seulement faire des tests de régression pour ces changements spécifiques.

TSQL les éléments suivants peuvent être utilisés sys.dm_sql_referencing_entities ou sys.sql_expression_dependencies

Alternativement, des outils tels que SQL Negotiator Pro, Redgate, etc. peuvent générer ceci visuellement pour vous en utilisant une interface graphique.