Documentando uma gigantesca rede de procedimentos armazenados inter-relacionados em um banco de dados MS SQL: Que ferramenta ou formato?

Espero que essa seja uma pergunta com uma resposta mais curta do que "Leia um livro de 1000 páginas", mas, se essa for a situação real, acerte-me com ela.

Não sou um DBA real, sou um desenvolvedor de software que está percebendo que precisamos de um DBA e, no entanto, a loja em que trabalho tem zero DBAs. No entanto, nosso design de banco de dados MS SQL, incluindo vários procedimentos armazenados principais, é uma bagunça gigante. Os procedimentos armazenados são lentos, suspeitamos que eles tenham bugs, mas nem sabemos como eles devem funcionar, portanto, não sabemos como corrigi-los.

Para começar, decidi que documentaremos como tudo deve funcionar; depois, iniciaremos o teste de unidade e criaremos um conjunto de testes de unidade que ajudarão a provar que os procedimentos armazenados realmente funcionam. A lógica que eles executam é uma parte essencial da nossa aplicação, você poderia dizer, são as "joias da coroa" do principal produto da nossa empresa, e a maneira como funciona é completamente indocumentada.

Estou procurando a documentação técnica específica que um DBA profissional pode esperar que exista, ou possa escrever por conta própria, se necessário, para entender uma gigantesca rede de procedimentos armazenados que se chamam.

1. Qual é o formato usual para documentar um procedimento armazenado grande? Descrição dos valores esperados para cada Parâmetro In (por exemplo, "pré-condições", "pós-condições", ou seja, para parâmetros booleanos, o que muda quando você o liga ou desliga, etc?)

2. Como se costuma documentar isso? Apenas comentários SQL? Ferramentas externas específicas para o objetivo? "Documentação" externa? Não temos ferramentas SQL, além do estúdio MS SQL Management, mas estamos nos perguntando se existe uma ferramenta que melhore a compreensão, a documentação e o teste de nosso ambiente. Talvez seja a melhor maneira de fazer minha pergunta; Qual ferramenta eu preciso para resolver nossa bagunça?

Nosso objetivo é ser capaz de:

R. Use a documentação que geramos, ou quaisquer ferramentas que adicionamos ao nosso ambiente, para ajudar a entender como os procedimentos devem funcionar, para que possamos criar uma cobertura de teste de unidade para os procedimentos armazenados.

B. Mostre aos desenvolvedores do aplicativo cliente como chamar adequadamente cada um desses procedimentos armazenados complexos.

C. Teste de unidade de nossos procedimentos armazenados.

A coisa mais importante sobre a documentação é que faz sentido para você. Não existe uma maneira realmente padrão de fazer isso.

Se você tem muitos procedimentos armazenados que se conectam, começando com um diagrama do Visio com um objeto para cada procedimento, os links entre eles para que você possa acompanhar como as coisas vão de procedimento para procedimento provavelmente são um bom começo.

A ferramenta RedGate SQL Dependency Tracker pode ser útil. Ele pode mostrar graficamente quais objetos de banco de dados (SPs / visualizações / tabelas) dependem um do outro. Usei-o enquanto trabalhava com algumas tabelas com as quais não estava familiarizado para determinar a ordem na qual desabilitar restrições.

Eu também o executei em todo o banco de dados apenas por diversão e foi o modo TMI. Se você conseguir focar em áreas específicas do banco de dados que não sejam interdependentes, isso pode ser útil. A árvore de dependência tem opções para se organizar visualmente usando algoritmos diferentes e isso por si só faz uma avaliação valer a pena.

Rastreamento. Outra opção é escrever linhas de log no início e no final dos procedimentos armazenados críticos. Cada linha pode incluir uma data, um "nível de detalhe", um "contexto" de melhor suposição, "subcontexto", nome do processo. e rowcounts. Provavelmente será uma bagunça (pense no log de eventos do Windows), mas talvez seja útil em algumas seções. Se um SP for usado para realmente fazer a inserção do log, ele poderá ser ligado / desligado facilmente sem muita carga adicional (ymmv).

Nota: uma vez eu carreguei a impressora com o papel legal 11 x 17, encontrei uma fonte minúscula e um recorte lógico para resumir um fluxo complexo de dados / SPs em ~ 5 páginas de algum pseudo-SQL. Tenho certeza de que só acabei me referindo a ele algumas vezes e ninguém mais se atreveu a se aproximar, pois lá não era padrão e é difícil confiar em algo não integrado e que pode ficar desatualizado. O processo de documentação forçou uma familiaridade com o código!

Paul White me transformou na ferramenta gratuita Atlantis Schema Surf da Atlantis Interactive, que pode ser de alguma ajuda para você.