Estoy ejecutando un procedimiento almacenado utilizando SQL Server Agent Job en SQL Server 2005.SQL Server Agent Trabajo en ejecución lenta
Este trabajo se estaba ejecutando rápidamente hasta ayer. Desde ayer, este trabajo lleva más de 1 hora en lugar de 2 minutos.
He ejecutado el procedimiento almacenado en SSMS, solo me llevó menos de 1 minuto ejecutarlo.
No pude entender por qué tarda más de 1 hora en ejecutarse como un trabajo del Agente SQL Server?
Después de algún tiempo comentando y suponiendo que el SP realiza con los mismos parámetros de entrada y los datos así cuando se ejecuta en SSMS, me finnaly creo que pueda darle un último consejo:
Dependiendo de qué acciones se llevan a cabo dentro del SP (por ejemplo, insertar/actualizar/eliminar una gran cantidad de datos dentro de un bucle o cursor), debe configurar nocount al principio de su código.
set nocount on
Si esto no es el caso o no ayuda, por favor agregue más información, ya se ha mencionado en los comentarios (por ejemplo, todos los ajustes de la tarea y cada JobStep, lo que se ha conectado, lo que está en el Jobhistory, verifique SQLerrorlogs, eventlogs, ....). También eche un vistazo a los "Registros de SQL Server", quizás pueda recopilar información aquí. También es una buena idea echar un vistazo al evento Applicationlove System del servidor de bases de datos. Para obtener una visión general básica, puede usar el Activitymonitor en SSMS, seleccionando el servidor de bases de datos y seleccionando "Monitor de actividad" del menú contextual y buscando el agente sql.
Mi último intento sería tratar de ejecutar una traza de sql para el agente. En este caso, debería iniciar un seguimiento y filtro, p. por el usuario que se ejecuta el servicio SQLAgent. Hay tantas opciones que puede establecer para las huellas, así que recomendaría buscarlas en google, buscar en MSDN o hacer otra pregunta aquí en stackoverflow.
"ESTABLECER NOCOUNT EN" hizo el truco para mí. –
Me he dado cuenta de que los trabajos de SQL Agent ignoran la configuración MAXDOP del servidor y ejecutan todo con un MAXDOP de 1. Si ejecuto un procedimiento almacenado en una ventana de consulta, obedece las configuraciones del servidor y utiliza 4 procesos. Si utilizo SQL Agent, cualquier procedimiento almacenado que ejecute utiliza solo un proceso.
Tengo un problema similar con una secuencia de comandos que llama a un número de UDF que he creado. Los UDF en sí mismos normalmente se ejecutan en segundo lugar bajo SSMS. Del mismo modo, ejecutar los informes que genero con ellos es soportable en SSMS (datos de 30d en 8s, datos de 365d en 22s). Siempre he hecho NOCOUNT ON con mis trabajos de SQL Agent, ya que normalmente generan archivos de texto para que otros procesos o Excel los recojan y no quiero los datos adicionales al final, por lo que no fue una solución para mí.
En este caso, cuando ejecutamos exactamente el mismo script bajo SQL Agent como un trabajo, mis tiempos crecen exponencialmente. La secuencia de comandos de mi 8s tarda 2m30s y mi script de 22s tarda 2h20m. Esto es lo mismo si lo ejecuto al mediodía con otra actividad y trabajos del usuario o después de horas sin actividad del usuario, ni trabajos ni copias de seguridad en ejecución. Nuestro servidor está inactivo y, en el mejor de los casos, obtengo uno de los 8 núcleos que se utilizan cuando se ejecuta. DB tiene solo 10 GB ejecutándose en SSD con una tarjeta RAID en caché y 16 de 32 GB de RAM son gratuitos. Como mi SQL se ejecuta de manera eficiente en SSMS, estoy bastante convencido de que estoy alcanzando un límite de subprocesamiento de algún tipo. Investigué e intenté ajustar MAXDOP justo antes de las secuencias de comandos en el Agente de SQL sin suerte.
Como esta es una actividad que quiero programar, necesita ser automatizada de una forma u otra. Podría dejar que estas secuencias de comandos tomen las horas que necesitan para ejecutarse como pasos de SQL en trabajos de SQL Agent, pero decidí ejecutarlas desde la línea de comandos y obtengo el mismo rendimiento que veo en SSMS.
sqlcmd -S SQLSRVRHost -i "C:\My Script Loc With Spaces.sql" -v MyVar="VarValue" >"C:\MyOutputFile.txt"
Así que creé un script por lotes con los trabajos SQL ejecutados desde sqlcmd. Luego ejecuto el script por lotes desde un trabajo del Agente SQL, por lo que todavía tengo la misma administración y control en su lugar. Mis 4 trabajos SQL que colectivamente tomaron más de 3 horas para ejecutarse se completaron en 1 minuto y unos pocos segundos desde un solo script por lotes ejecutado por SQL Agent.
espero que esto ayude ...
Tenemos una gran proc que se ejecuta en 88 segundos en SSMS y 30-45 minutos en Agente SQL Server. Agregué el dbo. prefijo en todos los nombres de tabla y ahora se ejecuta tan rápido como SSMS.
Si ejecuta el mismo SP en SSMS y funciona, tal vez haya cambiado la configuración de la tarea, p. se ejecuta en el databse incorrecto. Si no, verifique Activity Monitor lo que está haciendo el agente o inicie un seguimiento para obtener los comandos ejecutados. tal vez hay un problema de bloqueo. ¿El problema aún ocurre si ejecuta el trabajo manualmente? –
@Bernhard, gracias por su respuesta. Revisé el trabajo y lo recreé. Todavía el mismo problema. Sí, si ejecuto manualmente el trabajo, todavía lleva mucho tiempo – Prateek
@Preteek ¿puede publicar la configuración del trabajo? La única razón de este comportamiento que puedo pensar es una ejecución diferente del SP. Como los parámetros, etc. son los mismos que cuando se ejecutan manualmente, el SQLServer debería usar los mismos planes de ejecución, etc. quizás pueda echarle un vistazo al Registro de SQL; tal vez esto nos dé una pista. –