Назад | Перейти на главную страницу

Достаточно ли надежен планировщик задач в Windows XP, чтобы ему можно было доверять важные задачи?

Я спрашиваю, потому что программное обеспечение, которое моя компания собирается начать использовать, требует, чтобы одна рабочая станция (Windows) запускала небольшую программу автоматизации каждую ночь для увеличения нескольких полей в базе данных. Я уверен, что я не единственный, кто думает, что это ужасный дизайн, но на данный момент я мало что могу с этим поделать (по крайней мере, до тех пор, пока у меня не будет времени выяснить, что именно он делает, и заменить его cron -able Perl-скрипт).

Раньше несколько лет назад я имел дело только с мастером планировщика задач Windows для различных домашних задач. Я помню, что некоторые задачи вообще не выполняются, а некоторые другие запускаются с перебоями.

Предполагая, что задача настроена правильно, могу ли я доверять планировщику задач Windows XP ВСЕГДА запускать это задание, или это ненадежно?

У нас есть несколько «критических» систем, в которых наши поставщики предпочитают полагаться на диспетчер задач Windows. Единственные проблемы, которые я когда-либо видел, были бы; время выполнения пропущено, когда компьютер выключен (это не очередь заданий), задачи, которые не выполняются просто потому, что они были неправильно настроены, исполняемый файл или сам скрипт терпят неудачу каждый раз, когда диспетчер задач вызывает его, и самая большая проблема из всех была в том, что пользователь учетная запись, заданная для конкретной задачи, блокируется по любому количеству причин.

Чтобы предотвратить проблему блокировки учетной записи, я бы порекомендовал либо создать специальную учетную запись для этой задачи, либо найти небольшую хитрость, которую я нашел. Если задача не требует доступа к сети, вы можете запланировать ее запуск как Систему с пустым паролем.

Наконец, мы автоматически или вручную отслеживаем все критические задачи. На всякий случай.

Вы упомянули, что эта задача была для базы данных. Это база данных Microsoft SQL Server? Если это так, вы захотите изучить использование Агент SQL Server.

Я бы сказал, что сам планировщик надежен как ОС, на которой он работает.

В основном я имел дело с планировщиком задач на Server 2000 и 2003, а не с XP, но я не могу вспомнить сбой запланированной задачи для задачи, которая была связана с фактической неисправностью планировщика.

Если это рекомендуемая конфигурация для этого программного обеспечения, я уверен, что поставщик должен доверять планировщику задач XP.

Трудно сказать что-нибудь «ВСЕГДА» о компьютере, но в целом мне повезло с планировщиком задач XP (и его эквивалентами для Windows Server). XP, будучи одной из ОС на базе NT, в целом была для меня довольно стабильной.

Я бы попробовал.

Это зависит от устойчивости задачи. У меня он выполнял ежедневные задания, которые так или иначе заканчивались чисто, годами без проблем. Но я также видел случаи, когда работа не заканчивается из-за зависания скрипта. Хотя для каждой задачи можно настроить «убить через X промежуток времени», я видел, что это не удалось.

Я также видел неудачные ситуации, когда задача запланирована для выполнения с периодическими интервалами, когда задание выполнялось во время следующего выполнения. В том же духе каждые 5 минут у меня запускался сценарий, который опрашивал наши DNS-серверы. Запросы выполнялись примерно за 20-30 секунд, и мы никогда не видели, чтобы эти сценарии терпели неудачу при запуске через планировщик задач.

Я был бы склонен ответить «да», но только при условии, что вы можете быть уверены, что машина будет работать в указанное время. Если машина выйдет из строя по какой-либо причине, запланированная задача не будет запущена при перезагрузке машины. т.е. планировщик не смотрит, не было ли пропущено какое-либо расписание.

Если выполнение задачи критично, убедитесь, что компьютер хотя бы подключен к ИБП.

Мне повезло с самим планировщиком, работающим должным образом, хотя я видел, как задачи терпят неудачу без какой-либо четкой индикации из-за проблем с разрешениями.

Я бы посоветовал встроить код отладки или уведомления в скрипт, который фактически выполняет задачу. Таким образом, вы можете пассивно контролировать сценарий, когда он новый, и время от времени отслеживать его по мере роста вашей уверенности в его надежности.

У меня никогда не было проблем с планировщиком задач, однако, если рабочая станция выключена, приложение не запускается (очевидно).

Если вы выполняете задачи на уровне базы данных, большинство СУБД позволит вам запланировать выполнение запроса / задачи на уровне СУБД, чтобы исключить зависимость от сторонних задач. Это может быть более безопасный метод, если он практичен (то же самое относится и к запуску задания cron).

Несколько месяцев назад я искал в сети вопрос такого рода, и мои поиски пришли к четкому отрицательному ответу на ваш вопрос.