Cómo agregar la salida de seguimiento/depuración a los procedimientos almacenados en el servidor SQL (2008)

Question

¿Cuál es el más cercano a poder agregar la información de depuración de estilo log4net a un conjunto de procedimientos almacenados? Algunos de los procedimientos delegan el trabajo a otros procedimientos y quiero información de rastreo de ambos.

He salpicado las instrucciones de impresión y selección durante su desarrollo, y lo ideal sería poder ejecutar el proceso en diferentes modos dependiendo de si se trata de una operación normal de solución de problemas y obtener más o menos salida.

En este caso particular, el proceso primario almacenado se ejecutará repetidamente desde un trabajo de agente, pero puede ejecutarse desde el estudio de administración cuando se solucionan problemas.

Los procs ya usan una tabla de registro de errores y facilidades de correo electrónico para detectar los errores planteados. El tipo de cosas que busco rastrear es cuando un problema con los datos de entrada significa que los datos de salida son incorrectos, pero los procesos no fallan completamente, y sería útil ver exactamente lo que se hizo en cada paso.

¿Qué enfoques conoces para producir resultados significativos e idealmente filtrables?

Uno por respuesta para que podamos ver la clasificación final ;-)

Fuera de la caja respuestas dan la bienvenida, como "no - paso a paso con el estudio de la gestión cuando se necesitan"

Answer 1

Pilas de declaraciones de impresión

por ejemplo

print 'Doing something...' 
INSERT INTO foo(a) VALUES(1) 
print @@ROWCOUNT 

esta pregunta simplemente para mantener el equilibrio, ya que es redonda tranquilo aquí.

Answer 2

Uno El enfoque podría ser verificar si el proceso se está ejecutando desde SSMS y disparar algunos Custom user configurable SQL Server Profiler events si es así. p.ej.

CREATE PROC foo 
AS 
DECLARE @debug bit = CASE WHEN APP_NAME() = 'Microsoft SQL Server Management Studio - Query' 
          THEN 1 
          ELSE 0 END 

DECLARE @userinfo nvarchar(128) 
DECLARE @userdata varbinary(8000) 

--Do some work here 

IF @debug = 1 
BEGIN 
--Do some custom logging 
    SET @userinfo = N'Some custom info' 
    SET @userdata = CAST('Some custom data' AS varbinary(8000)) 
    EXEC sp_trace_generateevent @eventid = 82 /*Use 82-91*/ 
           ,@userinfo = @userinfo 
           ,@userdata = @userdata 

END 

---

Aunque en la práctica que suelen utilizar algo como el siguiente. A veces con un código adicional para registrar el mensaje (y posiblemente los valores de paso y estado) en una tabla según los requisitos. Esto permitiría cumplir con el requisito "filtrable".

Esto detiene el mensaje que se imprime, excepto si APP_NAME indica que se está ejecutando en (una versión en inglés) de SSMS y usa NOWAIT para que el mensaje se imprima inmediatamente en lugar de esperar a que se llene.

CREATE PROCEDURE [dbo].[PrintMessage] @message   NVARCHAR(MAX), 
             @PrependCurrentTime BIT = 0 
AS 
    IF APP_NAME() LIKE 'Microsoft SQL Server Management Studio%' 
     BEGIN 
      DECLARE @CurrentTimeString VARCHAR(30); 

      SET @CurrentTimeString = '' 

      IF @PrependCurrentTime = 1 
      BEGIN 
       SET @CurrentTimeString = CONVERT(VARCHAR(19), GETDATE(), 20) + ' ' 
      END 

      RAISERROR('%s%s',0,1,@CurrentTimeString,@message) WITH NOWAIT 

     END 

Answer 3

No agregue la salida de seguimiento, en su lugar solo realice el paso necesario según el depurador del estudio de administración del servidor sql.

(Agregado para ver si la gente prefiere esto)