Skip to Content

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

/wp-content/uploads/2013/07/table_screenshot_246702.png

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

/wp-content/uploads/2013/07/esh_cockpit_246703.png

  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

/wp-content/uploads/2013/07/changepointer_246740.png

·         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

/wp-content/uploads/2013/07/extractionuser_246773.png

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.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Aidan Hanet

    Hello,

    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) ?

    Thanks,

    Aidan

    (0) 
  2. 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

    Thanks

    Syed

    (0) 
  3. Anne Lubig

    Hello,

     

    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.

     

    Regards,

    Anne

    (0) 

Leave a Reply