Por que minha tarefa do CDC do AWS DMS usando o Oracle como origem falhou com uma mensagem, afirmando que “a sequência não existe”?

Breve descrição

Quando você usa um banco de dados Oracle como fonte para sua tarefa de migração, o AWS DMS obtém os dados da tabela durante a fase de carga total. Durante a fase CDC, o AWS DMS lê os redo logs arquivados. Em seguida, o AWS DMS captura os redo logs do banco de dados Oracle de origem e aplica somente as alterações confirmadas ao banco de dados de destino.

Você pode ver um erro de log de sequência semelhante a este:

"03980512: 2022-05-23T12:33:11 [SOURCE_CAPTURE ]E: Archived Redo log with the sequence 232488 does not exist, thread 1 [1022318] (oradcdc_thread.c:624"

Para solucionar esse erro, siga estas etapas:

1.    Execute esta consulta no banco de dados Oracle de origem para verificar se a sequência de log de arquivamento está presente na origem. Por exemplo, esta consulta verifica a sequência de redo log 232488:

select name, dest_id, thread#,
sequence#, archived, applied, deleted, status, first_time, next_time, 
completion_time  from v$archived_log where sequence# =232488;

2.    Execute este comando no local dos arquivos de log de arquivamento no servidor de origem. Este comando verifica se o log de arquivamento está fisicamente presente:

ls -l * 232488*

3.    Verifique o destino do log de arquivamento (log_archive_dest) no banco de dados Oracle de origem.

Os exemplos neste artigo investigam esse erro com duas causas raiz diferentes:

• O AWS DMS está procurando o redo log no DEST_ID errado
• DEL é SIM e a sequência do log de arquivamento não existe no Oracle de origem

Resolução

Exemplo 1: o AWS DMS está procurando o redo log no DEST_ID errado

O erro mostra que a sequência de redo log arquivada 232488 está ausente no banco de dados Oracle de origem. Isso pode acontecer se o log for excluído do banco de dados Oracle de origem, o que faz com que a tarefa falhe.

01788702: 2022-06-07T17:10:31:206453 [SOURCE_CAPTURE  ]D:  Going to 
prepare the statement 'select supplemental_log_data_min, DATABASE_ROLE, 
SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_ALL from v$database'  
(oracle_endpoint_conn.c:114)

01788702: 2022-06-07T17:10:31:209648 [SOURCE_CAPTURE  ]I:  Database role is 'PHYSICAL STANDBY'  (oracle_endpoint_conn.c:139)

1.    Execute esta consulta no banco de dados de origem para ver se a sequência de log de arquivamento 232488 existe na origem:

select name, dest_id, thread#, sequence#, archived, applied, deleted, 
status, first_time, next_time, completion_time  from v$archived_log 
where sequence# in (232488);

Resultado:

NAME                                             DEST_ID    THREAD#  SEQUENCE# ARC APPLIED   DEL S FIRST_TIM NEXT_TIME COMPLETIO

--------------------------------------------- ---------- ---------- ---------- --- --------- --- - --------- --------- ---------

/orafra/prdsvbo/arc/1_232488_950180179.arc             2          1     232488 YES YES       NO  A 07-JUN-22 07-JUN-22 07-JUN-22

2.    Verifique a coluna DEL. Se essa coluna listar NÃO, a sequência de archivedlog existirá no banco de dados de origem. Se listar SIM, o archivedlog não existe e pode ter sido removido da origem devido ao período de retenção.

Neste exemplo, a saída indica que a sequência do archivelog existe na origem. Mas a tarefa do AWS DMS ainda falha com um erro que diz que a sequência não existe. Para solucionar problemas quando DEL for SIM, consulte o Exemplo 2.

3.    Em seguida, verifique a coluna DEST_ID. Por padrão, o AWS DMS captura os redo logs em DEST_ID 1. Neste exemplo, você vê esse trecho nos logs:

01788702: 2022-06-07T17:10:31:658376 [SOURCE_CAPTURE  ]I:  Used Oracle archived Redo log destination id is '1'  (oracdc_merger.c:639)

01788702: 2022-06-07T17:10:31:658420 [SOURCE_CAPTURE  ]I:  Oracle instance uses more than one archived Redo log destination id. Please configure the correct destination id, if Redo logs of '1' destination cannot be accessed  (oracdc_merger.c:642)

Portanto, a tarefa do AWS DMS falha porque está procurando o redo log em DEST_ID 1, mas o arquivo de redo log está presente em DEST_ID 2.

4.    Para corigir este erro, use este atributo de conexão extra (ECA) no endpoint de origem:

additionalArchivedLogDestId=2

Para obter mais informações sobre additionalArchivedLogDestID, consulte Tipos de dados de origem para Oracle.

