tipos - procedimientos almacenados sql

Los procedimientos almacenados se agotan de manera intermitente!

Question

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

Todo fue bien, pero 2 de mis procedimientos almacenados comenzaron a agotar el tiempo de forma intermitente hoy con:

Tiempo agotado. El período de tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde. La instrucción se ha terminado.

Si ejecuto el sp manualmente desde el estudio de administración, sigue siendo bueno.

Nada cambió recientemente en mi db: el tiempo de espera de mi comando es el predeterminado.

¿Cualquier pista?

EDITAR

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

¡Gracias!

Answer 1

¿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, deberá 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 2

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

Verifique 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.

¿También cuántos datos estás devolviendo? Hemos tenido problemas con el SQL mal diseñado en el pasado que no apareció hasta que el informe acumulativo comenzó 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 3

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

EDITAR:

Para recompilar el proceso, vaya a Management Studio, abra el procedimiento para modificar y presione F5 o ejecute: EXEC sp_recompile ''proc_name''

Answer 4

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

Answer 5

Ok, así es como lo arreglé 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 provocaba 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 los índices y haciendo que el índice agrupado en la clave principal no agrupado desbloqueara la situación.

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

Answer 6

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 una propiedad de tiempo de espera para el objeto de comando ADO .

Answer 7

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

Answer 8

Esto a menudo se puede relacionar con:

• planes de mala consulta debido a un plan de reutilización excesivo ( detección de parámetros )
• diferentes opciones de SET, en particular ANSI_NULLS y CONCAT_NULL_YIELDS_NULL
• bloqueo (es posible que tenga un mayor nivel de aislamiento)
• la indexación debe ser reconstruida / estadísticas actualizadas / etc.

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