Le travail ne s'exécute pas dans les délais

J'ai donc un travail d'agent SQL de base qui exécute un script Robocopy pour déplacer tous les fichiers d'un dossier à un autre.

Le travail est une configuration assez basique.

Avec un horaire assez basique.

Et pourtant, il n'a pas encore fonctionné. Je ne veux pas dire courir avec succès non plus, je veux dire courir du tout. Y a-t-il une raison pour laquelle cela pourrait être le cas?

Pour plus d'informations, je rédigerai également le travail.

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

Commentaire sur cette question: En regardant ce post, j'observe que votre travail s'exécutait à l'origine en tant que «sa». Il semble que le compte de service de votre serveur SQL ne dispose pas des droits sur les partages de fichiers nécessaires .

C'est apparemment ce qui a conduit à donner l'impression que le travail était "en cours d'exécution " pour toujours. Bien sûr, rien ne se passait réellement.

Il est une meilleure pratique de retenir donner les droits de compte de service SQL Server pour les dossiers non essentiels . Cela permet d'éviter que l'environnement SQL Server ne soit exploité pour des activités dangereuses. (À peu près la même raison que la xp_cmdshellprocédure stockée est désactivée par défaut.)

Lorsque vous êtes passé d' saun compte disposant des droits nécessaires au système de fichiers, tout a fonctionné. Ce qui était, bien sûr, la bonne chose à faire.

Les travaux planifiés de l'Agent SQL se bloquent parfois (mais ils semblent toujours «en cours d'exécution») pendant longtemps. Cela est probablement dû à des problèmes externes, tels que le fait de ne pas avoir accès au système de fichiers.

Tant que l'agent SQL pense que le travail est "en cours d'exécution", il n'essayera pas de redémarrer le travail.

Leçons simples:

1. Considérez «sa» comme régissant SQL Server, mais vous devez demander des droits ailleurs.
2. Lorsque vous consultez l'historique des travaux de l'Agent SQL, soyez attentif aux travaux qui ont été exécutés trop longtemps. Cela signifie généralement que l'Agent SQL ne se rend pas compte que le processus est mort.
3. Prévoyez toujours d'utiliser un compte proxy pour les travaux de l'Agent SQL qui doivent accéder à des données ou à des objets en dehors de SQL Server. Et assurez-vous que les droits sont accordés aux informations d'identification que le proxy utilise.

Et, bien sûr, chaque règle a des exceptions.