Como posso rastrear dependências de banco de dados?

À medida que os aplicativos internos evoluem ao longo de vários anos, você ocasionalmente descobre que existem várias tabelas que as pessoas acreditam que não são mais relevantes e desejam selecionar. Quais são os métodos práticos para identificar as dependências do banco de dados, tanto no ambiente SQL, como talvez em diante, como SSIS?

Já trabalhei em locais onde opções bastante brutais foram adotadas, como:

• Solte primeiro, faça perguntas mais tarde (pode eliminar uma construção de armazém de dados se tentar extrair uma tabela que não existe mais)
• Remova as permissões primeiro e aguarde que os erros sejam relatados (podem causar erros silenciosos, se a falha não for tratada corretamente)

Aprecio que o SQL Server vem com ferramentas para rastrear dependências nessa instância, mas elas parecem ter problemas se você tiver bancos de dados em instâncias diferentes. Existem opções que facilitam a consulta de dependências, talvez respondendo a perguntas como "Onde esta coluna é usada?" com respostas como "Acabou neste outro servidor neste procedimento armazenado" ou "Acabou neste pacote SSIS"?

Não há uma maneira fácil de fazer isso. Os gatilhos não funcionam, como se você selecionasse em uma tabela nenhum gatilho é acionado. A melhor maneira que encontrei para fazer isso é fazer com que os desenvolvedores rastreiem o que usam. Quando algo for descartado, verifique com todas as equipes de desenvolvimento e, depois que todos terminarem, renomeie o objeto. Então nada é interrompido por um mês ou até, o objeto pode ser descartado com segurança.

1. Código de pesquisa para uso com sys.sql_modules.definition: está relacionado? Então...
2. Verifique as permissões: qual código de cliente pode chamá-lo? Então...
3. perfil

Portanto:

• Para uma tabela sem referência e sem permissões, ela não está sendo usada.
• Sem referências e algumas permissões, execute o profiler para ver o uso
• Sem permissões e referências, adicione log de uso

O que eu fiz antes é tornar a tabela uma visualização que mascara a tabela e, em seguida, faz com que a visualização tenha um desempenho ruim: (junção cruzada em si, distinta). Na verdade, você não o remove, mas gera tempos limite ou reclamações do cliente ...

Uma maneira rápida que eu usei no passado (e realmente depende do tamanho das tabelas, número de desempenho dos índices etc.) é adicionar um gatilho, que registra um carimbo de data / hora quando uma ação é executada na tabela. Como eu disse, isso pode ter problemas de desempenho, portanto, precisa ser tratado com cuidado - observe também que sua tabela de log não usa campos de identidade, pois isso pode danificar algum código antigo que usa @@ IDENTITY. Obviamente, isso pode apenas mostrar que um recurso em um aplicativo não é usado há algum tempo.

É muito difícil rastrear dependências quando todo o código que pode atingir o banco de dados não está no banco de dados, ou seja, clientes aleatórios consultando o banco de dados.

EDIT: Para abordar o ponto em que uma tabela não pode ter gatilhos SELECT, aqui está outra opção que deve funcionar, supondo que suas tabelas tenham índices (testados apenas em 2008).

SELECT          
    last_user_seek,
    last_user_scan,
    last_user_lookup,
    last_user_update
FROM
    sys.dm_db_index_usage_stats AS usage_stats
INNER JOIN
sys.tables AS tables ON tables.object_id = usage_stats.object_id
WHERE
    database_id = DB_ID() AND
    tables.name = 'mytable' 

mas observe que a tabela de estatísticas de uso é limpa quando o servidor é reiniciado, desanexado etc. Portanto, você precisa configurar um trabalho para coletar os dados. Um pouquinho, eu sei.

Uma maneira que eu usei no passado foi estabelecer uma lista de tabelas de candidatos para remover e renomeá-las e procurar falhas.

Como estabeleci a lista:

1. ver quais tabelas não estão em uso nos procedimentos, gatilhos e funções armazenados atuais

2. tabelas vazias (zero registros);

3. tabelas não referenciadas (tabelas que não possuem nenhum relacionamento);

4. veja quais tabelas não estavam em uso desde que o DB Server foi iniciado (DMVs)

Depois de criar a lista em um arquivo de texto, criei um script em lote que analisaria nossos arquivos .cs (estamos tendo apenas projetos .net) da pasta de controle de versão mapeada local e ver se essas tabelas são usadas nos arquivos .cs ( não deveria acontecer, mas ei ... eu tive surpresas). Se não, então é claro, se sim, criamos uma lista e damos aos desenvolvedores para verificar se esse módulo ainda está em uso.

Então, resumindo, os caras anteriores estão certos, não há bala de prata.

A política que estou implementando na minha empresa é colocar tudo o que toca o SQL Server sob controle de origem, em um local central.

