El trabajo no se ejecuta según lo programado

Así que tengo un trabajo básico de agente SQL que ejecuta un script Robocopy para mover todos los archivos de una carpeta a otra.

Job es una configuración bastante básica.

Con un horario bastante básico.

Y sin embargo, aún tiene que correr. No me refiero a correr con éxito tampoco me refiero a correr en absoluto. ¿Hay alguna razón para que este sea el caso?

Para obtener información adicional, también escribiré el trabajo.

USE [msdb]
GO

/****** Object:  Job [MoveMantisFilesToArchive]    Script Date: 12/23/2015 10:21:52 AM ******/
BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
/****** Object:  JobCategory [[Uncategorized (Local)]]]    Script Date: 12/23/2015 10:21:52 AM ******/
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'MoveMantisFilesToArchive', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=2, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'Moves Mantis files to archive. It''s a very descriptive title.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'sa', 
        @notify_email_operator_name=N'MyEmailGroup', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
/****** Object:  Step [Move the files in the afformentioned title.]    Script Date: 12/23/2015 10:21:53 AM ******/
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'Move the files in the afformentioned title.', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'CmdExec', 
        @command=N'robocopy MySoruce MyDestination /mov', 
        @flags=0, 
        @proxy_name=N'RunsAs'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobschedule @job_id=@jobId, @name=N'M-F', 
        @enabled=1, 
        @freq_type=8, 
        @freq_interval=62, 
        @freq_subday_type=1, 
        @freq_subday_interval=0, 
        @freq_relative_interval=0, 
        @freq_recurrence_factor=1, 
        @active_start_date=20151218, 
        @active_end_date=99991231, 
        @active_start_time=170000, 
        @active_end_time=235959, 
        @schedule_uid=N'bcb83273-19e8-49fb-a456-8517642370e3'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:

GO

Comentario sobre esta pregunta: al revisar esta publicación, observo que su trabajo se ejecutaba originalmente como 'sa'. Parece que a la cuenta de servicio de su SQL Server no se le otorgaron derechos sobre los archivos compartidos necesarios .

Aparentemente, esto es lo que hizo que el trabajo pareciera "En ejecución " para siempre. Por supuesto, nada estaba sucediendo realmente.

Es una buena práctica de retener dando derechos a la cuenta de servicio de SQL Server para cualquier carpetas no esenciales . Esto ayuda a evitar que el entorno de SQL Server sea explotado para actividades inseguras. (Casi la misma razón por la que el xp_cmdshellprocedimiento almacenado está deshabilitado de forma predeterminada).

Cuando cambiaste saa una cuenta que tenía los derechos necesarios para el sistema de archivos, todo funcionó. Lo cual, por supuesto, era lo correcto.

Los trabajos programados del Agente SQL a veces se bloquean (pero parece que todavía se están "ejecutando") durante mucho tiempo. Es probable que esto se deba a problemas externos, como no tener acceso al sistema de archivos.

Mientras el Agente SQL crea que el trabajo está "ejecutándose", no intentará iniciar el trabajo nuevamente.

Lecciones simples:

1. Piense en 'sa' como la regla del Servidor SQL, pero debe pedir derechos en otro lugar.
2. Al revisar el historial de trabajos del Agente SQL, esté atento a los trabajos que se han estado ejecutando durante demasiado tiempo. Eso generalmente significa que el Agente SQL no se da cuenta de que el proceso ha muerto.
3. Siempre planifique utilizar una cuenta de proxy para los trabajos del Agente SQL que necesiten acceder a datos u objetos fuera del SQL Server. Y asegúrese de que se otorguen los derechos a la Credencial que utiliza el Proxy.

Y, por supuesto, cada regla tiene excepciones.