Задание не выполняется по расписанию

Итак, у меня есть базовое задание агента SQL, которое запускает скрипт Robocopy для перемещения всех файлов из одной папки в другую.

Работа - довольно простая установка.

С довольно простым графиком.

И все же это еще не бежать. Я не имею в виду бежать успешно, я имею в виду бежать вообще. Есть ли причина, по которой это может быть так?

Для дополнительной информации я также составлю сценарий работы.

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

Комментарий к этому вопросу: просматривая этот пост, я замечаю, что ваша работа изначально выполнялась как 'sa'. Похоже, что учетной записи службы для вашего SQL Server не были предоставлены права на необходимые общие папки .

Это, очевидно, и привело к тому, что работа выглядела так, как будто она « работала » вечно. Конечно, на самом деле ничего не происходило.

Это лучшая практика , чтобы удержать предоставление права учетной записи службы SQL Server для любых несущественных папок . Это помогает избежать использования среды SQL Server для небезопасных действий. (По той же причине, что xp_cmdshellхранимая процедура по умолчанию отключена.)

Когда вы переключились с saучетной записи, которая имела необходимые права на файловую систему, все работало. Что, конечно, было правильно.

Запланированные задания агента SQL иногда зависают (но, похоже, все еще работают) в течение длительного времени. Вероятно, это обычно связано с внешними проблемами, такими как отсутствие доступа к файловой системе.

Пока агент SQL считает, что задание «выполняется», он не будет пытаться запустить задание снова.

Простые уроки:

1. Думайте о «sa» как о правит SQL Server, но должны просить права в другом месте.
2. При просмотре журнала заданий агента SQL обратите внимание на задания, которые выполнялись слишком долго. Обычно это означает, что агент SQL не понимает, что процесс умер.
3. Всегда планируйте использовать учетную запись-посредник для заданий агента SQL, которым требуется доступ к данным или объектам за пределами SQL Server. И убедитесь, что права предоставляются учетным данным, которые использует прокси-сервер.

И, конечно же, у каждого правила есть исключения.