Espero que esta 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, então me bata com ela.
Não sou um DBA de verdade, sou um desenvolvedor de software que está percebendo que precisamos de um DBA e, no entanto, a loja em que trabalho não tem 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, então 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 ajudam a provar que os procedimentos armazenados realmente funcionam. A lógica que eles executam é uma parte fundamental de nosso aplicativo, pode-se dizer, são as "jóias da coroa" do principal produto de nossa empresa, e o modo como ele funciona é completamente não documentado.
Estou procurando a documentação técnica específica que um DBA profissional pode esperar que exista, ou que possa escrever a si mesmo, se necessário, para entender uma rede gigante de procedimentos armazenados que chamam uns aos outros.
Qual é o formato usual para documentar um grande procedimento armazenado? Descrição dos valores esperados para cada parâmetro In (ou seja, "pré-condições", "pós-condições", ou seja, para parâmetros booleanos, o que muda quando você liga ou desliga, etc?)
Como alguém costuma documentá-lo? Somente comentários SQL? Ferramentas externas que são específicas para o propósito? "Documentação" externa? Não temos ferramentas SQL, além do MS SQL Management studio, mas estamos nos perguntando se existe uma ferramenta que torne melhor a compreensão, a documentação e o teste de nosso ambiente. Talvez seja uma maneira melhor de fazer minha pergunta; Que 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 cobertura de teste de unidade para os procedimentos armazenados.
B. Mostre aos desenvolvedores de aplicativos cliente como chamar corretamente cada um desses procedimentos armazenados complexos.
C. Teste de unidade nossos procedimentos armazenados.
O mais importante sobre a documentação é que ela faça sentido para você. Não há uma maneira realmente padrão de fazer isso.
Se você tem muitos procedimentos armazenados que se conectam uns aos outros, 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 um procedimento para outro provavelmente é um bom começo.
A ferramenta RedGate SQL Dependency Tracker pode ser útil. Ele pode mostrar graficamente quais objetos do banco de dados (SP's/views/tables) dependem uns dos outros. Eu o usei enquanto trabalhava com algumas tabelas com as quais não estava familiarizado para determinar a ordem na qual desabilitar as restrições.
Eu também executei em todo o banco de dados apenas por diversão e foi muito TMI. Se você for capaz de focar em áreas específicas do banco de dados que não são totalmente interdependentes, pode ser útil. A árvore de dependências tem opções para se organizar visualmente usando diferentes algoritmos e só isso já faz uma avaliação valer a pena.
Rastreamento. Outra opção é gravar linhas de log no início e no final de procedimentos armazenados críticos. Cada linha pode incluir uma data, um "nível de detalhe", um "contexto" de melhor palpite, "subcontexto" e nome do procedimento. e contagens de linhas. 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 de log, ele poderá ser ligado/desligado facilmente sem muita carga adicional (ymmv).
Nota lateral, uma vez carreguei a impressora com o papel legal de 11 x 17, encontrei uma fonte pequena e agradável e algum recuo lógico para resumir um fluxo complexo de dados/SP em ~ 5 páginas de algum pseudo-SQL. Tenho certeza que acabei me referindo a ele apenas algumas vezes e ninguém mais ousou chegar perto, 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!