El comportamiento y la planificación de cada componente del servicio de movimiento de datos se puede configurar en conformidad con las distintas necesidades de los entornos de desarrollo, de prueba y de producción. Las modificaciones en la configuración de uno de los componentes pueden tener un impacto directo sobre el comportamiento de los demás componentes que dependen de él.
En general, hay dos tipos de dependencias:
- El componente Capture invoca de forma periódica al componente Ciclo de vida fuente.
Si el componente Capture no está ejecutándose, no aplica la política del Ciclo de vida fuente.
El intervalo de tiempo entre invocaciones del componente Ciclo de vida es configurable.
En la figura anterior, el componente Ciclo de vida fuente se invoca cada 3 unidades de tiempo, realiza alguna actividad y a continuación le devuelve el control al componente Capture, que continúa el proceso.
- El componente Apply invoca el componente ETL y el componente Ciclo de vida destino una vez que los datos se han trasladado con éxito de la base de datos de origen a la base de datos de destino. Los componentes ETL y Ciclo de vida destino sólo se invocan cuando el componente Apply está ejecutándose.
Dado que es necesario que los componentes dependientes operen en planificaciones distintas de las del componente del que dependen, una invocación no acaba necesariamente en ejecución. Así, cada componente dependiente comprueba su planificación tras la invocación y si todavía no es el momento de efectuar las tareas, devuelve el control al componente que lo ha llamado.
En el ejemplo anterior, los componentes ETL y Ciclo de vida destino podrían ejecutarse únicamente dos veces si la planificación de ambos impide que se invoquen más de una vez cada cinco unidades de tiempo.

