Поведение и планирование каждого компонента Службы перемещения данных может
быть по-разному настроено в зависимости от потребностей среды разработки и тестирования
продуктов. Изменение конфигурации одного компонента может непосредственно повлиять на
поведение другого компонента.
В общем, существует две зависимости:
- Компонент сбора данных периодически запускает компонент жизненного цикла источника. Если компонент сбора данных не работает, активизация компонента жизненного цикла источника не
происходит. Можно настроить задержку между вызовами компонента жизненного цикла.
На приведенном выше рисунке компонент жизненного цикла источника вызывается каждые 3
единицы времени, выполняет некоторые действия и возвращает управление компоненту сбора
данных, который продолжает обработку.
- Компонент ETL и компонент жизненного цикла приемника вызываются компонентом применения изменений после успешного перемещения данных из исходной базы данных в
целевую базу данных. Компоненты ETL и жизненного цикла приемника будут вызваны,
только если выполняется компонент применения изменений.
Поскольку существует необходимость выполнения зависящих друг от друга компонентов по различному расписанию,
вызов не обязательно приводит к выполнению. Вместо этого каждый зависимый компонент
при вызове проверяет свое расписание, и если время оказывается неподходящим для выполнения
каких-либо задач, то он возвращает управление вызвавшему его компоненту. В приведенном
выше примере компоненты жизненного цикла приемника и ETL могут быть выполнены только дважды,
если расписание для обоих компонентов ограничивает их вызов одним разом каждые 5 единиц времени.

