A partir de la consulta que detecta quien bloquea y que hace podemos construir una forma algo más atrevida de monitorización de bloqueos. La idea es la siguiente, con el query que detecta los bloqueos, guardamos el resultado en una tabla temporal. y esperamos un tiempo prudencial -y configurable- y volvemos a ejecutar la misma sentencia. Si los mismos procesos siguen bloqueados por los mismos actores, es tiempo de reportar ese bloqueo. Es decir, es normal que en un momento del tiempo haya un bloqueo, es cosa de la concurrencia, pero no es normal que ese bloqueo dure mucho (el cuanto es ese mucho depende de la aplicación).
En el caso de que el bloqueo persista, se notifica, en nuestro caso a través de mail. Si has entendido todos estos conceptos y solo quieres el código…

Si poor el contrario quieres entenderlo un poquito mejor y ver como funciona y como se agendaría, aquí tienes el video de demostración.

Únete a la conversación

2 comentarios

  1. Estimado Miguel.
    Excelente tu código, ya lo estoy implementando.
    Una acotación, en vez de utilizar un delay porque no usar un Where
    WHERE CONVERT(TIME, DATEADD(SECOND, DATEDIFF(SECOND, start_time, GETDATE()), 0), 114) > @DelayLength

    Saludos Cordiales.
    Cristian Peña M.

    1. El motivo de usar un delay es porque si no esperamos, si no hacemos que simplemente unos segundos no se haga nada, siempre estarán presentes los mismos bloqueos entre el momento inicial y el del segundo query. La idea es que un bloequeo «corto» de , por ejemplo , 1 sg o así puede ser normal. Lo que no es normal es que permanezca mucho tiempo. Me alegro mucho que te guste!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *