Stored Procedures Reverse Engineering

Question

Wir haben ein Problem mit einer großen Anzahl von gespeicherten Stored Procedures bei der Arbeit. Wirst du irgendwelche Werkzeuge empfehlen, die helfen können, diese Verfahren besser zu verstehen? Eine Art von Reverse Engineering, die Abhängigkeiten zwischen den Prozeduren und/oder Prozeduren und Tabellenabhängigkeiten identifiziert. Kann ein kostenloses oder kommerzielles Tool sein.

Danke!

Answer 1

Redgate hat ein ziemlich teures Produkt namens SQL Dependency Tracker, das die Anforderungen zu erfüllen scheint.

Answer 2

Ich denke, die Red Gate Dependency Tracker mentioned by rpetrich ist eine anständige Lösung, es funktioniert gut und Red Gate hat 30 Tage Testversion (idealerweise lang genug für Sie tun Ihre Forensik).

Ich würde auch in Betracht ziehen, das System zu isolieren und den SQL Profiler laufen zu lassen, der Ihnen die ganze SQL Aktion auf den Tabellen zeigt. Dies ist oft ein guter Ausgangspunkt für den Aufbau eines Sequenzdiagramms oder aber Sie wählen diese Codes zu dokumentieren. Viel Glück!

Answer 3

Redgate SQL Doc. Die generierte Dokumentation enthielt Informationen über die Abhängigkeit. Zum Beispiel listet es für jede Tabelle Sichten, gespeicherte Prozeduren, Trigger usw. auf, die auf diese Tabelle verweisen.

Answer 4

In welcher Datenbank befinden sich die gespeicherten Prozeduren? Oracle, SQL Server, etwas anderes?

Edit basierend auf Kommentar: Wenn Sie Oracle dann verwenden, sehen Sie sich TOAD. Ich verwende eine Funktion namens Code Roadmap, mit der Sie PL/SQL-Abhängigkeiten innerhalb der Datenbank grafisch darstellen können. Es kann im Nur-Code-Modus ausgeführt werden, in dem die Abhängigkeiten des Laufzeitaufrufs angezeigt werden, oder im Code Plus-Datenmodus, in dem auch Datenbankobjekte (Tabellen, Ansichten, Trigger) angezeigt werden, die von Ihrem Code berührt werden.

(Hinweis - Ich bin ein TOAD Benutzer und gewinnen keinen Nutzen daraus bezieht)

Answer 5

Die billigere Lösung als ‚Dependency Tracker‘ ist die Data-Dictionary-Tabelle sys.sql_dependencies, die aus dem diese Daten sein kann aus dem Datenwörterbuch abgefragt. Oracle verfügt über eine Data Dictionary-Ansicht mit ähnlicher Funktionalität namens DBA_DEPENDENCIES (plus entsprechende USER_- und ALL_-Ansichten). Mit den anderen Data-Dictionary-Tabellen (sys.tables/DBA_TABLES) usw. können Sie Beziehungsberichte erstellen.

Wenn Sie besonders interessiert sind, können Sie eine rekursive Abfrage verwenden (Oracle CONNECT BY oder SQL Server Common Table Expressions), um ein vollständiges Objektabhängigkeitsdiagramm zu erstellen.

Hier ist ein Beispiel für eine rekursive CTE auf sys.sql_dependencies. Es wird einen Eintrag für jede Abhängigkeit mit seiner Tiefe zurückgeben. Elemente können für jede Abhängigkeitsbeziehung mehr als einmal, möglicherweise in unterschiedlichen Tiefen, auftreten. Ich habe keine funktionierende Oracle-Instanz zur Hand, um eine CONNECT BY-Abfrage für DBA_DEPENDENCIES zu erstellen, sodass jeder, der über Bearbeitungsberechtigungen sowie die Zeit und das Fachwissen verfügt, diese Anmerkung kommentieren oder bearbeiten kann.

Hinweis auch mit sys.sql_dependencies, dass Sie Spaltenreferenzen von referenced_minor_id erhalten können. Dies könnte (zum Beispiel) verwendet werden, um zu bestimmen, welche Spalten in den ETL-Sprocs aus einem Bereitstellungsbereich tatsächlich verwendet wurden, wobei Kopien der DB-Tabellen aus der Quelle mit mehr Spalten als tatsächlich verwendet wurden.

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 

Ich habe dies zu öffnen, um die Gemeinschaft jetzt.Könnte jemand mit bequemem Zugriff auf eine laufende Oracle-Instanz hier eine rekursive CONNECT BY-Abfrage posten? Beachten Sie, dass dies SQL-Server-spezifisch ist und der Fragesteller seither klargestellt hat, dass er Oracle verwendet. Ich habe keine laufende Oracle-Instanz zur Hand, um etwas zu entwickeln und zu testen.

Answer 6

Dies ist nicht wirklich tief oder gründlich, aber ich denke, wenn Sie MS SQL Server oder Oracle verwenden (Vielleicht kann Nigel mit einem PL-SQL-Beispiel helfen) ... Nigel ist auf etwas. Dies geht nur 3 Abhängigkeiten tief, aber könnte geändert werden, um zu gehen, wie tief Sie auch brauchen. Es ist nicht die schönste Sache ... aber es ist funktional ...

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 

Answer 7

Das einzige beste Werkzeug für das Reverse Engineering von APEX ist. Es ist wunderbar. Es kann sogar in .NET-Assemblies eingezeichnet werden und Ihnen sagen, wo die Procs verwendet werden. Es ist mit Abstand das tiefste Produkt seiner Art. RedGate hat großartige andere Werkzeuge, aber nicht in diesem Fall.

Answer 8

How to find the dependency chain of a database object (MS SQL Server 2000 (?) +) von Jacob Sebastian

Jedes Mal, wenn er einen neuen Bericht bereitstellen muss oder einen vorhandenen Bericht ändern, er wissen muss, was die Datenbankobjekte sind Das hängt von der angegebenen gespeicherten Berichtsprozedur ab. Manchmal sind die Berichte sehr komplex und jede gespeicherte Prozedur kann Dutzende von Objekte haben und jedes abhängige Objekt kann abhängig von anderen Dutzenden von Objekten sein.

Er benötigte einen Weg, rekursiv alle abhängigen Objekte einer gegebenen gespeicherten Prozedur zu finden. Ich schrieb eine rekursive Abfrage mit CTE, um dies zu erreichen.