2011-03-23 7 views
8

Tengo un número de trabajos programados del agente SQLServer, uno de ellos realiza una copia de seguridad completa de la base de datos. Deseo desactivar algunos otros trabajos cuando comience la copia de seguridad y volver a habilitarlos una vez que se realice la copia de seguridad. ¿Cuál es la forma correcta de hacerlo? Estaba pensando en agregar uno de los siguientes comandos tsql al primer paso de la tarea de copia de seguridad (y los respectivos comandos habilitar al último paso), pero no puedo encontrar cuál es mejor (o tal vez haya otra).La forma correcta de deshabilitar/habilitar trabajos del Agente SQLServer

UPDATE MSDB.dbo.sysjobs 
SET Enabled = 0 
WHERE [Name] IN (....) 

O un número de EXEC dbo.sp_update_job?
Gracias.

+0

No veo nada malo con su enfoque sugerido. –

+0

Entonces, ¿cuál crees que es mejor? '¿ACTUALIZAR sysojobs' directamente o usando' sp_update_job'? – a1ex07

+0

¿Qué vas a hacer con los trabajos inhabilitados si/cuando falla la copia de seguridad? – DForck42

Respuesta

4

Habría que ejecutar EXEC dbo.sp_update_job porque no se puede actualizar directamente las tablas del sistema ( aunque no estoy seguro de si sysjobs todavía cuenta como una tabla del sistema Mitch dice que puede ser actualizada)

lo haría considere el uso de sp_getapplock and sp_releaseapplock para "bloquear" otros trabajos sin actualizar realmente los trabajos.

+0

MSDB.dbo.sysjobs ciertamente parece actualizable .... –

+1

+1 para el punto acerca de los procesos de applock. –

+0

@Mitch Wheat: no lo he probado durante algunos años y no puedo en mi entorno actual – gbn

1

No veo nada de malo con su enfoque sugerido. También puede manipular a través de la categoría de trabajo:

UPDATE j 
SET j.Enabled = 0 
FROM MSDB.dbo.sysjobs j 
INNER JOIN MSDB.dbo.syscategories c ON j.category_id = c.category_id 
WHERE c.[Name] = 'Database Maintenance'; 

no he perfilado, pero sospecho

USE msdb ; 
GO 

EXEC dbo.sp_update_job 
    @job_name = N'SomeJob', 
    @enabled = 0; 
GO 

va a generar el mismo código, pero los procsos incorporadas son por lo general el camino a seguir.

+0

Gracias por su respuesta. – a1ex07

+1

No recomendaría actualizar la tabla sysjobs directamente, porque las planificaciones en caché no se actualizarán correctamente. Ver mi respuesta – BradC

0

El otro enfoque sería añadir un paso al comienzo de sus otros trabajos que comprueba el estado del trabajo de copia de seguridad y luego o bien aborta o duerme el trabajo actual, si la copia de seguridad se está ejecutando.

Hemos hecho las dos cosas a veces, depende de qué tan confiables/críticos sean los diferentes trabajos, cuál funciona mejor.

6

Definitivamente use sp_update_job. Si el trabajo es ya programado, manipular la tabla sysjobs directamente no necesariamente hará que se vuelva a calcular la programación en caché.

Podría funcionar para la bandera ENABLED (no lo he probado), pero sé de hecho que no funciona en para columnas como start_step_id.

+2

Correcto - la actualización de la tabla sysjobs directamente romperá las programaciones existentes – soslo

1

SQL Agent almacena en caché el estado habilitado de los trabajos. Entonces, si simplemente actualiza la tabla sysjobs, en realidad no impedirá que un cronograma active el trabajo. El procedimiento almacenado sp_update_job activa el caché para actualizar, por lo que le recomiendo que lo use.

Si aún desea configurar manualmente el valor en sysjobs, debe ejecutar sp_sqlagent_notify para obtener realmente la actualización del agente sql, es la memoria caché del estado habilitado. Simplemente mira el código de sp_update_job para conocer los parámetros exactos que necesitas.

Cuestiones relacionadas