An enterprise is migrating a self-managed, on-premises IBM DB2 LUW (version\ 11.5) databas… — AWS Certified Solutions Architect - Professional

An enterprise is migrating a self-managed, on-premises IBM DB2 LUW ( $version\ 11.5$ ) database to an Amazon Aurora PostgreSQL-Compatible Edition cluster. The source database contains high-volume transactional tables, some of which include Character Large Object (CLOB) columns storing data up to $10\text{ MB}$ in size. The migration strategy requires schema conversion using the AWS Schema Conversion Tool (SCT) and data replication with minimal downtime using AWS Database Migration Service (DMS) with continuous replication (CDC).

During a migration test run, the solutions architect observes the following issues:
1. The AWS DMS replication task successfully completes the Full Load phase but fails to replicate any subsequent transactions during the CDC phase, causing the replication task to stall.
2. Analysis of the target Aurora PostgreSQL database shows that several text fields originating from the CLOB columns are truncated.
3. The overall replication throughput is significantly lower than the target baseline.

Which combination of actions will resolve these issues while maintaining optimal replication performance?

A
Configure the source IBM DB2 database to use circular logging, and append the db2UseCircularLog=true connection attribute to the AWS DMS source endpoint. Create a single AWS DMS replication task for all tables, and configure it to use Full LOB mode with InlineLobMaxSize set to $10240\text{ KB}$ to prevent CLOB truncation.
B
Enable supplemental logging on the source IBM DB2 database using the ALTER DATABASE ADD SUPPLEMENTAL LOG DATA command. Create a single AWS DMS replication task for all tables, configure it to use Limited LOB mode with LobMaxSize set to $10\text{ MB}$ , and enable task validation to automatically rebuild and re-replicate any truncated LOBs.
Verify that archive logging is enabled on the source IBM DB2 database by setting LOGARCHMETH1 to a valid destination, and run ALTER TABLE <table_name> DATA CAPTURE CHANGES for each table selected for replication. Create two separate AWS DMS replication tasks: one task for tables without LOB columns with LOB support disabled to maximize throughput, and a second task for tables containing CLOB columns configured with Limited LOB mode and LobMaxSize set to $10240\text{ KB}$ .Answer
D
Verify that archive logging is enabled on the source IBM DB2 database by setting LOGARCHMETH1 to a valid destination, and run ALTER TABLE <table_name> DATA CAPTURE CHANGES for all replicated tables. Create a single AWS DMS replication task for all tables, and configure it to use Full LOB mode to avoid truncation, as splitting tables into separate Full Load and CDC tasks is not supported for IBM DB2 sources.

Answer

Verify that archive logging is enabled on the source IBM DB2 database by setting LOGARCHMETH1, run ALTER TABLE DATA CAPTURE CHANGES for the replicated tables, and split the migration into two AWS DMS tasks: one with LOB support disabled for non-LOB tables, and another using Limited LOB mode with LobMaxSize set to

10240\text{ KB}

for tables with CLOB columns.

The correct solution requires configuring the IBM DB2 LUW source database for Change Data Capture (CDC) by enabling archive logging via LOGARCHMETH1 and running ALTER TABLE DATA CAPTURE CHANGES on the replicated tables to ensure before/after images are written to the transaction logs. To address performance and CLOB truncation, separating the tables into two tasks is an AWS best practice. The task for tables without LOBs has LOB support disabled to optimize throughput, while the task for LOB-heavy tables uses Limited LOB mode with LobMaxSize set to

10240\text{ KB}

(

10\text{ MB}

) to prevent truncation.

Step-by-Step Solution

Configure database-level and table-level logging on the source IBM DB2 LUW database.

Database logging is configured to use archive logging instead of circular logging, and the DATA CAPTURE CHANGES setting is enabled on all tables targeted for migration.

AWS DMS CDC requires transaction logs to have write-ahead logging enabled with full row images (before and after images) to capture modifications, which circular logging or default logging does not provide.

Analyze LOB column requirements and segment tables based on LOB presence.

Group tables into two sets: tables with no LOB columns and tables with CLOB columns up to

10\text{ MB}

Separating LOB tables from non-LOB tables prevents LOB processing overhead (which requires additional round-trips or memory) from slowing down the replication of high-volume standard transactional data.

Configure AWS DMS replication task settings for each table group.

Disable LOB support for the non-LOB task to maximize throughput, and set the LOB task to Limited LOB mode with LobMaxSize set to

10240\text{ KB}

(

10\text{ MB}

Limited LOB mode pre-allocates memory buffer pools on the replication instance, making it much faster than Full LOB mode. Setting the size to

10240\text{ KB}

ensures that no CLOB values up to the maximum

10\text{ MB}

size are truncated.

Start both replication tasks with Full Load and CDC enabled.

Data is successfully migrated and replicated continuously without truncation or replication stalls.

The database changes are captured from the logs, and LOB data is replicated efficiently without exceeding memory buffers or causing truncation.

Key Concept

AWS DMS replication requires source-specific logging settings (like DATA CAPTURE CHANGES for IBM DB2) to enable CDC, and performance is optimized by splitting LOB and non-LOB tables into separate tasks with appropriate LOB size limitations.

Estimated Time:3m 0s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic