Procedimientos almacenados Ingeniería inversa

Question

Estamos teniendo problemas con una gran cantidad de procedimientos almacenados heredados en el trabajo. ¿Ustedes recomiendan alguna herramienta que pueda ayudar a entender mejor esos procedimientos? Algún tipo de ingeniería inversa que identifica dependencias entre procedimientos y/o procedimientos frente a dependencias de tablas. Puede ser una herramienta gratuita o comercial.

Gracias!

Answer 1

Redgate tiene un producto bastante caro llamado SQL Dependency Tracker que parece cumplir los requisitos.

Answer 2

Creo que Red Gate Dependency Tracker mentioned by rpetrich es una solución decente, funciona bien y Red Gate tiene una duración de prueba de 30 días (idealmente el tiempo suficiente para hacer su análisis forense).

También consideraría aislar el sistema y ejecutar SQL Profiler, que le mostrará toda la acción de SQL en las tablas. Suele ser un , un buen punto de partida para construir un diagrama de secuencia o como prefiera documentar estos códigos. ¡Buena suerte!

Answer 3

Redgate SQL Doc. la documentación generada incluía información de dependencia de referencias cruzadas. Por ejemplo, para cada tabla, enumera vistas, procedimientos almacenados, activadores, etc. que hacen referencia a esa tabla.

Answer 4

¿En qué base de datos están los procedimientos almacenados? Oracle, SQL Server, ¿algo más?

Editar Basado en comentario: Dado que estás utilizando Oracle, entonces, echa un vistazo a TOAD. Utilizo una función llamada Code Roadmap, que le permite visualizar gráficamente las interdependencias PL/SQL dentro de la base de datos. Puede ejecutarse en modo Sólo código, mostrando las dependencias de la pila de llamadas en tiempo de ejecución o el modo de datos Code Plus, donde también muestra los objetos de la base de datos (tablas, vistas, activadores) que tocó su código.

(Nota - Soy un usuario de SAPO, y no se benefician de referirla)

Answer 5

La solución más barata que la 'dependencia de seguimiento' es el sys.sql_dependencies tabla de diccionario de datos que a partir de la cual estos datos se pueden consultado desde el diccionario de datos. Oracle tiene una vista de diccionario de datos con una funcionalidad similar llamada DBA_DEPENDENCIES (más USER_ equivalente y ALL_ views). Usando las otras tablas de diccionarios de datos (sys.tables/DBA_TABLES) etc. puede generar informes de dependencia de objetos.

Si te sientes particularmente interesado, puedes utilizar una consulta recursiva (Oracle CONNECT BY o SQL Server Common Table Expressions) para crear un gráfico completo de dependencia de objetos.

Aquí hay un ejemplo de un CTE recursivo en sys.sql_dependencies. Devolverá una entrada para cada dependencia con su profundidad. Los elementos pueden aparecer más de una vez, posiblemente a diferentes profundidades, para cada relación de dependencia. No tengo a mano una instancia de Oracle que funcione para crear una consulta CONNECT BY en DBA_DEPENDENCIES, por lo que cualquier persona con privilegios de edición y el tiempo y la experiencia es bienvenido para anotar o editar esta respuesta.

Tenga en cuenta también con sys.sql_dependencies que puede obtener referencias de columnas de referenced_minor_id. Esto podría usarse (por ejemplo) para determinar qué columnas se usaron realmente en los scripts ETL de un área de ensayo con copias de las tablas de DB de la fuente con más columnas de las que realmente se usan.

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 

Tengo esto para abrir ahora a la comunidad.¿Podría alguien con acceso conveniente a una instancia de Oracle en ejecución publicar una consulta recursiva CONNECT BY aquí? Tenga en cuenta que esto es específico del servidor SQL y que el propietario de la pregunta dejó claro que está usando Oracle. No tengo una instancia de Oracle en ejecución para desarrollar y probar nada.

Answer 6

Esto no es realmente profundo o exhaustivo, pero creo que si está utilizando MS SQL Server u Oracle (quizás Nigel puede ayudar con una muestra de PL-SQL) ... Nigel está trabajando en algo. Esto solo tiene 3 dependencias profundas, pero podría modificarse para que llegue a la profundidad que necesites. No es la cosa más bonita ... pero es funcional ...

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

La única mejor herramienta para la ingeniería inversa es por APEX. Es asombroso. Incluso puede rastrearse en ensamblados .NET y decirle dónde se usan los procs. Es, con mucho, el producto más profundo de su tipo. RedGate tiene otras excelentes herramientas, pero no en este caso.

Answer 8

How to find the dependency chain of a database object (MS Server 2000 (?) + SQL) por Jacob Sebastián

Cada vez que necesita para desplegar un nuevo informe o modificar un informe existente , lo que necesita saber cuáles son los objetos de la base que dependen de el procedimiento almacenado informe dado. Algunas veces los informes son muy complejos y cada procedimiento almacenado puede tener docenas de objetos dependientes y cada objeto dependiente puede depender de otras docenas de objetos .

Necesitaba una manera de encontrar recursivamente todos los objetos dependientes de un procedimiento almacenado dado. Escribí una consulta recursiva usando CTE para lograr esto.