为何以 Oracle 作为源的 AWS DMS CDC 任务失败，并显示“Sequence doesn't exist”（序列不存在）消息？

简短描述

当您使用 Oracle 数据库作为迁移任务的源时，AWS DMS 会在满负载阶段从表中获取数据。在 CDC 阶段，AWS DMS 会从存档的重做日志中进行读取。然后，AWS DMS 会从源 Oracle 数据库捕获重做日志，并仅将已提交的更改应用到目标数据库。

您可能会看到如下所示的序列日志错误提示：

“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”（03980512：2022-05-23T 12:33:11 [SOURCE_CAPTURE] E：序列为 232488 的存档重做日志不存在，线程 1 [1022318] (oradcdc_thread.c.c:624）

要解决此错误，请执行以下步骤：

1.    对源 Oracle 数据库运行此查询，以检查源数据库上是否存在归档日志序列。例如，此查询检查重做日志序列 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.    对源服务器上存档日志文件的位置运行此命令。此命令检查归档日志是否实际存在：

ls -l * 232488*

3.    检查源 Oracle 数据库上的归档日志目标（log_archive_dest）。

本文中的示例通过两个不同的根本原因调查此错误：

• AWS DMS 正在错误的 DEST_ID 中查找重做日志
• DEL 是 YES 且源 Oracle 上不存在存档日志序列

解决方法

示例 1-AWS DMS 在错误的 DEST_ID 中查找重做日志

该错误显示源 Oracle 数据库上缺少存档的重做日志序列 232488。如果从源 Oracle 数据库中删除日志，可能会发生这种情况。这会导致任务失败。

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.    对源数据库运行以下查询，以查看源数据库中是否存在归档日志序列 232488：

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

输出：

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.    检查 DEL 列。如果此列列出 NO，则归档日志序列存在于源数据库中。如果此列列出 YES，则归档日志不存在，并且可能由于保留期而从源中清除。

在此示例中，输出指示源中存在存档日志序列。然而，AWS DMS 任务依然失败了，并显示序列不存在的错误提示。有关 DEL 为 YES 时的故障排除，请参阅示例 2。

3.    接下来，检查 DEST_ID 列。默认情况下，AWS DMS 会在 DEST_ID 1 上捕获重做日志。在此示例中，您可以在日志中看到以下片段：

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)

因此，AWS DMS 任务失败，因为它在 DEST_ID 1 中查找重做日志，但重做日志文件存在于 DEST_ID 2 中。

4.    要缓解此错误，请在源端点中使用以下额外连接属性（ECA）：

additionalArchivedLogDestId=2

有关 AdditionalArchivedLogdestID 的更多信息，请参阅 Oracle 的源数据类型。

5.    配置 ECA 后，继续执行 AWS DMS 任务。在此示例中，日志显示 AWS DMS 现在可以从 DEST_ID 2 捕获可用的重做日志序列 232488。

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)

示例 2 – DEL 为 YES 且归档日志序列在源 Oracle 上不存在

如之前的步骤 2 中所详述，如果 DEL 为 YES，则可能已从源 Oracle 数据库中清除了归档日志序列。

注意：Oracle 实例会删除存档日志文件以尽可能地减少存档日志所占用的空间。

本地或 Amazon Elastic Compute Cloud（Amazon EC2）的步骤

如果您安排恢复管理器（RMAN）删除 SYSDATE-1 之前的无提示存档日志，则此安排将删除所有超过一天的存档日志文件。要增加此时间，请将此命令修改为 SYSDATE-2，或关闭此计划。

请按照以下步骤查找当前的保留期，然后再增加该时间。

1.    连接到 RMAN。

2.    显示全部：

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

注意：默认的存档日志删除策略值为 NONE。

3.    将删除策略值更改为足以在源本地数据库上保留归档日志的值：

CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE

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

Amazon RDS 的步骤

Amazon RDS 每五分钟删除一次存档日志文件，并将副本保存在 Amazon Simple Storage Solution（Amazon S3）存储桶中。您可以使用此副本进行时间点恢复。    

1.    执行对 Oracle 数据库实例执行常见日志相关任务中的步骤，以提高存档日志文件的保留期。    

2.    验证为归档日志文件定义的保留期：

exec RDSADMIN.RDSADMIN_UTIL.SHOW_CONFIGURATION;

3.    检查在上一个查询中提取的归档日志文件在源数据库服务器上是否可用。

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

注意：在 Amazon RDS 中，已删除的列显示“NO”（否），即使该列已被清除。此信息来自控制文件。

4.    要检查 Amazon RDS 中是否存在重做日志，请运行以下查询：

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

注意：AWS DMS 并不控制档案重做日志的清除。归档重做日志由本地源或 RDS for Oracle 数据库清除。相反，AWS DMS 会在尝试处理下一个 LSN 时确认找不到该日志。

5.    如果可以找到，则会还原源目标中缺少的序列 232488 的归档日志，然后继续执行任务。232488 之后的所有重做日志必须存在于源上，然后才能成功恢复 AWS DMS 任务。

如果无法恢复丢失的归档日志序列，请尝试从满载阶段重新启动任务，然后重新开始迁移。

---

相关信息

将 Oracle 用作 AWS DMS 源时的额外连接属性

将 Oracle 数据库用作 AWS DMS 的源

为 Oracle 数据库实例执行与日志相关的常见任务