¿Cuál es la mejor manera de depurar los procedimientos almacenados (y escribir sprocs que son más fáciles de depurar)?

Question

¿Cuáles son las buenas metodologías para crear sprocs que reducen el dolor de la depuración? ¿Y qué herramientas hay para depurar procedimientos almacenados?

Quizás lo más importante es, ¿qué indicaciones hay que tener en cuenta para que los errores ocurran en un proceso y no en el código? Espero que no sea del todo terriblemente malo aquí. Votos para respuestas a cualquiera de los anteriores. Gracias.

Por lo que vale, trabajo en un entorno .NET, servidores SQL.

Answer 1

Un par de patrones que he visto utilizar con éxito son los modos de "diagnóstico" o "prueba" y el registro.

modos de prueba o diagnóstico son útiles cuando se está ejecutando SQL dinámico. Asegúrate de que puedes ver lo que vas a ejecutar. Si tiene áreas donde necesita (o debería) verificar errores, considere ingresar a una tabla con suficientes detalles para que pueda diagnosticar lo que está sucediendo.

Answer 2

Puede usar la depuración de servidor Sql, pero he encontrado que es un dolor en cualquier cosa que no sea la más directa de situaciones (depuración en un servidor local, etc.). Todavía tengo que encontrar algo mejor que imprimir declaraciones, por lo que voy a seguir este hilo con interés.

Answer 3

Para las herramientas, puede usar Visual Studio para depurar SP. Si el proceso almacenado tiene lógica larga, puede refactorizarlo, crear un proceso almacenado por separado y llamarlo desde su proceso almacenado principal. Esto ayudará a reducir sus pruebas también y le facilitará encontrar qué parte de las consultas es incorrecta.

Answer 4

TSQLUnit

Este es un marco de pruebas de unidad para SQL Server. No es exactamente una herramienta de depuración clásica, pero sí le permite escribir pruebas unitarias para sus procedimientos almacenados que pueden ayudar tremendamente a identificar errores y validar los comportamientos esperados.

Por ejemplo, si tiene un proceso almacenado con errores, puede escribir algunas pruebas de unidad para comprender cómo está fallando. Además, si realiza un cambio en su código SQL, puede validar que sus cambios no hayan roto ninguna otra cosa o que al menos le indiquen dónde reside un problema.

Si algo es difícil de probar, podría ser una buena indicación de que el proceso almacenado podría estar haciendo demasiado y podría beneficiarse si se dividiera en más foco y procs dirigidos. Estos procesos deberían ser relativamente más fáciles de depurar y mantener a largo plazo.

Answer 5

Aquí hay algunos consejos que me han sido reiterados hoy: si agrega una combinación a una consulta importante en la base de datos de producción, asegúrese de que sea segura cuando haya un campo nulo en la tabla de unión.

LEFT JOIN 

Me rompieron una página importante durante 20 minutos antes de que nos dimos cuenta de que era mi, se precipitó pequeño cambio procedimiento almacenado.

Y asegúrese de probar sus procedimientos cuando realice un cambio. Para hacer esto, me gusta poner una consulta de prueba simple en los comentarios del procedimiento.Obvisouly, no pude hacer esto hoy :-(

/************************************ 
    MyProcName 

    Test: 
    ----- 
    exec MyProcName @myParam 
*************************************/ 

Answer 6

Una técnica que uso en procedimientos almacenados para que sean más fáciles de depurar (sin IDE o depuradores) para SQL Server 2005: procedimientos

agrego una parámetro de entrada llamado @Debug = 0 (por defecto en 0 = apagado) al final de la lista de parámetros para el procedimiento

luego agrego si (@Debug = 1) print '...';.

declaraciones en el código en las coyunturas clave para mostrar cualquier valor interno útil, etc.

Sí, es "vieja escuela" y los depuradores que le permiten "recorrer el código" son geniales, pero esto funciona para cualquier persona desde cualquier herramienta SQL (incluida la depuración sin su IDE).

Ron

Answer 7

Otra técnica que utilizo para ambos sencilla salida de registro y depuración es crear una variable de tabla en la parte superior del procedimiento:

--************************************************************************** 
    -- Create a log table variable to store messages to be returned to the 
    -- calling application. 
    --************************************************************************** 
    declare @log    as table (msg varchar(MAX)); 

then 

    insert into @log values ('Inserted a new DVO Order into IRMA, order id: [' + convert(varchar(10), @@IDENTITY) + ']'); 
etc. 

then ... 

    select msg from @log; 
end 

al final del procedimiento - esto depende de qué tan bien la aplicación que llama registra la salida de su llamada de procedimiento, pero la aplicación que escribí lo registra todo. :-)

Answer 8

