After running an AutoM&M process with auto and manual rules, "auto merges" have been processed OK but if we check match table for manual ones there are many duplicates (same rowid_object, rowid_object_matched, rowid_match_rule). The only difference is that one of the matches have values in updated_by and last_update_date columns.
What's the reason of this behaviour?
Example of duplicated match:
Thx
Hi,
There is no check which would actually check in the MTCH table to identify if there is an entry created for two corresponding rowid values from the previous executions. So there is a possibility for duplicate requests present as it is of Manual match rules, Expectation for the Manual matches is that data steward reviews the record and then approve the right one. In some cases there might be a confusion on picking the right one among the multiple entries . That is the reason we usually recommend to either merge the records/remove the entries from the MTCH table before running the next match job.
Hope it helps!
Regards,
Rajan
Also please note, Duplicate entries will be removed once the right records are merged.
Regards,
Rajan
Can you please confirm if you used a single cleanse/process server for this match job or multiple process servers.
if you see create_date is different for 2 records, can you please and confirm if you ran Match job twice?
Also as mentioned above we usually recommend to either merge the records/remove the entries from the MTCH table before running the next match job
Based on data, i believe originally you must have a different value for ROWID_OBJECT for the 1st record. That must have merged to 12062082, so this ID is updated on the pending manual match records. Thats why you see a UPDATED_BY admin (probably automerge job run by admin)
There's a KB soon to be released on this. For now sharing the content of KB below.
HOW TO: Avoid invalid manual merge tasks in MDM
A quick workaround is creating a new MatchRuleSet specifically for manual/loose rules, but set it up as Auto rule. Run only Match job and not the merge job for this rule, then immediately flip the AUTOMERG_IND to 0 in the _MTCH table for this particular RuleID.
This way made sure the BMG is performed on these records and the Task daemon now assigns single TaskID to all the transitive matches
Hello Sathiesh. It seems that what you say is exactly what happens. Now the populated updated by and lud columns make sense.
Thanks
Just to add on the BMG process on Manual rules, In case you run the BMG process for loose rules it will potentially generate huge clusters of unrelated matched records. This will create a lot of work for the data steward to manually go through this clusters and resolve it. This is the reason why BMG designed to not be executed for manual rules.
