O trabalho não está sendo executado no agendamento

Portanto, eu tenho um trabalho básico de agente SQL que executa um script Robocopy para mover todos os arquivos de uma pasta para outra.

O trabalho é uma configuração bastante básica.

Com um cronograma bastante básico.

E ainda tem que correr. Eu não quero dizer executar com sucesso ou quero dizer executar de todo. Existe alguma razão para que isso aconteça?

Para obter informações adicionais, vou escrever o trabalho também.

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

Comentário sobre esta pergunta: Examinando esta postagem, observei que seu trabalho estava sendo executado originalmente como 'sa'. Parece que a conta de serviço do seu SQL Server não recebeu direitos para os compartilhamentos de arquivos necessários .

Aparentemente, foi isso que levou o trabalho a parecer que estava "em execução " para sempre. Claro, nada estava realmente acontecendo.

É uma prática recomendada recusar a concessão de direitos de conta de serviço do SQL Server a qualquer pasta não essencial . Isso ajuda a impedir que o ambiente do SQL Server seja explorado para atividades inseguras. (Muito pelo mesmo motivo que o xp_cmdshellprocedimento armazenado está desabilitado por padrão.)

Quando você mudou sapara uma conta que tinha os direitos necessários para o sistema de arquivos, tudo funcionou. O que era, obviamente, a coisa certa a se fazer.

Às vezes, os trabalhos agendados do SQL Agent são interrompidos (mas parecem que ainda estão em execução) por um longo tempo. Provavelmente, isso geralmente ocorre devido a problemas externos, como não obter acesso ao sistema de arquivos.

Desde que o SQL Agent acredite que o trabalho esteja "em execução", ele não tentará iniciar o trabalho novamente.

Lições simples:

1. Pense em 'sa' como governando o SQL Server, mas deve implorar por direitos em outro lugar.
2. Ao revisar o histórico de tarefas do SQL Agent, fique atento às tarefas que estão sendo executadas por muito tempo. Isso geralmente significa que o SQL Agent não percebe que o processo morreu.
3. Sempre planeje usar uma conta proxy para trabalhos do SQL Agent que precisem acessar dados ou objetos fora do SQL Server. E verifique se os direitos são concedidos à credencial que o proxy está usando.

E, é claro, toda regra tem exceções.