Skip to Content
Author's profile photo Former Member

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.


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



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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member


      Thanks for this, it's interesting.

      Concerning the section B. => execute real time indexing under specific user.

      We are using this for the moment but run into a subsequent authorization issue; the business users who trigger the indexation are not allowed to do so -- the reason is that they do not have the authorization to schedule jobs under another username than their own.

      Is there a solution to this (except to permit the users to run jobs under another user name) ?



      Author's profile photo Syed Baddar Abbas Rizvi
      Syed Baddar Abbas Rizvi

      Hi Haresh

      Thanks for useful Article. Just have one quick question

      any idea about impact of deleting the Change Pointers ? As I understand that that all the information store in the Change Pointers is cumulative basis and previous pointers become useless ? Please correct me if I am wrong



      Author's profile photo Anne Lubig
      Anne Lubig



      we are focussing a problem with the job esh_fu_demon*. Nowadays it is executed every few seconds in our CRM system and triggers an error in ERP. but the job ist not relevant for ERP. How can we stop the job? And could you explain where it is planned, so what is the reason that this job is scheduled.