Question

Nous rencontrons un problème avec un grand nombre de procédures stockées héritées au travail. Est-ce que vous recommandez un outil qui pourrait vous aider à mieux comprendre ces procédures? Une sorte de reverse engineering qui identifie les dépendances entre procédures et / ou les dépendances de procédure par rapport aux tables. Peut être un outil gratuit ou commercial.

Merci!

Était-ce utile?

La solution

Redgate propose un produit assez coûteux appelé Suivi des dépendances SQL qui semble remplir les exigences.

Autres conseils

La solution moins coûteuse que "Dépendance Tracker" est la table de dictionnaire de données sys.sql_dependencies à partir de laquelle ces données peuvent être interrogées à partir du dictionnaire de données. Oracle dispose d'une vue de dictionnaire de données avec une fonctionnalité similaire appelée DBA_DEPENDENCIES (plus des vues USER_ et ALL_ équivalentes). En utilisant les autres tables du dictionnaire de données (sys.tables / DBA_TABLES), etc., vous pouvez générer des rapports de dépendance d’objet.

Si vous vous sentez particulièrement intéressé, vous pouvez utiliser une requête récursive (Oracle CONNECT BY ou SQL Server Common Table Expressions) pour créer un graphique complet de dépendance par objet.

Voici un exemple de CTE récursif sur sys.sql_dependencies. Il renverra une entrée pour chaque dépendance avec sa profondeur. Les éléments peuvent apparaître plusieurs fois, éventuellement à différentes profondeurs, pour chaque relation de dépendance. Je n'ai pas d'instance Oracle en état de marche pour créer une requête CONNECT BY sur DBA_DEPENDENCIES. Toute personne disposant des privilèges d'édition, du temps et de l'expertise dont elle a besoin est alors la bienvenue pour annoter ou modifier cette réponse.

Notez également avec sys.sql_dependencies que vous pouvez obtenir des références de colonne à partir de id_minor_référencé . Cela pourrait être utilisé (par exemple) pour déterminer les colonnes réellement utilisées dans les sprocs ETL à partir d'une zone de stockage intermédiaire avec des copies des tables de base de données de la source avec plus de colonnes que celles réellement utilisées.

with dep_cte as (
select o2.object_id  as parent_id
      ,o2.name       as parent_name
      ,o1.object_id  as child_id
      ,o1.name       as child_name
      ,d.referenced_minor_id
      ,1 as hierarchy_level
  from sys.sql_dependencies d
  join sys.objects o1
    on o1.object_id = d.referenced_major_id
  join sys.objects o2
    on o2.object_id = d.object_id
 where d.referenced_minor_id in (0,1)
   and not exists
       (select 1
          from sys.sql_dependencies d2
         where d2.referenced_major_id = d.object_id)

union all

select o2.object_id  as parent_id
      ,o2.name       as parent_name
      ,o1.object_id  as child_id
      ,o1.name       as child_name
      ,d.referenced_minor_id
      ,d2.hierarchy_level + 1 as hierarchy_level
  from sys.sql_dependencies d
  join sys.objects o1
    on o1.object_id = d.referenced_major_id
  join sys.objects o2
    on o2.object_id = d.object_id
  join dep_cte d2
    on d.object_id = d2.child_id
 where d.referenced_minor_id in (0,1)
)

select *
  from dep_cte
 order by hierarchy_level

J'ai ceci à ouvrir à la communauté maintenant. Une personne disposant d'un accès pratique à une instance Oracle en cours d'exécution peut-elle envoyer ici une requête récursive CONNECT BY? Notez que ceci est spécifique au serveur SQL et que le propriétaire de la question a depuis lors précisé qu’il utilisait Oracle. Je n'ai pas d'instance Oracle en cours d'exécution pour développer et tester quoi que ce soit.

Je pense que le l'outil de suivi des dépendances de Red Gate mentionné par rpetrich est une solution décente, cela fonctionne bien et Red Gate a une période d’essai de 30 jours (idéalement assez longue pour que vous fassiez votre expertise).

