疑難排解移轉工作 AWS Database Migration Service - AWS 資料庫遷移服務
遷移任務執行緩慢任務狀態列不會移動任務完成但未遷移任何項目遺失外部索引鍵和次要索引AWS DMS 不會建立 CloudWatch 記錄連接到 Amazon 時出現問題 RDS發生網路問題CDC滿載後卡住重新開始任務時發生主索引鍵違規錯誤結構描述初始載入失敗任務失敗，出現不明錯誤任務從頭開始載入資料表每個任務導致問題的資料表數當在LOB列上創建主鍵時，任務失敗沒有主索引鍵之目標資料表上發生的重複記錄來源端點落在預留 IP 範圍內Amazon Athena 查詢中的時間戳記出現亂碼使用 Oracle 來疑難排解問題「我的」的疑難排解 SQL疑難排解問題 SQL疑難排解 Microsoft SQL 伺服器問題針對 Amazon Redshift 的問題進行疑難排解Amazon Aurora 我的疑難排解問題 SQL 疑難排解問題 SAP ASEIBMDb2 的疑難排解問題

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

疑難排解移轉工作 AWS Database Migration Service

接下來，您可以找到有關 AWS Database Migration Service (AWS DMS) 疑難排解問題的主題。這些主題可協助您解決使用 AWS DMS 和選取的端點資料庫的常見問題。

如果您已開啟 Sup AWS port 案例，您的支援工程師可能會識別其中一個端點資料庫設定的潛在問題。工程師也可能會要求您執行支援指令碼，以傳回資料庫的相關診斷資訊。如需透過此類支援指令碼下載、執行和上傳診斷資訊的詳細資訊，請參閱使用中的診斷支援指令碼 AWS DMS。

為了進行疑難排解，請在複寫執行個體中 AWS DMS 收集追蹤和傾印檔案。如果發生需要疑難排解的問題，您可以將這些檔案提供給 Sup AWS port。依預設，會DMS清除超過三十天的追蹤和傾印檔案。若要選擇退出追蹤和傾印檔案收集，請使用 Sup AWS port 開啟案例。

主題

遷移任務執行緩慢

有多種問題可能導致遷移任務執行緩慢，或導致後續任務的執行速度比初始任務較慢。

移轉工作執行緩慢的最常見原因是配置給 AWS DMS 複製執行個體的資源不足。若要確保執行個體擁有足夠的資源來執行您正在執行的工作，請檢查複寫執行個體的使用情況CPU、記憶體、交換檔案和IOPS。例如，使用 Amazon Redshift 作為端點的多任務會耗用大量 I/O。您可以增加IOPS複寫執行個體，或將工作分割到多個複寫執行個體，以提高移轉效率。

如需如何決定複寫執行個體大小的詳細資訊，請參閱選取複寫執行個體的最佳大小。

您可以執行下列操作來加快初始遷移載入的速度：

  • 如果您的目標是 Amazon RDS 資料庫執行個體，請確定目標資料庫執行個體未啟用異地同步備份。

  • 在載入期間關閉自動備份或登入目標資料庫，遷移完成後再重新開啟這些功能。

  • 如果目標上有此功能可用，請使用已佈建IOPS。

  • 如果您的移轉資料包含LOBs，請確定工作已針對LOB移轉進行最佳化。如需最佳化的詳細資訊LOBs，請參閱目標中繼資料任務設定。

任務狀態列不會移動

任務狀態列會顯示任務進度的估計。此估計的品質取決於來源資料庫資料表統計資料的品質；資料表統計資料越佳，估計越準確。

對於只有一個沒有預估資料列統計資料的資料表的工作， AWS DMS 無法提供任何類型的完成百分比估計值。在這種情況下，使用任務狀態和所指出已載入的資料列，來確認任務正在執行中並有所進展。

任務完成但未遷移任何項目

如果任務完成後未遷移任何項目，請執行下列動作。

  • 檢查建立端點的使用者是否具有您要遷移之資料表的讀取存取權。

  • 檢查您要遷移的物件是否為資料表。如果是檢視，請更新資料表對應並將物件定位器指定為「檢視」或「全部」。如需詳細資訊，請參閱 從主控台指定資料表選取及轉換。

遺失外部索引鍵和次要索引

AWS DMS 創建表，主鍵，並在某些情況下唯一索引，但它不會創建任何其他不需要有效地從源遷移數據的對象。例如，它不會建立輔助索引、非主索引鍵限制條件，或是資料預設。

若要從您的資料庫遷移次要物件，請使用資料庫的原生工具 (如果您將遷移至與來源資料庫相同的資料庫引擎)。如果您要遷移至與來源資料庫用來遷移次要物件之不同資料庫引擎，請使用 AWS Schema Conversion Tool (AWS SCT)。

AWS DMS 不會建立 CloudWatch 記錄

如果您的複寫任務未建立 CloudWatch 記錄檔，請確定您的帳戶具有該dms-cloudwatch-logs-role角色。如果此角色不存在，請執行下列動作來建立此角色：

  1. 登入 AWS Management Console 並開啟IAM主控台，位於https://console.aws.amazon.com/iam/。

  2. 選擇角色索引標籤。選擇建立角色。

  3. 在選取信任的實體類型區段中，選擇 AWS 服務。

  4. 在 [選擇使用案例] 區段中，選擇DMS。

  5. 選擇下一步：許可。

  6. AmazonDMSCloudWatchLogsRole在搜尋欄位中輸入，然後勾選 A 旁邊的方塊mazonDMSCloudWatchLogsRole。這會授予存取 AWS DMS 權限 CloudWatch。

  7. 選擇下一步：標籤。

  8. 選擇下一步：檢閱。

  9. 在角色名稱中輸入 dms-cloudwatch-logs-role。此名稱會區分大小寫。

  10. 選擇建立角色。

連接到 Amazon 時出現問題 RDS

