Работа не выполняется по расписанию

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

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

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

 Расписание

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

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

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 @[email protected], @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 @[email protected], @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
11 голосов | спросил Zane 23 WedEurope/Moscow2015-12-23T19:28:16+03:00Europe/Moscow12bEurope/MoscowWed, 23 Dec 2015 19:28:16 +0300 2015, 19:28:16

1 ответ


5

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

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

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

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

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

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

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

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

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

ответил RLF 1 Jpm1000000pmFri, 01 Jan 2016 19:43:56 +030016 2016, 19:43:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132