¡Los procedimientos almacenados se agotan de manera intermitente!

Question

Tengo una serie de procedimientos almacenados que llamo desde el código con ExecuteNonQuery.

todo era bueno, pero 2 de mis procedimientos almacenados comenzó el tiempo de espera de forma intermitente hoy con:

tiempo de espera agotado. El período de tiempo de espera transcurrió antes de la finalización de la operación o el servidor no está respondiendo . La declaración ha sido terminada.

Si ejecuto manualmente la sp desde el estudio de gestión, todo sigue siendo bueno.

Nada ha cambiado recientemente en mi db - el tiempo de espera de mi comando es el predeterminado.

¿Alguna pista?

EDITAR

la mesa contra los SP se están ejecutando es enorme -> 15 conciertos. Reiniciado el cuadro: el mismo problema, pero esta vez tampoco puede ejecutar el sp desde Management Studio.

Gracias!

Answer 1

Ok, así es como lo solucioné al final.

Un índice agrupado en una tabla con 45 millones de registros estaba matando a mi servidor SQL; cada inserción del código daba como resultado los desagradables tiempos de espera descritos en la respuesta. Aumentar la tolerancia de tiempo de espera no iba a resolver mis problemas de escalabilidad, así que jugué con índices y haciendo que el índice agrupado en la clave principal no agrupados se desbloqueara la situación.

Agradecería los comentarios sobre esto para comprender mejor cómo esto solucionó el problema.

Answer 2

¿Está configurado el tiempo de espera del comando? ¿Ha cambiado recientemente algo en su base de datos que está causando que este proceso tome más tiempo?

Si tiene que diagnosticar problemas de bloqueo, necesitará usar algo como sp_lock.

¿Puedes compartir la fuente de uno de tus procs?

http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx

Answer 3

Management Studio establece un tiempo de espera infinito en consultas/comandos que se ejecuta. Su conexión de base de datos desde el código tendrá un tiempo de espera predeterminado que puede cambiar en el command object.

Answer 4

Esto puede a menudo se refieren a:

• malos planes de consulta debido a un exceso de ganas plan de reutilización (parameter sniffing)
• opciones conjunto diferente - en ANSI_NULLS particulares y CONCAT_NULL_YIELDS_NULL
• bloqueo (que podría tener un nivel de aislamiento superior)
• indexación necesita ser reconstruido/actualizado las estadísticas/etc

Las opciones SET pueden llevar a que ciertos tipos de índice no se puedan utilizar (índices en columnas calculadas persistentes, por ejemplo, incluidas las consultas "promocionadas" xml/udf)

Answer 5

Intente volver a compilar estos procedimientos. Tuve tantos problemas pocas veces y no encontré la causa del problema, pero recompilar siempre ayuda.

EDIT:

recompilar proc, que ir al estudio de gestión, procedimiento abierto para modificar y presione F5 o ejecutar: EXEC sp_recompile 'proc_name'

Answer 6

Es posible que tenga que actualizar las estadísticas sobre la base de datos. ¿También ha cambiado recientemente la indexación en la mesa?

Compruebe el plan de ejecución de la sp para ver si puede encontrar el cuello de botella. Incluso si se ejecutó bien antes, probablemente puede ajustarse para funcionar de manera más eficiente.

¿Además de cuántos datos está devolviendo? Hemos tenido problemas con el SQL mal diseñado en el pasado que no aparecía hasta que el informe acumulativo comenzaba a tener más datos en el conjunto de resultados. Al no saber lo que hacen sus sps, es difícil decir si esto es posible, pero vale la pena mencionar para que investigue.

Answer 7

SQL Server esperará indefinidamente antes de volver al usuario. Es más que probable que haya un conjunto de propiedades de tiempo de espera del lado del cliente. Por ejemplo, puede establecer un timeout property for the ADO command object.

Answer 8

Obtenga el generador de perfiles SQL, compare los resultados entre ejecutarlo en Management Studio y a través de su aplicación.