O comportamento e o planejamento de cada componente de serviços de movimentação de
dados podem ser configurados para atender as diferentes necessidades de um ambiente de
desenvolvimento, de teste e produção. A alteração na configuração de um componente pode ter um impacto direto no comportamento de outros componentes dependentes desse componente.
Em geral, existem duas dependências:
- O componente Capture chama periodicamente o componente Source Life Cycle.
Se o componente Capture não estiver em execução, nenhuma aplicação do Source Life Cycle
será desempenhada. O retardo entre as chamadas do componente do ciclo de vida é configurável.
Na figura acima, o componente Source Life Cycle
é chamado a cada três unidades de tempo, desempenha alguma atividade e, então, retorna
o controle para o componente Capture, que continua o processamento.
- O componente ETL e o componente Target Life Cycle são chamados pelo
componente Apply após os dados terem sido movidos com êxito do banco de dados de origem
para o banco de dados de destino. Os componentes ETL e Target Life Cycle
serão chamados apenas quando o componente Apply estiver em execução.
Como os componentes dependentes precisam operar em planejamentos diferentes aos do componente
do qual eles dependem, uma chamada não resulta necessariamente
em execução. Em vez disso, cada componente dependente verifica seu planejamento
na chamada e retorna o controle ao componente de chamada se ainda não for
o momento de desempenhar qualquer tarefa. No exemplo acima, os componentes ETL e Target Life Cycle poderão ser executados duas vezes apenas se o planejamento para ambos
os componentes restringir suas chamadas a mais de uma vez a cada 5 unidades de tempo.

