Items in the JournalDelete table with a DeletionReason value of 4 and IDPartition value of -1 are not automatically removed

Problem

In some cases, connectivity to the Storage Queue or permissions to the Storage Queue will cause the inability for Enterprise Vault (EV) to archive items that are present in the EVStorageQueue. When this occurs, Enterprise Vault will create entries in the JournalDelete table for the corresponding items, with a DeletionReason value of 4(System ingest from queue failed), IdPartition of -1 and IndexCommitted = 0.

Once the issue with the EVStorageQueue is resolved, items will begin to be archived successfully. However, the old orphaned records (with DeletionReason 4) continue to remain in the JournalDelete table and manual intervention is the only option to clear them.

Error Message

The only way to identify the issue is when event 41022: Deleted items waiting to be deleted from indexes is seen.

However, this will only occur if the problem has reached the monitoring threshold that will trigger this event.

V-437-41022

Cause

This issue is caused by a stored procedure that does not take into consideration items placed into the JournalDelete table that have not been stored in the Saveset table.

Solution

Investigation still needs to be conducted as to what is causing items to be listed in the JournalDelete table with DeletionReason 4 and IdPartition -1.

The workaround to this issue is to clear the items from the JournalDelete table. Please contact Support to obtain the process to clear the table properly. The cause has been addressed in the currently supported releases.