無法連接到設定為來源或目標的 Amazon RDS 資料庫執行個體可能有多種原因。一些要檢查的項目如下：

  • 檢查使用者名稱和密碼的組合是否正確。

  • 檢查 Amazon RDS 主控台中顯示的執行個體的端點值是否與您用來建立端點的端 AWS DMS 點識別碼相同。

  • 檢查執行個體的 Amazon RDS 主控台中顯示的連接埠值是否與指派給 AWS DMS 端點的連接埠相同。

  • 檢查指派給 Amazon RDS 資料庫執行個體的安全群組是否允許從 AWS DMS 複寫執行個體進行連線。

  • 如果 AWS DMS 複寫執行個體和 Amazon RDS 資料庫執行個體不在同一個虛擬私有雲端 (VPC) 中，請檢查資料庫執行個體是否可公開存取。

錯誤訊息：不正確的執行緒連接字串：不正確的執行緒值 0

當您測試端點的連線時，此錯誤可能經常發生。此錯誤表示連接字串中有錯誤。範例是主機 IP 地址之後的空格。另一個是複製到連接字串中的字元錯誤。

發生網路問題

最常見的網路問題涉及 AWS DMS 複寫執行個體所使用的VPC安全性群組。根據預設，此安全群組規則的規則允許在所有連接埠上傳出到 0.0.0.0/0。在許多情況下，您可以修改此安全群組或使用您自己的安全群組。如果是這樣，請至少確保將輸出提供給各自資料庫連接埠上的來源和目標端點。

