可以配置每个数据移动服务组件的行为和调度,以满足开发、测试和生产环境的不同需求。更改某一组件的配置可能会直接影响依赖该组件的其他组件的行为。
通常,有两种依赖性:
- “捕获”组件定期调用“源生命周期”组件。
如果“捕获”组件没有运行,则不会执行源生命周期强制。生命周期组件调用之间的延迟是可配置的。
上图中,每 3 个时间单位调用一次“源生命周期”组件,它将执行某项活动,然后将控制返回到“捕获”组件,由“捕获”组件继续处理。
- 在成功将数据从源数据库移到目标数据库之后,由“应用”组件来调用 ETL 组件和“目标生命周期”组件。只有在“应用”组件运行时才调用 ETL 和“目标生命周期”组件。
由于依赖组件的运行调度与被依赖组件不同,所以调用未必会产生执行。每个依赖组件在被调用时会检查其调度,如果执行任务的时间还没到,则将控制返回给调用组件。上例中,如果 ETL 和“目标生命周期”组件的调度限制使对它们的调用每 5 时间单位不能超过一次,则这两个组件可能只执行两次。
如果在 T2(或 T3)调用和执行 ETL 组件(或“目标生命周期”组件)。
下一次调用大约在 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 的两个相关源表的所有更改。
- 更改“捕获”工作表的修剪时间间隔。
如果启用自动修剪(autoprune 参数等于“y”),“捕获”实用程序会每隔 300 秒(prune_interval 参数的缺省值)自动修剪其工作表。每个修剪活动都将自动产生“源生命周期”组件实例的调用,该实例由数据库触发器实施。更改“捕获”实用程序的修剪时间间隔参数会直接影响“源生命周期”组件修剪源表的频率。以下说明了更改“捕获”的修剪时间间隔对“源生命周期”组件实例的调用有何影响。
将“捕获”实例 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 以启用修剪,或设置为任何其他数值(最好是 0)以禁用修剪。
如果使用以下配置,则将修剪源表 wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI 中的行,但不会修剪表 wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE 中的行。
查询:“SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL”可能会导致以下情况:
- 更改保留时间策略:
只能更改位于运行时数据库中的源表的保留时间策略。对于所有位于状态数据库中的表,不管 WBIRMADM.RMPRUNECTRL 中的设置如何,保留期强制为 0。保留期定义为源表中的行在可删除(如果满足两个条件)前必须保留的最小时间。这两个条件中,只有一个是可通过控制表来定制的:以分钟为单位的保留时间。任何已标记为可删除且已在源表中保留了至少 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'”可能会导致以下情况:
本例中,由名为 WBIRMADM.WBIRMSP_10 和 WBIRMADM.WBIRMSP_14 的存储过程处理在状态数据库中捕获并应用于运行时数据库中登台表的业务度量模型 STEW_S 的数据更改。
成功处理的数据将保存在运行时数据库中的目标表(由 TGT_TAB_NAME 列标识)。
- 修改 ETL 组件实例配置。
ETL 组件实例配置存储在 WBIRMADM.RMCONTROL 控制表中。
已指定给状态至运行时数据移动服务的实例在运行时数据库中维护其配置;所有其他实例在历史数据库中维护其配置。对配置的任何更改都将在下一次启动时由存储过程获取。通过控制表可配置三种选项:
- 两次 ETL 执行之间的最小耗用时间(ETLSCHEDMETHOD, ETL_0_MINUTES)
- 日志记录输出的详细程度(LOGLEVEL)
- 事务持续时间(COMMITINTERVAL)
该表中的每一行对应于一个 ETL 组件实例,而每个 ETL 组件实例则对应于一个需要填充的目标表。以下示例配置说明了对配置的更改将如何影响实例行为。
- 更改 ETL 调度。
每次“应用”组件实例完成对预订集的处理时,都会调用 ETL 组件实例。一经调用,ETL 实例会检查其调度,然后启动处理或立即将控制返回到“应用”组件实例。
它使用存储在控制表 WBIRMADM.RMCONTROL 中的信息,来确定是否需要执行。下图显示了调用和执行之间的区别:根据调度,第一次调用和第三次调用时执行 ETL 组件实例。第二次调用发生在调度以外,并不会导致任何处理活动。
决定 ETL 组件实例在状态至运行时数据移动服务中和运行时至历史的数据移动服务中运行频率的因素有多种:
- 可用性:目标表中的数据隔多久可访问。
选择较小的时间间隔会使数据较早可用,但也会增加系统负载。
- 数据量:复制实用程序不间断地(或根据配置)将数据输入登台表,而不管是否由 ETL 组件实例来处理它。使用的数据库资源越多,需要处理的数据就越多。更频繁地处理数据会降低最大资源使用率。
- 处理时间:ETL 在运行时数据库中处理数据的时间少于在历史数据库中处理数据的时间。请据此规划调度。如果执行的持续时间大于调度延迟,则缩小执行之间的延迟不会提高性能。例如,如果 ETL 组件实例需要 60 秒完成处理,则 30 秒的调度时间间隔实际上变成至少 60 秒的调度时间间隔,因为 ETL 组件实例是连续执行的。
- 更改日志记录级别。
存储过程支持两个日志记录级别:最小(0)和最大(1)。要修改缺省的最小设置,请在 WBIRMADM.CONTROL 中更改需要更改日志记录级别的存储过程(TGT_RM_SPETL_NAME)的 LOGLEVEL 列的值。将所有日志记录输出附加到 WBIRMADM.RMLOG。这两个示例存储过程 WBIRMADM.WBIRMSP_10 和 WBIRMADM.WBIRMSP_14 都会执行最小日志记录:
由于不会自动修剪日志表,因此需要由 DBA 定期监控。
除非另有说明,否则应使日志记录输出保持最小。
- 更改事务持续时间。
存储过程成功处理的数据将立即写入目标表。然而,根据落实时间间隔设置(WBIRMADM.RMCONTROL 中的 COMMITINTERVAL 列),在处理了指定的行数或没有更多行需要处理之前,对目标表所做的任何更新都不是永久的。增加 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 将在此类更改出现时加以记录。