5.    Depois de configurar o ECA, retome a tarefa do AWS DMS. Neste exemplo, os logs mostram que o AWS DMS agora pode capturar a sequência de redo log disponível 232488 de DEST_ID 2.

01898667: 2022-06-08T05:45:08:535588 [SOURCE_CAPTURE  ]D:  Going to retrieve archived REDO log with sequence 232488, thread 1  (oradcdc_thread.c:510)

01898667: 2022-06-08T05:45:08:535607 [SOURCE_CAPTURE  ]T:  Use a prepared statement to access v$archived_log, thread 1  (oradcdc_thread.c:587)

01898667: 2022-06-08T05:45:08:598396 [SOURCE_CAPTURE  ]D:  Going to open Redo Log with original name '/orafra/prdsvbo/arc/1_232488_950180179.arc', thread id '1'  (oradcdc_redo.c:492)

01898667: 2022-06-08T05:45:08:599614 [SOURCE_CAPTURE  ]D:  archived Redo log '/orafra/prdsvbo/arc/1_232488_950180179.arc' with sequence 232488 is opened, thread id '1'  (oradcdc_redo.c:747)

Exemplo2: DEL é SIM e a sequência do log de arqarchivelog não existe no Oracle de origem

Conforme detalhado anteriormente na etapa 2, se DEL for SIM, é possível que a sequência do archivelog tenha sido eliminada do banco de dados Oracle de origem.

Observação: As instâncias Oracle deletam os arquivos de log de arquivamento para minimizar o espaço que os logs de arquivamento ocupam.

Etapas para On-premises ou para o Amazon Elastic Compute Cloud (Amazon EC2)

Se você agendou o Recovery Manager (RMAN) para excluir o noprompt archivelog até o horário SYSDATE-1, esse agendamento excluirá todos os arquivos de log de arquivamento com mais de um dia. Para aumentar isso, modifique esse comando para SYSDATE-2 ou desative o agendamento.

Siga estas etapas para encontrar o período de retenção atual e, em seguida, aumentá-lo.

1.    Conecte-se ao RMAN.

2.    Mostrar tudo:

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

Observação: o valor padrão da política de exclusão do Archivelog é NONE.

3.    Altere o valor da política de exclusão para um valor que seja suficiente para reter os archivelogs no banco de dados on-premises de origem:

CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE

  CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;

Etapas para o Amazon RDS

O Amazon RDS exclui os arquivos de log de arquivamento a cada cinco minutos e mantém uma cópia em um bucket do Amazon Simple Storage Solution (Amazon S3). Você pode usar essa cópia para fazer uma restauração point-in-time.    

1.    Aumente a retenção dos arquivos de log de arquivamento usando as etapas em Execução de tarefas comuns relacionadas a logs para instâncias de banco de dados Oracle.    

2.    Verifique o período de retenção definido para os arquivos de log de arquivamento:

exec RDSADMIN.RDSADMIN_UTIL.SHOW_CONFIGURATION;

3.    Verifique se o arquivo de log de arquivamento que você buscou na consulta anterior está fisicamente disponível no servidor de banco de dados de origem.

SQL>select name, archived, deleted, status, sequence# from v$archived_log where sequence# = 232488;

Observação: no Amazon RDS, a coluna excluída mostra NO, mesmo que tenha sido eliminada. Essas informações vêm do arquivo de controle.

4.    Para verificar se o redo log existe no Amazon RDS, execute esta consulta:

select * from table(RDSADMIN.RDS_FILE_UTIL.LISTDIR('ARCHIVELOG_DIR')) where filename='redolog-5924417-1-1013939085.arc' order by mtime desc;

Observação: o AWS DMS não controla a limpeza dos redo logs de arquivamento. Os redo logs de arquivamento são eliminados pelo banco de dados on-premises ou RDS for Oracle de origem. Em vez disso, o AWS DMS confirma que não consegue encontrar o log ao tentar processar o próximo LSN.

5.    Se estiver disponível, restaure o log de arquivamento ausente da sequência 232488 no destino de origem e, em seguida, retome a tarefa. Todos os redo logs seguintes ao 232488 devem estar presentes na origem para que você possa retomar com êxito a tarefa do AWS DMS.

Se você não conseguir restaurar a sequência de log de arquivamento ausente, tente reiniciar a tarefa a partir da fase de carga total e, em seguida, reinicie a migração.

---

Informações relacionadas

Atributos de conexão extras ao usar o Oracle como fonte para o AWS DMS

Usando um banco de dados Oracle como fonte para o AWS DMS

Execução de tarefas comuns relacionadas a logs para instâncias de banco de dados Oracle