Monitoring 

Tools

You use administration tools to monitor TREX and SES. For an overview of the available tools, see Tools.

Tasks

You can monitor the following properties of a TREX system:

●      TREX server availability

●      System status

●      TREX Configuration

●      TREX server load

●      TREX index distribution

●      Operating system resources

●      Memory usage

●      Document processing status

The documents to be processed by TREX go through various processing steps on the TREX servers (index server, queue server, and preprocessor). You can monitor these processing steps and intervene in processing in the event of any errors.

 

The following tasks must be completed:

Tasks	Additional Information
Check system status and resources, availability and configuration. ●      Are all TREX servers and instances in a distributed system available? ●      Are there indexes or queues that are not assigned to a server? ●      Do the queues contain documents that could not be indexed? ●      Have all TREX systems reported by e-mail? ●      How many documents are there in the delta index? ●      Are there any error messages? ●      Do the TREX trace files contain new entries?	●      You can monitor all essential TREX system properties centrally using the TREX alert server. ●      You can use CCMS (transaction RZ 20) to monitor the availability, system status, and configuration of the TREX servers see Monitoring of Parameters, Availability, Log Files, and Processes).
Check TREX server load and distribution of TREX indexes. ●      How is the memory usage changing on the hard disks? ●      Is disk space getting low? ●      Are there unexpected jumps in memory usage? ●      Is the TREX search unusually slow because the CPU load is too high? ●      Does indexing large quantities of documents take too long?	●      You can monitor the TREX load and index distribution using the Reorg function in the TREX admin tool and trigger a reorganization of the TREX system landscape if necessary. ●      To improve the load of the TREX servers and the distribution of the TREX indexes, it may be necessary to scale and distribute TREX (see Distributed TREX Systems (Multiple Host Installation).
Check the connection to applications using TREX. ●      Is the RFC connection between the ABAP system and the TREX system working? ●      Is the HTTP connection between the JAVA system and the TREX system working?	●      You use the TREX alert server to check the connection to the application using TREX.    ●      You can use the Landscape RFC window to monitor the RFC connection and restore it if necessary (see RFC Connection).
Monitor document processing and trigger it again if necessary.	●      TREX Admin Tool (Stand-Alone)  ® Queue Area ® Queue Content/Documents in Queue tab page ® Information on Processing Documents     ●      TREX Admin Tool in the SAP System ® Queue-Administration ® Get Entries ® Information on Processing Documents    ●      TREX Monitor in KM ® Display Queue Entries ® Information on Processing Documents

 

Checking Data Consistency

Data Consistency Between the Application Using TREX and TREX

TREX is used by numerous SAP applications to search in business objects (structured data) and document collection (unstructured data). On the TREX side, an index is created from the original application data to be able to apply the TREX functions to the data. To produce this, TREX indexes the original data and stores the index generated. TREX is therefore a secondary data store. Only the application can check the consistency of the two data stores, TREX cannot check it.

If you are using the BI Accelerator (BIA) through the Business Information Warehouse (BI), the data consistency check is performed between the BIA index on the TREX side and the associated InfoCube on the BI side. (See Checking a BI Accelerator Index (Transaction RSRV)) 

For more information about checking data consistencies, see the corresponding section of the Technical Operations Manual for SAP NetWeaver for the application using TREX (for example, Knowledge Management) 

Data Consistency Within TREX

Each existing TREX index is assigned to a specific index server. This assignment can sometimes be lost (error message: index non assigned). This data inconsistency means that the index is no longer available for the search. In a distributed TREX system landscape with more than one TREX installation and a large number of indexes, manual reassignment of the index to the correct index server is very difficult. The name server contains a list of the assignments and reassigns indexes and index servers automatically after a restart. You do not need to check the assignments manually.