BI Query Runtime Statistics 

Purpose

Using the BI query runtime statistics, you can determine how much time the execution of certain user actions require in the front end and in the analytic engine. The system records the performance-critical parts of the processing (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).

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

Front End and Calculation Layer of the Analytic Engine

Description	Examples
This area includes the front end and OLAP including BI Integrated Planning (Front End/Calculation Layer). There is a large number of various events that 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 BI Integrated Planning: Writing of delta records, saving of data, execution of a planning function

Aggregation Layer of the Analytic Engine

Description	Examples
This area includes the data manager (Aggregation Layer). There is a small number of various events that 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:

For more information, see Analysis of Statistics Data.

Implementation Considerations

In the maintenance for statistics properties, you can specify for each object for which statistics data is to be recorded (query, workbook, Web template), whether and at which granularity you want to record the statistics data. You can also switch the statistics on or off for all queries of an InfoProvider. (See Maintenance of Statistics Properties).

Integration

Some BI accelerator tests in the analysis and repair environment work with statistics data (see Checking SAP NetWeaver BI Accelerator Indexes (Transaction RSRV), tests: Propose Delta Index for Indexes, Compare Size of Fact Tables with Fact Index). As a prerequisite, the statistics have to be switched on for the relevant InfoProvider.

Features

The following figure provides an overview of the process for a runtime reading with BI query runtime statistics:

The runtime reading starts with the first user action (for example, with the initial execution of a Web template) 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 within 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, that is, with the same handle type, are executed for various objects within a step, the system differentiates between them using the 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 area of the front end and calculation layers of the analytic engine (FE/Calculation Layer), the accumulated times of all events of 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 engine 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.

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, if required. 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 in the table RSDDSTATHANDLTP.

You can create new handle types using the table maintenance (transaction SM30).