Troubleshooting issues with TREX indexing

The purpose of this document is to highlight issues with TREX indexing and provide pointers to resolve these issues. Understand why TREX search gives inconsistent results and why the performance of real-time indexing is slow after continuous usage of TREX.

1.    A. Reorganization of change pointers is not considered while setting up the TREX.

The default setting is to keep change pointers for 360 days which is unnecessary.

The following screenshot shows the default setting in table ESH_EX_CP_REORG

Risks / Impact

• Unnecessary usage of disk space.
• High number of change pointers this could slow down the performance of the real-time indexing.

Steps to correct this issue

1. Execute the tcode esh_cockpit. Goto System settings->Control real time indexing

  2.   Press the Stop button and wait until the status changes to ‘On Hold’

  3.   Now you can change the time for which change pointers should be kept by executing report ESH_EX_FU_CPOINTER_REORG with the following options/parameters

o   Execute now

o   Un-flag both “Execute this step” options in areas “Remove Outdated Change Pointers” and “Remove Successfully Processed Data Content”. This is in  order to avoid unnecessary long execution time in foreground.

o   Set parameter “Keep entries for (days)” to 3 for example

o   Leave parameter “Keep data for (hours)” untouched

o   Flag parameter “Store changes”

o   Then execute the program with these settings

·         4.  Restart the realtime indexing that was stopped earlier.

Result

The obsolete change pointers from table ESH_EX_CPOINTER will stay for 3 days and will get cleaned automatically after 3 days. The cleanup job for obsolete change pointers will be triggered automatically by TREX.

1.     B. Data extraction for real-time indexing might not be correct due to insufficient authorizations

The system writes change pointers for every change that is relevant for indexing on TREX. The change pointers are processed by a real-time indexing report (ESH_EX_FU_DEMON) which is automatically scheduled as a job by the system as soon as change pointers are available.If no specific user is defined for the real-time indexing report the report is scheduled with the name of the user that created the first change pointer(s) before the real-time indexing process was scheduled by the system. As this could be any business user, this user might not have sufficient authorizations for the data extraction.

Risks / Impact

If the user which is used for the extraction has no sufficient authorizations, this could lead to missing

data on TREX as the data cannot be indexed properly

Steps to correct this issue

o   Create a user that has sufficient authorization for the data extraction.  You could also use the user which you are using for the initial indexing.

o   Execute the report ESH_EX_SET_EXTRACTION_USER and provide the required details.

You can refer to the Note 1345160 – Users and roles for Enterprise Search data extraction

Result

TREX will always write the change pointers with the user that is set as extraction user. This will rule out the authorization issues while writing the change pointers.