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”?
Quero migrar dados do meu banco de dados local ou do Amazon Relational Database Service (Amazon RDS) para Oracle usando o AWS Database Migration Service (AWS DMS). A tarefa de captura de dados de alteração (CDC) do AWS DMS é executada conforme o esperado, mas falha com um erro semelhante a este: "Oracle CDC maximum retry counter exceeded" (archivelog sequence does not exist)" Como posso solucionar e resolver esse erro?
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
Conteúdo relevante
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos
- AWS OFICIALAtualizada há 2 anos