Ingénierie inverse des procédures stockées
-
09-06-2019 - |
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!
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.