Ingegneria inversa delle procedure memorizzate

Question

Stiamo riscontrando problemi con un numero enorme di procedure memorizzate legacy al lavoro.Ragazzi, consigliate qualche strumento che possa aiutare a comprendere meglio tali procedure?Una sorta di reverse engineering che identifica le dipendenze tra procedure e/o procedure vs.dipendenze delle tabelle.Può essere uno strumento gratuito o commerciale.

Grazie!

Answer 1

Redgate ha un prodotto piuttosto costoso chiamato Monitoraggio delle dipendenze SQL che sembra soddisfare i requisiti.

Answer 2

La soluzione più economica rispetto al "tracker delle dipendenze" è la tabella del dizionario dati sys.sql_dependencies da cui è possibile interrogare questi dati dal dizionario dati.Oracle dispone di una vista del dizionario dati con funzionalità simili denominata DBA_DEPENDENCIES (più visualizzazioni USER_ e ALL_ equivalenti).Utilizzando le altre tabelle del dizionario dati (sys.tables/DBA_TABLES) ecc.è possibile generare report sulle dipendenze degli oggetti.

Se ti senti particolarmente interessato, puoi utilizzare una query ricorsiva (Oracle CONNECT BY o SQL Server Common Table Expressions) per creare un grafico completo delle dipendenze degli oggetti.

Ecco un esempio di CTE ricorsivo su sys.sql_dependencies.Restituirà una voce per ogni dipendenza con la sua profondità.Gli elementi possono verificarsi più di una volta, possibilmente a profondità diverse, per ogni relazione di dipendenza.Non ho un'istanza Oracle funzionante a portata di mano per creare una query CONNECT BY su DBA_DEPENDENCIES, quindi chiunque abbia privilegi di modifica, tempo e competenza è benvenuto per annotare o modificare questa risposta.

Nota anche con sys.sql_dependencies da cui puoi ottenere i riferimenti alle colonne referenced_minor_id.Questo potrebbe essere utilizzato (ad esempio) per determinare quali colonne sono state effettivamente utilizzate negli sproc ETL da un'area di gestione temporanea con copie delle tabelle DB dall'origine con più colonne di quelle effettivamente utilizzate.

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

Adesso devo aprirmi alla comunità.Qualcuno con un comodo accesso a un'istanza Oracle in esecuzione potrebbe pubblicare qui una query ricorsiva CONNECT BY?Tieni presente che questo è specifico del server SQL e da allora il proprietario della domanda ha chiarito che sta utilizzando Oracle.Non ho un'istanza Oracle in esecuzione a portata di mano per sviluppare e testare nulla.

Answer 3

Penso che la Red Gate Dependency Tracker menzionato da rpetrich è una soluzione decente, funziona bene e Red Gate ha una prova di 30 giorni (idealmente abbastanza a lungo per eseguire le tue analisi forensi).

Prenderei anche in considerazione l'idea di isolare il sistema ed eseguire il file SQL Profiler che ti mostrerà tutte le azioni SQL sulle tabelle.Questo è spesso a buon punto di partenza per costruire un diagramma di sequenza o comunque tu scelga di documentare questi codici.Buona fortuna!

Answer 4

Documento SQL Redgate.la documentazione generata includeva informazioni sulle dipendenze con riferimenti incrociati.Ad esempio, per ogni tabella vengono elencate le viste, le procedure memorizzate, i trigger ecc. che fanno riferimento a quella tabella.

Answer 5

In quale database si trovano le procedure memorizzate?Oracle, SQL Server, qualcos'altro?

Modifica in base al commento: Dato che stai usando Oracle, dai un'occhiata a ROSPO.Utilizzo una funzionalità chiamata Code Roadmap, che consente di visualizzare graficamente le interdipendenze PL/SQL all'interno del database.Può essere eseguito in modalità Code Only, mostrando le dipendenze dello stack di chiamate di runtime, o in modalità Code Plus Data, dove mostra anche gli oggetti del database (tabelle, visualizzazioni, trigger) toccati dal codice.

(Nota: sono un utente TOAD e non ottengo alcun vantaggio dal segnalarlo)

Answer 6

Questo non è molto approfondito o approfondito, ma penso che se stai utilizzando MS SQL Server o Oracle (forse Nigel può aiutarti con un esempio PL-SQL)...Nigel ha capito qualcosa.Questo arriva solo a 3 dipendenze in profondità, ma potrebbe essere modificato per andare in profondità quanto necessario.Non è una cosa bellissima...ma è funzionale...

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

Come trovare la catena di dipendenze di un oggetto di database (MS SQL Server 2000 (?)+) Di Jacob Sebastian

Ogni volta che ha bisogno di distribuire un nuovo rapporto o modificare un rapporto esistente, deve sapere quali sono gli oggetti del database che dipendono dalla procedura memorizzata del rapporto fornito.Alcune volte i rapporti sono molto complessi e ogni procedura memorizzata potrebbe avere dozzine di oggetti dipendenti e ogni oggetto dipendente può dipendere da altre dozzine di oggetti.

Aveva bisogno di un modo per trovare ricorsivamente tutti gli oggetti dipendenti di una determinata procedura memorizzata.Ho scritto una query ricorsiva usando CTE per raggiungere questo obiettivo.

Answer 8

Lo strumento migliore per il reverse engineering è APEX.È fantastico.Può persino tracciare gli assembly .NET e dirti dove vengono utilizzati i processi.È di gran lunga il prodotto più profondo del suo genere.RedGate ha altri ottimi strumenti ma non in questo caso.