El componente ETL y el componente Ciclo de vida destino se invocan y ejecutan a T2 y T3 respectivamente.
La invocación siguiente tendrá lugar aproximadamente a T6. Puesto que han transcurrido menos de 5 unidades de tiempo desde su última ejecución, el componente Apply retoma de inmediato el control. Las invocaciones posteriores aproximadamente a T8 y T9 respectivamente provocan su ejecución puesto que han transcurrido más de cinco unidades de tiempo. Cada componente es implementado por una o más instancias del componente. Es posible configurar por separado cada una de las instancias para conseguir un control de mayor granularidad.
Nota: A menos que se indique lo contrario, los cambios que se hagan entrarán en vigor de inmediato.
La configuración por omisión de los componentes Capture y Apply se puede modificar cambiando las tablas de control pertinentes o alterándolas temporalmente utilizando los parámetros de línea de mandatos de los scripts de inicio. Los componentes ETL y Ciclo de vida se pueden configurar actualizando una de las tablas de control.
Lleve a cabo los siguientes pasos para personalizar los componentes del servicio de movimientos de datos para satisfacer los requisitos de los entornos de desarrollo, prueba y producción.
Configuración de las instancias del componente Capture (fuente)
Una instancia de componente Capture es equivalente a un programa de utilidad de duplicación de Capture de DB2.
Este programa de utilidad está configurado por omisión de modo que capture continuamente los cambios que se efectúen en las tablas de origen y grabe los cambios en las tablas de trabajo internas. Por lo general, no es necesario modificar la configuración por omisión de las instancias del componente Capture.
- Identificación de las instancias del componente Capture.
Para capturar los datos asociados a un
modelo de magnitudes empresariales se utilizan varias instancias del componente Capture (es decir, programas de utilidad Capture de
DB2).
Para determinar qué programas de utilidad Capture se han asignado para proporcionar servicios a un
modelo de magnitudes empresariales es preciso:
- Identificar el servicio de movimiento de datos para el que desea modificar la configuración del programa de utilidad Capture.
- Inspeccionar la tabla de metadatos WBIRMADM.RMMETADATA de la base de datos de estado (para el servicio de movimiento de datos de estado a tiempo de ejecución) o en la base de datos de tiempo de ejecución (para el servicio de movimiento de datos de tiempo de ejecución a histórica) e identificar
todos los nombres del programa de utilidad Capture (columna SRC_RM_CAP_SVR_NAME).
Ejemplo: la consulta
"SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME, SRC_RM_CAP_SVR_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime' " puede producir lo siguiente:
En el ejemplo anterior, al programa de utilidad Capture
CAPTURE_1 se ha asignado capturar todas las modificaciones realizadas en las dos tablas de origen asociadas al modelo de magnitudes empresariales STEW_S en la base de datos de estado.
- Modificación del intervalo de poda de la tabla de trabajo de Capture.
Los programas de utilidad Capture podan automáticamente sus tablas de trabajo cada 300 segundos (el valor por omisión del parámetro prune_interval) si la poda automática está habilitada (el parámetro autoprune tiene el valor "y"). Cada actividad de poda invoca automáticamente una instancia del componente Ciclo de vida fuente, que es implementada por un desencadenante de base de datos. La modificación del parámetro de intervalo de poda de un programa de utilidad Capture tiene un impacto directo sobre la frecuencia en que el componente Ciclo de vida lleva a cabo la poda de las tablas de origen. A continuación se ilustra el efecto que provoca la modificación del intervalo de poda de Capture en la invocación de la instancia del componente Ciclo de vida fuente.
El incremento del parámetro prune_interval de 2 unidades de tiempo (por ejemplo,300 segundos) a 3 unidades de tiempo (450 segundos) hace que:
- Las filas de las tablas de trabajo de Capture que cumplen las condiciones para ser suprimidas permanezcan más tiempo en la tabla de trabajo y, en consecuencia, que hagan aumentar los requisitos de espacio potencial. Las tablas de trabajo aumentarán su tamaño, pero la carga del sistema y los riesgos potenciales pueden verse reducidos.
- Las filas de las tablas de origen que pueden suprimirse en base a la política de retención del ciclo de vida, permanezcan en la tabla de origen más tiempo del previsto.
En general, si el parámetro prune_interval de Capture se establece con un valor mayor que el parámetro prune_interval del componente Ciclo de vida, tiene prioridad el valor del parámetro de Capture. Si el programa de utilidad de Capture no está ejecutándose o si su función de poda automática no está habilitada, no se aplicará la política del Ciclo de vida.
Configuración del componente Ciclo de vida fuente
En cada una de las bases de datos de origen (estado y tiempo de ejecución) se utilizan varias instancias del componente Ciclo de vida. Cada una de las instancias, que ejecuta un desencadenante, impone las políticas de retención que haya definidas en la tabla WBIRMADM.RMPRUNECTRL, la cual está ubicada en la base de datos de origen del servicio de movimiento de datos. Las políticas de retención del ciclo de vida se especifican a nivel de tabla. Así, una fila de WBIRMADM.RMPRUNECTRL corresponde a una tabla que precisa ser podada.
- Identificación de las instancias del componente Ciclo de vida fuente.
Para saber cuáles son los desencadenantes que se han asignado para hacer cumplir las políticas de retención de un determinado
modelo de magnitudes empresariales, debe realizar lo siguiente:
- Identifique el servicio de movimiento de datos cuya configuración de ETL desea modificar.
- Inspeccione la tabla WBIRMADM.RMMETADATA de la base de datos de estado (del servicio de movimiento de datos de estado a tiempo de ejecución) o de la base de datos de tiempo de ejecución (del servicio de movimiento de datos de tiempo de ejecución a histórica) y busque en la columna SRC_RM_PRUNE_TRG_NAME los nombres de los desencadenantes asociados.
Ejemplo: La consulta "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime'" puede producir lo siguiente:
En este ejemplo hay dos desencadenantes (WBIRMADM.MCPruneTrig_8 y WBIRMADM.MCPruneTrig_9) en la base de datos de estado que hacen cumplir la política de retención del ciclo de vida de las tablas de origen del
modelo de magnitudes empresariales STEW_S. Puesto que las políticas de retención se definen por tabla y no por los nombres de las instancias del componente Ciclo de vida, haga un seguimiento de la columna SRC_TAB_NAME cuando planifique cambiar el comportamiento de las políticas de ciclo de vida.
- Modificación de las configuraciones de las instancias del componente Ciclo de vida fuente.
- Habilitación e inhabilitación de las instancias del componente Ciclo de vida:
La poda puede tener un impacto significativo en el rendimiento del sistema. Cuando la poda está habilitada, se reduce la cantidad de información que tienen que manejar los servidores de transacciones (estado) y los servidores de informes (tiempo de ejecución). También añade una pequeña carga adicional sobre dichas tablas durante cada invocación en función de los parámetros del componente Ciclo de vida.
Cuando la característica de poda está inhabilitada, las tablas de origen irán aumentando de tamaño y pueden acabar causando una degradación del rendimiento.
Las tablas de origen están configuradas por omisión para que su poda se realice automáticamente de acuerdo con su política de retención del ciclo de vida. Para inhabilitar la poda temporalmente, modifique las entradas WBIRMADM.RMPRUNECTRL correspondientes: establezca la columna PRUNE_ENABLED en 1 para habilitar la poda y en cualquier otro valor numérico (cero preferiblemente) para inhabilitarla.
Si se utiliza la configuración siguiente se depurarán las filas de la tabla wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI, pero no las de la tabla wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE. La consulta: "SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL" puede producir lo siguiente:
- Modificación de la política de retención:
Las políticas de retención basadas en el tiempo sólo pueden modificarse para las tablas de origen que estén ubicadas en la base de datos de tiempo de ejecución.
Para todas las tablas ubicadas en la base de datos de estado se aplica un periodo de retención de 0, independientemente de los valores establecidos en WBIRMADM.RMPRUNECTRL.
El período de retención es el tiempo mínimo que debe retenerse una fila en una tabla de origen antes de que pueda eliminarse, siempre que cumpla dos criterios. Solamente uno de los dos criterios puede personalizarse mediante la tabla de control: el tiempo de retención que se especifica en minutos.
Todas las filas que se marquen para ser suprimidas y que permanezcan en la tabla de origen durante al menos RETENCIÓN_EN_MINUTOS podrán ser eliminadas.
Si se utiliza la configuración por omisión en las tablas de origen fuente de la base de datos de tiempo de ejecución, las filas que el servidor marque como listas para su supresión deben conservarse durante al menos un día
(1440 minutos) antes de que puedan eliminarse. La consulta: "SELECT
TABLE_NAME, RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL" puede producir lo siguiente:
Las modificaciones de las entradas de la tabla de control WBIRMADM.RMPRUNECTRL se recogerán cada vez que se invoque el componente Ciclo de vida fuente.
- Planificación de la poda de los datos de origen:
Existe una dependencia
entre el intervalo de poda de la tabla de trabajo de Capture y la invocación del componente del ciclo de vida fuente. Una invocación no resultará en una ejecución si no ha transcurrido el tiempo suficiente entre las invocaciones de instancias del componente Ciclo de vida fuente, tal como se muestra abajo en la siguiente figura.
Suponiendo que el componente Ciclo de vida fuente se ha planificado para que se ejecute cada 4 unidades de tiempo, pero el componente Capture se ha configurado para que pode sus tablas de trabajo cada 2 unidades de tiempo, la invocación a la hora T4 no desembocará en ejecución.
Para modificar la planificación por omisión, localice las entradas apropiadas en WBIRMADM.RMPRUNECTRL y modifique el valor PRUNE_INTERVAL de la columna, el cual representa el tiempo mínimo en minutos que debe transcurrir entre ejecuciones.
El incremento del valor provoca ejecuciones menos frecuentes, pero el número de invocaciones permanece invariable. Cada ejecución determina qué filas de la tabla de origen ya pueden suprimirse y las elimina.
Supervise con regularidad las bases de datos de origen para identificar y eliminar los problemas de rendimiento potenciales que provocan tales supresiones y los consecuentes bloqueos.
Configuración del componente APPLY (destino)
Una instancia de un componente Apply es un programa de utilidad de duplicación Apply de DB2.
Las modificaciones que capturan los programas de utilidad Capture son aplicadas permanentemente y por omisión a las tablas de base de la base de datos de destino. Los parámetros por omisión del programa de utilidad son apropiados para la mayor parte de los entornos, por lo que no tendrían que modificarse.
- Identificación de las instancias del componente Apply.
Para aplicar cualquier modificación a los datos de las tablas de base internas asociadas al
modelo de magnitudes empresariales se precisan varias instancias del componente Apply (programa de utilidad Apply de
DB2).
Para determinar qué programas de utilidad Apply se han asignado para proporcionar servicios para un
modelo de magnitudes empresariales:
- Identificar el servicio de movimiento de datos para el que desea modificar la configuración del programa de utilidad Apply.
- Inspeccionar la tabla de metadatos WBIRMADM.RMMETADATA de la base de datos de tiempo de ejecución (para el servicio de movimiento de datos de estado a tiempo de ejecución) o en la base de datos de histórica (para el servicio de movimiento de datos de tiempo de ejecución a histórica) e identificar
todos los nombres del programa de utilidad Apply (columna TGT_RM_APP_SVR_NAME).
La consulta: "SELECT OM_NAME, SRC_TAB_NAME,
SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State
to Runtime'" puede producir lo siguiente:
En este ejemplo, los cambios realizados en los datos del modelo de magnitudes empresariales STEW_S que se hayan capturado en la base de datos de estado, el programa de utilidad Apply APPLY_4 los aplicará a las tablas de base de la base de datos de tiempo de ejecución.
Cada vez que Apply termina de procesar todos los cambios (confirmados) que haya grabado hasta ese momento el programa Capture, se invocan una o más instancias del componente ETL y del componente Ciclo de vida destino.
Configuración del componente ETL
Los componentes ETL han sido implementados en WebSphere Business Monitor como procedimientos almacenados de base de datos. Estos procedimientos almacenados siempre residen en la base de datos de un servicio de movimiento de datos determinado. Por lo tanto, todos los procedimientos almacenados ETL que están asignados al servicio de movimiento de datos de estado a tiempo de ejecución están ubicados en la base de datos de tiempo de ejecución y los procedimientos almacenados ETL asignados al servicio de movimiento de datos de tiempo de ejecución a histórica residen en la base de datos histórica.
- Identificación de las instancias del componente ETL.
Para procesar los datos que se añaden a las tablas de base asociadas a un
modelo de magnitudes empresariales se establecen varias instancias del componente ETL.
Para determinar qué procedimientos almacenados se han asignado para proporcionar servicios
a un determinado
modelo de magnitudes empresariales:
- Identifique el servicio de movimiento de datos cuya configuración de ETL desea modificar.
- Inspeccionar la tabla de metadatos WBIRMADM.RMMETADATA de la base de datos de tiempo de ejecución (para el servicio de movimiento de datos de estado a tiempo de ejecución) o en la base de datos de histórica (para el servicio de movimiento de datos de tiempo de ejecución a histórica) e identificar
todos los nombres de procedimientos almacenados ETL (columna TGT_RM_SPETL_NAME).
La consulta siguiente:
"SELECT OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME
FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'" puede producir lo siguiente:
En este ejemplo, todos los cambios realizados en los datos del modelo de magnitudes empresariales STEW_S que se hayan capturado en la base de datos de estado y aplicado a las tablas de base de la base de datos de tiempo de ejecución, serán procesados por los procedimientos almacenados denominados
WBIRMADM.WBIRMSP_10 y WBIRMADM.WBIRMSP_14. Los datos procesados satisfactoriamente se almacenarán en las tablas destino (identificadas mediante la columna TGT_TAB_NAME) de la base de datos de tiempo de ejecución.
- Modificación de las configuraciones de las instancias del componente ETL
Las configuraciones de las instancias del componente ETL están almacenadas en la tabla de control WBIRMADM.RMCONTROL.
Las instancias asignadas al servicio de movimiento de datos de estado a tiempo de ejecución guardan su configuración en la base de datos de tiempo de ejecución; todas las demás se guardan en la base de datos histórica. Los procedimientos almacenados recogen los cambios que se efectúan en una configuración en el próximo arranque. Hay tres opciones que pueden configurarse a través de la tabla de control:
- Tiempo mínimo trascurrido entre dos ejecuciones ETL (ETLSCHEDMETHOD, ETL_0_MINUTES)
- Granularidad de las anotaciones cronológicas (LOGLEVEL)
- Duración de las transacciones (COMMITINTERVAL).
Cada fila de esta tabla corresponde a una instancia del componente ETL que a su vez corresponde exactamente a una tabla destino que se necesita llenar. La siguiente configuración de ejemplo muestra el modo en que los cambios en la configuración afectan al comportamiento de las instancias.
- Modificación de la planificación de ETL.
Las instancias del componente ETL se invocan cada vez que una instancia del componente Apply termina de procesar un conjunto de subscripciones. Tras la invocación, una instancia ETL comprueba su planificación e inicia el proceso o bien, devuelve de inmediato el control a la instancia del componente Apply.
Utiliza la información almacenada en la tabla de control WBIRMADM.RMCONTROL para determinar si necesita ejecutarse. En la figura siguiente se muestran las diferencias entre invocación y ejecución: la primera y la tercera vez la instancia del componente ETL se ejecuta de acuerdo con la planificación. La segunda invocación tiene lugar fuera de la planificación, con lo que no provoca ninguna actividad de proceso.
Varios factores determinan la frecuencia con la que se deben ejecutar las instancias del componente ETL en el servicio de movimiento de datos de estado a tiempo de ejecución y el servicio de movimiento de datos de tiempo de ejecución a histórica:
- Disponibilidad: cuándo estarán los datos accesibles en las tablas de destino. La elección de un intervalo más corto provoca que los datos estén disponibles más pronto, pero también aumenta la carga del sistema.
- Volumen de datos: los programas de utilidad de duplicación suministran datos de forma continuada (o según sea la configuración) a las tablas de base, independientemente
de si los procesan o no las instancias del componente ETL. Cuantos más recursos de base de datos se utilicen, mayor será el número de datos que requieren procesarse. El uso de recursos puede reducirse procesando los datos con mayor frecuencia.
- Hora de proceso: ETL tarda menos tiempo en procesar los datos de la base de datos de tiempo de ejecución que los datos de la base de datos histórica. Planifique los horarios de proceso teniendo esto en cuenta. El uso de un intervalo de tiempo corto entre ejecuciones no mejora el rendimiento si una ejecución tarda más tiempo que el intervalo planificado. Por ejemplo, si una instancia del componente ETL tarda 60 segundos en procesarse, un intervalo planificado de 30 segundos se convierte de hecho en un intervalo de al menos 60 segundos puesto que las instancias del componente ETL se ejecutan de modo secuencial.
Actualmente se admiten dos modalidades de planificación:
- Modificación del nivel de anotación cronológica.
Los procedimientos almacenados admiten dos niveles de anotación cronológica: mínimo (0) y máximo (1). Para modificar el valor predeterminado mínimo, cambie el valor de la columna LOGLEVEL de WBIRMADM.CONTROL de los procedimientos almacenados (TGT_RM_SPETL_NAME) que lo precisen. Todas las anotaciones cronológicas se añadirán a WBIRMADM.RMLOG. Los dos procedimientos almacenados de ejemplo,
WBIRMADM.WBIRMSP_10 y WBIRMADM.WBIRMSP_14 llevan a cabo la anotación cronológica mínima:
Puesto que la tabla de anotaciones no se poda automáticamente, es necesario que DBA la supervise regularmente. Mantenga las anotaciones cronológicas en el nivel mínimo a menos que se le indique lo contrario.
- Modificación de las duraciones de las transacciones
Los datos que el procedimiento almacenado procesa correctamente se graban de inmediato en las tablas de destino.
Sin embargo, dependiendo del valor del intervalo de confirmación (columna COMMITINTERVAL de
WBIRMADM.RMCONTROL), las actualizaciones de la tabla destino no se asientan de forma definitiva hasta que no se haya procesado el número de filas especificado o hasta que no queden más filas pendientes de ser procesadas.
Aumentar el valor de COMMITINTERVAL (por ejemplo, a 1500) hace que el procedimiento almacenado procese más datos antes de confirmar los cambios. En la tabla de destino los bloqueos se mantienen más tiempo, lo que puede tener un impacto negativo en otros componentes que intenten tener acceso a la misma tabla en ese momento.
Disminuir la duración (por ejemplo, a 500) reduce el número de filas que deben procesarse antes de que pasen
a estar disponibles en la tabla destino y libera los bloqueos con mayor prontitud.
Configuración del componente Ciclo de vida destino.
Las tablas de trabajo ETL crecen continuamente siempre que las instancias del componente Apply añadan nuevos datos o actualicen los existentes. A una tabla de trabajo de cada base de datos de destino (tiempo de ejecución e histórica) se asigna, mediante la ejecución de un procedimiento almacenado, una instancia del componente
Ciclo de vida. Cada instancia aplica las políticas de retención internas definidas en la tabla de control WBIRMADM.RMPRUNECTRL. Al igual que en las tablas fuente, las políticas de retención del ciclo de vida para las tablas de trabajo de ETL se especifican por cada tabla. Así, una fila de WBIRMADM.RMPRUNECTRL corresponde a una tabla que precisa ser podada.
Resumen de los parámetros de configuración de los servicios de movimiento de datos
En la tabla siguiente se resumen los parámetros que más se utilizan con los componentes de servicios de movimiento de datos. Para obtener más información sobre los parámetros de configuración, consulte la publicación acerca de la duplicación de DB2.
Componente |
Nombre del parámetro |
Valores por omisión |
Valores válidos |
Ubicación del parámetro |
Capture |
autoprune |
Y |
|
|
Capture |
prune_interval (segundos) |
300 |
|
|
Ciclo de vida fuente |
PRUNE_ENABLED |
1 |
0 - Inhabilitada
1 - Habilitada
|
Base de datos de origen de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
Ciclo de vida fuente |
RETENTION_IN_MINUTES |
0 - Estado a Tiempo de ejecución
1440 - Tiempo de ejecución a Histórica
|
0 al
límite de DB2 para BIGINT |
Base de datos de origen de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
Ciclo de vida fuente |
PRUNE_INTERVAL (minutos) |
5 |
0 al
límite de DB2 para BIGINT |
Base de datos de origen de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - Planificación flexible
1 - Planificación de intervalo estricto
Otro - Inhabilita ETL
|
Base de datos de destino servicio de movimiento de datos: WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 - Estado a Tiempo de ejecución
1440 - Tiempo de ejecución a Histórica
|
0 al
límite de DB2 para INTEGER |
Base de datos de destino servicio de movimiento de datos: WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - anot. cronol. normal
1 - anot. cronol. con rastreo
|
Base de datos de destino servicio de movimiento de datos: WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (número de registros) |
1000 |
0 - Inhabilita las confirmaciones hasta el final
1 - Confirma cada registro.
n - Límite de DB2 para BIGINT
|
Base de datos de destino servicio de movimiento de datos: WBIRMADM.RMCONTROL
|
Ciclo de vida destino |
PRUNE_ENABLED |
1 |
0 - Inhabilitada
1 - Habilitada
|
Base de datos de destino de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
Ciclo de vida destino |
RETENTION_IN_MINUTES |
0 |
0 al
límite de DB2 para BIGINT |
Base de datos de destino de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
Ciclo de vida destino |
PRUNE_INTERVAL (minutos) |
1440 |
0 al
límite de DB2 para BIGINT |
Base de datos de destino de servicio de movimiento de datos: WBIRMADM.RMPRUNECTRL
|
Nota: IBM se reserva el derecho a efectuar cambios en las tablas y columnas de las bases de datos abajo indicadas.
Algunas tablas y columnas pueden eliminarse o sufrir modificaciones o adiciones de un release a otro. Al cambiar de release, el cliente será enteramente responsable de la confianza que deposite en el contenido o las estructuras abajo citadas. IBM documentará tales cambios a medida que se produzcan.