BEx Query Runtime Statistics
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:
More information: Analysis of Statistics Data.
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).
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.
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.
Example 1: A Web template containing two queries is executed. This is a step. Both queries pass through the OLAP processor, for example the Reading of Master Data event, which belongs to the handle type OLAP. The handle IDs are different: The first query is assigned the ID "1" and the second query is assigned the ID "2".
Example 2: A Web template is executed. This involves displaying various Web items. This time is recorded under the Web Reporting Item Rendering event, which belongs to the handle type W3_I. Each new Web item is recorded under a new handle ID.
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 object for the handle type OLAP is a query; the object for the handle type W3_I is a Web item; the object for the handle type W3_T is a Web template.
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 event OLAP: Read Data (event 3100), a data request is sent to the data manager; the system therefore records event 9000. For event 3100, however, the system only logs the time before and after the data manager is called.
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.
You can create new events using the table maintenance (transaction SM30).
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.Tip
Event 2525 counts the read accesses for the OLAP cache. You can therefore identify from this figure, or from the fact that this event does not exist, whether a query uses the OLAP cache.
- 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.
You can create new handle types using the table maintenance (transaction SM30).