Как настроить job scheduler

Как настроить job scheduler

В статье рассматриваются некоторые свойства и примеры употребления планировщика заданий, появившегося в версии Oracle 10 на смену старому.

Введение

СУБД Oracle — большой и сложный механизм, требующий выполнения определенных плановых работ, таких как сбор статистики о хранимых объектах или сбор/чистка внутренней информации. Необходимость осуществлять плановый запуск работ могут испытывать и пользователи БД.

Первый механизм планового запуска появился в версии 7 для поддержки автоматических обновлений снимков (snapshots), как поначалу именовались нынешние материализованные виртуальные таблицы (materialized views). В версии 8 этот механизм был открыт для обычных пользователей через посредство некоторых параметров СУБД, таблиц словаря-справочника, а также пакета DBMS_JOB. Пакет DBMS_JOB позволял (и позволяет) запускать хранимую процедуру, или же неименованный блок PL/SQL в моменты времени, вычисляемые по указанной пользователем формуле.

К версии 10 такое устройство имевшегося планировщика заданий было сочтено слишком примитивным, и в ней появился новый планировщик, значительно более проработанный. Он использует следующие основные понятия:

• Schedule (расписание)
• Program (программа)
• Job (плановое задание = расписание + программа)

Кроме того, с ним связаны дополнительные, более специфичные понятия:

• Job class (класс заданий)
• Window и window group (ресурсное «окошко», интервал для автоматического включения ресурсного плана СУБД и группа окошек)
• Chain (цепочка заданий)
• Event schedule (возможность запустить задание по событию, зафиксированному по сообщению из очереди AQ)

В отличие от старого планировщика, в новом «программой» может быть не только блок PL/SQL, но и хранимая процедура на PL/SQL или на Java, внешняя процедура на С или даже команда ОС. Последнее означает, что Oracle отменяет необходимость использовать специфичные для разных платформ планировщики заданий ОС (cron, at) при построении БД-центричного приложения. Вдобавок, сам запуск заданий получил возможность учета текущей вычислительной обстановки в СУБД, а также желаемой приоритетности среди прочих заданий.

Как и в случае со старым планировщиком, новый, по сути, представляет собой элемент ядра СУБД, доступ пользователя к которому предоставляется посредством программной логики и элементов схемы БД. Именно, в распоряжении пользователя имеется следующее:

• таблицы словаря-справочника LIKE ‘%SCHEDULER_%’ (DBA_SCHEDULER_JOBS, DBA_SCHEDULER_JOB_LOG и прочие);
• несколько типов объектов хранения, как то:
  • JOB
  • SCHEDULE
  • PROGRAM
  • JOB CLASS,

  ряд других;

• системные привилегии:
  • CREATE SESSION
  • CREATE JOB
  • CREATE ANY JOB
  • EXECUTE ANY PROGRAM
  • EXECUTE ANY CLASS
  • MANAGE SCHEDULER
  • CREATE EXTERNAL JOB,

  и объединяющая их роль SCHEDULERADMIN;

• объектные привилегии:
  • EXECUTE
  • ALTER
  • ALL,

  распространяющиеся на объекты типов JOB, SCHEDULE, PROGRAM и JOB CLASS;

• пакет DBMS_SCHEDULER.

Версия 11 дополнила планировщик возможностями:

• запуска «легковесных» заданий, делающей реальным их создание и удаление сотнями за секунду;
• запуска заданий на удаленных машинах посредством использования специального агента;
• запуска заданий только на основной БД физического горячего резерва или на страхующей БД логического резерва.

Некоторые ключевые моменты использования планировщика в Oracle 10 рассматриваются ниже на примерах.

Простой запуск задания

Простой запуск задания очень напоминает запуск с помощью процедуры SUBMIT из пакета DBMS_JOB. Однако, в отличие от SUBMIT, он возможен только при наличии привилегии CREATE JOB. В последующих примерах созданием заданий и управлением ими для простоты будет заниматься пользователь SCOTT, хотя в жизни разумно подумать об отдельном администраторе для этой цели. Выдадим пользователю SCOTT нужную привилегию:

Кроме системных привилегий, использование планировщика регулируется объектными привилегиями EXECUTE, ALTER и ALL, выдача которых применительно (GRANT . ON) к заданию, программе, расписанию или классу заданий позволяет работать с объектами БД типов JOB, PROGRAM, SCHEDULE и JOB CLASS соответственно, введенных в Oracle 10 вместе с новым планировщиком.

Ввиду того, что в дальнейшем предполагаются эксперименты с изменениями зарплаты сотрудников, будет удобно исходную зарплату сохранить:

Внутреннее задание для СУБД

Пример внутреннего задания в виде неименованного блока PL/SQL:

Обратите внимание:

1. Обрамлять блок словами BEGIN и END не обязательно, так как код пакета DBMS_SCHEDULER это сделает самостоятельно (ради особой программной логики, добавляемой им к тексту пользователя).
2. Задание запускается в этом же сеансе и сопровождается неявной выдачей COMMIT. В этом легко удостовериться: Зарплата SAL увеличится на 2. Проверить это в качестве упражнения.

Для хранимой процедуры задание формируется аналогично:

Обратите внимание, что нам не потребовалось удалять старое задание SIMPLE_JOB, так как при выбранных нами параметрах процедуры CREATE_JOB задания (и первое, и второе) прогонялись однократно, моментально и сразу же удалялись автоматически. Последнее как раз можно и отменить посредством не использованного в примере выше параметра AUTO_DROP.

В случае невозможности запустить задание СУБД, подобно тому, как это делалось для старого планировщика (пакет DBMS_JOB), будет делать повторные попытки, но только по несколько иной схеме: через секунду, затем через 10 секунд, затем через 100 и далее – всего 6 раз, если только до этого не наступит очередной плановый момент.

Внешнее задание (для ОС)

Совсем новым в планировщике Oracle 10 является возможность запускать плановые задания в ОС. Однако чтобы это было возможно, в ОС должна быть запущена программа extjob из ПО СУБД. На Windows она запускается службой OracleJobScheduler . Для того чтобы следующий пример проработал, службу необходимо запустить. Вдобавок потребуется выдать пользователю SCOTT еще одну привилегию.

Обратите внимание, что в Windows выдача команды ОС или же запуск командного файла напрямую (без вызова cmd.exe), не проходит.

В Unix аналогичное действие можно записать как ‘ls > /tmp/out. txt’.

Возможности запуска, наблюдения, вмешательства

Так же, как для пакета DBMS_JOB, в новом планировщике предусмотрено именно плановое, а не одноразовое исполнение задания. Добавим к последнему вызову параметр:

В результете корневой файл out.txt получим через 10 секунд после создания задания. Добавим еще параметр: В результате задание будет исполняться ежемесячно по воскресениям и последним субботам месяца. В отличие от DBMS_JOB, DBMS_SCHEDULER, в дополнение к возможности употребить выражение на PL/SQL, имеет для формулирования графика запуска еще и специальный язык. Он позволяет указывать частоту, интервал и уточнитель запуска задания. Примеры:

Для проверки правильности составления выражения можно воспользоваться специальной процедурой:

Полное описание языка приводится в документации по Oracle.

Если указать план запуска, задание появится в системе уже надолго. Удалить его при необходимости можно будет так:

Информацию об имеющихся заданиях пользователь SCOTT может посмотреть запросом:

Более подробную информацию SCOTT обнаружит в таблицах USER_SCHEDULER_%, а более общую – в обычной таблице USER_OBJECTS.

Скомпонованное задание

Более развитая возможность DBMS_SCHEDULER позволяет скомпоновать задание из независимых элементов: программы и расписания. Характерная особенность в том, что оба эти элемента самостоятельны; их можно комбинировать в разных заданиях и изменять, не внося изменений в определения заданий.

Создание программы

Простой пример создания программы:

Список сведений об имеющихся программах для планировщика имеется в таблицах DBA/ALL/USER_SCHEDULER_PROGRAMS.

Другими значениями параметра PROGRAM_TYPE могут быть ‘PLSQL_BLOCK’ и ‘EXECUTABLE’ (см. выше).

При наличии у процедуры параметров их количество потребуется указать особо:

Обратите внимание, что программа создана «отключенной». Дело в том, что указать фактические значения параметрам программе во «включенном» состоянии нельзя, так что последовательность действий будет следующая:

Создание расписания

Пример создания расписания:

В общем случае язык указания графика для расписания (параметр REPEAT_INTERVAL) допускает ссылаться на ранее созданные таким же образом расписания.

Список сведений об имеющихся расписаниях для планировщика имеется в таблицах DBA/ALL/USER_SCHEDULER_SCHEDULES.

Простой пример скомпонованного задания

Из самостоятельно существующих программы и расписания можно составить задание:

При наличии параметра пример может выглядеть так:

Обратите внимание, что в этом случае задание сначала создается выключенным, и только после указания значения параметра программе оно может включаться.

Создание и использование ресурсного окошка СУБД для задания

Очередной запуск внутреннего задания может прийтись на время активного использования ресурсов СУБД другими процессами. Это может замедлить выполнение планового задания, обесценить его выполнение и даже поставить его выполнение под угрозу. Справиться с этой проблемой призвано ресурсное окошко. Суть его состоит в одновременном с очередным запуском задания автоматическом переключении СУБД на работу по требуемому ресурсному плану (план поведения для распределителя ресурсов СУБД, resource manager). Сами ресурсные окошки (windows) принадлежат схеме SYS, но создавать их разрешено и другим пользователям при наличии соответствующей привилегии:

Ресурсный план построить несложно, но, чтобы не отвлекаться, воспользуемся встроенным в любую БД планом SYSTEM_PLAN (см. таблицу DBA_RSRC_PLANS). Тогда создание окошка может выглядеть так:

Теперь каждые три минуты на минуту будет включаться ресурсный план SYSTEM_PLAN. Это легко наблюдать, выдав несколько раз от имени SYS:

Если подгадать момент, когда значение OPERATION для окошка MY_JOB_WINDOW станет OPEN, от имени SYS можно будет удостовериться, что план включен:

Чтобы связать с этим периодически открывающимся ресурсным окошком задание, пользователю SCOTT достаточно указать его вместо расписания:

С этого момента можно наблюдать уменьшение зарплат сотрудников, осуществляемое каждые три минуты в условиях благоприятного ресурсного плана. В качестве варианта, в процедуре CREATE_WINDOW можно было сослаться и на какое-то существующее расписание.

Так как СУБД в каждый момент времени умеет работать только по одному ресурсному плану, окошки «не умеют» перекрываться, а могут только переопределять своим планом другой, ранее установленный и пришедшийся на то же время.

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

Изменение свойств объектов планировщика

Хотя упомянутые JOB, SCHEDULE, PROGRAM, WINDOW и проч., причисляются к объектам хранения БД (и видны в таблицах DBA/ALL/USEROBJECTS), не только их создание и удаление, но и изменение свойств выполняются так, как было удобно разработчику: через API. Для всех перечисленных видов объектов существует довольно много поведенческих свойств, указанию которых нет места в процедурах LIKE ‘CREATE_%’. Устанавливать их следует явно единой для всех процедурой SET_ATTRIBUTE. Вот пример, как для задания MY_WINDOW_JOB (а) задать приоритет выполнения (по отношению к другим заданиям своего класса), если на одно время пришлось выполнение нескольких заданий одновременно, и (б) потребовать прекращения (процедурой STOP_JOB), если оно еще не выполнилось, а ресурсное окошко уже закрылось:

Полный список атрибутов и объектов, к которым они применимы, имеется в документации по Oracle.

Заключение

Помимо использованного выше общения с планировщиком Oracle 10 средствами PL/SQL и SQL, общаться с ним можно через графический интерфейс Oracle Enterprise Manager. По сути, OEM ничего нового не дает, так как в конечном итоге отсылает к СУБД те же команды на PL/SQL и SQL, но выполнение разовых действий через OEM часто администратору быстрее и понятнее. Для автоматизации работ, однако, лучше может подойти работа со сценариями запросов.

После проведенных опытов с планировщиком не забудьте освободить БД от ненужных объектов. Например:

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

Источник

Русские Блоги

Использование и принцип работы Android JobScheduler

Давайте посмотрим на использование JobScheduler, разберемся с использованием JobScheduler и посмотрим на исходный код реализации JobScheduler.

Сначала посмотрим, как его использовать, перевод сtutsplus

JobScheduler позволяет разработчикам создавать задания, которые выполняются в фоновом режиме.При соблюдении заданных условий эти задания будут выполняться в фоновом режиме.

При разработке Android мы будем сталкиваться с множеством таких ситуаций, например, при выполнении некоторых операций в определенный момент в будущем или при выполнении определенных условий в будущем (например, при подключении к сети Wi-Fi или подключении к ней). В Android L Google предоставляет компонент JobScheduler, который помогает нам справиться с этой ситуацией.

JobScheduler Api может выполнять некоторые операции в нашем приложении, и эти операции будут выполняться при выполнении некоторых из наших предустановленных условий. с участием AlarmManager Не то же самое, время выполнения этих операций строго не точное. JobScheduler соберет серию заданий и выполнит их вместе, что не только позволяет выполнять наши задания, но также учитывает использование энергии мобильного телефона и достигает цели экономии электроэнергии.

Как использовать JobScheduler Api

Прежде всего, мы должны убедиться, что минимальный SDK, поддерживаемый создаваемым приложением, выше Android L, потому что пока нет пакета совместимости, обеспечивающего эту функцию.

Напишите наследство и в нашем проекте JobService Сервис (например, называетсяJobSchedulerService), этот Сервис предоставляет два метода обратного вызова, один из которых onStartJob(JobParameters params) с участием onStopJob(JobParameters params) 。

Когда система хочет запустить выполнение нашего задания, она вызывает onStartJob метод. Этот метод вернет логическое значение.

При возвращении false , Система подумает onStartJob Когда этот метод возвращается, работа, которую мы должны сделать, была сделана. Это не требует много времени.

При возвращении true Время, система подумает, что мы должны выполнить трудоемкую задачу, onStartJob Когда этот метод возвращается, наша работа все еще выполняется асинхронно. Когда наша работа будет завершена, мы должны вручную позвонить jobFinished(JobParameters params, boolean needRescheduled)