Puede que esta no sea la respuesta que está buscando pero si ya se encuentra en un entorno .Net LINQtoSQL ha reducido considerablemente la cantidad de procesos almacenados que escribo/uso/necesito depurar.

La dificultad de depurar SQL es una de las razones por las que la lógica de programación de negocios en LINQ es mi nueva práctica preferida.

Answer 9

He notado muchas sugerencias sobre el uso de diferentes entornos y técnicas para depurar procesos SQL, pero nadie ha mencionado DBFit. Si no está familiarizado con Fit y FitNesse, hágase un favor y búsquelo. Utilizando estas tres herramientas puede construir rápidamente un conjunto completo de pruebas de aceptación que le darán la tranquilidad de saber que puede refactorizarse con impunidad.

DBFit es simplemente una serie de accesorios que se pueden utilizar para ejercitar una base de datos. Usando Fitness puedes escribir tantas permutaciones de llamadas en tu proceso almacenado como quieras para crear pruebas.

Esto no está depurando per se, pero se sorprendería de la rapidez con que puede identificar un problema una vez que tenga una batería completa de pruebas contra un solo proceso almacenado. Una prueba fallida lo llevará directamente al problema y le dará el contexto exacto con el que falló, por lo que no hay que adivinar. Además de todo esto, ahora puedes refactorizar tus procesos almacenados sin miedo porque simplemente tendrás que volver a ejecutar las pruebas para asegurarte de que no hayas roto nada.

Answer 10

SQL Server 2008 depurador integrado realizado paso a paso la depuración de un juego de niños del estudio de la gerencia (en comparación con el judo necesario para encontrar la manera de llegar VS2005 + SQL para depurar)

Answer 11

Ésta puede ser una preferencia personal, pero me resulta extremadamente difíciles de leer consultas SQL que están todas abrochadas en una larga línea. Yo prefiero el siguiente estilo de sangría:

SELECT 
    [Fields] 
FROM 
    Table 
WHERE 
    x = x 

Esta sencilla práctica me ha ayudado mucho al escribir procedimientos almacenados para un nuevo esquema de base de datos.Al dividir las declaraciones en muchas líneas, es más fácil identificar el culpable de un error en su consulta. En SQL Server Management Studio, por ejemplo, se proporciona el número de línea de la excepción, por lo que puede apuntar al código problemático mucho más rápido.

Sea sencillo con sus compañeros desarrolladores ... no meta 800 caracteres de una consulta SQL en una sola línea. Más adelante te agradecerás si el nombre de campo o el tipo de datos de una base de datos cambia y nadie te envía un correo electrónico.

Answer 12

Al igual que Ron's Logging, llamamos a un proceso de registro a través de todos los demás procedimientos almacenados para ayudar a obtener el seguimiento en todas las llamadas. Se utiliza un BatchId común para permitir el seguimiento de una determinada ejecución por lotes. Posiblemente no sea el proceso más eficiente, pero ayuda mucho a rastrear fallas. También es bastante simple compilar informes de resumen para administradores de correo electrónico.

es decir.

Select * from LogEvent where BatchId = 'blah' 

ejemplo de la llamada

EXEC LogEvent @Source='MyProc', @Type='Start' 
, @Comment='Processed rows',@Value=50, @BatchId = @batchNum 

principal Proc

CREATE PROCEDURE [dbo].[LogEvent] 
    @Source varchar(50), 
    @Type varchar(50), 
    @Comment varchar(400), 
    @Value decimal = null, 
    @BatchId varchar(255) = 'BLANK' 
AS 

IF @BatchId = 'BLANK' 
    SET @BatchId = NEWID() 

    INSERT INTO dbo.Log 
    (Source, EventTime, [Type], Comment, [Value],BatchId) 
    VALUES 
    (@Source, GETDATE(), @Type, @Comment, @Value,@BatchId) 

En el futuro, sería bueno para aprovechar el CLR y mirar a llamar algo así como Log4net a través de SQL. Como nuestro código de aplicación usa Log4Net, sería ventajoso integrar el lado SQL de los procesos en la misma infraestructura.

Answer 13

Le sugiero encarecidamente que eche un vistazo a las herramientas integradas en SQL Management Studio.

he escrito un post bastante detallada blog sobre ello aquí:

http://www.diaryofaninja.com/blog/2010/11/23/debugging-sql-queries-function-amp-stored-procedures-with-sql-management-studio

básicamente el quid de la cuestión es que se introduce de consultas SQL para ejecutar el procedimiento almacenado, y en lugar de pulsar F5 o golpear la exclamación, presiona el botón de reproducción y usa F10 y F11 para avanzar y entrar en tus procesos almacenados.

muy, muy útil, y parece que nadie lo usa.