Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

AWS DMS CDC Converter error Postgres 18 WIN1252 to Oracle 19 WE8MSWIN1252

0

AWS DMS CDC Fails with ORA-24806 or "Converter not found" (Postgres to Oracle CLOB)

I am running an AWS DMS CDC task to sync an AWS RDS PostgreSQL (v18.1) source to an AWS RDS Oracle 19 SE target. The Oracle database encoding is WE8MSWIN1252.

I have attempted two different setups, both resulting in fatal errors that stall the CDC stream:

Setup 1: PostgreSQL with UTF8 Encoding (Default)

  • Behavior: DMS fails when attempting to apply changes to Oracle CLOB columns.
  • Error: ORA-24806: LOB form mismatch
  • Result: The failure drops the Oracle endpoint connection, and DMS retries indefinitely, stalling the entire CDC stream.

Setup 2: PostgreSQL with WIN1252 Encoding

  • Behavior: Explicitly created the Postgres DB with WIN1252 encoding (via template0).
  • Error: Last Error Converter not found Stop Reason FATAL_ERROR Error Level FATAL

Relevant Task Logs:

[METADATA_MANAGE]I: Going to connect to ODBC connection string: Driver={PostgreSQL Unicode(x64)};Server=[...].rds.amazonaws.com;Port=5432;Database=[...];UseDeclareFetch=1;Fetch=10000;Uid=[...];sslmode=require; (postgres_endpoint_util.c:283)
[SOURCE_UNLOAD]I: PostgreSQL database server encoding is 'WIN1252' 
[SOURCE_CAPTURE]E: Failed getting converter for encoding 'WIN1252' [1002404 (postgres_endpoint_capture.c:247)
[SOURCE_CAPTURE]E: Error executing source loop [1002404]
[TASK_MANAGER ]E: Task encountered a fatal error

What options do I have?

Topics
Migration & ModernizationDatabase
Tags
AWS Database Migration ServicePostgreSQLOracle to PostgreSQL
Language
English

asked a month ago70 views

2 Answers
2
Accepted Answer

Based on the errors you're encountering, here are your options to resolve the CDC issues between PostgreSQL and Oracle:

For the ORA-24806 LOB form mismatch error (Setup 1):

This error typically occurs when there's a character set incompatibility between source and target databases. Since your Oracle database uses WE8MSWIN1252 encoding and PostgreSQL defaults to UTF8, the mismatch in character sets is causing the CLOB operations to fail.

For the "Converter not found" error (Setup 2):

The WIN1252 encoding you're using in PostgreSQL is not directly supported by AWS DMS as a source encoding. DMS expects standard PostgreSQL encodings and doesn't have a built-in converter for WIN1252 when used as a source database encoding.

Recommended approaches:

  1. Use UTF8 encoding on PostgreSQL with proper endpoint configuration: Keep your PostgreSQL database in UTF8 (the standard and recommended encoding) and configure your DMS source endpoint with appropriate extra connection attributes to handle character set conversion properly. You may need to specify character set mapping parameters in the endpoint settings.

  2. Review data type mappings: Character set incompatibilities and unsupported data types are known to cause task failures in DMS. Ensure your CLOB columns and their mappings are compatible between the two database engines.

  3. Check replication instance capacity: If you're receiving errors that cause the task to stall, verify that your replication instance has sufficient memory and resources to handle the workload. Insufficient capacity can exacerbate conversion and processing issues.

  4. Review CloudWatch logs: Examine your CloudWatch logs for detailed error messages by searching for "]E:" or "]W:" to identify the specific component (SOURCE_CAPTURE, TARGET_APPLY) where the failure occurs and get more context about the conversion issues.

The fundamental issue is that WIN1252 is not a supported PostgreSQL encoding for DMS CDC operations. Your best path forward is to use UTF8 encoding on PostgreSQL and work with AWS Support through the AWS Support Center to configure the proper character set handling for your Oracle target with WE8MSWIN1252 encoding.
Sources
Troubleshoot AWS DMS replication task failures and stuck states | AWS re:Post

answered a month ago

EXPERT

reviewed a month ago

  • Florin
    a month ago

    Hey Florian,

    Thank you for your answer! This is exactly what I was looking for - a second confirmation that PostgreSQL WIN1252 is not supported by DMS.

    Just as info, I am already handling the points you mentioned:

    • Limited LOB Mode
    • Endpoint Attributes
    • Data Mappings
    • Pre-creation of target tables (to ensure correct column types)

    Thank you for highlighting those as well!

    Moving forward, my solution will likely be to revert PostgreSQL back to UTF8 (obviously), exclude the CLOB columns from the Postgres-to-Oracle CDC task, and handle their transport separately.

    Thanks again!

2

In Short: Revert PostgreSQL to UTF8 and switch your DMS task to Limited LOB Mode. This bypasses the strict OCI LOB-locator binding that triggers the ORA-24806 error.

Stick with Setup 1 (PostgreSQL in UTF8). The "Converter not found" error in Setup 2 is a dead end, because AWS DMS does not support WIN1252 as a native source encoding for PostgreSQL CDC.

The ORA-24806: LOB form mismatch error in Setup 1 happens because DMS reads the PostgreSQL data as Unicode (UTF8) and attempts to bind it to the Oracle CLOB column using the national character set (NCHAR) form, which conflicts with your Oracle database's standard WE8MSWIN1252 character set. To resolve this issue, apply the following fixes to your UTF8 setup:

  • Switch to Limited LOB Mode: If your task is currently using Full LOB Mode, switch it to Limited LOB Mode (and define an appropriate max LOB size, e.g., 32 KB or 64 KB). In Limited LOB Mode, DMS binds the data inline as standard text, allowing the Oracle OCI driver to seamlessly convert the incoming UTF8 data into the target WE8MSWIN1252 CLOB storage.

  • Verify Target Data Types: Ensure that the target columns in Oracle are explicitly defined as CLOB and not NCLOB. If DMS created the tables automatically, use a DMS Table Mapping Transformation rule to explicitly force the target data type to CLOB.

  • Check Endpoint Attributes: Ensure your Oracle Target Endpoint does not have conflicting environment variables or Extra Connection Attributes (ECAs) that force NCHAR conversion. If the issue persists in Limited LOB Mode, try adding charLengthSemantics=CHAR; to your target endpoint attributes.

EXPERT

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content