Expected Event Monitor program to query table instead of DB view /saptrx/v_expe_a

[Former Member]

Hi All,

In the Expected Event monitor program( /SAPTRX/EE_MONITOR_PACK ) we see that method /saptrx/cl_eh_ee_monitor_cntrl~GET_OVERDUE_EXPEVS queries a Database view /saptrx/v_expe_a to get a list of all events to be processed for marking 'overdue'.

The above mentioned db view is an aggregation of two tables /SAPTRX/EH_HDR and /SAPTRX/EH_EXPEV. There are two secondary indexes created by sap in table /SAPTRX/EH_EXPEV. The select query in the above mentioned class/method also has the same columns in the 'where' clause. However, the indexes wont be used since the code is querying directly on DB View and not on the native db tables.

If there are huge no. of records in both these tables, the necessity of using the indexes becomes crucial.

Does SAP provide an OSS note which changes this code to query the tables instead of querying the DB View to make use of the already created secondary Indexes.

Appreciate a prompt response.

Thanks,

Tirth

[former_member190756]

Hello Tirth,

the projects i know that had long runtimes here needed to tune DB optimizer statistics. So i think you should contact your DB admin or create a ticket to get help here.

Best regards,

Steffen

[Former Member]

Thanks Steffen for the reply.

Do we have any solution at an application level rather than going for DB optimizer. We want to do everything that can be done at application level before going to the infra team for DB optimizing.

Thanks,

Tirth

[former_member190756]

Hello Tirth,

on application level you cannot do anything here. The statement needs to select all overdue EE.

And as it is a rather simple select statement you can only tune the DB optimizer that it uses the indices taht are defined for the tables.

Best regards,

Steffen

[kevin_wilson2]

Steffen,

I haven't looked but what fields out of EH_HDR are used in the view select? We also experience performance problems with this program and maybe there needs to be a version 2 of the program that works better? Maybe run EE_OVERDUE_PACK in a continuous loop until all messages are done, thus breaking the select up in to smaller chunks.

[former_member190756]

Hello Kevin,

we are discussing options to allow handling bigger amounts of data with the EE Monitor e.g. by paralellization. But here is the problem that an existing database index is not used by the DB. We had this before and only an DB Optimizer tuning and statistic update helped. So doing the select more often would not help here but even make it worser.

Best regards,

Steffen