Pregunta

Estamos teniendo problemas con una gran cantidad de procedimientos almacenados heredados en funcionamiento.¿Recomiendan alguna herramienta que pueda ayudar a comprender mejor esos procedimientos?Algún tipo de ingeniería inversa que identifique dependencias entre procedimientos y/o procedimiento vs.dependencias de tablas.Puede ser una herramienta gratuita o comercial.

¡Gracias!

¿Fue útil?

Solución

Redgate tiene un producto bastante caro llamado Rastreador de dependencia SQL que parece cumplir los requisitos.

Otros consejos

La solución más económica que el 'rastreador de dependencias' es la tabla del diccionario de datos sys.sql_dependencies desde 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 las vistas equivalentes USER_ y ALL_).Usando las otras tablas del diccionario de datos (sys.tables/DBA_TABLES), etc.puede generar informes de dependencia de objetos.

Si se siente especialmente interesado, puede utilizar una consulta recursiva (Oracle CONNECT BY o SQL Server Common Table Expressions) para crear un gráfico completo de dependencia de objetos.

A continuación se muestra un ejemplo de un CTE recursivo en sys.sql_dependencies.Devolverá una entrada para cada dependencia con su profundidad.Los elementos pueden ocurrir más de una vez, posiblemente en diferentes profundidades, para cada relación de dependencia.No tengo una instancia de Oracle funcional a mano para crear una consulta CONNECT BY en DBA_DEPENDENCIES, por lo que cualquier persona con privilegios de edición, tiempo y experiencia puede anotar o editar esta respuesta.

Tenga en cuenta también con sys.sql_dependencies del que puede obtener referencias de columnas referenced_minor_id.Esto podría usarse (por ejemplo) para determinar qué columnas se usaron realmente en los procesos ETL desde un área de preparación con copias de las tablas de base de datos del origen 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 abrirme a la comunidad ahora.¿Alguien con acceso conveniente a una instancia de Oracle en ejecución podría publicar una consulta recursiva CONNECT BY aquí?Tenga en cuenta que esto es específico del servidor SQL y desde entonces el propietario de la pregunta dejó en claro que está usando Oracle.No tengo a mano una instancia de Oracle en ejecución para desarrollar y probar nada.

Pienso que el Rastreador de dependencia de Red Gate mencionado por rpetrich es una solución decente, funciona bien y Red Gate tiene una prueba de 30 días (idealmente el tiempo suficiente para que puedas hacer tus análisis forenses).

También consideraría aislar el sistema y ejecutar el SQL Profiler que le mostrará todas las acciones SQL en las tablas.Esto es a menudo un Buen punto de partida para construir un diagrama de secuencia o como usted elija documentar estos códigos..¡Buena suerte!

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

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

Editar según el comentario: Dado que estás usando Oracle, echa un vistazo a SAPO.Utilizo una función llamada Code Roadmap, que le permite mostrar gráficamente las interdependencias PL/SQL dentro de la base de datos.Puede ejecutarse en modo Solo código, que muestra las dependencias de la pila de llamadas en tiempo de ejecución, o en modo Código más datos, donde también muestra los objetos de la base de datos (tablas, vistas, activadores) que son tocados por su código.

(Nota: soy usuario de TOAD y no obtengo ningún beneficio al recomendarlo)

Esto no es muy profundo ni exhaustivo, pero creo que si estás usando MS SQL Server u Oracle (quizás Nigel pueda ayudarte con una muestra de PL-SQL)... Nigel tiene razón.Esto solo abarca 3 dependencias de profundidad, pero podría modificarse para llegar a la profundidad que necesite.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

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 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 forma de encontrar recursivamente todos los objetos dependientes de un procedimiento almacenado dado.Escribí una consulta recursiva usando CTE para lograr esto.

La mejor herramienta para la ingeniería inversa es APEX.Es asombroso.Incluso puede rastrear ensamblajes .NET e indicarle dónde se utilizan los procesos.Es, con diferencia, el producto más profundo de su tipo.RedGate tiene otras herramientas excelentes, pero no en este caso.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top