• projetos asp.net
• Projetos SSRS
• Projetos SSIS
• Eu até escrevo todos os objetos de banco de dados em um tipo de repositório.

Ainda não o tenho configurado, mas, eventualmente, quero implementar algum tipo de mecanismo de pesquisa de índice / central que eu poderia usar para pesquisar tabelas, sprocs etc. específicos. Na verdade, somos uma nova loja do SQL Server - convertendo do FoxPro . Objetos SQL antigos não são um grande problema ainda, mas estou planejando o futuro.

O problema que vejo com a abordagem de renomeação / rastreamento é que algumas coisas acontecem apenas anualmente, e nem todos os anos. Sem mencionar as várias coisas ad-hoc que as pessoas pedem para você escrever e depois pedir novamente meses ou anos depois.

Há uma variedade de ferramentas e técnicas para usar no rastreamento de dependências, envolvendo:

Ferramentas que eu conheço:

• Visualizador de Dependências do SQL Server (mas pode ter problemas se sp usando a tabela foi criada antes da criação da tabela)
• Rastreador de Dependência SQL Redgate (via resposta de @Eric Humphrey)
• Re-compartilhador (ferramenta .net que pode ser usada para procurar caminhos de chamada, acho que pode ser usada para rastrear onde as principais chamadas SQL são usadas)

Métodos

• O código procura o uso de objetos SQL (embora replique algumas das ferramentas acima)

• Olhe para as estatísticas de uso (ou seja: quando foi chamado pela última vez um objeto SQL), eu uso o SQL abaixo:

  SELECT 
      last_execution_time,   
      (SELECT TOP 1 
          SUBSTRING(s2.text,statement_start_offset / 2+1 , 
              ((CASE WHEN statement_end_offset = -1 THEN 
                  (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
              ELSE statement_end_offset END) - statement_start_offset) / 2+1)
      )  AS sql_statement,
      execution_count
  FROM sys.dm_exec_query_stats AS s1 
  CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
  WHERE 
      s2.text like '%[OBJECT NAME]%' 
      and last_execution_time > [DATE YOU CARE ABOUT]
  ORDER BY last_execution_time desc

Nota : A tabela de estatísticas de uso é limpa quando o servidor é reiniciado, desconectado etc. Portanto, você precisa configurar um trabalho para coletar os dados. Um pouquinho, eu sei. (de @Miles D)

Técnicas

• Pesquise o último uso (veja as estatísticas de uso acima)
• Procure onde é usado (consulte ferramentas)
• Analise o uso do código com os desenvolvedores (via @MrDenny)
• Renomeie o objeto (ou seja: post / prefix com _toBeDropped) e observe os erros
• Altere as permissões e observe os erros
• Largue o objeto e ore

Há vários anos, tentei criar uma ferramenta para verificar coisas semelhantes. A resposta TL; DR é que achei que não era possível fazer com os recursos disponíveis naquele momento.

Onde esta coluna é usada?

Essa pergunta fica mais complicada quando você percebe que várias consultas, exibições e procedimentos armazenados são usados select *na tabela em que a coluna reside. Em seguida, é necessário examinar os programas que usam esses resultados - para que você precise de algum scanner / indexador / analisador capaz de ler código-fonte que pode ser C #, Delphi, Java, VB, ASP (clássico) e assim por diante, apenas para tentar procurar todas as referências a essa coluna. Então você precisa analisar esses programas para tentar identificar se esse código está sendo chamado mais.

Não lidará com referências SQL, mas você pode querer verificar o Rastreador de Dependências SQL da Redgate . É uma boa ferramenta de visualização.

Essa não é realmente uma resposta para sua pergunta, mas acho que vale a pena mencionar: essa é uma das razões pelas quais todos os sistemas fora do banco de dados devem se comunicar por meio de visualizações e sprocs . Você tem os scripts de construção para esses arquivos .sql pesquisáveis, para poder ver facilmente se uma tabela ou coluna específica está sendo usada externamente.

É claro que o SSIS normalmente se conectará diretamente às tabelas, portanto isso provavelmente não ajuda muito sua necessidade no momento. Mas quando os desenvolvedores se conectam ao seu banco de dados e se queixam de ter que esperar você (ou quem quer que esteja servindo como DBA) para criar as visualizações e os sprocs necessários, você pode dizer a eles: "Qualquer tabela ou coluna pode ser excluída ou renomeada." sou obrigado apenas a mantê-lo informado sobre alterações de visualizações e broches ". E eles só precisam fazer testes de regressão para essas mudanças específicas.

TSQL pode ser usado o seguinte sys.dm_sql_referencing_entities ou sys.sql_expression_dependencies

Como alternativa, ferramentas como o SQL Negotiator Pro, Redgate etc. podem gerar isso visualmente para você usando uma GUI