Серверы сезонного времени и сетевого времени одинаково влияют на параметры текущего времени на сервере. В службах перемещения данных системное время используется для определения времени проверки серверами наличия новых данных и выполнения перемещения данных. Внесение изменений в системное время воздействует на компоненты служб данных и их производительность.
Ручной перевод системных часов также влияет на время. Вне зависимости от способа перевода часов, оказывается воздействие на систему. При переводе часов назад возникают нежелательные задержки в работе служб перемещении данных. При переводе часов вперед задержки не возникают, однако компоненты служб перемещения данных будут выполнять запланированные задания раньше срока.
Воздействие перевода часов на компоненты
Если системные часы переведены назад, внутреннее системное время подверженных компонентов будет задано в будущем, а системные часы - в прошлом. Перевод системных часов окажет влияние на системные часы, это внутреннее системное время и параметры, указывающие интервалы.
Если системные часы перевести вперед, то внутреннее системное время подверженных компонентов будет задано в прошлом, а текущее системное время системных часов - в будущем. Это схоже с обычным поведением системных часов; разница заключается в том, что будут затронуты некоторые показатели времени, определяющие время следующего запланированного запуска или жизненный цикл записи базы данных. Фактический период прошедшего времени окажется меньше, чем подсчитанный.
Пример: Запись должна оставаться в системе в течение 24 часов после того, как она становится доступной для удаления. Предположим, что запись стала доступной для удаления 15:00 во вторник. Таким образом, согласно правилу о 24-часовой отсрочке, запись может быть удалена в любое время после 15:00 в среду. Также предположим, что в 15:01 во вторник системные часы были переведены на 15:01, пятницу. Соответственно, несмотря на то, что прошла только одна минута из отпущенных 24 часов, система посчитает, что прошло 3 дня и 1 минута и 24-часовой период хранения записи завершился. Это означает, что из-за изменения времени запись может быть удалена скорее, чем в том случае, если бы системное время не менялось.
Другой пример: Некий компонент ETL выполняется каждые 24 часа и сразу после его запуска системное время переведено вперед на 26 часов. Вместо того, чтобы подождать положенные 24 часа до следующего запуска, компонент ETL будет вновь запущен при первой возможности. Ведь система посчитала, что с его последнего запуска прошло не меньше 26 часов. Таким образом, перевод часов вперед привел к сокращению интервала между запусками ETL. После второго запуска компонент ETL вернется к своему нормальному расписанию, если только в системное время не будут внесены другие изменения.
Следующие разделы посвящены только переводу часов назад после выполнения компонентов до того, как часы были переведены обратно.
Компонент применения изменений также поддерживает внутреннее системное время, определяющее время выполнения проверки на наличие новых записей. В этом сценарии внутреннее системное время будет больше, чем текущее системное время системы. Компонент применения изменений ждет пока системное время системы не сравняется с его внутренним системным временем, даже при наличии новых записей. Когда системное время сравняется, он приступит к поиску записей, доступных для перемещения данных.
Системное время не определяет какие строки следует скопировать. Это определяется внутренним значением, на которое системные часы не влияют. Компоненты жизненного цикла источника и приемника используют системное время для определения времени запуска и записей, подлежащих удалению.
Компонент жизненного цикла источника в службе перемещения данных Состояния в Среду выполнения использует только системное время для определения времени запуска. Системное время для определения объектов для удаления не используется. Этот компонент данной службы не поддерживает функцию стратегии отсрочки, позволяющую информации, допускающей удаление, хранится некоторое время согласно стратегии отсрочки. Однако эта функция имеется в компоненте жизненного цикла источника службы перемещения данных Среды выполнения в Хронологию. Некоторые записи не соответствуют критериям стратегии отсрочки пока текущее системное время не сравняется. Компоненты жизненного цикла приемника в обеих службах перемещения данных поддерживают определение стратегии отсрочки, поэтому любые изменения времени влияют на время их выполнения и удаляемые ими объекты.
Компоненты ETL используют системное время для создания внутреннего расписания. После запуска эти компоненты ожидают увеличения времени. Когда же системные часы переводятся назад, это воздействует на расписание ETL, и ETL не выполняется до тех пор, пока системное время не сравняется.
Восстановление
Выполнять восстановление в ходе изменений, сделанных сервером времени, нет необходимости, так как разница во времени должна быть очень малой - всего несколько минут. В результате будет создан небольшой интервал, в течение которого ничего не будет происходить, пока время компонентов не сравняется. При изменении времени, из-за сезонного времени, перевод часов назад приведет к остановке копирования компонентов в течение часа, после чего компоненты должны будут догнать систему. Является ли это проблемой - зависит от вашей системы.
Это может оказаться серьезной проблемой если по ошибке системное время переведено вперед на существенное значение во время выполнения серверов компонентов. В такой ситуации (вне зависимости от того, что выполняется на серверах) время будет восстановлено на текущее. Внутреннее системное время компонентов будет переведено вперед, но выполняться они будут в текущих временных рамках. Перед следующей обработкой строк службой перемещения данных возникнет существенная задержка.Эта задержка может привести к накоплению работы в системе, которая повлияет на время восстановления. Администратор может принять меры для исправления ситуации.
Исправление ситуации
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%'
-- ДЛЯ ВЫПОЛНЕНИЯ немедленно. 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;
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%';
-- ДЛЯ ВЫПОЛНЕНИЯ немедленно. 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%';
CONNECT TO <TARGET> -- Этот запрос показывает SELECT TARGETTABLE, TGT_RM_SPETL_NAME, ETL_0_MINUTES, NEXTSTARTTIME, LASTUPDATED, CURRENT TIMESTAMP as "CURRENT TIMESTAMP" FROM WBIRMADM.RMCONTROL;
-- ДЛЯ ВЫПОЛНЕНИЯ в следующем интервале 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
Пример:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="."После:
db2cmd asncap CAPTURE_SERVER=STATE CAPTURE_SCHEMA=CAPTURE_1 CAPTURE_PATH="." STARTMODE=COLDЗатем запустите все сценарии. В результате выполнения полного обновления компоненты сбора данных и применения изменений сбросят параметры внутреннего системного времени, но потребуют дополнительных расходов на перемещение и повторную обработку данных. Важно заранее подготовиться к потенциальному снижению производительности до момента, пока система не сравняется.