I have a DMS doing on-going replication from SSMS databases to S3 folders. The source rows do not have a timestamp column for changes. All operations on the source are either row creation or updates. These is no source of history, and only current rows. There is a percentage of records appearing in the S3 target that are not duplicates, but got the same timestamp from DMS. It is impossible to determine which of the rows in S3 is the current record.
If I delete both records from the S3 layer, will DMS go back and repopulate them (hopefully with new and differing timestamps? It would be easy enough to create a Glue job to remove them, if they will repopulate in a usable way. Are there any suggestions for fixing the underlying problem that is creating the issue? The resolution of the DMS timestamp datatype is a thousand times more precise than would be needed to distinguish these rows. They are typical one tenth of a second apart, or so.
Thanks!
This is a problem with a production system.