Código de Resiliência

Definir Procedimentos de Limpeza Automatizados

A definição de procedimentos de limpeza automatizados ajudará com a resiliência do código.

Conforme você desenvolve seu código e executa seus testes, será necessário redefinir seu ambiente repetidamente enquanto estiver corrigindo bugs, melhorando o desempenho e otimizando estratégias de carregamento. A criação de procedimentos de limpeza antecipadamente permitirá que você melhore esses procedimentos à medida que o código se desenvolver, para o ponto em que eles deverão ser flexíveis o suficiente para permitir que você redefina seu ambiente para qualquer estado desejado:

Redefinir tudo, não há dados no sistema de destino
Redefina o ambiente para o estado em que estava antes do último carregamento (isso incluiria variáveis, status ou tabelas de auditoria, etc.)
Redefinir o ambiente para que os dados de um carregamento específico (ou batch_id ou run_id) sejam redefinidos em todo o ambiente sem afetar outros dados

A automatização do processo de limpeza geralmente torna esse processo mais eficiente para ser executado (não é necessário procurar uma lista de tabelas a serem redefinidas ou consultas SQL a serem executadas). A automação também reduz drasticamente o risco de alguém redefinir a parte incorreta do ambiente – principalmente quando a depuração está para ser frustrante e pessoas têm problemas.

Conforme esses procedimentos de limpeza se tornam mais refinados, eles podem ser incluídos nos processos de integração. Há duas maneiras de tirar vantagem das seguintes:

Execute sempre uma limpeza preemptiva antes de carregar os dados. Se você estiver carregando dados que podem ser facilmente identificados (com um id de batch ou uma data específica), isso fornecerá uma maneira fácil de substituir os carregamentos anteriores desse mesmo conjunto de dados que poderiam ter falhado
Use esses procedimentos de limpeza nos workflows, no caso de erro. Não é possível abortar todo o carregamento porque, para um curto período, você perdeu a conexão com o ambiente de origem ou de destino. Digamos que você está carregando centenas de arquivos e executando transformações complexas nesses arquivos. Gostaria de abortar tudo porque, para um segundo de divisão, você teve um problema para acessar apenas um dos arquivos, ou ainda deve concluir tudo, repetir esse arquivo o mais rápido possível, e tomar medidas mais dramáticas se esse arquivo ainda não puder ser carregado? Dependendo da estabilidade do ambiente em que está sendo executado, você pode optar por tentar várias vezes antes de alertar os indivíduos apropriados. Da mesma forma, com base no tipo de paralisação, que você enfrenta em seu ambiente, poderá querer forçar uma pausa antes de tentar novamente.

Considere diferentes tipos de procedimentos de recuperação. Para tarefas simples, muitas vezes é suficiente apenas repetir a operação que falhou sem nenhuma outra limpeza ou redefinição. Mas, como o código evolui e torna-se mais complexo, o tipo de erro encontrado evoluirá também. Depois de resolver os erros de carregamento (a carga em si não funciona), é possível executá-los em erros de negócios (os dados são carregados, mas você está carregando os dados incorretos ou alguns cálculos estão incorretos). Você deve investigar cuidadosamente como deseja tratar esses tipos de correções. Nos estágios anteriores, pode ser válido redefinir tudo quando os erros de negócios forem encontrados. Mas você deseja aumentar mais refinado como evoluído de código, para que possa ser mais confuso em suas correções.

É possível definir loops no Oracle Data Integrator para incluir procedimentos de limpeza e contadores de incrementos que rastreiam o número de tentativas. Para um melhor rastreamento de interrupções, as melhores práticas incluem um registro dos erros encontrados, de forma que as ações apropriadas possam ser tomadas se houver erros mais frequentes: você não quer criar resiliência para o custo de ocultar problemas em crescimento. Você pode usar a abordagem descrita em Recuperar Erros das Etapas com Falha.

Se você souber que uma etapa específica em seus processos é propenso a erros (por exemplo, um sistema remoto que fica off-line regularmente sem um tempo de definição para a paralisação), então você pode aproveitar a capacidade incorporada do Oracle Data Integrator para repetir uma etapa em seus pacotes. Use Repetições Automáticas descreve como definir repetições automatizadas para uma etapa.

Duas coisas a serem consideradas se você usar esta abordagem:

O Oracle Data Integrator não o notificará de que o processo falhou se estiver definido para nova tentativa. Se uma das outras tentativas for bem-sucedida, a etapa será registrada como bem-sucedida nos logs do Oracle Data Integrator (você ainda poderá acompanhar essas tentativas em suas próprias tabelas de auditoria).
Repetições e aguardam o aumento da duração da execução dessa etapa. Lembre-se de que ao revisar o desempenho de seus processos de integração.

Identificar Tendência de Desempenho

O desempenho muitas vezes segui gradualmente ao longo do tempo. É importante monitorar o desempenho e garantir que, para o mesmo volume de dados processados, você ainda obterá o desempenho original.Estabelecer mais tempo para processar mais dados faz sentido. Usar mais tempo para processar a mesma quantidade de dados pode ser um sinal de advertência.

Você vai entender onde os atrasos são e o que causa esses atrasos. Isso pode estar relacionado ao aumento da atividade de rede que reduz a largura de banda disponível, estatísticas desatualizadas nos seus bancos de dados que impactam negativamente a execução do código SQL ou um profundo dos arquivos em um servidor no qual você só está interessado em alguns selecionados.

A melhor prática do Oracle Data Integrator é expurgar os logs (e relatórios de cenário) com a frequência possível para melhorar o desempenho. Isso é muito útil para arquivar os logs ou copiar informações relevantes para o desempenho de forma que você possa pesquisar o desempenho com o passar do tempo.

Conforme você investiga a queda de desempenho, olhe em etapas individuais do Oracle Data Integrator (não interrompa no desempenho geral): essa será a melhor maneira de começar a entender onde os atrasos estão vindos. Verifique também se você tem um processo automatizado para expurgar os logs do Oracle Data Integrator. Na verdade, você pode criar um job do Oracle Data Integrator que executa essas expurgações, incluindo relatórios de cenário. Para obter detalhes, consulte Expurgar Logs com o OdiPurgeLog.

Como o Oracle Data Integrator só oferece a expurgação de relatórios de cenário vinculados às sessões presentes no operador, a expurgação de relatórios de cenário após a limpeza das sessões requer assistência do Oracle Support. Se você esqueceu de expurgar os relatórios de cenário antes de expurgar as sessões, entre em contato com o Suporte Técnico da Oracle. O Oracle pode guiá-lo pelo procedimento apropriado.

Para uma longa execução, é crucial monitorar continuamente o desempenho. A degradação de desempenho muitas vezes é um sinal de advertência de uma degradação do ambiente. Especificamente, a Oracle recomenda controlar os planos de execução usando o SPM (SQL Plan Management). As alterações do plano de execução na produção podem causar falhas, e os carregamentos de tabelas podem causar riscos de alteração nos planos de execução.

Expurgar Logs com o OdiPurgeLog

Se você examinar na gaveta de Utilitários dos Pacotes Oracle Data Integrator, verá uma ferramenta chamada OdiPurgeLog. Você pode usar isso em um cenário criado para expurgar os logs do Oracle Data Integrator e programar esse cenário para ser executado regularmente para garantir que você mantenha o menor número possível de logs.

As práticas recomendadas incluem:

Você sempre deve limpar os relatórios também. Elas são mais difíceis de remover seus próprios do que são enquanto você expurga os logs.
Você pode definir um nível de latência na expurgação: pode usar variáveis para armazenar um horário anterior ou uma data anterior antes da qual tudo deve ser expurgado (você usaria com o parâmetro End Date).
Você só pode optar por expurgar logs de cenário (e relatórios) ou expurgar os dois cenários e carregar logs de planos.

