Серверы сезонного времени и сетевого времени

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

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

Воздействие перевода часов на компоненты

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

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

Пример: Запись должна оставаться в системе в течение 24 часов после того, как она становится доступной для удаления. Предположим, что запись стала доступной для удаления 15:00 во вторник. Таким образом, согласно правилу о 24-часовой отсрочке, запись может быть удалена в любое время после 15:00 в среду. Также предположим, что в 15:01 во вторник системные часы были переведены на 15:01, пятницу. Соответственно, несмотря на то, что прошла только одна минута из отпущенных 24 часов, система посчитает, что прошло 3 дня и 1 минута и 24-часовой период хранения записи завершился. Это означает, что из-за изменения времени запись может быть удалена скорее, чем в том случае, если бы системное время не менялось.

Другой пример: Некий компонент ETL выполняется каждые 24 часа и сразу после его запуска системное время переведено вперед на 26 часов. Вместо того, чтобы подождать положенные 24 часа до следующего запуска, компонент ETL будет вновь запущен при первой возможности. Ведь система посчитала, что с его последнего запуска прошло не меньше 26 часов. Таким образом, перевод часов вперед привел к сокращению интервала между запусками ETL. После второго запуска компонент ETL вернется к своему нормальному расписанию, если только в системное время не будут внесены другие изменения.

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

Компонент сбора данных будет продолжать собирать данные об изменениях для всех отслеживаемых таблиц. Для определения времени внесения этих изменений и обеспечения их доступности для компонента применения изменений и компонента жизненного цикла источника используется подсчет времени. Компонент сбора данных наиболее вероятно имеет метки внутреннего системного времени, относящиеся к будущему. Он не будет выполнять транзакцию до тех пор, пока внутреннее время не превысит внутренние метки системного времени, а также некоторые внутренние параметры для интервала между выполнениями. В данном случае, если системные часы переведены на 1 час назад, то в худшем случае транзакции, которые следует выполнить в следующий час, будут недоступны до истечения этого часа. Если часы были переведены на 1 год назад, то для возврата к нормальному режиму работы системе потребуется 1 год.
Прим.: Компонент сбора данных выполняется после определенного числа транзакций; по умолчанию 120. Возможно, что данные будут доступны компонентам применения изменений и жизненного цикла источника ранее отведенного срока.

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

Системное время не определяет какие строки следует скопировать. Это определяется внутренним значением, на которое системные часы не влияют. Компоненты жизненного цикла источника и приемника используют системное время для определения времени запуска и записей, подлежащих удалению.

Компонент жизненного цикла источника в службе перемещения данных Состояния в Среду выполнения использует только системное время для определения времени запуска. Системное время для определения объектов для удаления не используется. Этот компонент данной службы не поддерживает функцию стратегии отсрочки, позволяющую информации, допускающей удаление, хранится некоторое время согласно стратегии отсрочки. Однако эта функция имеется в компоненте жизненного цикла источника службы перемещения данных Среды выполнения в Хронологию. Некоторые записи не соответствуют критериям стратегии отсрочки пока текущее системное время не сравняется. Компоненты жизненного цикла приемника в обеих службах перемещения данных поддерживают определение стратегии отсрочки, поэтому любые изменения времени влияют на время их выполнения и удаляемые ими объекты.

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

Возможны следующие сценарии перевода системного времени:

Восстановление

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

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

Исправление ситуации