Важно отметить, если onStartJob Возвращает true, после завершения асинхронной работы мы должны вручную вызвать jobFinished Метод, если не вызван jobFinished , Система всегда будет думать, что мы выполняем текущее задание, тогда система не будет ставить другие задания в очередь для выполнения, то есть очередь выполнения JobScheduler будет заблокирована

Когда система получает запрос на отмену задания, а задание все еще выполняется, система вызывает onStopJob метод.

Другими словами, когда система получает запрос на отмену, она не обязательно вызовет onStopJob Только метод onStartJob вернуть true Будет называться, когда onStopJob , Иначе не называется.
, но независимо от того, вызывается он или нет onStopJob Метод, когда система получит запрос на отмену, она отменит задание (как его отменить, мы проанализируем, когда будем говорить об исходном коде).

Следует отметить, что JobService работает в основном потоке нашего приложения, а это означает, что нам нужно открыть новый поток или использовать Handler или AsyncTask для обработки трудоемкой работы.
Для простоты в следующем коде используется Handler Чтобы справиться с трудоемкой работой и трудоемкой работой в процессе, нужно всего лишь выдать всплывающий тост.

jobFinished(JobParameters params, boolean needRescheduled) Два параметра в первом параметре JobParameter поступают из onStartJob(JobParameters params) Параметры в,Это также показывает, что если мы хотим onStartJob Для выполнения асинхронных операций необходимо сохранить этот JobParameter 。

Далее трансформируем оригинал onStartJob с участием onStopJob ，

Чтобы JobScheduler работал нормально, он должен быть зарегистрирован в AndroidManifest.xml и объявлены разрешения.

1. Создать JobScheduler
   Чтобы использовать созданный нами JobService, у нас должен быть систематический сервис JobScheduler, как показано ниже.

Затем используйте JobInfo.Builder, чтобы установить условия запуска нашего JobScheduler.

JobInfo.Builder может устанавливать множество параметров, но некоторые из них являются взаимоисключающими, и после их установки будет выдано исключение. Вот подробное описание:

setMinimumLatency(long minLatencyMillis) : Этот метод указывает, по крайней мере, сколько миллисекунд будет выполняться наше задание, например setMinimumLatency(5000) , Это показывает, что мы следуем за этим JobScheduler, это задание должно быть выполнено по крайней мере через 5 секунд, и оно определенно не будет выполнено в первые 5 секунд. Этот параметр и setPeriodic Взаимоисключающий. Две одновременные настройки вызовут исключение.

setOverrideDeadline(long maxExecutionDelayMillis) : Этот метод указывает, что наша работа должна быть выполнена через определенный период времени, даже если другие установленные условия не выполняются (например, мы также устанавливаем требования для зарядки, подключения к Wi-Fi и т. Д.). Это строгое и пунктуальное исполнение, такое как setOverrideDeadline(5000) Это означает, что данное задание будет выполнено вовремя на пятой секунде, игнорируя другие условия. Этот метод также setPerioidc Взаимоисключающий.

setPersisted(boolean isPersisted) : Чтобы указать, следует ли продолжать расписание после перезапуска задания.

setRequiredNetworkType(int networkType) : Тип сети, необходимый для начала работы, всего три значения JobInfo.NETWORK_TYPE_NONE Указывает, что при запуске нашей работы подключение к сети не требуется; JobInfo.NETWORK_TYPE_ANY Это указывает на то, что при запуске нашей работы необходимо только подключиться к Интернету, а тип сети не требуется. JobInfo.NETWORK_TYPE_UNMETERED Указывает, что перед началом работы необходимо подключить Wi-Fi.

setRequiresCharging(boolean requiresCharging) Чтобы указать, нужно ли нам подключать питание перед началом работы

setRequiresDeviceIdle(boolean requiresDeviceIdle) : Чтобы указать, нужно ли машине простаивать при запуске нашей работы.

Важно отметить, что при использовании setRequiredNetworkType(int networkType) , setRequiresCharging(boolean requireCharging) с участием setRequiresDeviceIdle(boolean requireIdle) Эти три условия могут привести к тому, что наша работа никогда не будет выполнена. На этот раз нам нужно setOverrideDeadline(long time) Чтобы наша работа могла быть выполнена один раз

После выполнения двух вышеуказанных шагов мы можем запланировать нашу работу

JobScheduler из schedule Метод возвращает целое число. При сбое расписания вернет отрицательное число, при успехе вернет JobInfo.Builder JobId передается, когда.

JobScheduler предоставляет два метода отмены задания, один из которых cancel(int jobId) , Этот метод отменяет указанное задание, одно из них cancelAll Отменить все задания.

Это общий процесс использования JobScheduler, в следующей статье будет проанализирован исходный код JobScheduler.

Источник