Представление системного времени в WebSphere Business Monitor

Так как WebSphere Business Monitor использует несколько баз данных в компоненте служб данных, важно знать как системное время преобразуется системой между этими базами данных во время репликации баз данных.

Возможно несколько допустимых конфигураций топологий WebSphere Business Monitor. Для достижения желаемых результатов для системного времени необходимо знать, как настраиваются эти топологии. При этом используются серверы, содержащие базу данных Рабочая, базу данных Хронология и сервер, на котором установлен WebSphere Portal, являющийся расположением DB2 Alphablox. Если результаты будут сообщаться по гринвичскому времени (GMT), то системное время базы данных Рабочая, базы данных Хронология и систем WebSphere Portal должно быть настроено как GMT. В таком случае системное время и все размерные отчеты будут соответствовать GMT.

При необходимости указывать время как восточное стандартное время (EST) все серверы должны быть настроены на EST. Если необходимо, чтобы клиенты находились в различных часовых поясах, рекомендуется настроить все серверы на GMT. Если клиентские параметры в WebSphere Portal не GMT, то возникнут противоречия между отчетами, использующими системное время (которые будут относительны параметрам WebSphere Portal) и отчетами, выполняющими размерный анализ. Они будут использовать GMT. Ниже приведены технические сведения.

Столбцы системного времени в базе данных Состояние хранятся столько же, сколько и типы данных Java (сериализованные отметки системного времени Java на основе GMT). По мере перемещения системного времени через три базы данных, оно преобразовывается в фактическое системное время DB2 из длинных Java во время этапов ETL между базой данных Рабочая и базой данных Состояние. Это изменение выполняется с помощью UDF на основе Java, преобразующего длинные в системное время и возвращающего тип данных системного времени в DB2. На этом этапе системное время преобразуется исходя из параметров времени сервера, на котором хранится база данных Рабочая. Если это системное время задано как GMT, системное время преобразуется в GMT; в ином случае оно будет преобразовано исходя из смещения часового пояса и смещений сезонного времени в системном времени. Отметки системного времени хранятся в DB2 относительно данного часового пояса, а не GMT. DB2 обладает специальным регистром для извлечения смещения часового пояса и его применения к системному времени.

Системное время, перемещаемое в базу данных Хронология, не преобразуется, поэтому база данных Хронология сохраняет системное время в том же часовом поясе, что и система базы данных Рабочая. Это означает, что серверы баз данных Рабочая и Хронология должны иметь одинаковые параметры часового пояса. В ходе ETL это системное время сравнивается с таблицей DIM_TIME. Таблица DIM_TIME сама по себе не имеет параметров часового пояса, но при объединении с сервером базы данных она будет использовать параметры часового пояса сервера. Таким образом все преобразования в таблицу DIM_TIME выполняются с учетом того, что DIM_TIME и найденное системное время указаны относительно часового пояса сервера базы данных Хронология, который может отличаться от GMT.

Сервер, являющийся хостом для WebSphere Portal, также должен быть настроен на тот же часовой пояс, что и серверы с базами данных Рабочая и Хронология. В настоящее время когда сводные панели отправляют запросы к столбцам системного времени напрямую (без применения измерения времени), текущая архитектура предполагает что часовой пояс баз данных Рабочая и Хронология совпадает с часовым поясом сервера сводной панели. Системное время преобразуется обратно в системное время Java, и WebSphere Portal подразумевает, что системное время сервера базы данных совпадает с его часовым поясом, и выполняет преобразование системного времени обратно в GMT исходя из этого. Клиентская система может иметь другие параметры часового пояса. Неполадок не возникнет до тех пор пока WebSphere Portal преобразовывает системное время в GMT безошибочно. Условием для верного преобразования являются одинаковые параметры часового пояса на серверах баз данных Рабочая и Хронология и WebSphere Portal.

Последний элемент является более ложным из-за TIME DIMENSION в WebSphere Business Monitor. Во время этапа ETL имеются несколько ссылок на TIME DIMENSION для анализа DIMENSIONAL. Пользователь, выполняющий анализ, должен знать, что вне зависимости от клиентских параметров часового пояса, отчеты основаны на часовом поясе серверов баз данных Рабочая и Хронология, где происходит преобразование из GMT в локальное время этих серверов. Несмотря на то, что уровень дискретности TIME DIMENSION составляет только день, разница в часовых поясах может изменить ДЕНЬ, к которому относится определенная запись.


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