database - Procedimientos almacenados ingeniería inversa

stored-procedures reverse-engineering

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

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

Edición basada en comentarios: dado que estás usando Oracle, 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 TOAD y no obtengo ningún beneficio al referirme)

Answer 2

Creo que Red Gate Dependency Tracker mencionado por 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 que pueda hacer su análisis forense).

También consideraría aislar el sistema y ejecutar el Analizador de SQL que le mostrará toda la acción de SQL en las tablas . Este es a menudo un buen punto de partida para construir un diagrama de secuencia o como quiera que documente estos códigos . ¡Buena suerte!

Answer 3

Esto no es realmente profundo o exhaustivo, pero creo que si estás usando 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 lo más bonito ... 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 4

La mejor herramienta para la ingeniería inversa es 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 5

La solución más económica que el "rastreador de dependencias" es la tabla de diccionarios de datos sys.sql_dependencies a partir de la cual se pueden consultar estos datos 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 se siente particularmente interesado, puede usar una consulta recursiva (Oracle CONNECT BY o SQL Common Common Table Expressions) para construir 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 columna 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 a la comunidad ahora. ¿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

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 7

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

Answer 8

Cómo encontrar la cadena de dependencia de un objeto de base de datos (MS SQL Server 2000 (?) +) Por Jacob Sebastian

Cada vez que necesita implementar un nuevo informe o modificar un informe existente, necesita saber cuáles son los objetos de la base de datos que dependen del procedimiento almacenado del informe. 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 forma de encontrar recursivamente todos los objetos dependientes de un procedimiento almacenado dado. Escribí una consulta recursiva usando CTE para lograr esto.