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.
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.
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.
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
