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](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs).
+ **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](CHAP_Troubleshooting_Latency_Target.md#CHAP_Troubleshooting_Latency_Target_Sorter) 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](CHAP_Troubleshooting_Latency.md#CHAP_Troubleshooting_Latency_Causes_Replication_Network) 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.Self-Managed.Configuration.SupplementalLogging).
+ 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.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](https://docs.aws.amazon.com/dms/latest/APIReference/API_OracleSettings.html#DMS-Type-OracleSettings-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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.REDOonASM) 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](CHAP_Source.Oracle.md#CHAP_Source.Oracle.ConnectionAttrib).