其他與組態相關的問題可能包括下列各項：

  • 複寫執行個體以及同一個來源和目標端點 VPC — 端點所使用的安全性群組必須允許來自複寫執行個體的資料庫連接埠輸入。確定複寫執行個體所使用的安全群組已輸入這些端點。或者您也可以在端點所使用的安全群組中建立規則，允許存取複寫執行個體的私有 IP 地址。

  • 來源端點位於複寫執行個體所使VPC用的範圍之外 (使用網際網路閘道) — VPC 安全性群組必須包含傳送不適用於網際網路閘道之VPC流量的路由規則。在此組態中，與端點的連線看起來就像是來自複寫執行個體上的公有 IP 地址。

  • 來源端點位於複寫執行個體所使VPC用的範圍之外 (使用NAT閘道) — 您可以使用繫結至單一 elastic network interface 的單一彈性 IP 位址來設定網路位址轉譯 (NAT) 閘道。此NAT閘道會收到一個NAT識別碼 (nat-#####)。

    在某些情況下，VPC包括指向該NAT閘道而不是 Internet 閘道的默認路由。在這種情況下，複寫執行個體會改為使用NAT閘道的公用 IP 位址連絡資料庫端點。在這裡，VPC需要輸入到資料庫端點以外的資料庫端點，以允許從位NAT址而非複寫執行個體的公用 IP 位址輸入。

如需使用您自己的內部部署名稱伺服器的相關資訊，請參閱 使用自己的內部部署名稱伺服器。

CDC滿載後卡住

當多個 AWS DMS 設定互相衝突時，複寫變更可能會在完全載入遷移後將變慢或停滯。

例如，假設目標資料表準備模式參數設定為不執行任何操作或截斷。在這種情況下，您已指示不 AWS DMS 要對目標資料表進行設定，包括建立主索引和唯一索引。如果您尚未在目標資料表上建立主索引鍵或唯一索引鍵，請針對每個更新 AWS DMS 執行完整資料表掃描。這種方式可能會大幅影響效能。

重新開始任務時發生主索引鍵違規錯誤

當資料保留在先前遷移任務的目標資料庫時，可能會出現此錯誤。如果 Target 資料表準備模式選項設定為「不執行任何動作」，則 AWS DMS 不會對目標資料表執行任何準備工作，包括清除先前工作所插入的資料。

為了重新開始任務並避免這些錯誤，請移除在執行先前任務時插入目標資料表中的資料列。

結構描述初始載入失敗

在某些情況下，結構描述的初始載入可能會失敗，並顯示錯誤 Operation:getSchemaListDetails:errType=, status=0, errMessage=, errDetails=。

在這種情況下，用來連線 AWS DMS 到來源端點的使用者帳戶沒有必要的權限。

任務失敗，出現不明錯誤

不明類型的錯誤原因可能有所不同。但是，我們經常發現問題涉及分配給 AWS DMS 複製實例的資源不足。

若要確保您的複寫執行個體有足夠的資源來執行遷移，請檢查執行個體的使用情況CPU、記憶體、交換檔案和IOPS. 如需監控的詳細資訊，請參閱AWS Database Migration Service 指標。

任務從頭開始載入資料表

AWS DMS 當尚未完成表的初始加載時，從頭開始重新啟動表加載。當工作 AWS DMS 重新啟動時，在初始載入未完成時，會從頭重新載入資料表。

每個任務導致問題的資料表數

沒有設定限制，限制每項複寫任務的資料表數量。但就經驗法則來說，我們建議將任務中的資料表數限制為少於 60,000。當單一任務使用 60,000 個以上的資料表時，資源的使用通常會成為瓶頸。

當在LOB列上創建主鍵時，任務失敗

在FULLLOB或LIMITEDLOB模式中， AWS DMS 不支援LOB資料類型的主索引鍵的複寫。

DMS一開始會移轉資料行為 null 的資料LOB列，然後稍後更新資LOB料行。因此，當在LOB列上創建主鍵時，初始插入失敗，因為主鍵不能為空。因應措施是將另一個資料行新增為主索引鍵，並從LOB資料行中移除主索引鍵。

沒有主索引鍵之目標資料表上發生的重複記錄

執行完整載入和CDC工作可以在沒有主索引鍵或唯一索引的目標資料表上建立重複的記錄。若要避免在完整載入和CDC工作期間重複目標資料表上的記錄，請確定目標資料表具有主索引鍵或唯一索引。

來源端點落在預留 IP 範圍內

如果 AWS DMS 來源資料庫使用的 IP 位址位於 192.168.0.0/24 的保留 IP 範圍內，則來源端點連線測試會失敗。下列步驟提供可能的解決方法：

  1. 尋找一個不在保留範圍內的 Amazon EC2 執行個體，該執行個體可以在 192.168.0.0/24 與來源資料庫通訊。

  2. 安裝 socat 代理並執行。下列顯示一個範例。

    yum install socat
                
socat -d -d -lmlocal2 tcp4-listen:database port,bind=0.0.0.0,reuseaddr,fork tcp4:source_database_ip_address:database_port
&

使用 Amazon EC2 執行個體 IP 地址和前面為 AWS DMS 端點指定的資料庫連接埠。請確定端點具有允許 AWS DMS 存取資料庫連接埠的安全性群組。請注意，代理需要在DMS任務執行期間運行。視使用案例而定，您可能需要自動執行代理設定。

Amazon Athena 查詢中的時間戳記出現亂碼

如果時間戳記在 Athena 查詢中出現亂碼，請使用 AWS Management Console 或ModifyEndpoint動作將 Amazon S3 端點的parquetTimestampInMillisecond值設定為。true如需詳細資訊，請參閱 S3Settings。

使用 Oracle 來疑難排解問題

接下來，您可以了解疑難排解 AWS DMS 與 Oracle 資料庫搭配使用的特定問題。

從檢視提取資料

您可以從檢視提取資料；但您無法將其用於進行中複寫。若要能夠從檢視擷取資料，您必須將下列程式碼新增至 Oracle 來源端點頁面的端點設定區段。當您從檢視擷取資料時，檢視會顯示為目標結構描述上的資料表。

"ExposeViews": true

LOBs從甲骨文移轉

AWS DMS 可以使用兩種方法來捕獲對 Oracle 數據庫的更改，即二進制閱讀器和 Oracle LogMiner。依預設， AWS DMS 會使用 Oracle 擷 LogMiner 取變更。但是，在甲骨文 12c 上，甲骨文 LogMiner 不支持LOB列。若要擷取 Oracle 12c 上LOB資料行的變更，請使用二進位讀取器。

在 Oracle LogMiner 和二進制閱讀器之間切換

AWS DMS 可以使用兩種方法來捕獲對來源 Oracle 數據庫，二進制閱讀器和 Oracle 的更改 LogMiner。甲骨文 LogMiner 是默認的。若要切換為使用 Binary Reader 擷取變更，請執行下列操作：

使用 Binary Reader 擷取變更

  1. 登入 AWS Management Console 並在 https://console.aws.amazon.com/dms/v2/ 開啟 AWS DMS 主控台。

  2. 選擇端點。

  3. 選擇您希望使用 Binary Reader 的 Oracle 來源端點。

  4. 選擇 Modify (修改)。

  5. 選擇進階，然後將下列程式碼新增至額外連線屬性。

    
useLogminerReader=N

  6. 使用 Oracle 開發人員工具 (例如 SQL-Plus)，將下列其他權限授與用於連線至 Oracle 端點的使用 AWS DMS 者帳戶。

    
SELECT ON V_$TRANSPORTABLE_PLATFORM

錯誤：甲骨文CDC停止 122301 甲骨文CDC最大重試計數器超過。

當所需的 Oracle 存檔日誌在能夠擷取變更之前，已從伺服器移除所需的 Oracle 存檔 AWS DMS 日誌時，就會發生此錯誤。在您的資料庫伺服器提高日誌保留期政策。對於 Amazon RDS 資料庫，請執行下列程序以增加日誌保留。例如，下列程式碼會將 Amazon RDS 資料庫執行個體的日誌保留時間增加到 24 小時。


exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours',24);

自動將補充記錄新增至 Oracle 來源端點

依預設， AWS DMS 會關閉補充記錄。若要為來源 Oracle 端點自動開啟補充日誌記錄，請執行下列操作：

自動將補充記錄新增至來源 Oracle 端點

  1. 登入 AWS Management Console 並在 https://console.aws.amazon.com/dms/v2/ 開啟 AWS DMS 主控台。

  2. 選擇端點。

  3. 選擇要新增補充記錄的 Oracle 來源端點。

  4. 選擇 Modify (修改)。

  5. 選擇進階，然後將下列程式碼新增至額外連線屬性文字方塊：

    
addSupplementalLogging=Y

  6. 選擇 Modify (修改)。

LOB未擷取變更

目前，資料表必須有主索引鍵 AWS DMS 才能擷取LOB變更。如果包含的表格LOBs沒有主索引鍵，您可以採取數個動作來擷取LOB變更：

  • 將主索引鍵新增至資料表。此動作與新增 ID 資料行並使用觸發將其填入序列一樣簡單。

  • 建立資料表的具體化視觀表，其中包含系統產生的 ID 作為主索引鍵，並遷移具體化視觀表，而非資料表。

  • 建立邏輯備用副本，將主索引鍵新增至資料表，並從邏輯備用副本遷移。

錯誤：ORA-12899：對於資料行而言太大的值 column-name

錯誤「ORA-12899：值對於列來說太大 column-name「通常是由幾個問題引起的。

在其中一個問題中，來源和目標資料庫所使用的字元集不相符。

在另一個問題中，兩個資料庫之間的國家語言支援 (NLS) 設定不同。當來源資料庫 NLS _ _ 參數設定為CHAR且目標資料庫 LENGTH _ _ SEMANTICS 參數設定為時，會造成此錯誤的常見原因BYTE。NLS LENGTH SEMANTICS

NUMBER數據類型被誤解

Oracle 數NUMBER據類型被轉換成各種 AWS DMS 數據類型，這取決於的精度和規模NUMBER。這些轉換記錄在此處：Oracle 的來源資料類型。使用來源 Oracle 端點的端點設定也會影響NUMBER類型的轉換方式。這些端點設定將記錄在 使用 Oracle 作為來源時的端點設定 AWS DMS 中。

記錄在完全載入期間遺失

執行完整載入時，會在資料庫層級 AWS DMS 尋找開啟的交易，並等待交易確認。例如，根據工作設定TransactionConsistencyTimeout=600，即使開啟 AWS DMS 的交易位於未包含在表格對應中的資料表上，仍會等待 10 分鐘。但是，如果開啟的交易位於資料表對應中包含的資料表上，並且交易未及時遞交，就會導致目標資料表結果中的記錄遺失。

如果您知道開啟的交易需要更長的時間才能遞交，則可以修改 TransactionConsistencyTimeout 任務設定並延長等待時間。

另請留意 FailOnTransactionConsistencyBreached 任務設定的預設值為 false。這表示會 AWS DMS 繼續套用其他交易，但未結交易會遺漏。如果您希望任務在開啟的交易未及時關閉時失敗，您可以將 FailOnTransactionConsistencyBreached 設為 true。

資料表錯誤

如果 WHERE 子句未參考主索引鍵資料欄，而且未針對所有資料欄使用補充記錄，則 Table Error 會在複寫期間顯示在資料表統計資料中。

若要修正這個問題，請開啟參照資料表之所有資料欄的補充記錄。如需詳細資訊，請參閱設定補充記錄。

錯誤：無法擷取 Oracle 封存還原日誌目的地識別碼

當您的 Oracle 來源沒有產生任何封存記錄或 V$ ARCHIVED _ LOG 為空時，就會發生此錯誤。您可以手動切換日誌來解決此錯誤。

對於 Amazon RDS 資料庫，請執行下列程序以切換記錄檔。該 switch_logfile 程序沒有參數。

exec rdsadmin.rdsadmin_util.switch_logfile;

對於自我管理的 Oracle 來源資料庫，請使用下列命令強制日誌切換。

ALTER SYSTEM SWITCH LOGFILE ;

評估 Oracle 還原或封存日誌的讀取效能

如果 Oracle 來源發生效能問題，您可以評估 Oracle 還原或封存日誌的讀取效能，以找出改善效能的方法。若要測試重做或存檔日誌讀取效能，請使用AWS DMS 診斷 Amazon 機器映像 (AMI)。

您可以使用 AWS DMS 診斷AMI來執行以下操作：

  • 您可以使用此 bFile 方法來評估重做日誌檔效能。

  • 您可以使用此 LogMiner 方法來評估重做日誌檔效能。

  • 您可以使用 PL/ SQL (dbms_lob.read) 方法來評估重做日誌檔效能。

  • 使用單執行緒來評估上ASMFile的讀取效能。

  • 使用多執行緒來評估上ASMFile的讀取效能。

  • 使用 Direct OS Readfile() Windows 或 Pread64 Linux 函數來評估還原日誌檔案。

然後，您可以根據結果採取補救步驟。

測試 Oracle 還原或封存日誌檔案的讀取效能

  1. 建立 AWS DMS 診斷 AMI Amazon EC2 執行個體並連線至該執行個體。

    如需詳細資訊，請參閱使用 AWS DMS 診斷AMI。

  2. 執行 awsreplperf 命令。

    $ awsreplperf

    此命令會顯示「 AWS DMS Oracle 讀取效能公用程式」選項。

    0.	Quit
1.	Read using Bfile
2.	Read using LogMiner
3.	Read file PL/SQL (dms_lob.read)
4.	Read ASMFile Single Thread
5.	Read ASMFile Multi Thread
6.	Readfile() function

  3. 從清單選取選項。

  4. 輸入下列資料庫連線和封存日誌資訊。

    Oracle user name [system]:
Oracle password:

Oracle connection name [orcllx]:
Connection format hostname:port/instance

Oracle event trace? [N]: 
Default N = No or Y = Yes

Path to redo or archive log file []:

  5. 檢查顯示的輸出是否有相關的讀取效能資訊。例如，下列顯示可能因選取選項編號 2「讀取使用」而產生的輸出 LogMiner。

    讀取效能公用程式輸出

  6. 若要結束公用程式，請輸入 0 (零)。

後續步驟

  • 當結果顯示讀取速度低於可接受的閾值時，請在端點上執行 Oracle 診斷支援指令碼、檢閱等待時間、載入設定檔和 IO 設定檔區段。然後調整任何可能改善讀取效能的異常組態。例如，如果您的重做日誌檔不超過 2 GB，請嘗試BUFFER將 LOG _ 增加到 200 MB，以協助改善效能。

  • 檢閱AWS DMS 最佳做法，確保您的DMS複寫執行個體、工作和端點設定為最佳狀態。

「我的」的疑難排解 SQL

接下來，您可以了解疑難排解 AWS DMS 與我的SQL資料庫搭配使用的特定問題。

CDCAmazon RDS 資料庫執行個體端點的工作失敗，因為二進位記錄

Amazon RDS 資料庫執行個體會發生此問題，因為自動備份已停用。將備份保留期設非零的值以啟用自動備份。

與目標的連線我的SQL執行個體在工作期間中斷連線

如果您有與我LOBs的SQL目標中斷連線的工作，您可能會在工作記錄中看到下列類型的錯誤。

[TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: 08S01 NativeError: 
2013 Message: [MySQL][ODBC 5.3(w) Driver][mysqld-5.7.16-log]Lost connection 
to MySQL server during query [122502] ODBC general error.
 [TARGET_LOAD ]E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
2006 Message: [MySQL][ODBC 5.3(w) Driver]MySQL server has gone away 
[122502] ODBC general error.

在此情況下，您可能需要調整部分任務設定。

若要解決工作與我的SQL目標中斷連線的問題，請執行下列動作：

  • 檢查您的數據庫變量是否max_allowed_packet設置足夠大以容納最大的變量LOB。

  • 確認您將下列變數設定為具有高逾時值。我們建議您對每項變數的值設定為至少 5 分鐘。

    • net_read_timeout

    • net_write_timeout

    • wait_timeout

如需有關設定我的SQL系統變數的資訊，請參閱我的SQL文件中的伺服器系統變數。

將自動提交添加到 My 兼容端SQL點

將自動提交新增至目標 My SQL 相容端點

  1. 登入 AWS Management Console 並在 https://console.aws.amazon.com/dms/v2/ 開啟 AWS DMS 主控台。

  2. 選擇端點。

  3. 選擇您要新增自動提交的 My SQL 相容目標端點。

  4. 選擇 Modify (修改)。

  5. 選擇進階，然後將下列程式碼新增至額外連線屬性文字方塊：

    
Initstmt= SET AUTOCOMMIT=1

  6. 選擇 Modify (修改)。

在目標我的SQL相容端點上停用外鍵

您可以在目標 My SQL SQL、Amazon Aurora 我的SQL相容版本或 MariaDB 端點的「進階」區段中，將下列項目新增至「額外連線屬性」，以停用「我的」上的外來索引鍵檢查。

在目標我的SQL相容端點上停用外部索引鍵

  1. 登入 AWS Management Console 並在 https://console.aws.amazon.com/dms/v2/ 開啟 AWS DMS 主控台。

  2. 選擇端點。

  3. 選擇您要停用外部索引鍵的我的SQL、我的 Aurora 或 MariaDB 目標端點。SQL

  4. 選擇 Modify (修改)。

  5. 選擇進階，然後將下列程式碼新增至額外連線屬性文字方塊：

    
Initstmt=SET FOREIGN_KEY_CHECKS=0

  6. 選擇 Modify (修改)。

以問號取代的字元

造成此問題的最常見情況是來源端點字元已由 AWS DMS 不支援的字元集編碼時。

「錯誤事件」日誌項目

移轉記錄檔中的「錯誤事件」項目通常表示在來源資料庫端點上嘗試了不支援的資料定義語言 (DDL) 作業。不支援的DDL作業會造成複寫執行個體無法略過的事件，因此會記錄錯誤的事件。

若要修正此問題，請從頭開始重新開始任務。這樣做會重新載入資料表，並在發出不支援的DDL作業之後的某個時間點開始擷取變更。

使用 My SQL 5.5 更改數據捕獲

AWS DMS Amazon RDS My SQL 相容資料庫的變更資料擷取 (CDC) 需要完整映像資料列型二進位記錄，My 5.5 或更低SQL版本不支援此功能。若要使用 AWS DMS CDC，您必須將 Amazon 資RDS料庫執行個體升級到我的 5.6 SQL 版。

增加 Amazon RDS 資料庫執行個體的二進位記錄保

AWS DMS 需要保留二進位記錄檔才能擷取變更資料。若要增加 Amazon RDS 資料庫執行個體的日誌保留，請使用下列程序。下列命令會將日誌保留期提高為 24 小時。


call mysql.rds_set_configuration('binlog retention hours', 24);

日誌訊息：套用於目標資料庫時，來源資料庫中的某些變更並未產生作用。

將 [我的SQL資料庫] 資料行的值 AWS DMS 更新為現有值時，會從 [我] 傳回的zero rows affected訊息SQL。此行為與其他資料庫引擎 (例如 Oracle 和SQL伺服器) 不同。這些引擎會更新一個資料列，即使取代值與目前值相同。

錯誤：識別碼太長

識別碼太長時會發生下列錯誤：


TARGET_LOAD E: RetCode: SQL_ERROR SqlState: HY000 NativeError: 
1059 Message: MySQLhttp://ODBC 5.3(w) Driverhttp://mysqld-5.6.10Identifier 
name 'name' is too long 122502 ODBC general error. (ar_odbc_stmt.c:4054)

在某些情況下，您可 AWS DMS 以設定在目標資料庫中建立資料表和主索引鍵。在這些情況下，DMS目前不會為來源資料庫中使用的主索引鍵使用相同的名稱。而是根據資料表名稱DMS建立主索引鍵名稱。當資料表名稱較長時，建立的自動產生識別碼可能會超過「我SQL的」允許的限制。

為了解決這個問題，目前的方法是先在目標資料庫中預先建立資料表和主索引鍵。然後使用任務，將任務設定目標資料表準備模式設為不執行任何操作或截斷來填入目標資料表。

錯誤：不支援的字元集導致欄位資料轉換失敗

不支援的字元集導致欄位資料轉換失敗時，會發生下列錯誤：


"[SOURCE_CAPTURE ]E: Column 'column-name' uses an unsupported character set [120112] 
A field data conversion failed. (mysql_endpoint_capture.c:2154)

請檢查與連線相關的資料庫參數。您可以使用下列命令來設定這些參數。


SHOW VARIABLES LIKE '%char%';

錯誤:字碼頁 1252 到 UTF8 [120112] 欄位資料轉換失敗

如果來源 My 資料庫中有非字碼頁 -1252 字元，移轉期間可能會發生下列錯誤。SQL

  
[SOURCE_CAPTURE ]E: Error converting column 'column_xyz' in table
'table_xyz with codepage 1252 to UTF8 [120112] A field data conversion failed. 
(mysql_endpoint_capture.c:2248)

因應措施是，您可以將CharsetMapping額外的連線屬性與來源 My SQL 端點搭配使用，以指定字元集對應。如果您新增此端點設定，則可能需要從頭開始重新啟動 AWS DMS 移轉工作。

例如，下列端點設定可用於SQL來源字元集為Utf8或的 My 來源端點latin1。65001 是字UTF8碼頁識別碼。

   
CharsetMapping=utf8,65001
CharsetMapping=latin1,65001

未遷移的索引、外部索引鍵或梯級更新或刪除

AWS DMS 不支援移轉次要物件，例如索引和外部索引鍵。若要從梯級更新或刪除操作複寫對子資料表所做的變更，您必須在目標資料表上啟用觸發的外部索引鍵條件。若要解決此限制，請在目標資料表上手動建立外部索引鍵。然後，針對完全負載和建立單一工作CDC，或建立兩個單獨的工作來完全載入CDC，如下所述：

創建一個支持全負載和 CDC

此程序說明如何使用單一工作來移轉外部索引鍵與索引CDC。

建立完整負載和CDC工作

  1. 在目標上手動建立具有外部索引鍵和索引的資料表，以符合來源資料表。

  2. 將下列項目新增ECA至目標 AWS DMS 端點：

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. 建立TargetTablePrepMode設 AWS DMS 定為的工作DO_NOTHING。

  4. 將 Stop task after full load completes 設定設為 StopTaskCachedChangesApplied。

  5. 開始工作。 AWS DMS 在工作完成完整載入後自動停止工作，並套用任何快取的變更。

  6. 刪除SET FOREIGN_KEY_CHECKSECA您之前添加的。

  7. 繼續任務。工作會進入CDC階段，並將來源資料庫的持續變更套用至目標。

分別建立完整負載和CDC工作

這些程序說明如何使用個別工作來移轉外部索引鍵與索引CDC。

建立完全載入任務

  1. 在目標上手動建立具有外部索引鍵和索引的資料表，以符合來源資料表。

  2. 將下列項目新增ECA至目標 AWS DMS 端點：

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  3. 建立TargetTablePrepMode參數設定為DO_NOTHING且EnableValidation設定為的 AWS DMS 工作FALSE。

  4. 開始工作。 AWS DMS 在工作完成完整載入後自動停止工作，並套用任何快取的變更。

  5. 工作完成後，請記下中的完整載入工作開始時間 UTC (或二進位記錄檔名稱和位置)，以啟動CDC唯一的工作。請參閱記錄檔以UTC從初始完整載入開始時間取得時間戳記。

創建一個CDC唯一的任務

  1. 刪除SET FOREIGN_KEY_CHECKSECA您先前設置的。

  2. 建立CDC唯一的工作，並將開始位置設定為上一個步驟中記錄的完整載入開始時間。或者，您可以使用在先前步驟中記錄的二進位日誌位置。將 TargetTablePrepMode 設定設為 DO_NOTHING。視需要透過將 EnableValidation 設定設為 TRUE，來啟用資料驗證。

  3. 啟動CDC唯一的任務，並監視日誌是否有錯誤。

注意

此因應措施僅適用於「我SQL到我的」SQL 移轉。您無法將此方法與「批次套用」功能搭配使用，因為「批次套用」要求目標資料表不包含作用中的外部索引鍵。

疑難排解問題 SQL

接下來，您可以了解有關 AWS DMS 與 Postgre SQL 數據庫一起使用的特定問題的故障排除。

JSON數據類型被截斷

AWS DMS 將 Postgre 中的JSON資料類型視SQL為LOB資料類型資料行。這表示您使用限制LOB模式時的LOB大小限制會套用至JSON資料。

例如，假設限制LOB模式設定為 4,096 KB。在這種情況下，任何大於 4,096 KB 的JSON資料都會在 4,096 KB 的限制下被截斷，並且在 Postgre 中的驗證測試失敗。SQL

下列記錄資訊顯JSON示由於限制LOB模式設定和驗證失敗而遭到截斷。

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt
2017-09-19T03:00:49 [TARGET_APPLY ]E: Failed to execute statement: 
  'UPDATE "public"."delivery_options_quotes" SET "id"=? , "enabled"=? , 
  "new_cart_id"=? , "order_id"=? , "user_id"=? , "zone_id"=? , "quotes"=? , 
  "start_at"=? , "end_at"=? , "last_quoted_at"=? , "created_at"=? , 
  "updated_at"=? WHERE "id"=? ' [1022502] (ar_odbc_stmt.c:2415)

03:00:49
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)
2017-09-19T03:00:49 [TARGET_APPLY ]E: RetCode: SQL_ERROR SqlState: 
  22P02 NativeError: 1 Message: ERROR: invalid input syntax for type json;, 
  Error while executing the query [1022502] (ar_odbc_stmt.c:2421)

使用者定義資料類型的資料欄未正確遷移

從 Postgre SQL 來源複製時，除了具有使用者定義資料類型的資料欄以外，所有資料行都使用相同的資料類型 AWS DMS 建立目標資料表。在這種情況下，此資料類型在目標中會建立為「字元不相同」。

錯誤：未選取要在其中建立的結構描述

在某些情況下，您可能會看到錯誤「SQL_ ERROR SqlState: 3F000 NativeError: 7 訊息ERROR:: 未選取要在中建立的綱要」。

當您的資料JSON表對應包含結構描述的萬用字元值，但來源資料庫不支援該值時，就會發生此錯誤。

不會使用複寫資料表的刪除和更新 CDC

如果來源資料表沒有主索引鍵，則會忽略變更資料擷取 (CDC) 期間的刪除和更新作業。 AWS DMS 支持更改帶有主鍵的 Postgre SQL 表的數據捕獲（CDC）。

如果表沒有主鍵，則預寫（WAL）日誌不包含數據庫行的前圖像。在這種情況下， AWS DMS 無法更新表格。如果是要複寫的刪除操作，請在來源資料表建立主索引鍵。

未傳播截斷陳述式

使用變更資料擷取 (CDC) 時，不支援TRUNCATE作業 AWS DMS。

防止波斯格雷捕SQL獲 DDL

您可以新增下列端點設定DDL陳述式，以防止 Postgre SQL 目標端點擷取陳述式。


"CaptureDDLs": "N"

選取建立要擷DDL取之資料庫物件的綱要

您可以控制在哪些結構描述中建立與擷取相關DDL的資料庫物件。新增下列端點設定陳述式。您可以從來源端點的索引標籤中使用端點設定參數。


"DdlArtifactsSchema: "xyzddlschema"

甲骨文表在遷移到郵政後丟失 SQL

在這種情況下，資料表和資料通常仍是可存取的狀態。

甲骨文默認為大寫表名，和 Postgre SQL 默認為小寫表名。當您執行從 Oracle 到 Postgre 的遷移時SQL，建議您在任務的表格映射部分下提供某些轉換規則。這些是轉換規則，用於轉換資料表名稱的大小寫。

如果您在不使用轉換規則來轉換資料表名稱大小寫的情況下遷移資料表，則請在參考這些資料表時將資料表名稱括在引號中。

ReplicationSlotDiskUsage 增加和 restart_lsn 在長期交易期間停止向前移動，例如工作負載 ETL

啟用邏輯複寫時，每個交易保留在記憶體中的變更數目上限為 4MB。之後，變更會溢出到磁碟。結果 ReplicationSlotDiskUsage 會增加，restart_lsn 在交易完成/中止並且回復完成前不會有所進展。由於這個交易很耗時，回復所需時間可能很長。

因此，當啟用邏輯複寫時，請避免長時間執行的交易。相反地，請嘗試將交易分解為幾個較小的交易。

使用檢視做為來源的任務沒有複製的資料列

若要遷移檢視，請將 table-type 設為 all 或 view。如需詳細資訊，請參閱 從主控台指定資料表選取及轉換。

支援檢視的來源包括以下內容。

  • Oracle

  • Microsoft SQL 伺服器

  • 我的 SQL

  • 後備 SQL

  • IBMDB2 LUW

  • SAP調適性伺服器企業 (ASE)

疑難排解 Microsoft SQL 伺服器問題

接下來，您可以了解疑難排解 AWS DMS 與 Microsoft SQL 伺服器資料庫搭配使用的特定問題。

SQL伺服器容錯移轉至次要後，進行中RDS的複寫失敗

如果來源SQL伺服器執行個體容錯移轉至次要執行個體， AWS DMS 進行中的複寫會繼續嘗試連線，並在來源重新上線時繼續複寫。但是，對RDS於SQL伺服器MAZ執行個體，在某些情況下，可以將次要資料庫擁有者設定為NT AUTHORITY\SYSTEM。容錯移轉之後，這會導致DMS工作失敗，並出現下列錯誤：

[SOURCE_CAPTURE  ]E:  RetCode: SQL_ERROR  SqlState: 42000 NativeError: 33009 Message: 
                [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]The database owner SID recorded in the master 
                database differs from the database owner SID recorded in database 'rdsadmin'. You should correct 
                this situation by resetting the owner of database 'rdsadmin' using the ALTER AUTHORIZATION statement. 
                Line: 1 Column: -1 [1022502]  (ar_odbc_stmt.c:5035)

若要修正此問題，請依照將 db_owner 變更為資料庫的 rdsa 帳戶中的步驟執行，然後繼續您的工作。DMS

擷取SQL伺服器資料庫變更時出錯

變更資料擷取 (CDC) 期間的錯誤通常可能表示未符合其中一個先決條件。例如，最常忽略的必要條件是完整資料庫備份。任務日誌會透過下列錯誤指出此疏忽：


SOURCE_CAPTURE E: No FULL database backup found (under the 'FULL' recovery model). 
To enable all changes to be captured, you must perform a full database backup. 
120438 Changes may be missed. (sqlserver_log_queries.c:2623)

複查中針對使用SQL伺服器作為來源所列出的先決條件使用 Microsoft SQL 伺服器資料庫作為來源 AWS DMS。

遺失身分資料行

AWS DMS 建立目標結構描述時，不支援識別資料行。您必須完成初始載入時將其新增。

錯誤：SQL服務器不支持出版物

當您使用SQL伺服器快速作為來源端點時，會產生下列錯誤：


RetCode: SQL_ERROR SqlState: HY000 NativeError: 21106 
Message: This edition of SQL Server does not support publications.

AWS DMS 目前不支援SQL伺服器快速作為來源或目標。

變更不會出現在目標中

AWS DMS 要求來源SQL伺服器資料庫處於 '' 或 FULL 'BULKLOGGED' 資料復原模式，才能持續擷取變更。不支援 SIMPLE '' 模型。

SIMPLE復原模式會記錄允許使用者復原其資料庫所需的最小資訊。所有非作用中的日誌項目會在檢查點發生時自動截斷。

所有操作仍會記錄下來。不過，一旦出現檢查點，日誌就會自動遭到截斷。此截斷表示日誌可供重複使用，而且可以覆寫較舊的日誌項目。覆寫記錄項目時，就無法擷取變更。這個問題就是為什麼 AWS DMS 不支持數SIMPLE據恢復模式。如需將SQL伺服器用作來源的其他必要先決條件的資訊，請參閱使用 Microsoft SQL 伺服器資料庫作為來源 AWS DMS。

跨分割區對應的非統一資料表

CDC在變更資料擷取 (CDC) 期間，如果無法在資料表上正確執行，則會 AWS DMS 暫停具有特殊結構的資料表移轉。系統發出如下所示的訊息：


[SOURCE_CAPTURE ]W: Table is not uniformly mapped across partitions. Therefore - it is excluded from CDC (sqlserver_log_metadata.c:1415)
[SOURCE_CAPTURE ]I: Table has been mapped and registered for CDC. (sqlserver_log_metadata.c:835)

CDC在SQL伺服器資料表上執行時，會 AWS DMS 剖析SQL伺服器 Tlog。在每個 tlog 記錄上，針對 AWS DMS 變更期間插入、更新或刪除的資料行，剖析包含資料的十六進位值。

若要剖析十六進位記錄，請從SQL伺服器系統資料表 AWS DMS 讀取資料表中繼資料。這些系統資料表會識別特殊結構化資料表的資料欄，並揭露其部分的內部屬性，例如 "xoffset" 和 "null bit position"。

AWS DMS 預期資料表中所有原始分割區的中繼資料都是相同的。但在某些情況下，結構特殊的資料表在其所有分割區上都沒有相同的中繼資料。在這些情況下， AWS DMS 可以在該資料表CDC上暫停，以避免錯誤剖析變更，並為目標提供不正確的資料。因應措施包括以下項目：

  • 如果資料表具有叢集索引，請執行索引重建。

  • 如果資料表沒有叢集索引，請將叢集索引新增至資料表 (如果需要，可以稍後將其捨棄)。

針對 Amazon Redshift 的問題進行疑難排解

接下來，您可以了解 AWS DMS 與 Amazon Redshift 資料庫搭配使用的特定問題進行疑難排解。

在不同 AWS 區域中載入至 Amazon Redshift 叢集

您無法在與 AWS DMS 複寫執行個體不同的 AWS 區域中載入 Amazon Redshift 叢集。DMS要求您的複寫執行個體和 Amazon Redshift 叢集位於同一個區域。

錯誤：關聯 "awsdms_apply_exceptions" 已存在

錯誤「關係 'awsdms_apply_例外' 已經存在」通常發生在 Redshift 端點被指定為 Postgre 端點時。SQL若要修正此問題，請修改端點，並將 Target engine (目標引擎) 變更為 "redshift"。

名稱以 "awsdms_changes" 開頭的資料表錯誤

當兩個嘗試將資料載入至相同 Amazon Redshift 叢集中的任務同時執行時，就可能會出現名稱以 "awsdms_changes" 開頭的資料表錯誤訊息。由於臨時資料表命名方式的緣故，並行任務在更新相同資料表時可能發生衝突。

在具有名稱的叢集中查看表格，例如變更 XXXX

AWS DMS 從 Amazon S3 中存放的檔案載入資料時，會建立暫存資料表。這些臨時資料表名稱各具有字首 dms.awsdms_changes。這些表是必需的，因此 AWS DMS 可以在第一次加載數據時以及將其放置在最終目標表中之前存儲數據。

使用 Amazon Redshift 所需的許可

若要 AWS DMS 搭配 Amazon Redshift 使用，您用來存取 Amazon Redshift 的使用者帳戶必須具有下列許可：

  • CRUD(選擇、插入、更新、刪除)

  • 大量載入

  • 建立、修改、刪除 (如果任務的定義需要)

若要查看使用 Amazon Redshift 作為目標所需的必要條件，請參閱使用 Amazon Redshift 資料庫作為 AWS Database Migration Service 的目標。

Amazon Aurora 我的疑難排解問題 SQL

接下來，您可以了解疑難排解 AWS DMS 與 Amazon Aurora 我的SQL資料庫搭配使用的特定問題。

錯誤：以 '結束的CHARACTERSETUTF8欄位，以'\ n '結束的' "'行括住

如果您使用 Amazon Aurora My SQL 作為目標，您可能會在日誌中看到類似下列的錯誤。這種類型的錯誤通常表示您將 ANSI _ QUOTES 作為 SQL _ MODE 參數的一部分。將 ANSI _ 做QUOTES為 SQL _ MODE 參數的一部分會導致雙引號像引號一樣處理，並且在執行工作時可能會產生問題。

若要修正此錯誤，請QUOTES從 ANSI _ MODE 參數中移除 SQL _。


2016-11-02T14:23:48 [TARGET_LOAD ]E: Load data sql statement. load data local infile 
"/rdsdbdata/data/tasks/7XO4FJHCVON7TYTLQ6RX3CQHDU/data_files/4/LOAD000001DF.csv" into table 
`VOSPUSER`.`SANDBOX_SRC_FILE` CHARACTER SET UTF8 fields terminated by ',' 
enclosed by '"' lines terminated by '\n'( `SANDBOX_SRC_FILE_ID`,`SANDBOX_ID`,
`FILENAME`,`LOCAL_PATH`,`LINES_OF_CODE`,`INSERT_TS`,`MODIFIED_TS`,`MODIFIED_BY`,
`RECORD_VER`,`REF_GUID`,`PLATFORM_GENERATED`,`ANALYSIS_TYPE`,`SANITIZED`,`DYN_TYPE`,
`CRAWL_STATUS`,`ORIG_EXEC_UNIT_VER_ID` ) ; (provider_syntax_manager.c:2561)

疑難排解問題 SAP ASE

接下來，您可以了解疑難排解 AWS DMS 與SAPASE資料庫搭配使用的特定問題。

錯誤：當 source 具有具有LOBNULL值的複合唯一索引時，列具有NULL值

SAPASE當使用具有設定複合唯一索引 (允許NULL值的複合唯一索引) 的資料表的來源時，LOB值可能不會在進行中複寫期間移轉。此行為通常是在DMS複寫執ANSI行個體用戶端上預NULL設值設為 1 的結果。

若要確保LOB欄位正確移轉，請將 Endpoint 設定包含'AnsiNull=0'至工作的 AWS DMS 來源端點。

IBMDb2 的疑難排解問題

接下來，您可以了解有關 AWS DMS 與 IBM Db2 資料庫搭配使用的疑難排解問題。

錯誤：從時間戳記繼續是不支援的任務

對於進行中的複寫 (CDC)，如果您打算從特定時間戳記開始複寫，請StartFromContext將連線屬性設定為所需的時間戳記。如需詳細資訊，請參閱使用 Db2 LUW 時的端點設定。將 StartFromContext 設為必要的時間戳記可避免下列問題：

Last Error Resume from timestamp is not supported Task error notification received from 
subtask 0, thread 0 [reptask/replicationtask.c:2822] [1020455] 'Start from timestamp' was blocked to prevent Replicate from 
scanning the log (to find the timestamp). When using IBM DB2 for LUW, 'Start from timestamp' is only supported if an actual 
change was captured by this Replicate task earlier to the specified timestamp.