Design de Resiliência

Design para Capacidade de Reinicialização

Alguns processos de integração podem ser muito complexos e têm dependências com outros processos. Eles podem entrar em um número de estágios antes que os dados sejam carregados no sistema de destino final. Para ajudar na reinicialização a considerar a adição de uma coluna adicional às tabelas intermediárias para rastrear e identificar a carga atual (load_id ou load_date, ou qualquer coisa que identifique exclusivamente esta carga). Isso permitirá melhor rastreamento e tornará seus procedimentos de limpeza mais fáceis de projetar.

O que significa o Oracle Data Integrator?

Use variáveis para controlar o identificador do processo que está sendo carregado e, se possível, adicione esses valores aos estágios de dados intermediários (colunas adicionais em suas tabelas intermediárias).
Use essas variáveis para definir um nome de sessão diferente (SESS_NAME) para cada execução de cenário: isso permitirá que os operadores identifiquem imediatamente os processos que não são exatamente onde serão pesquisados. Consulte Usar Nomes Exclusivos ou Dinâmicos para Sessões de Cenário.
Tirar o exemplo anterior onde o mesmo processo é usado para carregar centenas de arquivos, é mais prático ter um job com nome após o arquivo que está sendo processado, o que tem o mesmo nome de job genérico para todos os arquivos.

Projetar para Limitar Impactos de Paralisação

A execução de extrações em massa em horários predefinidos tem um grande impacto em toda a sua infraestrutura.

Por exemplo:

O sistema de origem é afetado, pois ele deve atender à solicitação.
A rede é impactada porque a largura de banda é inundada com o serviço da solicitação.
Os jobs de integração geral demoram mais para serem executados em decorrência do volume mais baixo de dados que tem de ser processado.
Um pequeno blip ou paralisação da sua rede no momento da integração tem um grande impacto na sua tarefa de integração.

Os jobs de integração não precisam ser lote ou em tempo real. Muitas vezes, elas podem ser ambas. Se o carregamento final tiver de ser uma operação em lote (porque os dados são consolidados ou agregados para instância), a extração e alguns processos de pré-integração poderão ser executados de maneira mais em tempo real. Isso reduz a carga na infraestrutura geral e limita o impacto que você deve ter uma paralisação ao tentar acessar o sistema de origem no momento da integração. Se os dados foram extraídos e preparados de forma de stream, você não precisa acessar o sistema de origem quando ele for o horário para a integração final.

O Oracle Data Integrator fornece várias ferramentas que podem ser usadas na construção de pacotes para detectar que novos dados estão disponíveis. Consulte Usar Ferramentas Baseadas em Eventos para obter uma lista.

Para integração com a replicação em tempo real verdadeira, o Oracle Data Integrator pode criar uma infraestrutura que permitirá o consumo de alterações, aproveitando as APIs mencionadas acima.

Escolher Entre Inserir e Mesclar Dados

Existem negociações entre uma abordagem INSERT e MERGE com o carregamento de dados. Além da estratégia de integração, talvez você queira considerar o que acontece quando um carregamento falhar parcialmente.

Dependendo de como você está carregando os dados em seu sistema de destino, diferenciando o que foi corretamente carregado em relação ao que falhou ou identificar os elementos de um carregamento parcial pode ser bem complexo. Mesmo que, de uma perspectiva de projeto, todos os que você está fazendo esteja acrescentando dados no sistema de destino, ela pode ser útil em uma perspectiva de capacidade de recuperação para considerar os benefícios de mesclar os dados recebidos com os dados que já estão no sistema de destino.

Se estiver escolhendo essa abordagem, você precisará verificar o impacto que essa estratégia tem no desempenho dos carregamentos. Mas lembre-se de que uma carga INSERT totalmente otimizada não é mais rápida do que um MERGE menos eficiente com sucesso.

De uma perspectiva do Oracle Data Integrator, alterar de uma estratégia INSERT para uma estratégia MERGE é uma operação muito simples: você só precisa alterar sua estratégia de integração e selecionar o Módulo de Conhecimento apropriado. Isso disse, alterar os módulos de conhecimento para um grande número de mapeamentos pode ser uma tarefa uniforme. Você pode automatizar essa tarefa usando o Oracle Data Integrator SDK.

Projetar para Limitar Paralisações Planejadas do Sistema

As interrupções planejadas geralmente são necessárias para aplicação de patches e upgrades.

Em um ambiente de nuvem em que patches e atualizações são maiores e mais fáceis da perspectiva do usuário final, a última coisa que queremos ser forçada em uma paralisação, pois estamos aplicando patches no código dos processos de integração. Isso significa que a aplicação de patches deve fazer parte da estratégia de desenvolvimento avançando para garantir que as paralisações sejam mantidas no mínimo.

A unidade de execução para o Oracle Data Integrator é um cenário. Quando um cenário é gerado, ele é associado a um número de versão (começando com 001). Os cenários podem ser gerados novamente (para substituir a versão atual), ou uma nova versão pode ser gerada (002, 003, etc.).

Ao chamar um cenário, a Oracle recomenda que você sempre especifique o número de versão -1. Isso terá dois benefícios:

O Oracle Data Integrator sempre usará a versão mais recente do cenário. Você não precisará alterar como chamar esses cenários ao gerar novas versões;
Logo após a criação de uma nova versão do cenário, esta é a versão que é executada pelo Oracle Data Integrator. Configurar o Timeout de Cache de Blueprint do Agente descreve como controlar possíveis atrasos. Você não precisa interromper e reiniciar o Oracle Data Integrator ou qualquer ferramenta de orquestração externa que estiver usando, para que o Oracle Data Integrator use a versão mais recente dos cenários de integração.

Observação: essa abordagem só será possível se você não tiver loops infinitos no Oracle Data Integrator. Os loops infinitos nunca são recomendados no Oracle Data Integrator (na verdade, eles estão qualificados como um antipadrão):

Os logs do Oracle Data Integrator são clog: expurgações de log nunca causarão impacto em um job em execução. Um loop infinito está sempre em execução, pois os logs correspondentes não podem ser expurgados.
Eles impedem a aplicação de patches ao vivo dos cenários: no ODI para selecionar a nova versão de um cenário, é necessário ter uma oportunidade de iniciar esse cenário. Um loop infinito nunca termina... e, portanto, nunca tem a chance de ser reiniciado.
Em vez de ter um loop infinito, você pode finalizar seu cenário chamando esse mesmo cenário de forma assíncrona: a última etapa do cenário antes de terminar é iniciar uma nova cópia em uma nova sessão.