BEx Query Runtime Statistics

Purpose

Using the BEx query runtime statistics, you can determine how much time the execution of certain user actions take in the front end and in the analytic manager. The system records performance-intensive processing steps (known as statistics events). It calculates the net times by calculating the runtime of an event using the difference between the start and end times (minus the times for other events called from within the event).

BEx query runtime statistics incorporate the following areas, which clearly differ with relation to event processing:

Front End and Calculation Layer of the Analytic Manager

Description Examples

This area includes the front end and OLAP including BW Integrated Planning (Front End/Calculation Layer).

Many events are processed serially.

Front end: Display of Web items, building of entire page, data provider and data area provider command processing

OLAP: Generation of queries, creation of cache entries, quantity conversion

BW Integrated Planning: Writing of delta records, saving of data, execution of a planning function

Aggregation Layer in the Analytic Manager

Description Examples

This area includes the data manager (Aggregation Layer).

A small number of various events are processed in parallel.

MultiProviders, aggregate splits, database access times (particularly access to E and F tables), RFC times

The statistics data is stored in various tables.

To analyze the statistics data, you have the following options:

Implementation Considerations

In the transaction for maintaining statistics properties, you can specify the required granularity for each object that you want to record statistical data for. You can also activate and deactivate the statistics for all queries belonging to an InfoProvider (see Maintenance of Statistics Properties).

Integration

Some BW accelerator tests in the analysis and repair environment work with statistical data (see Tests for BWA Indexes in Transaction RSRV tests: Propose Delta Index for Indexes, Compare Size of Fact Tables with Fact Index). The statistics must have been activated for the relevant InfoProviders.

Features

The graphic below provides an overview of the process for a runtime reading with BEx query runtime statistics:

The runtime reading starts with the first user action (with the initial execution of a Web template for example) and finishes when the session is ended by the user (log out). All times for this session are saved under the same SESSIONUID.

This can involve numerous user actions (such as navigation steps, updating of Web template, planning). Each user action is defined as a step and generates a new STEPUID if it contains events relevant for the statistics. The times for the event are summarized under this UID.

Events in a step are assigned to the relevant context (such as Front End, OLAP, Planning). The context is specified by the handle type. If events in the same context, i.e. with the same handle type, are executed for various objects in a step, the system differentiates between them using different handle IDs.

A handle consists of the tuple from the handle type and the handle ID. A handle has only one object for which events are recorded. The object type is attached to the handle type.

The name of the object is also saved.

If an event is executed multiply in the same context (that is, during the same session, in the same step, and with the same handle), the system cumulates the times for the event. For each event, it calculates the net time by subtracting from the runtime the times for other events called from within the event, if applicable.

In the front end and the calculation layer in the analytic manager (FE/Calculation Layer), the accumulated times of all events in a step can therefore be less than or equal to the overall runtime of the step.

This does not apply in the area of the aggregation layer of the analytic manager since multiple processes, and thus multiple events, are executed in parallel.

When a request is sent to the data manager in the context of a query execution from the OLAP area, the system records the event Data Manager (event 9000) for the handle type OLAP. It then records the exact times and data separately in the data manager statistics. The front end/calculation layer and aggregation layer data are then linked by the key from STEPUID and the handle (handle type, handle ID).

Events and Handles

Events and corresponding short descriptions for them are in the table RSDDSTATEVENTS.

Statistics events have two forms: pure counter events and time events.

  • For pure counter events, the indicator is selected in the Count Only column. The system does not record time, but cumulates an integer value for this event.
  • If the event is not a pure counter event, the system always records a time. It can also write a counter. What the counter reveals in some cases results from the Description of the event.

The Start-End column has just one technical meaning in the way data is recorded.

Handle types and corresponding short descriptions for them are stored in table RSDDSTATHANDLTP.