Je voudrais également envisager d'isoler le système et d'exécuter le SQL Profiler, qui vous montrera toutes les actions SQL sur les tables . C’est souvent un bon point de départ pour créer un diagramme de séquence ou choisir de documenter ces codes . Bonne chance!

Redgate SQL Doc. la documentation générée incluait des informations sur les dépendances croisées. Par exemple, pour chaque table, il répertorie les vues, les procédures stockées, les déclencheurs, etc., qui font référence à cette table.

Dans quelle base de données se trouvent les procédures stockées? Oracle, SQL Server, autre chose?

Modifier en fonction des commentaires: Etant donné que vous utilisez Oracle, consultez TOAD . J'utilise une fonctionnalité appelée Code Roadmap, qui vous permet d'afficher graphiquement les interdépendances PL / SQL dans la base de données. Il peut être exécuté en mode Code uniquement, affichant les dépendances de la pile d’appel au moment de l’exécution, ou en mode Code Plus, où il affiche également les objets de base de données (tables, vues, déclencheurs) concernés par votre code.

(Remarque - je suis un utilisateur de TOAD et je n'ai aucun avantage à le renvoyer.)

Cela n’est pas vraiment profond ni approfondi, mais je pense que si vous utilisez MS SQL Server ou Oracle (Nigel peut peut-être vous aider avec un exemple PL-SQL) ... Nigel est sur quelque chose. Cela va seulement 3 dépendances profondes, mais pourrait être modifié pour aller aussi profond que vous avez besoin. Ce n’est pas la plus jolie chose… mais c’est fonctionnel…

select 
    so.name + case when so.xtype='P' then ' (Stored Proc)' when so.xtype='U' then ' (Table)' when so.xtype='V' then ' (View)' else ' (Unknown)' end as EntityName, 
    so2.name + case when so2.xtype='P' then ' (Stored Proc)' when so2.xtype='U' then ' (Table)' when so2.xtype='V' then ' (View)' else ' (Unknown)' end as FirstDependancy,
    so3.name + case when so3.xtype='P' then ' (Stored Proc)' when so3.xtype='U' then ' (Table)' when so3.xtype='V' then ' (View)' else ' (Unknown)' end as SecondDependancy,
    so4.name + case when so4.xtype='P' then ' (Stored Proc)' when so4.xtype='U' then ' (Table)' when so4.xtype='V' then ' (View)' else ' (Unknown)' end as ThirdDependancy
from 
  sysdepends sd 
    inner join sysobjects as so on sd.id=so.id 
    left join sysobjects as so2 on sd.depid=so2.id
    left join sysdepends as sd2 on so2.id=sd2.id and so2.xtype not in ('S','PK','D')
    left join sysobjects as so3 on sd2.depid=so3.id and so3.xtype not in ('S','PK','D')
    left join sysdepends as sd3 on so3.id=sd3.id and so3.xtype not in ('S','PK','D')
    left join sysobjects as so4 on sd3.depid=so4.id and so4.xtype not in ('S','PK','D')
where so.xtype = 'P' and left(so.name,2)<>'dt'
group by so.name, so2.name, so3.name, so4.name, so.xtype, so2.xtype, so3.xtype, so4.xtype

Comment trouver la chaîne de dépendance d'un objet de base de données (MS SQL Server 2000 (?) +) par Jacob Sebastian

  

Chaque fois qu'il a besoin de déployer un nouveau rapport ou de modifier un rapport existant   rapport, il a besoin de savoir quels sont les objets de base de données qui dépendent de   la procédure stockée de rapport donnée. Parfois, les rapports sont très   complexe et chaque procédure stockée peut avoir des dizaines de personnes à charge   les objets et chaque objet dépendant peuvent dépendre d’autres dizaines de   objets.

     

Il avait besoin d'un moyen de trouver récursivement tous les objets dépendants d'un   donnée procédure stockée. J'ai écrit une requête récursive en utilisant CTE pour réaliser   ceci.

Le meilleur outil de reverse engineering est APEX. C'est incroyable. Il peut même tracer dans des assemblys .NET et vous dire où les procs sont utilisés. C'est de loin le produit le plus profond du genre. RedGate a d’autres excellents outils mais pas dans ce cas.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top