Компонент ETL
(и компонент жизненного цикла приемника) вызывается и выполняется в момент T2 (соответственно, T3).
Следующий вызов происходит приблизительно в момент T6. Поскольку с момента их последнего выполнения
прошло менее 5 единиц времени, управление немедленно возвращается к компоненту применения
изменений. Последующий вызов приблизительно в момент T8 (соответственно T9) приводит к
выполнению, поскольку прошло более 5 единиц времени. Каждый компонент реализован в виде
одного или нескольких экземпляров. Экземпляры можно настраивать по отдельности для более
гибкого управления.
Прим.: Изменения вступают в силу
немедленно, если не указано иначе.
По умолчанию конфигурации компонентов сбора данных и применения изменений могут быть
изменены или путем соответствующего изменения управляющих таблиц, или с помощью
параметров команд в сценариях запуска. Компоненты вызова жизненного цикла и ETL
можно настроить с помощью одной из управляющих таблиц.
Для настройки компонентов Службы перемещения данных в зависимости от потребностей
среды разработки, тестирования и выполнения необходимо выполнить следующие действия.
Настройка экземпляров компонента сбора данных (Исходного)
Экземпляр компонента сбора данных является эквивалентом утилиты репликации сбора данныхDB2. По умолчанию эта утилита настроена на постоянный сбор измененных данных в
исходных таблицах и запись этих изменений во внутренние рабочие таблицы.
В общем случае, нет необходимости менять настройки по умолчанию для экземпляров
компонента сбора данных.
- Идентификация экземпляров компонента сбора данных.
Для сбора данных, связанных с моделью бизнес-величин, используется несколько
экземпляров компонента сбора данных (или утилит сбора данных
DB2). Для того чтобы выяснить, какие утилиты сбора данных назначены для обслуживания
модели бизнес-величин, выполните следующие действия:
- Определите, для какой службы перемещения данных вы хотите изменить конфигурацию
утилиты сбора данных.
- Проверьте
содержимое таблицы метаданных WBIRMADM.RMMETADATA в базе данных состояний
(для службы перемещения данных из базы данных состояний в рабочую базу данных)
или в рабочей базе данных (для службы перемещения данных из рабочей базы данных
в базу данных хронологии ) и определите имена всех утилит сбора данных (поле SRC_RM_CAP_SVR_NAME).
Пример: По
запросу "SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME, SRC_RM_CAP_SVR_NAME FROM
WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime' " может быть выдано:
В приведенном примере утилита сбора данных CAPTURE_1 назначена для сбора всех
измененных данных в двух исходных таблицах, связанных с моделью бизнес-величин
STEW_S в базе данных состояний.
- Изменение интервала сокращения рабочей таблицы сбора данных.
Утилиты сбора данных
автоматически сокращают свои рабочие таблицы каждые 300 секунд (значение
по умолчанию параметра prune_interval), если включено автоматическое сокращение
(параметр autoprune равен "y"). Каждая операция сокращения
автоматически вызывает экземпляр компонента жизненного цикла источника с
помощью триггера базы данных. Поэтому изменение значения параметра
интервала сокращения для утилиты сбора данных непосредственно влияет на
частоту сокращения исходной таблицы компонентом жизненного цикла источника.
Ниже приведен пример, который иллюстрирует, как изменение интервала
сокращения для утилиты сбора данных может повлиять на вызов экземпляра
компонента жизненного цикла источника.
Увеличение значения параметра prune_interval экземпляра утилиты сбора данных от 2 единиц
времени (например, 300 секунд) до 3 единиц времени (например, 450 секунд) приводит к тому, что:
- Подлежащие удалению
записи рабочих таблиц сбора данных продолжают дольше оставаться в рабочих таблицах.
Следовательно, увеличиваются возможные требования к объему памяти. Размеры рабочих
таблиц возрастают, но загрузка системы и риск возникновения аварийных ситуаций уменьшается.
- Записи исходных таблиц, удаленные
на основании стратегии сохранения жизненного цикла, остаются в исходных таблицах
дольше, чем ожидалось.
Вообще, если параметр
prune_interval утилиты сбора данных имеет большее значение, чем параметр
prune_interval компонента жизненного цикла, то более высокий приоритет
имеет значение параметра утилиты сбора данных. Если утилита сбора данных
не выполняется, или если выключена функция автоматического сокращения, то не выполняется
никаких активаций жизненного цикла источника.
Настройка компонента жизненного цикла источника
В каждой исходной базе данных (состояний и рабочей) используются множественные
экземпляры компонента жизненного цикла. Каждый экземпляр, реализованный с помощью
триггера, осуществляет стратегию сохранения, определенную в таблице WBIRMADM.RMPRUNECTRL,
расположенной в исходной базе данных для службы перемещения данных. Стратегии хранения
жизненного цикла задаются на основе таблиц. Таким образом, одна запись в
WBIRMADM.RMPRUNECTRL соответствует одной таблице, для которой необходимо сокращение.
- Идентификация экземпляров компонента жизненного цикла источника.
Для того чтобы определить, какие триггеры назначены для осуществления стратегий
хранения для данной модели бизнес-величин, выполните следующие действия:
- Определите, для какой службы перемещения данных вы хотите изменить конфигурацию ETL.
- Проверьте содержимое таблицы метаданных WBIRMADM.RMMETADATA в базе данных состояний
(для службы перемещения данных из базы данных состояний в рабочую базу данных) или в
рабочей базе данных (для службы перемещения данных из рабочей базы данных в базу данных
хронологии) и определите имена всех связанных триггеров в поле SRC_RM_PRUNE_TRG_NAME.
Пример: По запросу "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime'" может быть выдано:
В этом примере два триггера (WBIRMADM.MCPruneTrig_8 и WBIRMADM.MCPruneTrig_9)
осуществляют стратегию хранения жизненного цикла для исходных таблиц модели
бизнес-величин STEW_S в базе данных состояний. Поскольку стратегии хранения определены с
помощью таблицы, а не именами экземпляров компонента жизненного цикла,
отслеживайте значения поля SRC_TAB_NAME при планировании изменения режима
вызовов жизненного цикла.
- Изменение конфигурации экземпляра компонента жизненного цикла источника .
- Включение и выключение экземпляров компонента жизненного цикла:
Сокращение может значительно повысить производительность системы. Когда сокращение
включено, это уменьшает объем информации, которую должны обрабатывать сервера
транзакций (статические) и сервера отчетов (динамические). Это также немного
увеличивает нагрузку на те же самые таблицы при каждом вызове в соответствии
со значениями параметров компонента жизненного цикла. Когда сокращение выключено,
объем исходных таблиц будет некоторое время увеличиваться, что может привести
к снижению быстродействия.
По умолчанию исходные таблицы автоматически
сокращаются в соответствии со стратегией хранения жизненного цикла. Для временного
выключения сокращения измените соответствующие записи в WBIRMADM.RMPRUNECTRL: установите
значение поля PRUNE_ENABLED равным 1 для включения сокращения или равным любому другому
численному значению (предпочтительно нулю) для его выключения.
Записи исходной таблицы wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI будут очищены, но никаких
записей таблицы wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE очищено не будет, если используется
следующая конфигурация. По запросу: "SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL"
может быть выдано:
- Изменение стратегии хранения:
Стратегии хранения могут быть изменены только для исходных таблиц, расположенных
в рабочей базе данных. Для всех таблиц, расположенных в базе данных состояний,
время хранения принудительно устанавливается равным 0, независимо от значений
параметров в WBIRMADM.RMPRUNECTRL. Период хранения определяется как минимальное
время, в течение которого запись должна сохраняться в исходной таблице до ее
удаления при наличии двух признаков. Только один из этих двух признаков можно
настроить с помощью управляющих таблиц: время хранения, заданное в минутах.
Каждая запись, помеченная как готовая для удаления, которая остается в исходной
таблице не менее времени RETENTION_IN_MINUTES, подлежит удалению.
Для исходных таблиц рабочей базы
данных значение времени хранения по умолчанию составляет один день (1440 минут),
в течение которого записи, помеченные сервером как готовые к удалению, должны
оставаться в таблицах. По запросу: "SELECT
TABLE_NAME, RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL" может быть выдано:
Измененные записи
управляющей таблицы WBIRMADM.RMPRUNECTRL собираются при каждом вызове
компонента жизненного цикла источника.
- Планирование сокращения исходных данных:
Существует зависимость между интервалом сокращения рабочей таблицы сбора
данных и вызовом компонента жизненного цикла источника. Вызов не приводит
к выполнению компонента, если прошло недостаточно времени после последнего
вызова экземпляра компонента жизненного цикла источника, как показано на
следующем рисунке:
Допустим, что запланировано выполнение компонента жизненного цикла источника
каждые 4 единицы времени, но компонент сбора данных настроен на сокращение
своих рабочих таблиц каждые 2 единицы времени. Тогда вызов в момент T4 не приведет к
выполнению.
Для изменения
расписания, установленного по умолчанию, найдите соответствующие записи в
WBIRMADM.RMPRUNECTRL и измените значение поля PRUNE_INTERVAL, в котором указана
минимальная задержка между выполнениями в минутах.
Увеличение этого значения
приведет к меньшей частоте выполнений (но число вызовов останется прежним). При
каждом выполнении определяется, какие записи исходной таблицы подлежат удалению, и они
удаляются. Регулярно производите отслеживание исходных баз данных для
обнаружения и устранения потенциальных причин снижения производительности,
связанных с блокировками, возникшими в результате этих удалений.
Настройка компонента применения изменений (приемника)
Экземпляр компонента применения изменений - это утилита репликации применения изменений DB2.
Изменения, собранные утилитами сбора данных, непрерывно применяются к промежуточным
таблицам в целевой базе данных по умолчанию. Значения по умолчанию параметров
настройки утилиты должны подходить для большинства сред, и их не следует изменять.
- Идентификация экземпляров компонента применения изменений.
Для внесения изменений данных во внутренние промежуточные таблицы, связанные с
моделью бизнес-величин, используется несколько экземпляров компонента
применения изменений (утилит применения изменений
DB2). Для определения того, какие утилиты применения изменений назначены для
обслуживания модели бизнес-величин, выполните следующие действия:
- Определите, для какой службы перемещения данных вы хотите изменить конфигурацию
утилиты применения изменений.
- Проверьте содержимое таблицы метаданных WBIRMADM.RMMETADATA в базе данных состояний
(для службы перемещения данных из базы данных состояний в рабочую базу данных) или в
рабочей базе данных (для службы перемещения данных из рабочей базы данных в базу данных
хронологии) и определите имена всех утилит применения изменений (поле TGT_RM_APP_SVR_NAME).
По запросу: "SELECT OM_NAME, SRC_TAB_NAME,
SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State
to Runtime'" может быть выдано:
В этом примере все измененные данные в модели бизнес-величин STEW_S, собранные
в базе данных состояний, вносятся в промежуточные таблицы рабочей базы данных
утилитой применения изменений APPLY_4.
Каждый раз,
когда утилита применения изменений завершает обработку всех (подтвержденных) изменений,
записанных к этому моменту утилитой сбора данных, вызываются один или несколько экземпляров
компонента ETL и экземпляры компонента жизненного цикла приемника.
Настройка компонента ETL
Компоненты ETL реализованы в WebSphere Business Monitor в
виде хранимых процедур базы данных. Эти хранимые процедуры всегда расположены в целевой
базе данных для всех служб перемещения данных. Поэтому все хранимые процедуры ETL,
назначенные для службы перемещения данных из базы данных состояний в рабочую базу данных,
расположены в рабочей базе данных, а хранимые процедуры ETL, назначенные для службы
перемещения данных из рабочей базы данных в базу данных хронологии, расположены в базе данных
хронологии.
- Идентификация экземпляров компонента ETL.
Для обработки данных, добавленных во внутренние промежуточные таблицы,
связанные с моделью бизнес-величин, используется несколько экземпляров
компонента ETL. Для того чтобы выяснить, какие хранимые процедуры назначены для
обслуживания заданной модели бизнес-величин, выполните следующие действия:
- Определите, для какой службы перемещения данных вы хотите изменить конфигурацию ETL.
- Проверьте содержимое таблицы метаданных WBIRMADM.RMMETADATA в базе данных состояний
(для службы перемещения данных из базы данных состояний в рабочую базу данных) или в
рабочей базе данных (для службы перемещения данных из рабочей базы данных в базу данных хронологи) и
определите имена всех хранимых процедур ETL (поле TGT_RM_SPETL_NAME). По следующему запросу:
"SELECT OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME
FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'" может быть
выдано:
В этом примере, все измененные данные в модели бизнес-величин STEW_S, собранные
в базе данных состояний и внесенные в промежуточные таблицы в рабочей базе
данных, будут обрабатываться хранимыми процедурами с именами
WBIRMADM.WBIRMSP_10 и WBIRMADM.WBIRMSP_14. Успешно обработанные данные сохраняются в целевых таблицах (определяемых в поле
TGT_TAB_NAME) рабочей базы данных.
- Изменение конфигурации экземпляра компонента ETL.
Конфигурации экземпляров
компонента ETL хранятся в управляющей таблице WBIRMADM.RMCONTROL. Для экземпляров,
назначенных для службы перемещения данных из базы данных состояний в рабочую базу данных,
конфигурации хранятся в рабочей базе данных; а для всех остальных - в
базе данных хронологии. Все изменения, внесенные в конфигурацию, будут собраны
хранимыми процедурами при следующем запуске. С помощью управляемой таблицы можно
настроить три опции:
- Минимальное время между двумя выполнениями ETL (ETLSCHEDMETHOD, ETL_0_MINUTES)
- Уровень дискретности вывода протокола (LOGLEVEL)
- Продолжительность транзакции (COMMITINTERVAL)
Каждая запись
этой таблицы соответствует одному экземпляру компонента ETL, который, в свою очередь,
соответствует одной целевой таблице, требующей заполнения. Следующий пример
иллюстрирует влияние изменений конфигурации на поведение экземпляра.
- Изменение расписания ETL.
Экземпляры компонента ETL вызываются при каждом
завершении обработки набора подписки экземпляром компонента применения изменений. При
вызове экземпляр ETL проверяет свое расписание, а затем или начинает обработку, или
возвращает управление непосредственно экземпляру компонента применения изменений. Он
использует информацию из управляющей таблицы WBIRMADM.RMCONTROL для определения того,
есть ли необходимость в выполнении или нет. На следующем рисунке показана разница между
вызовом и выполнением: при первом и третьем вызовах экземпляр компонента ETL выполняется
в соответствие с расписанием. Второй вызов происходит не по расписанию и не приводит
ни к каким действиям.
На частоту выполнения экземпляров компонента ETL в Службе перемещения данных из
базы данных состояний в рабочую базу данных и в Службе перемещения данных из рабочей
базы данных в базу данных хронологии влияет ряд факторов:
- Коэффициент готовности: определяет, насколько быстро данные должны стать доступны в
целевой таблице. Выбор меньшего интервала приведет к тому, что данные станут доступны
быстрее, но при этом увеличится загрузка системы.
- Объем данных: Утилиты репликации постоянно (или в соответствии с настройками)
поставляют данные в промежуточные таблицы, независимо от того, обработаны ли они
экземплярами компонента ETL или нет. Чем больший объем данных необходимо обрабатывать,
тем больше используется ресурсов базы данных. Более частая обработка данных может
уменьшить максимальное использование ресурсов.
- Время обработки: Обработка компонентом ETL рабочей базы данных занимает меньше
времени, чем обработка базы данных хронологии. Составляйте расписания
соответственно. Применение небольшой задержки между выполнениями не повысит
производительность, если выполнение происходит дольше указанной в расписании задержки. Например, если экземпляр компонента ETL совершает обработку за 60 секунд, то установленный
в расписании 30-секундный интервал в действительности превратится в 60-секундный, поскольку
экземпляры компонентов ETL выполняются последовательно.
В настоящее время поддерживаются два режима планирования:
- Гибкое расписание:
Экземпляр ETL выполняется, только если как минимум
ETL_0_MINUTES прошло после его последнего выполнения (LASTUPDATED). Например,
предположим, что управляющая таблица содержит следующую информацию.
Хранимая процедура
WBIRMADM.WBIRMSP_10 выполнится не раньше, чем 11 октября 2005 в 18:20:20 (11
октября 2005 17:20:20 + 60 минут). Расписания могут проскальзывать, если
хранимая процедура будет вызвана позже, чем 11 октября 2005 года в 18:20.20.
Предположим, что текущее время 19 часов, и хранимая процедура не была выполнена,
как ожидалось, в 18:20. Хранимая процедура вызывается и выполняется (примерно
на 40 минут позже). Она не будет выполняться повторно до, по крайней мере,
19:00+ 60 минут = 20:00. Запланированное выполнение пропущено, поскольку
выполнение процедур ETL было запланировано на 20 минут после начала каждого часа,
но теперь происходит в начале каждого часа. При необходимости можно сбросить расписание, изменив значение системного
времени в поле LASTUPDATED.
Используйте
этот способ планирования, если не требуется выполнение в фиксированное время.
Для включения этого вида планирования установите значение поля ETLSCHEDMETHOD
в таблице WBIRMADM.RMCONTROL равным 0 для всех процедур, которые присвоены
одной группе бизнес-величин:
- Фиксированное расписание:
Это расписание установлено по умолчанию для всех
компонентов ETL. Экземпляры компонента ETL выполняются, если текущее время больше
NEXTSTARTTIME. Для того чтобы избежать пропусков, при каждом выполнении хранимой
процедуры вычисляется время следующего выполнения на основе текущего времени
и предыдущего запланированного времени выполнения. Следующий пример иллюстрирует
подобное расписание:
Предположим, что текущее время равно 19:00 и по некоторым причинам хранимая процедура не
была выполнена, как ожидалось, в 18:20. Хранимая процедура выполняется, поскольку текущее
время больше NEXTSTARTTIME (18:20), а дата та же. Следующее выполнение будет
запланировано на 19:20, в соответствии с первоначальным расписанием, а не на
20:00, как в случае гибкого расписания. Используйте этот метод планирования,
если хранимые процедуры должны выполняться в пределах установленного промежутка
времени. Для включения этого вида планирования установите значение поля ETLSCHEDMETHOD
в таблице WBIRMADM.RMCONTROL равным 1 для всех процедур, которые присвоены
одной группе бизнес-величин:
Настоятельно рекомендуется использовать одинаковый метод планирования для
экземпляров компонента ETL, принадлежащих одной модели бизнес-величин, по
причине их взаимозависимости. Это особенно важно для базы данных хронологии
и для расписаний с большими интервалами (несколько часов или более).
Если для ETLSCHEDMETHOD указано значение,
отличное от 0 или 1, то экземпляр компонента ETL будет выключен.
- Изменение уровня ведения протоколов.
Хранимые процедуры поддерживают два
уровня ведения протоколов: минимальный (0) и максимальный (1). По умолчанию установлено
минимальное значение. При необходимости его можно изменить в поле LOGLEVEL таблицы WBIRMADM.CONTROL для
некоторых хранимых процедур (TGT_RM_SPETL_NAME). Весь вывод протокола
добавляется к таблице WBIRMADM.RMLOG. В следующем примере обе хранимые процедуры
WBIRMADM.WBIRMSP_10 и WBIRMADM.WBIRMSP_14 используют минимальный уровень ведения
протокола:
Поскольку таблица протокола не сокращается автоматически, ее
необходимо регулярно отслеживать с помощью DBA. Используйте минимальный уровень
ведения протокола, если не указано иначе.
- Изменение продолжительности транзакций.
Успешно обработанные хранимыми
процедурами данные немедленно записываются в целевые таблицы. Однако, в зависимости от
значения интервала фиксации (поле COMMITINTERVAL таблицы WBIRMADM.RMCONTROL) изменения в
целевой таблице не фиксируются до тех пор, пока не будет обработано заданное количество
записей, или пока не останется записей для обработки. Увеличение значения COMMITINTERVAL
(например, до 1500) приведет к тому, что хранимая процедура будет обрабатывать большее
количество данных перед выполнением фиксации изменений. Блокировки целевой таблицы будут
более длительными, и это может негативно повлиять на другие компоненты, которые пытаются
получить доступ к этой таблице. При уменьшении продолжительности (например, до 500)
меньшее количество записей обрабатывается до фиксации изменений в целевой таблице, и
блокировки освобождаются раньше.
Настройка компонента жизненного цикла приемника
Объем рабочих таблиц ETL постоянно растет по мере внесения или изменения данных
экземплярами компонента применения изменений. Один экземпляр компонента жизненного цикла
приемника, реализованный с помощью хранимой процедуры, назначается одной рабочей таблице
в каждой целевой базе данных (рабочей или хронологии). Каждый экземпляр
осуществляет внутренние стратегии хранения, определенные в управляющей таблице
WBIRMADM.RMPRUNECTRL. Так же, как и в случае исходных таблиц, стратегии хранения
жизненного цикла для рабочих таблиц ETL задаются на основе таблиц. Таким образом,
одна запись в WBIRMADM.RMPRUNECTRL соответствует одной таблице, для которой
необходимо сокращение.
Обзор параметров конфигурации служб перемещения данных
В следующей таблице перечислены наиболее часто используемые параметры, предусмотренные
для всех компонентов службы перемещения данных. Дополнительная информация о параметрах конфигурации приведена в руководстве по репликации DB2.
Компонент |
Имя параметра |
Значения по умолчанию |
Допустимые значения |
Расположение параметра |
Сбора данных |
autoprune |
Y |
|
|
Сбора данных |
prune_interval (секунд) |
300 |
|
|
Жизненного цикла источника |
PRUNE_ENABLED |
1 |
0 - Выключен
1 - Включен
|
Служба перемещения данных Исходная DB: WBIRMADM.RMPRUNECTRL
|
Жизненного цикла источника |
RETENTION_IN_MINUTES |
0 - Из базы данных состояний в рабочую
1440 - Из рабочей базы данных в базу данных хронологии
|
От 0 до предельного значения BIGINT, установленного в
DB2 |
Служба перемещения данных Исходная DB: WBIRMADM.RMPRUNECTRL
|
Жизненного цикла источника |
PRUNE_INTERVAL (минут) |
5 |
От 0 до предельного значения BIGINT, установленного в
DB2 |
Служба перемещения данных Исходная DB: WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - Гибкое расписание
1 - Расписание с фиксированными
интервалами
Другое - ETL выключен
|
Служба перемещения данных Целевая DB: WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 - Из базы данных состояний в рабочую
1440 - Из рабочей базы данных в базу данных хронологии
|
От 0 до предельного значения INTEGER, установленного в DB2 |
Служба перемещения данных Целевая DB: WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - Для нормального протокола
1 - Для протокола
трассировки
|
Служба перемещения данных Целевая DB: WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (количество записей) |
1000 |
0 - Выключить фиксации до завершения
1 - Фиксировать
каждую запись
n - предельное значение BIGINT, установленное в
DB2
|
Служба перемещения данных Целевая DB: WBIRMADM.RMCONTROL
|
Жизненного цикла приемника |
PRUNE_ENABLED |
1 |
0 - Выключен
1 - Включен
|
Служба перемещения данных Целевая DB: WBIRMADM.RMPRUNECTRL
|
Жизненного цикла приемника |
RETENTION_IN_MINUTES |
0 |
От 0 до предельного значения BIGINT, установленного в
DB2 |
Служба перемещения данных Целевая DB: WBIRMADM.RMPRUNECTRL
|
Жизненного цикла приемника |
PRUNE_INTERVAL (минут) |
1440 |
От 0 до предельного значения BIGINT, установленного в
DB2 |
Служба перемещения данных Целевая DB: WBIRMADM.RMPRUNECTRL
|
Прим.: IBM оставляет за собой право вносить изменения в таблицы базы данных и поля, указанные ниже.
Поэтому некоторые таблицы и поля могут быть изменены, удалены или
добавлены в новом выпуске. Пользователь подвергает себя риску, ожидая увидеть в следующем
выпуске те же содержание и структуру таблиц, которые описаны здесь. IBM документирует
все подобные изменения по мере их появления.