Depuração do procedimento armazenado SQL com segurança no processo de produção

5

Temos um número enorme de procedimentos armazenados SQL aninhados e várias maneiras diferentes de depurá-los (variando de desenvolvedor para desenvolvedor).

Até agora, nossos métodos incluem:

  1. Um parâmetro opcional @debug , que faz com que o procedimento print mensagens enquanto é executado (passando a variável até chamada procedimentos).

  2. Verificando @@servername em relação a um tabela de nomes de servidores de teste e print ing como acima

  3. Escrevendo tudo o procedimento faz para uma tabela de log (em produção e teste)

Qual destes é preferível (e porquê), ou existe um método melhor que negligenciamos?

    
por Stu Pegg 14.10.2010 / 13:07
fonte

3 respostas

4

Você também deve considerar o SQL Server Profiler . No SQL Server Management Studio, selecione Ferramentas - > SQL Server Profiler. Quando a janela do profiler abrir, selecione File - > New Trace ... (Eu não sei detalhes sobre outros RDBMSs, mas eles precisam ter ferramentas com funcionalidades semelhantes).

Como solução de longo prazo, é claro que você deve remover a lógica de negócios dos procedimentos armazenados.

    
por 14.10.2010 / 15:06
fonte
2

Eu prefiro # 1 pessoalmente. Com um sinalizador @debug , você pode especificar se o código de produção é executado ou não, e descubro que print messages são uma das coisas mais úteis para se tentar descobrir o que está acontecendo.

    
por 14.10.2010 / 14:40
fonte
1

Eu uso um sinalizador @debug ou @test como a variável de entrada para todos os procs armazenados complexos.

O que eu faço com isso depende do proc. Normalmente, eu emito uma reversão se estiver no modo de teste. Também posso mostrar os resultados de várias inserções antes da reversão para ver se o que eu esperava era o que recebi.

Se eu tiver SQL dinâmico quando usar o @debug e nesse caso imprimo o sql em vez de executá-lo, então posso verificar a instrução SQL produzida.

É claro que posso ter um @test (usado somente quando estou afetando dados e quero ter certeza de que posso reverter isso) e um @debug (para imprimir o SQl dinâmico) no mesmo proc, embora eu geralmente não use Execute os dois modos ao mesmo tempo.

Eu também usei uma @print para imprimir as etapas conforme eu for se eu estiver depurando (ajuda muito para ver onde a coisa falhou!) ou, alternativamente, você pode usar uma variável de tabela para manter as etapas processadas ou qualquer código de erro e, em seguida, selecione a partir da variável de tabela após a reversão, quando no modo de teste, para ver o que realmente aconteceu. Você pode até mesmo inserir os valores da variável table em uma tabela permanente se precisar ver os dados ao longo do tempo (fazemos isso para importações complexas para mostrarmos ao cliente com que frequência os dados ruins quebraram a importação e nos fizeram ter que trabalhe para corrigir o problema.) É importante usar uma variável de tabela e não uma tabela temporária para isso, pois ela permanece no escopo após o rollback, uma tabela temporária retorna.

(Observe que o conteúdo da tabela temporária da tabela variável é específico do SQL Server, não sei se isso funcionará com outros bancos de dados.)

Um profiler também pode fornecer o SQL real que foi enviado para o banco de dados e deve ser usado especialmente se você não estiver usando procs armazenados.

    
por 14.10.2010 / 16:51
fonte