為什麼使用 Oracle 作為來源的 AWS DMS CDC 任務失敗並顯示「序列不存在」訊息？

簡短描述

使用 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-23T12:33:11 [SOURCE_CAPTURE ]E：序號為 232488 的已封存重做日誌不存在，執行緒 1 [1022318] (oradcdc_thread.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) 的步驟

如果您排程 Recovery Manager (RMAN) 刪除 noprompt 封存日誌直至時間 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 資料庫執行個體執行常見日誌相關任務