Pergunta

Estamos tendo problemas com um grande número de procedimentos armazenados legados em funcionamento.Vocês recomendam alguma ferramenta que possa ajudar a entender melhor esses procedimentos?Algum tipo de engenharia reversa que identifica dependências entre procedimentos e/ou procedimentos vs.dependências de tabelas.Pode ser uma ferramenta gratuita ou comercial.

Obrigado!

Foi útil?

Solução

Redgate tem um produto bastante caro chamado Rastreador de Dependência SQL que parece preencher os requisitos.

Outras dicas

A solução mais barata que o 'rastreador de dependência' é a tabela de dicionário de dados sys.sql_dependencies, a partir da qual esses dados podem ser consultados no dicionário de dados.O Oracle possui uma visualização de dicionário de dados com funcionalidade semelhante chamada DBA_DEPENDENCIES (mais visualizações USER_ e ALL_ equivalentes).Usando as outras tabelas de dicionário de dados (sys.tables/DBA_TABLES) etc.você pode gerar relatórios de dependência de objetos.

Se você estiver particularmente interessado, poderá usar uma consulta recursiva (Oracle CONNECT BY ou SQL Server Common Table Expressions) para construir um gráfico completo de dependência de objetos.

Aqui está um exemplo de CTE recursivo em sys.sql_dependencies.Ele retornará uma entrada para cada dependência com sua profundidade.Os itens podem ocorrer mais de uma vez, possivelmente em profundidades diferentes, para cada relacionamento de dependência.Não tenho uma instância Oracle funcional disponível para criar uma consulta CONNECT BY em DBA_DEPENDENCIES, portanto, qualquer pessoa com privilégios de edição e tempo e experiência pode anotar ou editar esta resposta.

Observe também com sys.sql_dependencies onde você pode obter referências de colunas referenced_minor_id.Isso poderia ser usado (por exemplo) para determinar quais colunas foram realmente usadas nos sprocs ETL de uma área de teste com cópias das tabelas de banco de dados da origem com mais colunas do que realmente usadas.

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

Tenho que abrir isso para a comunidade agora.Alguém com acesso conveniente a uma instância Oracle em execução poderia postar uma consulta recursiva CONNECT BY aqui?Observe que isso é específico do servidor SQL e o proprietário da pergunta deixou claro que está usando o Oracle.Não tenho uma instância do Oracle em execução para desenvolver e testar nada.

Eu acho que o Red Gate Dependency Tracker mencionado por rpetrich é uma solução decente, funciona bem e o Red Gate tem 30 dias de teste (idealmente, tempo suficiente para você fazer sua análise forense).

Eu também consideraria isolar o sistema e executar o SQL Profiler que mostrará todas as ações SQL nas tabelas.Isto é muitas vezes um bom ponto de partida para construir um diagrama de sequência ou como você decidir documentar esses códigos.Boa sorte!

Documento SQL Redgate.a documentação gerada incluía informações de dependência com referência cruzada.Por exemplo, para cada tabela, ele lista visualizações, procedimentos armazenados, gatilhos, etc., que fazem referência a essa tabela.

Em qual banco de dados estão os procedimentos armazenados?Oracle, SQL Server, algo mais?

Editar com base no comentário: Dado que você está usando Oracle, dê uma olhada em SAPO.Eu uso um recurso chamado Code Roadmap, que permite exibir graficamente interdependências PL/SQL dentro do banco de dados.Ele pode ser executado no modo Code Only, mostrando dependências da pilha de chamadas de tempo de execução, ou no modo Code Plus Data, onde também mostra objetos de banco de dados (tabelas, visualizações, gatilhos) que são tocados pelo seu código.

(Observação: sou um usuário do TOAD e não obtenho nenhum benefício ao indicá-lo)

Isso não é muito profundo ou completo, mas acho que se você estiver usando o MS SQL Server ou Oracle (talvez Nigel possa ajudar com um exemplo de PL-SQL) ... Nigel está no caminho certo.Isso atinge apenas 3 dependências de profundidade, mas pode ser modificado para ir até a profundidade necessária.Não é a coisa mais bonita... mas é 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

Como encontrar a cadeia de dependências de um objeto de banco de dados (MS SQL Server 2000(?) +) Direção: Jacob Sebastian

Toda vez que ele precisar implantar um novo relatório ou modificar um existente relatório, ele precisa saber quais são os objetos de banco de dados que dependem de o procedimento armazenado do relatório fornecido.Algumas vezes os relatos são muito complexo e cada procedimento armazenado pode ter dezenas de dependentes objetos e cada objeto dependente pode ser dependendo de outras dezenas de Objetos.

Ele precisava de uma maneira de encontrar recursivamente todos os objetos dependentes de um determinado procedimento armazenado.Eu escrevi uma consulta recursiva usando CTE para conseguir este.

A melhor ferramenta para engenharia reversa é a APEX.É incrível.Ele pode até rastrear assemblies .NET e informar onde os procs são usados.É de longe o produto mais profundo desse tipo.RedGate tem ótimas outras ferramentas, mas não neste caso.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top