Робота не працює за графіком

Тож у мене є основна робота агента 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 Agent іноді зависають (але виглядають так, що вони все ще 'запущені') тривалий час. Ймовірно, це зазвичай пов'язано із зовнішніми проблемами, такими як недоступ до файлової системи.

Поки агент SQL вважає, що завдання "працює", він не буде намагатися запустити завдання знову.

Прості уроки:

1. Подумайте про "sa" як правлячий SQL Server, але потрібно просити прав в іншому місці.
2. Переглядаючи історію завдань SQL Agent, будьте уважні до завдань, які надто довго виконуються. Це зазвичай означає, що агент SQL не усвідомлює, що процес загинув.
3. Завжди плануйте використовувати обліковий запис проксі для завдань SQL Agent, яким потрібно отримати доступ до даних або об'єктів за межами SQL Server. І переконайтеся, що права надані довіреному користувачу, який використовує проксі.

І, звичайно, кожне правило має винятки.