Removing entries from the index

You can remove certain object types, or objects that meet other criteria such as dates, from the index.

You can execute a DQL query to get object IDs of the documents that you wish to delete from the index. Save the list of object IDs in a text file.

1. Navigate to xplore_home/dsearch/xhive/admin.
2. Open deletedocs.properties in a text editor.
3. Make sure that the host and port values correspond to your environment.
4. Set the value of dss_domain to the xPlore domain from which you wish to delete indexed documents.

  NOTE : dss_domain:<Repo-Name>

5. Change the value of the key file_contains_id_to_delete to the path to your object IDs. Alternatively, you can list the object IDs, separated by commas, as the value of the key ids_to_delete.

6. On Windows, run deleteDocs.bat; on Linux, run deleteDocs.sh.

The deletedocs utility records activity in a log in xplore_home/dsearch/xhive/admin/logs/deleteDocs.log

If you already know the object ID and only have a few objects to delete, you can either create a simple ids.txt file with that single entry, or you can put that object ID in the deletedocs.properties under the ids_to_delete key. This key is commented out by default, so just remove the # and put in the object id:

ids_to_delete=090071eb80bf4c60

However, if the document has been deleted from the repository, it should automatically be removed from the index. It doesn’t always happen immediately, especially if there’s a large amount of items in the queue.

Where possible, verify above solution via test environment prior to applying to production.

Another possibility is that the event for dm_destroy has been removed. Using DA, run the following DQL:

select * from dmi_registry where user_name like 'dm_fulltext_index_use%'

You should see a dm_destroy for type dm_sysobject by default.

If you are only selecting indexing for custom type you should have a destroy listed for it.

2601164d80002102 dm_fulltext_index_user 0301164d8000016e dm_readonlysave 0 0 1 0 0000000000000000 1 0
2601164d80000501 dm_fulltext_index_user 0301164d80000101 dm_destroy 0 0 0 0 0000000000000000 1 0
2601164d80000502 dm_fulltext_index_user 0301164d80000101 dm_saveasnew 0 0 0 0 0000000000000000 1 0
2601164d80000503 dm_fulltext_index_user 0301164d80000104 dm_save 0 0 0 0 0000000000000000 1 0
2601164d80000504 dm_fulltext_index_user 0301164d80000104 dm_destroy 0 0 0 0 0000000000000000 1 0
2601164d80000505 dm_fulltext_index_user 0301164d80000105 dm_save 0 0 0 0 0000000000000000 1 0
2601164d80000506 dm_fulltext_index_user 0301164d80000105 dm_readonlysave 0 0 0 0 0000000000000000 1 0
2601164d80000507 dm_fulltext_index_user 0301164d80000105 dm_checkin 0 0 0 0 0000000000000000 1 0
2601164d80000508 dm_fulltext_index_user 0301164d80000105 dm_destroy 0 0 0 0 0000000000000000 1 0
2601164d80000509 dm_fulltext_index_user 0301164d80000105 dm_move_content 0 0 0 0 0000000000000000 1 0

The 03 ids are for the dm_type objects that correspond with the event. If there are no dm_destroy events, it may explain why the object hasn’t been removed from the index.

NOTE

If you either run the ftintegrity utility on the xPlore server or run the dm_FTStateOfIndex job you will find they generate a list of objectIds which are only in the index and not in the repository.

we can find the list of the report  :/home/dmadmin/dctm65sp2/dba/log/00021e3c/sysadmin/FTStateOfIndexDoc.txt
ID : /home/dmadmin/dctm65sp2/dba/log/00021e3c/sysadmin/ObjectId-indexOnly.txt