1. Inicio
  2. Pregunta y respuesta
  3. El procedimiento almacenado se bloquea aparentemente sin explicación

El procedimiento almacenado se bloquea aparentemente sin explicación

2010-10-15 34 views
16

tenemos un procedimiento almacenado que funcionó bien hasta hace 10 minutos y luego simplemente se cuelga después de llamarlo.El procedimiento almacenado se bloquea aparentemente sin explicación

Observaciones:

  • copiar el código en una ventana de consulta se obtiene el resultado de la consulta en 1 segundo
  • SP lleva> 2,5 minutos hasta que la cancele
    • monitor
  • de actividad muestra que no está siendo bloqueado por nada , solo está haciendo una SELECCIÓN.
  • Correr sp_recompile en el SP no ayuda
  • caída y volver a crear el SP no ayuda
  • Configuración LOCK_TIMEOUT a 1 segundo no ayuda

¿Qué más puede estar pasando?

ACTUALIZACIÓN: supongo que tenía que ver con el descubrimiento de parámetros. Utilicé la rutina de Adam Machanic para descubrir qué subconsulta estaba pendiente. Encontré las cosas mal con el plan de consulta gracias a la sugerencia de Martin Smith. Aprendí sobre EXEC ... WITH RECOMPILE, OPTION(RECOMPILE) para las subconsultas dentro del SP, y OPTION (OPTIMIZE FOR (@parameter = 1)) para atacar el rastreo de parámetros. Todavía no sé lo que estaba mal en este caso en particular, pero salí de esta batalla más experimentado y mejor armado. Sé qué hacer la próxima vez. ¡Así que aquí están los puntos!

Fuente

2010-10-15 thomaspaulb

+2

¿Cómo se ve el plan de ejecución? (Puede usar esta consulta para obtenerla http://stackoverflow.com/questions/3831644/why-does-a-database-query-only-go-slow-in-thepplication/3831685#3831685) ¿Cómo funciona? ¿se compara con el plan cuando copia el código en la ventana de consulta y lo ejecuta? –

+0

Algo es diferente: ¿se utilizan variables al pegar la instrucción en una ventana de consulta? –

+0

@OMG: Las variables son 2 INTS y ​​2 DATES y son las mismas, las declare al comienzo de la ventana de consulta. Y ahora (aproximadamente media hora más tarde) el procedimiento se está ejecutando nuevamente. Tal vez fue recompilar? – thomaspaulb

Respuesta

0

Gracias por todos los comentarios.

Todavía no he encontrado la respuesta, pero publicaré el progreso aquí.

No he podido reproducir el problema anteriormente, pero hoy me encontré con otro procedimiento almacenado con el mismo problema. Una vez más los mismos síntomas aparecieron:

  • Colgando pedazo de consulta se ejecuta bien y rápido (3 segundos) en la ventana de consulta normal (pieza colgando identifica con sp_whoisactive)
  • No hay cerraduras, de acuerdo con el Monitor de Actividad SPID está haciendo SELECT
  • procedimiento almacenado se ejecuta durante más de 6 horas sin respuesta
  • parámetros pasados ​​a SP y variables declaradas en la ventana son los mismos

Uso de arriba consejos, he encontrado la ejecución SP plan y no mostró nada fuera de lo común (para mí, al menos). Crear un nuevo procedimiento almacenado con los mismos contenidos tampoco solucionó el problema. Así que comencé a quitar el SP a cada vez menos contenido hasta que encontré una llamada UDF a otra base de datos. Cuando eliminé eso (reemplacé la llamada por el contenido en línea de la función, una declaración CASE), volvió a funcionar correctamente.

Así que este PODRÍA haber sido el problema, pero no estoy muy seguro, ya que la última vez el problema desapareció por sí solo y también cambié un montón de otras cosas al quitar este SP.

Fuente

2010-11-03 16:45:26 thomaspaulb

+0

Intenta agregar "CON RECOMPULE" al proceso almacenado. Esto reconstruirá el plan de consulta cada vez. –

+0

Gracias, no sabía de eso, lo intentaré la próxima vez. – thomaspaulb

+0

Enlaces: http://stackoverflow.com/questions/211355/parameter-sniffing-or-spoofing-in-sql-server y http://stackoverflow.com/questions/1601939/stored-procedure-timing-out-drop -then-create-and-its-up-again/ – thomaspaulb

0

Creo que tuve el mismo problema. Eliminé mis parámetros de las subconsultas. Funcionó bien después de eso. No estoy seguro de si esto es posible en su script, pero eso es lo que me solucionó.

Fuente

2012-08-14 15:55:00 Lee

10

Creo que esto está relacionado con el rastreo de parámetros y la necesidad de parametrizar los parámetros de entrada a los parámetros locales dentro del SP. Al agregar con la recompilación, se recrea el plan de ejecución y se eliminan muchos de los beneficios de tener un SP. Estábamos usando With Recompile en muchos informes para tratar de eliminar este problema y ocasionalmente colgar SP's que pudieron haber estado relacionados con otros bloqueos y/o transacciones que accedían a las mismas tablas simultáneamente. Vea este enlace para más detalles Parameter Sniffing (or Spoofing) in SQL Server y cómo cambiar SP a la siguiente para solucionar este problema:.

CREAR PROCEDIMIENTO [dbo] [SPName] @ p1 int, @ p2 int AS

DECLARE @ localp1 int, @ localp2 int

SET @ localp1 = @ p1 SET @ localp2 = @ p2

Fuente

2013-11-20 05:35:12

+0

Eres un genio. Esta es la solución que salvó mi día. – Nuzzolilo

+1

Esto, inesperadamente, resolvió mi problema con algunos SP que se ejecutan aleatoriamente en la eternidad. Sólo quedan 350 SP para actualizar ahora ...;) – Mackan

+0

Funcionó para mí también. Ejecutar la consulta manualmente funcionó bien, ejecutándose desde entity framework o ejecutándose solo para siempre ... Cambió los parámetros a los locales y ahora funcionan bien gracias – Klors

1

Cuando añadimos nuevos datos a veces el plan de ejecución no es válida o no está actualizada, entonces el procedimiento almacenado comienza a ir en esta fase el limbo. Ejecute los siguientes comandos en la base de datos

DBCC DROPCLEANBUFFERS 

DBCC FREEPROCCACHE

Se vaciará la memoria caché y reconstruir el plan de ejecución próxima vez que se ejecute el procedimiento almacenado.

msdn.microsoft.com

Fuente

2014-07-17 04:48:31 savvyBrar

0

Primero lo primero.

Compruebe si hay transacciones no confirmadas. Una transacción de inicio sin "COMPRAR TRANSACCIÓN"

Fuente

2017-05-24 23:19:57 user7954693

Cuestiones relacionadas

 Cuestiones relacionadas