Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
Abrie_M
Contributor III
Contributor III

DDL changes on DB2 LUW

Good day

From the Replicate documentation:

When the Change table option is enabled in the Store Changes Settings tab, the first timestamp record in the table may be Zero in some cases (i.e. 1970-01-01 00:00:00.000000)

I've also found that when a CDC task is stopped and resumed, the first DDL record also have the 1970 timestamp. This means that Compose does not pick up the DDL changes.

Abrie_M_0-1651146119682.png

As it is normal behavior for tasks to be stopped/resumed (server maintenance, etc), would one assume that CDC with schema evolution does not work for a DB2 LUW endpoint?

Anyone found a workaround for this?

Thanx

Abrie

Labels (1)
1 Solution

Accepted Solutions
SwathiPulagam
Support
Support

@Abrie_M   For some sources(like DB2 LUW and Postgres etc.,), Replicate can't capture the exact timestamp( due to source limitations) when we start the task for the first time or stop and resume the task. So Replicate record that uncaptured time stamp as 1970-01-01 00:00:00.000000.

    The good news is that Replicate overcome this issue for the Postgres source by adding the last commit timestamp to the stream position and we can provide a workaround how to handle the remaining situations where the replicate still maintains the timestamp as 1970-01-01 00:00:00.000000

   If you create a case listing the problems then R&D will revisit DB2 source limitations related to these timestamp issues. 

Thanks,

Swathi

View solution in original post

1 Reply
SwathiPulagam
Support
Support

@Abrie_M   For some sources(like DB2 LUW and Postgres etc.,), Replicate can't capture the exact timestamp( due to source limitations) when we start the task for the first time or stop and resume the task. So Replicate record that uncaptured time stamp as 1970-01-01 00:00:00.000000.

    The good news is that Replicate overcome this issue for the Postgres source by adding the last commit timestamp to the stream position and we can provide a workaround how to handle the remaining situations where the replicate still maintains the timestamp as 1970-01-01 00:00:00.000000

   If you create a case listing the problems then R&D will revisit DB2 source limitations related to these timestamp issues. 

Thanks,

Swathi