Recuperar Erros de Etapas com Falha

A API getPrevStepLog() geralmente seria usada em um procedimento Oracle Data Integrator. É muito conveniente se uma etapa falhar e você quiser recuperar os erros reportados nessa etapa antes de tentar tomar ações corretivas.

Essa API é chamada com um nome de propriedade que retornará as informações apropriadas. Por exemplo, se você quiser o nome da sessão, o nome da etapa que falhou e a mensagem de erro associada, poderá usar o código a seguir para recuperar o erro do procedimento:

Session:
        <%=odiRef.getInfo("SESS_NAME")%> encountered the following
        error at step: <%=odiRef.getPrevStepLog("STEP_NAME")%>Error Message:
        <%odiRef.getPrevStepLog("MESSAGE")%>

Você encapsula esse snippet em código adicional que armazena essas informações em algum lugar ou envia essas informações para processamento adequado.

Usar Repetições Automáticas

As novas tentativas automáticas economizam tempo, pois o processo completo recebe uma chance de ser concluído versus o cancelamento em decorrência de portas curtas ou temporárias.

Em seu pacote, selecione a etapa para a qual você deseja permitir novas tentativas. Na caixa de propriedades, clique na guia ‘Avançado’. Na área Processamento após falha:

Definir o número de vezes que deseja tentar repetir essa etapa
Defina por quanto tempo você deseja aguardar entre cada repetição

Usar Nomes Exclusivos ou Dinâmicos para Sessões de Cenário

Quando o mesmo cenário é executado várias vezes para carregar diferentes conjuntos de dados, a view Operador Oracle Data Integrator não é muito útil se todas mostrar for uma lista de muitas instâncias desse mesmo cenário em execução, talvez com erro ocasional.

Uma forma elegante ao redor dessa chamada ao cenário é tirar proveito do parâmetro Nome da Sessão (SESS_NAME). Se o mesmo cenário estiver executando muitas vezes, provavelmente você já tem um parâmetro informando esse cenário quais dados ele tem para processar (fatia de dados específica, load_id, data etc.). Você pode usar essa variável para criar um nome exclusivo para cada execução do cenário. Definindo o nome da sessão na chamada do cenário, as sessões adicionais de um pacote resultam em logs muito mais legíveis no operador Oracle Data Integrator. Isso facilitará a compreensão de qual conjunto de dados está problemático quando houver falha.

Usar Ferramentas Baseadas em Eventos

O Oracle Data Integrator oferece várias ferramentas que podem ser usadas em pacotes para aguardar que novos dados estejam disponíveis.

Todas essas ferramentas permitem que você defina sua taxa de sondagem, bem como um período de timeout:

OdiFileWait aguarda que o arquivo esteja disponível em um diretório (lembre-se de que o agente Oracle Data Integrator terá de ver esse diretório!).
OdiWaitForData aguarda que os novos dados estejam disponíveis em uma tabela com base em uma consulta fornecida.
OdiWaitForTable aguarda a criação de uma tabela no banco de dados.

Configurar o Timeout de Cache de Blueprint do Agente

Com o Oracle Data Integrator 12c, a eficiência do agente foi melhorada armazenando em cache a definição dos cenários que são executados. Você pode controlar por quanto tempo os cenários são armazenados em cache na definição do agente físico na Topologia do Oracle Data Integrator.

O armazenamento no cache do cenário no agente é útil para jobs em tempo real, de forma que o agente não precise obter as informações no repositório para cada execução. A devolução é que uma implantação de uma nova versão de um cenário não é selecionada imediatamente. O tempo limite padrão até uma nova versão de um cenário armazenado em cache ser selecionada é 600 segundos (10 minutos) e 100 entradas são armazenadas em cache por padrão.

Você pode gerenciar esses valores. Na definição Agente, na guia Definição, use a seção Gerenciamento de Cache de Blueprint da Sessão para definir Máximo de entradas de cache e Vida Útil de Blueprint Não Utilizada (Seg).