Inicio del área de contenido

Documentación de funciónOptimizing Performance Localizar documento en árbol de navegación

Use

When you execute a report, the system reads the transaction data records and summarizes them so that the user can navigate as he or she wishes through the free characteristics selected in the report definition. Further summarizations over the free characteristics take place during the terminal session, in order to build up the lists. This data is contained in the main memory. This can create a large volume of data and cause long response times. In order to read 100,000 records of a length of 500 bytes from the hard-drive, the system typically requires about three minutes. The quantity of data is often much larger than this. This means that, in many cases, executing reports online takes too long. The following section describes a number of possibilities for obtaining optimal response times in reporting.

Executing the Report Online

To achieve a reasonable response time when calling up a report which reads data from the transaction database, the amount of data to be read should be as small as possible. As a rule, it makes sense to execute reports of up to 20,000 records online. With special tuning measures, this figure can be higher, for example when the database buffer is enlarged and access to the hard drive is no longer required. You can also make improvements by creating special indices. The details of the tuning measures are dependent on the database system and the operating system.

Executing the Report in the Background and Saving Data

You can execute a report in the background and save the data contained in the main memory. This data is then known as saved data.

This method has the advantage that the end user does not have to wait for the transaction data to be read. The report can be scheduled in the background and the end user automatically receives the data from the most recently saved data. The saved data is also in exactly the level of detail which the end user requires. A report with saved data can be called up much more quickly than a report which is executed online, since little demand is placed on the database server.

The disadvantage of this method is that you must create a variant for each variable combination. This can be troublesome if a large number of different variable combinations are required. However, these variants can be summarized in one variant group and executed together in the background.

It is also important to realize that a report with saved data might not contain the most up-to-date data in the R/3 system. One thing is certain, however: with larger and more complex reports, saved data is a useful means of improving response times.

Avoiding Characteristic Hierarchies

The R/3 system allows you to arrange characteristic values hierarchically in order to show the contextual dependencies which exist in the system. Within the system, you do this by maintaining a separate table, which you need to access in addition to the actual table of characteristics. These extra database accesses can have a negative effect on report performance. You must therefore consider whether or not the benefits of characteristic hierarchies outweigh the loss of performance.

Summarization Levels

You can reduce the quantity of data to be read (and, therefore, the response time of a report) by holding the dataset in a summarized form. These summarized datasets are called summarization levels. You can determine both the number of levels required and the respective degree of detail.

This process has the advantage that the data which is read from the summarization levels can be called up quickly. Also, the data is always up-to-date compared to the saved data. The data is always updated at the same time as the aspect transaction database. A disadvantage of this process is that the greater the number of summarization levels, the slower the data transfer will be.

The use of summarization levels makes sense if the data is required by several reports.

Since not every summarization level can produce an improvement in response time compared to a report executed online, there are guidelines for defining summarization levels.

Using the Report/Report Interface

With the report/report interface you can connect several individual reports, each with a limited number of characteristics, to one another like building blocks in order to be able to navigate from highly aggregated objects into detail, or to other types of objects. To achieve optimal response times, you start with a highly summarized report. Only a small number of free characteristics should be included in this report. Using the report/report interface, you can call up (connected) reports, which contain additional characteristics with which the objects are described in more detail. These connected reports normally have good response times, as only a small and very specific amount of data must be selected.

Nota

In many cases, these processes are not mutually exclusive. A better result is often attained with a combination of the methods, for example:

 

See also:

Freezing Report Data in the Background Using Variants

Summarization levels

Overview: Report/Report Interface

 

 

Fin del área de contenido