Solução de problemas do endpoint do Oracle - AWS Database Migration Service

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solução de problemas do endpoint do Oracle

Esta seção contém cenários de replicação específicos do Oracle.

Leitura da origem pausada

AWS DMS interrompe a leitura de uma fonte Oracle nos cenários a seguir. Esse comportamento é por projeto. É possível investigar as causas disso utilizando o log de tarefas. Procure mensagens semelhantes às seguintes no log de tarefas. Para obter mais informações sobre como trabalhar com o log, consulte o Visualizando e gerenciando registros AWS de tarefas do DMS.

  • Mensagem do SORTER: indica que o DMS está armazenando transações em cache na instância de replicação. Para obter mais informações, consulte Mensagem de SORTER no log de tarefas a seguir.

  • Logs de tarefas de depuração: se o DMS interromper o processo de leitura, a tarefa gravará repetidamente a seguinte mensagem nos logs de tarefas de depuração, sem alterar o campo de contexto ou o timestamp:

    • Binary Reader:

      [SOURCE_CAPTURE ]T: Produce CTI event: context '00000020.f23ec6e5.00000002.000a.00.0000:190805.3477731.16' xid [00000000001e0018] timestamp '2021-07-19 06:57:55' thread 2 (oradcdc_oralog.c:817)
    • Logminer:

      [SOURCE_CAPTURE ]T: Produce INSERT event: object id 1309826 context '000000000F2CECAA010000010005A8F500000275016C0000000000000F2CEC58' xid [000014e06411d996] timestamp '2021-08-12 09:20:32' thread 1 (oracdc_reader.c:2269)
  • AWS DMS registra a seguinte mensagem para cada nova operação de redo ou registro arquivado.

    00007298: 2021-08-13T22:00:34 [SOURCE_CAPTURE ]I: Start processing archived Redo log sequence 14850 thread 2 name XXXXX/XXXXX/ARCHIVELOG/2021_08_14/thread_2_seq_14850.22977.1080547209 (oradcdc_redo.c:754)

    Se a fonte tiver novas operações de redo ou log arquivado e não AWS DMS estiver gravando essas mensagens no log, isso significa que a tarefa não está processando eventos.

Alta geração de redo

Se a tarefa estiver processando redo logs e de arquivamento, mas a latência da origem permanecer alta, tente identificar a taxa de geração de redo log e os padrões de geração. Se você tiver um alto nível de geração de redo log, isso aumentará a latência da origem, pois a tarefa lê todos os redo logs e de arquivamento para buscar as alterações relacionadas às tabelas replicadas.

Para determinar a taxa de geração de refazer, utilize as consultas a seguir.

  • Taxa de geração de refazer por dia:

    select trunc(COMPLETION_TIME,'DD') Day, thread#, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) GB, count(*) Archives_Generated from v$archived_log where completion_time > sysdate- 1 group by trunc(COMPLETION_TIME,'DD'),thread# order by 1;
  • Taxa de geração de refazer por hora:

    Alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select trunc(COMPLETION_TIME,'HH') Hour,thread# , round(sum(BLOCKS*BLOCK_SIZE)/1024/1024) "REDO PER HOUR (MB)", count(*) Archives from v$archived_log where completion_time > sysdate- 1 group by trunc(COMPLETION_TIME,'HH'),thread# order by 1 ;

Para solucionar problemas de latência nesse cenário, verifique o seguinte:

  • Verifique a largura de banda da rede e o desempenho de thread único da replicação para garantir que a rede subjacente seja compatível com a taxa de geração do redo de origem. Para obter informações sobre como a largura de banda da rede pode afetar o desempenho da replicação, consulte o artigo Velocidade e largura de banda da rede anterior.

  • Verifique se você configurou o registro em log suplementar corretamente. Evite registros em log adicionais na origem, como a ativação do registro em log em todas as colunas de uma tabela. Para obter informações sobre a configuração do registro em log suplementar, consulte Configuração de registro em log suplementar.

  • Verifique se está utilizando a API correta para ler os redo logs ou de arquivamento. Você pode usar o Oracle LogMiner ou o AWS DMS Binary Reader. Enquanto LogMiner lê os redo logs on-line e os arquivos de redo log arquivados, o Binary Reader lê e analisa diretamente os arquivos de redo log brutos. Como resultado, o Binary Reader tem desempenho melhor. É recomendável utilizar o Binary Reader se a geração do redo log for superior a 10 GB/hora. Para obter mais informações, consulte Usando Oracle LogMiner ou AWS DMS Binary Reader para CDC.

  • Verifique se você definiu ArchivedLogsOnly como Y. Se essa configuração de endpoint estiver definida, o AWS DMS lerá os redo logs arquivados. Isso aumenta a latência da fonte, pois AWS DMS espera que o redo log on-line seja arquivado antes da leitura. Para obter mais informações, consulte ArchivedLogsOnly.

  • Se a origem do Oracle utilizar o gerenciamento automático de armazenamento (ASM), consulte Armazenando REDO no Oracle ASM ao usar o Oracle como fonte para AWS DMS para obter informações sobre como configurar adequadamente o datastore. Também é possível otimizar ainda mais o desempenho de leitura utilizando o atributo de conexão adicional (ECA) asmUsePLSQLArray. Para obter informações sobre como utilizar o asmUsePLSQLArray, consulte Configurações de endpoint ao usar o Oracle como fonte para AWS DMS.