Child pages
  • Enterprise Search Minimum Landscape with TREX
Skip to end of metadata
Go to start of metadata

Purpose

Details the recommended landscape for TREX based ESH implementation.  

Overview

A standard ESH landscape consists of a single TREX IndexServer implementation in Single Master or Master-Backup configurations only. Master-Slave arrangements are NOT supported. Multiple Masters in a distributed configuration or multiple IndexServers on a single host are NOT supported. This together with CRON scheduling only of the TREX memory-delta merge constitutes a basic minimum landscape for TREX supporting ESH.

ESH manages the creation of its indices in TREX and for delta updates utilises a TREX Memory-Delta index which you can see in TREXADMIN->Index Admin. Such indices are incompatible with Master –Slave arrangements. Thus this configuration cannot be utilised. Additionally the ESH indices must reside on the same master – otherwise there are problems in implementing the index joins. Therefore the only recommended configuration for TREX in the ESH scenario is a (single IndexServer) Master only or Master-Backup scaled vertically (please contact the H/W partner for scaling estimations).

TREX Master-Backup

For ESH we support TREX Single Master or Master-Backup Distributed Systems Only.

 

 

  • The TREX Hosts must be sufficiently sized to avoid memory and other problems in the system - see note 1266024.
  • They must each consist of a single IndexServer only (Multiple Masters are not permitted).
  • Master-Slave arrangements are never supported as this cannot support the memory delta requirement of ESH.
  • As a minimum we recommend TREX 7.10 Revision 58 or higher.

TREX CRON Scheduling

Post an Initial Indexing of a object ESH switches the index to delta mode within TREX. This means that realtime or periodic data is no longer indexed to the main index but to a delta index.

This new data needs to be merged daily with the main index. Failure to execute this can lead to severe performance problems in TREX and possible data loss. The best method to carry out the delta merges is via the CRON scheduler. For this to operate in TREX you create a new CRON process and schedule the python delta-merge script for a quieter period once a day. Additionally you need to disable the normal memwatch delta-merge from triggering merges prematurely. Such a system setup is detailed in note 2196916.  

TREX System Check for ESH

You can check that the system is correctly setup for ESH using the script attached to note 2227741 and we strongly recommend that it is executed in all systems at least once. To execute it: unpack the script to the /usr/sap/<sid>/trxnn/exe/python_support directory and from there run it as <sid>adm

>python check_esh.py

As well as checking for the above minimum setup it also checks indexing preloading (KBA 2115082), thread numbers, concurrent requests and other critical settings. If requested please follow up on any item highlighted by the check.

Note: You must have created the ESH indices in TREX firstly via the esh_cockpit (but not necessarily filled them) for all checks to be made.

 

Related Content

Related Documents

Defining the Roles of TREX Hosts 

Scheduling Delta Index Integration Using the Python Scheduler

Related SAP Notes/KBAs

SAP Note 1628169 Landscape restriction for TREX Master/Slave

SAP Note 2174128 TREX 700 / TREX 710 - settings for the delta indexes

SAP Note 2214184 - TREX 7.10: Installation of TREX for Enterprise Search with Multiple Master Hosts

SAP KBA 2196916 How to schedule cron job for merging delta indexes

SAP Note 1721505 Index property "Delta OFF" during initial indexing 

SAP Note 1266024 TREX Sizing for Embedded Search

SAP Note 2227741 TREX 710: check of the TREX settings for the Enterprise/embedded Search scenario
__________________________________________________________________________________________________________

  • No labels