O componente ETL (e o componente
Target Life Cycle) é chamado e executado em T2 (T3 respectivamente).
A próxima chamada ocorre em aproximadamente T6. Como menos de cinco unidades de tempo
decorreram desde a última execução, o controle é retornado imediatamente ao componente
Apply. Chamadas subseqüentes em aproximadamente T8 (T9 respectivamente)
resultam na execução, pois mais de cinco unidades de tempo decorreram. Cada componente
é implementado por uma ou mais instâncias de componente. É possível configurar
cada uma das instâncias separadamente para permitir um controle mais granular.
Nota: Se
forem feitas alterações, elas terão efeito imediatamente, a menos que indicado de outra forma.
A configuração padrão para os componentes Capture e Apply pode ser
modificada através da alteração das tabelas de controle apropriadas ou da substituição das mesmas
utilizando os parâmetros de linha de comandos nos scripts de início. Você pode configurar os componentes de aplicação ETL e do
ciclo de vida, atualizando uma das tabelas de controle.
Desempenhe as etapas a seguir para customizar os componentes do serviço de movimentação de dados
a fim de atender aos requisitos dos ambientes de desenvolvimento, teste e produção.
Configurando as Instâncias do Componente Capture (Origem)
Uma instância do componente Capture é equivalente a um utilitário de replicação DB2 Capture. Por padrão,
esse utilitário é configurado para capturar alterações continuamente nas tabelas de origem
e registrar as alterações nas tabelas de trabalho internas. Em geral, não é necessário
alterar a configuração padrão para as instâncias do componente Capture.
- Identificando Instâncias do Componente Capture.
Várias instâncias do componente Capture
(ou seja, utilitários DB2 Capture) são utilizadas para capturar os dados
associados a um
modelo de medidas de negócios. Para determinar
quais utilitários Capture foram designados para fornecer serviços para um
modelo de medidas de negócios, você deve:
- Identificar o serviço de movimentação de dados para o qual deseja alterar a
configuração do utilitário Capture.
- Inspecionar a tabela de metadados WBIRMADM.RMMETADATA no banco de dados
de Estado (para o serviço de movimentação de dados de Estado para Tempo de Execução) ou no
banco de dados de Tempo de Execução (para o serviço de movimentação de dados de Tempo de Execução para Histórico) e identificar
todos os nomes de utilitários Capture (coluna SRC_RM_CAP_SVR_NAME).
Exemplo: A
consulta "SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME, SRC_RM_CAP_SVR_NAME FROM
WBIRMADM.RMMETADATA WHERE SERVICE_NAME='Estado para Tempo de Execução' " pode resultar no
seguinte:
No exemplo acima, o utilitário CAPTURE_1 do Capture foi designado
para capturar todas as alterações feitas nas duas tabelas de origem associadas ao modelo de
medidas de negócios STEW_S no banco de dados de Estado.
- Alterando o Intervalo de Remoção da Tabela de Trabalho do Capture.
Os utilitários Capture
removem automaticamente suas tabelas de trabalho a cada 300 segundos (o padrão
para o parâmetro prune_interval) se a remoção automática estiver ativada (parâmetro autoprune
igual a "y"). Cada atividade de remoção resulta automaticamente em uma chamada
de uma instância do componente Source Life Cycle, que é implementada por um acionador
do banco de dados. A alteração do parâmetro do intervalo de remoção para
um utilitário Capture tem um impacto direto na freqüência com que as tabelas de origem são
removidas pelo componente Source Life Cycle. O item a seguir ilustra como a alteração
do intervalo de remoção para o Capture pode afetar a chamada da instância do componente Source Life Cycle.
O aumento
do parâmetro prune_interval da instância do Capture de 2 unidades de tempo (por exemplo, 300
segundos) para três unidades de tempo (por exemplo, 450 segundos) resulta no seguinte:
- As linhas nas tabelas de trabalho do Capture, elegíveis para remoção, permanecem
por mais tempo na tabela de trabalho, aumentando os potenciais requisitos de espaço.
As tabelas de trabalho crescerão mais, mas o carregamento do sistema e o risco
de contingências poderão ser menores.
- As linhas nas tabelas de origem, que podem ser removidas com base na política
de retenção do ciclo de vida, permanecem por mais tempo na tabela de origem do que o esperado.
Em geral, se o parâmetro prune_interval do Capture estiver configurado para um valor
maior do que o parâmetro prune_interval para o componente do ciclo de vida, a configuração
do parâmetro do Capture terá prioridade. Se um utilitário Capture não estiver
em execução ou se seu recurso de remoção automática estiver desativado, nenhuma execução forçada do ciclo de vida de origem será desempenhada.
Configurando o Componente Source Life Cycle
Várias instâncias do componente do ciclo de vida estão sendo utilizadas em cada
banco de dados de origem (banco de dados de Estado e Tempo de Execução). Cada instância, que é implementada por um acionador, executa as políticas de retenção conforme definido na tabela de controle WBIRMADM.RMPRUNECTRL localizada no banco de dados de origem para esse serviço de movimentação de dados. As políticas de retenção do ciclo de vida
são especificadas em uma base por tabela. Assim, uma linha em WBIRMADM.RMPRUNECTRL
corresponde a uma tabela que requer remoção.
- Identificando Instâncias do Componente Target Life Cycle.
Para determinar
quais acionadores foram designados para aplicar as políticas de retenção para um determinado
modelo de medidas de negócios, você deve:
- Identificar o serviço de movimentação de dados para o qual deseja modificar a
configuração de ETL.
- Inspecionar a tabela WBIRMADM.RMMETADATA no banco de dados de Estado (para o serviço
de movimentação de dados de Estado para Tempo de Execução) ou no banco de dados de Tempo de Execução (para o serviço de movimentação
de dados de Tempo de Execução para Histórico) e procurar os nomes de acionadores associados
na coluna SRC_RM_PRUNE_TRG_NAME.
Exemplo: A consulta "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='Estado para Tempo de Execução'" pode resultar no seguinte:
Neste
exemplo, dois acionadores (WBIRMADM.MCPruneTrig_8 e WBIRMADM.MCPruneTrig_9)
estão aplicando a política de retenção do ciclo de vida para as tabelas de origem
modelo de medidas de negócios STEW_S
no banco de dados de Estado. Como as políticas de retenção são definidas
pela tabela e não pelos nomes de instâncias do componente do ciclo de vida, mantenha o controle
da coluna SRC_TAB_NAME ao planejar a alteração do comportamento de aplicação do ciclo de vida.
- Modificando Configurações da Instância do Componente Source Life Cycle.
- Ativando e Desativando Instâncias do Componente do Ciclo de Vida:
A remoção pode
afetar muito o desempenho de seu sistema. Quando a remoção estiver ativada, ela reduzirá
a quantidade de informações com que servidores de transação (Estado) e servidores
de relatórios (Tempo de Execução) devem lidar. Também incluirá um pequeno carregamento adicional nessas
mesmas tabelas durante cada chamada, de acordo com os parâmetros do componente
Life Cycle. Quando a remoção estiver desativada, as tabelas de origem crescerão ao longo
do tempo, o que também pode causar degradação do desempenho.
Por
padrão, as tabelas de origem são automaticamente removidas de acordo com a política de retenção do ciclo de vida. Para
desativar a remoção temporariamente, modifique as entradas WBIRMADM.RMPRUNECTRL
correspondentes: configure a coluna PRUNE_ENABLED como 1 para ativar a remoção
ou qualquer outro valor numérico (preferivelmente zero) para desativá-la.
As linhas serão
removidas da tabela de origem wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI, mas nenhuma
linha será removida da tabela wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE se a configuração
a seguir for utilizada. A consulta: "SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL"
pode resultar no seguinte:
- Alterando a política de retenção:
As políticas de tempo de retenção podem ser alteradas
para as tabelas de origem localizadas apenas no banco de dados de Tempo de Execução. Para todas as tabelas localizadas
no banco de dados de Estado, um período de retenção de 0 será aplicado, independentemente das configurações
em WBIRMADM.RMPRUNECTRL. Um período de retenção será definido como o
tempo mínimo em que uma linha deve ser retida em uma tabela de origem até que ela
possa ser removida, se atender dois critérios. Dos dois critérios, apenas um é customizável
através da tabela de controle: o tempo de retenção especificado em minutos.
Qualquer linha
que tenha sido marcada como pronta para exclusão e que permaneceu na tabela
de origem por pelo menos RETENTION_IN_MINUTES torna-se elegível para remoção.
Utilizando
a configuração padrão para as tabelas de origem no banco de dados de Tempo de Execução, as
linhas que foram marcadas como prontas para exclusão pelo servidor precisarão ser mantidas
por um dia (1440 minutos) antes de serem removidas. A consulta: "SELECT
TABLE_NAME, RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL" pode resultar no
seguinte:
As alterações
nas entradas da tabela de controle WBIRMADM.RMPRUNECTRL serão recuperadas sempre que
o componente Source Life Cycle for chamado.
- Planejando a remoção de dados de origem:
Existe uma dependência entre o intervalo
de remoção da tabela de trabalho do Capture e a chamada do componente Source Life Cycle.
Uma chamada não resultará em execução se não tiver decorrido tempo suficiente
entre as chamadas da instância do componente Source Life Cycle, conforme mostrado
na figura a seguir.
Supondo que
o componente Source Life Cycle esteja planejado para executar a cada 4 unidades de tempo,
mas o componente Capture estiver configurado para remover suas tabelas de trabalho a cada 2 unidades
de tempo, a chamada no tempo T4 não resultará em execução.
Para alterar
o planejamento padrão, localize as entradas apropriadas em WBIRMADM.RMPRUNECTRL
e altere o valor da coluna para PRUNE_INTERVAL, que representa o retardo mínimo
em minutos entre as execuções.
O aumento do valor resulta em execuções
menos freqüentes (mas o número de chamadas permanece o mesmo). Cada execução
determina quais linhas da tabela de origem são elegíveis para remoção e as remove.
Monitore regularmente seus bancos de dados de origem para identificar e eliminar possíveis
problemas de desempenho que são resultado de bloqueios, resultantes dessas exclusões.
Configurando o Componente APPLY (Destino)
Uma instância de um componente Apply é um utilitário de replicação DB2 Apply. As alterações
que foram capturadas pelos utilitários Capture são aplicadas continuamente às tabelas
de migração de dados no banco de dados de destino, por padrão. Os parâmetros de configuração
do utilitário padrão devem ser suficientes para a maioria dos ambientes e não devem ser alterados.
- Identificando Instâncias do Componente Apply.
Várias instâncias do componente
Apply (utilitários DB2 Apply)
são utilizadas para aplicar alterações de dados às tabelas de migração de dados internas associadas
a um
modelo de medidas de negócios. Para determinar
qual utilitário Apply foi designado para fornecer serviços para um
modelo de medidas de negócios:
- Identifique o serviço de movimentação de dados para o qual deseja alterar a
configuração do utilitário Apply
- Inspecione a tabela de metadados WBIRMADM.RMMETADATA no banco de dados
de Tempo de Execução (para o serviço de movimentação de dados de Estado para Tempo de Execução) ou no
banco de dados de Histórico (para o serviço de movimentação de dados de Tempo de Execução para Histórico) e identifique
todos os nomes de utilitários Apply (coluna TGT_RM_APP_SVR_NAME). A consulta: "SELECT OM_NAME, SRC_TAB_NAME,
SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='Estado
para Tempo de Execução'" pode resultar no seguinte:
Neste exemplo, quaisquer alterações de dados no modelo de medidas de negócios STEW_S que foram capturadas
no banco de dados de Estado serão aplicadas às tabelas de migração de dados no banco de dados de
Tempo de Execução pelo utilitário Apply APPLY_4.
Cada vez que o componente Apply conclui o processamento de todas as alterações (confirmadas)
que tenham sido registradas pelo utilitário Capture, uma ou mais instâncias do componente ETL
e instâncias do componente Target Life Cycle são chamadas.
Configurando o Componente ETL
Os componentes ETL foram implementados no WebSphere Business Monitor como
procedimentos armazenados do banco de dados. Esses procedimentos armazenados sempre residem no banco de dados de destino para um determinado serviço de movimentação de dados. Portanto, todos os procedimentos armazenados ETL
designados ao serviço de movimentação de dados de Estado para Tempo de Execução estão localizados
no banco de dados de Tempo de Execução e os procedimentos armazenados ETL designados ao
serviço de movimentação de dados de Tempo de Execução para Histórico residem no
banco de dados de Histórico.
- Identificando Instâncias do Componente ETL.
Várias instâncias do
componente ETL são configuradas para processar os dados incluídos nas tabelas de migração
de dados internas associadas a um
modelo de medidas de negócios.
Para determinar qual procedimento armazenado foi designado para fornecer serviços
para um determinado
modelo de medidas de negócios:
- Identifique o serviço de movimentação de dados para o qual deseja modificar a configuração de ETL.
- Inspecione a tabela de metadados WBIRMADM.RMMETADATA no banco de dados
de Tempo de Execução (para o serviço de movimentação de dados de Estado para Tempo de Execução) ou no
banco de dados de Histórico (para o serviço de movimentação de dados de Tempo de Execução para Histórico) e identifique
todos os nomes de procedimentos armazenados ETL (coluna TGT_RM_SPETL_NAME). A seguinte consulta:
"SELECT OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME
FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='Estado para Tempo de Execução'" pode resultar
no seguinte:
Neste exemplo, quaisquer alterações de dados no modelo de medidas de negócios STEW_S
que foram capturadas no banco de dados de Estado e aplicadas às tabelas de migração de dados
no banco de dados de Tempo de Execução serão processadas por procedimentos armazenados nomeados WBIRMADM.WBIRMSP_10
e WBIRMADM.WBIRMSP_14. Os dados processados com êxito serão armazenados nas tabelas de
destino (identificadas pela coluna TGT_TAB_NAME) no banco de dados de Tempo de Execução.
- Modificando Configurações da Instância do Componente ETL.
As configurações da instância do componente ETL são armazenadas na tabela de controle WBIRMADM.RMCONTROL.
As instâncias que foram designadas ao serviço de movimentação de dados de Estado para Tempo de Execução
mantêm sua configuração no banco de dados de Tempo de Execução; todas as outras, no
banco de dados de Histórico. Quaisquer alterações feitas em uma configuração serão adotadas
pelos procedimentos armazenados na próxima inicialização. Três opções podem ser configuradas
através da tabela de controle:
- Tempo mínimo decorrido entre duas execuções ETL (ETLSCHEDMETHOD, ETL_0_MINUTES)
- Granularidade da saída de registro (LOGLEVEL)
- Durações da transação (COMMITINTERVAL)
Cada linha nesta tabela corresponde a uma instância do componente ETL,
que corresponde a exatamente uma tabela de destino que precisa ser ocupada. O exemplo
de configuração a seguir ilustra como as alterações na configuração afetam
o comportamento das instâncias.
- Alterando o Planejamento do ETL.
As instâncias do componente ETL
são chamadas cada vez que uma instância do componente Apply conclui o processamento
de um conjunto de assinaturas. Na chamada, uma instância ETL verifica seu planejamento e
inicia o processamento ou retorna o controle imediatamente à instância do componente Apply.
Ela utiliza as informações armazenadas na tabela de controle WBIRMADM.RMCONTROL para
determinar se precisa ser executada. A figura a seguir mostra as diferenças
entre chamada e execução: a primeira e a terceira vezes que a instância do componente
ETL está sendo executada, de acordo com o planejamento. A segunda chamada ocorreu
fora do planejamento e não resulta em nenhuma atividade de processamento.
Vários
fatores determinam quantas vezes as instâncias do componente ETL devem ser executadas
no serviço de movimentação de dados de Estado para Tempo de Execução e no serviço de
movimentação de dados de Tempo de Execução para Histórico:
- Disponibilidade: quando os dados devem estar acessíveis nas tabelas de destino.
A escolha de um intervalo baixo causa a disponibilidade adiantada dos dados, mas
também aumenta o carregamento do sistema.
- Volume de dados: os utilitários de replicação alimentam continuamente (ou como
configurados) os dados nas tabelas de migração de dados, independentemente se são
processados pelas instâncias do componente ETL. Quanto mais recursos do banco
de dados são utilizados, mais dados precisam ser processados. Os
dados do processamento podem reduzir com mais freqüência a utilização máxima
do recurso.
- Tempo de processamento: o processamento de ETL utiliza menos tempo para dados
no banco de dados do Tempo de Execução do que o processamento de dados no banco de
dados de Histórico. Programe os planejamentos de acordo. A utilização de um pequeno
retardo entre execuções não melhorará o desempenho se uma execução dura mais do
que o retardo planejado. Por exemplo, se uma instância do componente ETL demora
60 segundos para concluir o processamento, um intervalo de planejamento de 30
segundos torna-se efetivamente um intervalo de planejamento de pelo menos 60
segundos porque as instâncias do componente ETL são executadas de forma seqüencial.
Atualmente dois modos de planejamento são suportados:
- Alterando o Nível de Registro.
Dois níveis de registro são suportados
pelos procedimentos armazenados: mínimo (0) e máximo (1). Para modificar a
configuração padrão de mínimo, altere o valor da coluna LOGLEVEL em WBIRMADM.CONTROL
para os procedimentos armazenados (TGT_RM_SPETL_NAME), cujo nível de registro precisa
ser alterado. Todas as saídas de registro são anexadas ao WBIRMADM.RMLOG. Os dois
procedimentos armazenados de exemplo WBIRMADM.WBIRMSP_10 e WBIRMADM.WBIRMSP_14
desempenham o registro mínimo:
Como a tabela de registros não é removida automaticamente, ela
precisa ser monitorada regularmente pelo DBA. Mantenha o registro de saída no mínimo
a menos que instruído de maneira diferente.
- Alterando a Duração das Transações.
Os dados que foram processados
com êxito pelo procedimento armazenado são gravados nas tabelas de destino imediatamente.
Entretanto, dependendo da configuração do intervalo de confirmação (coluna COMMITINTERVAL em
WBIRMADM.RMCONTROL), qualquer atualização à tabela de destino não é permanente até que
o número especificado de linhas tenha sido processado ou até que não haja mais linhas
a serem processadas. O aumento do valor de COMMITINTERVAL (por exemplo, para
1500) forçará o procedimento armazenado a processar mais dados antes de confirmar
qualquer alteração. Os bloqueios na tabela de destino serão mantidos por mais tempo
e podem ter um impacto negativo em outros componentes que estão tentando acessar a
mesma tabela.
Diminuir a duração (por exemplo, para 500) diminui o número de linhas que precisam
ser processadas antes de tornarem-se disponíveis na tabela de destino e libera
bloqueios antecipadamente.
Configurando o Componente Target Life Cycle.
As tabelas de trabalho ETL crescem continuamente enquanto dados novos ou atualizados
são aplicados pelas instâncias do componente Apply. Uma instância do componente Target life Cycle, implementada por um procedimento armazenado, é designada a uma tabela de trabalho
em cada banco de dados de destino (Tempo de Execução e Histórico). Cada instância força a execução das
políticas de retenção internas como definido na tabela de controle WBIRMADM.RMPRUNECTRL. Como nas tabelas de origem, as políticas de retenção do ciclo de vida para tabelas de trabalho ETL são especificadas
em uma base por tabela. Assim, uma linha em WBIRMADM.RMPRUNECTRL corresponde a uma
tabela que requer remoção.
Resumo dos Parâmetros de Configuração dos Serviços de Movimentação de Dados
A tabela a seguir resume os parâmetros mais comumente utilizados, fornecidos
para cada um dos componentes de serviços de movimentação de dados. Para obter informações adicionais sobre parâmetros de configuração, consulte o guia de Replicação do DB2.
Componen-
te |
Nome do Parâmetro |
Valores Padrão |
Valores Válidos |
Local do Parâmetro |
Capture |
autoprune |
Y |
|
|
Capture |
prune_interval (segundos) |
300 |
|
|
Source Life Cycle |
PRUNE_ENABLED |
1 |
0 - Desativado
1 - Ativado
|
BD de Origem do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
Source Life Cycle |
RETENTION_IN_MINUTES |
0 - Estado para Tempo de Execução
1440 - Tempo de Execução para Histórico
|
0 ao limite DB2 para BIGINT |
BD de Origem do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
Source Life Cycle |
PRUNE_INTERVAL (minutos) |
5 |
0 ao limite DB2 para BIGINT |
BD de Origem do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - Planejamento flexível
1 - Planejamento
de intervalo estrito
Outro - Desativa ETL
|
BD de Destino do do serviço de movimentação de dados: WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 - Estado para Tempo de Execução
1440 - Tempo de Execução para Histórico
|
0 ao limite DB2 para INTEGER |
BD de Destino do do serviço de movimentação de dados: WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - Para Registro Normal
1 - Para Registro de Rastreio
|
BD de Destino do do serviço de movimentação de dados: WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (número de registros.) |
1000 |
0 - Desativar confirmações até o final
1 - Confirmar
cada Registro.
n - Limite DB2 para BIGINT
|
BD de Destino do do serviço de movimentação de dados: WBIRMADM.RMCONTROL
|
Target Life Cycle |
PRUNE_ENABLED |
1 |
0 - Desativado
1 - Ativado
|
BD de Destino do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
Target Life Cycle |
RETENTION_IN_MINUTES |
0 |
0 ao limite DB2 para BIGINT |
BD de Destino do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
Target Life Cycle |
PRUNE_INTERVAL (minutos) |
1440 |
0 ao limite DB2 para BIGINT |
BD de Destino do serviço de movimentação de dados: WBIRMADM.RMPRUNECTRL
|
Nota: A IBM reserva o direito de fazer alterações nas tabelas de banco de dados e colunas referenciadas acima.
Como tal, algumas tabelas e colunas podem ser alteradas,
removidas ou incluídas de release para release. Qualquer confiança no conteúdo ou
estrutura referido nas informações de release para release é de total
risco do próprio consumidor. A IBM documentará
essas alterações à medida que ocorrerem.