Одним из вариантов является принудительное выполнение полного обновления компонентами сбора данных и применения изменений и последующее обновление внутреннего системного времени компонентов жизненного цикла источника, жизненного цикла приемника и ETL.
  1. Идентифицируйте все баз данных, выполняемые на сервере, на котором время было переведено вперед и затем обратно назад. Возможны два вариант: Состояние и Рабочая либо Рабочая и Хронология.
  2. Остановите все серверы, поддерживающие службы перемещения данных в подверженных системах. Во время этого процесса вы измените внутренние параметры и некоторые компоненты могут оказаться не синхронизированными, если их выполнение разрешено. Дополнительная информация приведена в разделе Запуск и остановка службы перемещения данных.
  3. Измените внутреннее системное время компонентов жизненного цикла источника и компонентов жизненного цикла приемника.
    Прим.: Это действие различается в разных выпусках.
    1. Обновление системного времени сокращения таблиц жизненного цикла источника. При этом будут изменены свойства всех компонентов жизненного цикла источника, обслуживающих все модели бизнес-величин в системе.
      Проверьте текущие свойства:
      connect to <source_database>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL, CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME LIKE 'APP%'
      Прим.: Проверьте значения LAST_PRUNED и PRUNE_INTERVAL, и CURRENT TIMESTAMP. Определитесь, будете ли вы удалять немедленно или в следующем интервале.
      -- ДЛЯ ВЫПОЛНЕНИЯ немедленно.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME LIKE 'APP%';
      -- ДЛЯ ВЫПОЛНЕНИЯ в следующем интервале.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(ntreott системное время)
      WHERE TABLE_NAME LIKE 'APP%';
      connect reset;
    2. Обновление системного времени сокращения таблиц жизненного цикла приемника.
      CONNECT TO <target_database>
      SELECT PC.TABLE_NAME, PC.RETENTION_IN_MINUTES, PC.LAST_PRUNED, PC.PRUNE_INTERVAL,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP"
      FROM WBIRMADM.RMPRUNECTRL PC
      WHERE PC.TABLE_NAME NOT LIKE 'APP%';
      Прим.: Проверьте значения LAST_PRUNED и PRUNE_INTERVAL, и CURRENT TIMESTAMP. Определитесь, следует ли сократить немедленно или в следующем интервале.
      -- ДЛЯ ВЫПОЛНЕНИЯ немедленно.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(CURRENT TIMESTAMP - PRUNE_INTERVAL MINUTES)
      WHERE TABLE_NAME NOT LIKE 'APP%';
      -- ДЛЯ ВЫПОЛНЕНИЯ в следующем интервале.
      UPDATE WBIRMADM.RMPRUNECTRL SET (LAST_PRUNED)=(ntreott системное время)
      WHERE TABLE_NAME NOT LIKE 'APP%';
    3. Обновление расписания ETL.
      Прим.: Это окажет воздействие на действия ETL во всех моделях.
      CONNECT TO <TARGET>
      -- Этот запрос показывает
      SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED,
      CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
      Прим.: Значения ETL_0_MINUTES, NEXTSTARTTIME и LASTUPDATED сравниваются с CURRENT TIMESTAMP.
      -- ДЛЯ ВЫПОЛНЕНИЯ в следующем интервале
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP + ETL_0_MINUTES MINUTES, CURRENT TIMESTAMP);
      -- ДЛЯ ВЫПОЛНЕНИЯ немедленно.
      UPDATE WBIRMADM.RMCONTROL SET (NEXTSTARTTIME, LASTUPDATED)=
      (CURRENT TIMESTAMP,CURRENT TIMESTAMP-ETL_0_MINUTES MINUTES);
      CONNECT RESET
    4. Принудительно выполните полное обновление. Самым простым способом принудительного выполнения полного обновления серверов Сбора данных и Применения изменений является копирование и изменение сценариев StartCapture для каждой модели бизнес-величин. Найдите все сценарии запуска сбора для каждой модели, развернутой в системе (если вы следовали инструкциям в разделе, посвященном объединенному запуску и остановке сценариев, то просто найдите все команды asncap), и добавьте параметр: STARTMODE=COLD в конец командной строки.
      Прим.: Полное обновление является крайней мерой и может привести к снижению производительности до завершения выполнения полного обновления. Причиной этому является то, что при полном обновлении добавляется дополнительная нагрузка, обычно отсутствующая при обычной деятельности служб данных. Поэтому важно выполнять полное обновление тогда, когда система не слишком загружена. Быстродействие полного обновления зависит от объема данных в исходной базе данных службы перемещения данных.

      Пример:

      До:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."
      После:
      db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLD
      Затем запустите все сценарии. В результате выполнения полного обновления компоненты сбора данных и применения изменений сбросят параметры внутреннего системного времени, но потребуют дополнительных расходов на перемещение и повторную обработку данных. Важно заранее подготовиться к потенциальному снижению производительности до момента, пока система не сравняется.

Copyright IBM Corporation 2005, 2006. Все права защищены.