About the Replicated Rows Shadow Values Delete Utility

To delete replicated rows and shadow values that no longer need to be retained, use the Replicated Rows Shadow Values Delete Utility.

Use of the utility

Caution:

The use of this utility requires in-depth knowledge of the application database, replication, and business rules. The deletions performed by this utility are PERMANENT and cannot be undone. Ensure that you perform all replication development and testing in a controlled pilot environment before you implement it in a production environment. In addition, because of the large number of records that can be involved, this utility can take considerable time to process records.

If you are uncomfortable using this utility or unwilling to assume responsibility for data loss, we strongly recommend that you contact Infor Professional Services for assistance.

When this utility is first launched, the Refresh and Process buttons are both disabled. Before you can use them, you must first provide information about the _mst tables and sites that have the records that need to be deleted.

Once that information has been provided, you can use the Refresh button and the other fields to retrieve and then to filter out unwanted records and find the exact records you want to delete.

When you have filtered to and selected the exact records to delete, you then click Process, which fires a background task in the TaskMan service. If there is a large number of records to delete, the sysem, by default, processes them in batches of 10,000.

During this processing, not only replication records from the specified ReplicatedRows3_mst table are deleted, but also records from these tables:

ShadowValues
IONMessagingErrors
COR_OUTBOX_ENTRY

When to use this utility

This utility can be useful in these kinds of situations:

(Most commonly:) When cleaning up replication records for outbound Data Lake sites that have no corresponding active Infor OS Data Lake data flows.
When active replication rules include sites that are no longer applicable. This can occur, commonly, when on-boarding a customer to the Multi-Tenant Cloud.

It can be difficult to know when you should use this utility. If you know or suspect that replication data is not being sent properly to Data Lake or ION, you can use the Replication Viewer form (which gives visibility to the ReplicatedRows3_mst and ShadowValues tables), to see if records are accumulating there.

You can also check the ION Messaging Errors form, which shows messages caused by failures during replication using the IMS service, which is used by Data Lake. If there are errors showing on that form, it can mean that there are problem records in the ReplicatedRows3_mst table.

When a problem leads to stranded rows, for example, the replication rule no longer exists, or the logical id is no longer valid, the only way to fix that is to remove those rows from the table. So, if this is the problem, you can use this utility to selectively delete them, which should allow the remaining ones to go through.

It should be noted that not all such problems require a deletion of records. Deletion is required only for those records that shouldn’t be going over, or where the logical ID is wrong.

It can happen that you might accidentally initiate a large batch of BODs and then want to remove them. They don’t sit in the ReplicatedRows3_mst and ShadowValues tables for long; but if for some reason they are still there, you can use this utility to purge those records as well.