How to BW_Statistics

SAP (SAP AG and SAP America, Inc.) assumes no responsibility for errors or omissions in these materials.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

%:�6WDWLVWLFV�ASAP FOR BW ACCELERATOR

BUSINESS INFORMATION WAREHOUSE

%:�6WDWLVWLFV�±�$�7RRO�IRU�$QDO\]LQJ�DQG�2SWLPL]LQJ�WKH�%XVLQHVV�,QIRUPDWLRQ�

:DUHKRXVH�'RFXPHQW�9HUVLRQ��

TECHNICAL CONTENT - BW STATISTICS 2

1998 SAP AG AND SAP AMERICA, INC.

Table of Contents

1 INTRODUCTION ...........................................................................................................................2

1.1 APPLICATIONS OF THE BW STATISTICS – AN OVERVIEW ............................................................ 2

2 ARCHITECTURE OVERVIEW ......................................................................................................3

2.1 BW STATISTICS INFOCUBE....................................................................................................... 4 2.2 FIXED VALUES FOR CHARACTERISTICS OF THE INFOCUBE .......................................................... 6

3 ANALYZING AND OPTIMIZING THE BUSINESS INFORMATION WAREHOUSE ....................9

3.1 OVERVIEW ............................................................................................................................... 9 3.2 OLAP SERVER....................................................................................................................... 10

3.2.1 Using the Business Information Warehouse (OLAP) .................................................... 10 3.2.2 Capacity Utilization of the Business Information Warehouse – Historical View ............ 12 3.2.3 Runtimes for Queries .................................................................................................... 13 3.2.4 Classifying Usage according to Users .......................................................................... 14

3.3 AGGREGATES......................................................................................................................... 15 3.4 WAREHOUSE MANAGEMENT ................................................................................................... 16 3.5 VALUATING INFOCUBES (USAGE VS. WORK)............................................................................ 17

4 SELECTING AGGREGATES......................................................................................................18

4.1 PROCEDURE FOR SELECTING AGGREGATES ............................................................................ 18 4.2 CREATING AGGREGATES MANUALLY ....................................................................................... 18 4.3 CREATING AGGREGATES AUTOMATICALLY (RELEASE 1.2B) ..................................................... 20

5 LOADING DATA..........................................................................................................................26

5.1 DELIVERED PROGRAM (RELEASE 1.2B) ................................................................................... 26

6 INSTALLING BW STATISTICS ..................................................................................................27

7 APPENDIX...................................................................................................................................28

7.1 ANTICIPATED DATA VOLUME ................................................................................................... 28



1 Introduction

Installing a Data Warehouse presents the administrator with challenges of a constantly changing nature. Even in a productive system, in which no new InfoCubes are created, new data, for example, is always being loaded. This results in an increase in the quantity of data, or in a change to its structure. In addition to this, there are recreated or ad-hoc queries, which change the way that accessing data is seen as a whole. This not only influences the load times, but also the execution times for queries. On the other hand, it is a good idea to have an optimum work in order to minimize the response time of the Data Warehouse. Just from these few points, it is already clear that an overview of the processes in the Business Information Warehouse is not only advantageous but also necessary, and is indeed far above the detailed view of a set of database statistics or the CCMS, for example.

For the Business Information Warehouse, data is, therefore, made available on the level of InfoCubes, queries, InfoSources and aggregates under the term BW Statistics.

1.1 Applications of the BW Statistics – an Overview

All the options in the Business Information Warehouse can be used for evaluating. Since data can be saved from the area of the OLAP processor and Warehouse Management, the applications extend over a wide range of areas, that can be approximately subdivided as follows.

½ Information

á Which InfoCubes, InfoObjects, InfoSources, source systems, queries, aggregates, and so on, are currently being used in the system? How frequently? Which datasets are being moved? Who is currently using the system?

á Are there queries, whose run time is over the allowed fast value for online processing? Are tasks, such as batch printing or loading data, executed in times of less work?

á How does the data flow through the Data Warehouse, from where and where to?

½ Documentation

á Which departments or users have used up which resources over a particular time period, for example, in the last quarter, year?

á How has the work for the database, the OLAP processor, or the frontend changed in the past? Which requirements can be expected in the future?

½ Optimization

á From time to time, jobs should be scheduled that run for a long time. An example of this is batch printing reports. Another example is loading large datasets or rolling up data in aggregates. When is the most convenient time to schedule this?, meaning when is the basic load at its lowest? Will the planning be checked later: Was the time really convenient or has it become so due to overlapping for an unreasonably high work.

á Using which aggregates can the run time for queries be reduced? How does the load time, including rolling up data in aggregates, increase by doing this?

á Which aggregates, InfoCubes, InfoObjects or InfoSources are no longer being used and can, therefore, be deleted? Can, or must, the periodic loading of InfoCubes be changed?

á To what extent do queries put a load on the database, the OLAP server and the frontend? Can the work be reduced by changing the query design?

á How intensively or little is an InfoCube used in relation to the work of loading data?



These and other questions can be answered for the Business Information Warehouse. The infrastructure implemented and data made available for this are reviewed as follows under the term BW STATISTICS. You will be subsequently shown how to select suitable aggregates with this data.

Additional details can be found in the supplied documentation.

2 Architecture Overview The Business Information Warehouse is itself used for storing and administering the data of the BW STATISTICS (Illustration 1).

When executing queries, different data for the OLAP server and the database is entered, and is stored temporarily at the end of each navigation step. This also occurs when using the ODBO (OLE DB for OLAP) interface. Additional data is collected when filling or rolling up aggregates, and after loading data in the Warehouse Management.

BW StatisticsBW server(internal)

Queriesor ODBOQueries

or ODBO

aggregatesaggregates

warehousemanagementwarehouse

management

buffer

BW Statisticsinfocube

analysis by queries(in workbooks)

suggest aggregatessuggest aggregates

Accounting

BW framework

automaticanalysis

buffer

buffer

Info-SourceInfo-

Source

turn on/offlogging for each infoCube

smaller cube(s)

Updaterules

Updaterules

Illustration 1: Overview of the technical implementation for the BW STATISTICS

Although it only takes a negligible amount of time to enter and save the BW STATISTICS data, the dataset for larger installations can still become quite large (see illustration 7.1). Both entering and saving data can, therefore, be separately deactivated for each InfoCube as well as for OLAP and Warehouse Management. You get to the selection screen, shown in illustration 2, in the Administrator Workbench via the menu ‘Goto’ and, once there, ‘BW Statistics for InfoCubes’.



Illustration 2: (De-) Activating the Data Entry for BW STATISTICS

The temporarily stored data is then made available via an InfoSource1. Going from this InfoSource, all tools of the Business Information Warehouse, such as the update rules, for example, can then be used. The data in the BW STATISTICS can be used in the delivered InfoCube 0BWTC_C01, in which data is grouped together from all areas. For aggregates to be automatically suggested, however, you require InfoCube 0BWTC_C01 (see sections 4.1 and 4.3).

BW STATISTICS data in the database tables, that is no longer required (buffers), can be deleted. By doing this, not only is the occupied memory area reduced, but the data selection by the extractor is also accelerated. Via the symbol ‘Delete data’ in Illustration 2, you get to a dialog, in which the time interval (day and time respectively) can be entered, for which data should be deleted.

2.1 BW Statistics InfoCube

In the framework of the technical content, InfoCube 0BWTC_C01 is delivered, that is made up of the delivered characteristics in Table 1 and key figures in Table 2 (status 1.2B):

Characteristics

1 Loading data using an extractor takes place in a later BW release.

Can be turned on/off for OLAP/WHM

‘old’ data in database tables (buffers) can be deleted

New settings can be stored permanently

access via Goto %:�Statistics for Infocubes



Technical Name Description

General

0TCTSYSID Description of the BW System, in which data was entered

0TCTUSERNM Name of a user who carried out the action

0TCTIFCUBE Name of an InfoCube

OLAP – Processor

0TCTQUERID Unique description for a query

0TCTAGGREG Name of an aggregate, that was used when executing a query or was rolled up for the data

0TCTSESUID Unique value, that compounds data records in fact tables for each frontend session

0TCTNAVUID Unique value, that compounds data records in fact tables for each navigation step

0TCTSTAUID Unique value, that compounds data records in fact tables for each description of a select

0TCTNAVSTEP Counter for navigation steps during a frontend session

0TCTRTIME Type of time in 0TCTTIME, fixed values see Table 3

0TCTRRECO Type of number in 0TCTRECO, fixed values see Table 4

0TCTOLAPRD Read mode of the OLAP processor: Recently required data is either subsequently read at each navigation step, or all data is read immediately when starting the query.

0TCTOLAPACT Origin of the data, fixed values see Table 5

0TCTDBSELTP Type of read data, fixed values see Table 6

0TCTRTIMEC The entire execution time for a navigation step is listed to the power of ten (1,10,100,... seconds)

OLAP-Processor, Description of the Data Selection

0TCTIOBJNM InfoObject (characteristics, over which it was not aggregated, and key figures that were displayed).

0TCTIOBJTP Navigation attribute for 0TCTIOBJNM; enters the type of InfoObject (key figure, characteristic, ...)

0TCTAGGRST Aggregation level for the characteristic in 0TCTIOBJNM (summarized, fixed value, hierarchy level, not summarized)

0TCTIOBJVAL Fixed value for the InfoObject in 0TCTIOBJNM, if 0TCTAGGRST is correspondingly set.

0TCTHIEID Name of the used hierarchy for the InfoObject 0TCTIOBJNM, if 0TCTAGGRST is correspondingly set

0TCTHIELEV Hierarchy level

Warehouse Management

0TCTISOURC InfoSource, with which the data was loaded

0TCTSOURSYS Source system, from which the data was loaded



0TCTREQSID Request for the loaded data

0TCTIPAKID Package ID of the loaded data

0TCTWHMMAN Distinction whether data was posted manually or automatically

0TCTWHMACT Transaction type in Warehouse Management, fixed values see Table 8

0TCTWHMTFM Transfer mode, fixed values see Table 7

General

0CALDAY Date on which an action was started

0TIME Time at which an action was started (only hours are used)

Table 1: Characteristics for the BW Statistics InfoCube

Key Figures

Technical Name Description

OLAP, Aggregate, ODBO

0TCTTIME Time, restriction with characteristic 0TCTRTIME (see Table 3)

0TCTRECO Number, restriction with characteristic 0TCTRRECO (see Table 4)

0TCTSESCTR Number of frontend sessions

0TCTNAVCTR Number of navigations

0TCTDBSCTR Number of database selects

Warehouse Management

0TCTMNRECO Number of data records procedure in Warehouse Management, restriction with characteristic 0TCTWHMACT (see Table 8)

0TCTMTIME Duration of a procedure in Warehouse Management, restriction with characteristic 0TCTWHMACT (see Table 8)

General

0TCTSDATE Date on which an action was started

0TCTSTIMEK Time at which an action was started (to the second)

Table 2: Key Figures for the BW Statistics InfoCube

2.2 Fixed Values for Characteristics of the InfoCube

Fixed Values for Characteristic 0TCTRTIME ‘Type of Time (OLAP),

000 Not assigned

001 Initializing OLAP processor

002 OLAP processor

003 Database, read on the

004 Frontend



005 Entry time in the variables screen

006 Time since the last navigation step in the frontend

007 Reading texts

008 Authorization check

009 Unassigned time

010 ODBO, general

011 ODBO: Initialization

012 ODBO: Preparing the axis

013 ODBO: Data request

014 ODBO: Preparing the data records

015 ODBO: Converting into flat table form

016 Aggregates: Time for reading when rolling up data

017 Aggregate: Time for inserting when rolling up data

018 Total time (OLAP)

Table 3: Fixed Values for Characteristic 0TCTRTIME for Restricting Key Figure 0TCTTIME

Fixed Values for Characteristic 0TCTRRECO ‘Type of Number (OLAP),

000 Unassigned

001 Selected on the database

002 Transferred from the database

003 Read cycles (fetch) OLAP processor

004 Read texts

005 Cells sent to the frontend

006 Formatting sent to the frontend

007 ODBO: External call up of the interface

008 ODBO: Size of the internal buffer

009 Records in the aggregate

010 Mean summarization of the records in the aggregate

011 Total number (OLAP)

Table 4: Fixed Values for Characteristic 0TCTRRECO for Restricting Key Figure 0TCTRECO

Fixed Values for Characteristic 0TCTOLAPACT ‘Origin of the Data,

000 No OLAP procedure

001 Execute query / navigation step

002 Batch printing

003 Rolling up an aggregate

004 Warehouse Management



005 ODBO interface (OLE DB for OLAP)

Table 5: Fixed Values for Characteristic 0TCTOLAPACT

Fixed values for Characteristic 0TCTDBSELTP ‘Type of read data,

000 Unassigned

001 Cumulative value

002 Non-cumulative value, reference points

003 Non-cumulative value, delta

Table 6: Fixed Values for Characteristic 0TCTDBSELTP

Fixed Values for Characteristic 0TCTWHMTFM ‘Transfer mode,

000 Unassigned

001 Data was transferred by IDOC

002 Data was transferred by TRFC

Table 7: Fixed Values for Characteristic 0TCTWHMTFM

Fixed Values for Characteristic 0TCTWHMACT ‘Type of process (WHM),

010 Runtime in the source system

020 Conversion time for communication structure

030 Time for saving data in the ODS

039 Time for reading from the ODS

050 Conversion time for update rules

060 Time for inserting in InfoCube

065 Time for changing the InfoCube

200 Runtime delete InfoCube content

210 Runtime delete request from the InfoCube

220 Runtime reserve posting

300 Total time until saving the data in BW (ALE/ODS)

600 Runtime InfoCube restructure

900 Total runtime



Table 8: Fixed Values for Characteristic 0TCTWHMACT

3 Analyzing and Optimizing the Business Information Warehouse

3.1 Overview

Besides InfoCube 0BWTC_C01 and its InfoObjects, in the framework of the technical content, the workbook ‘BW STATISTICS‘ with queries and charts is also delivered.

Illustration 3 shows the page with the overview of the charts and queries (tables) grouped according to the subject areas aggregates, OLAP processor (OLAP) and Warehouse Management (WHM). Analyses that affect two areas are listed between the headers. Pushbuttons marked gray stand for queries (tables), and blue for charts. By using the pushbuttons, you can navigate directly to the query, or chart, respectively.

%XVLQHVV�,QIRUPDWLRQ�:DUHKRXVH�6WDWLVWLFV

OLAPAggregates WHM

Usage by InfoCubes

Usage by Queries

Usage by Runtime

Usage by Day of Year

Usage by Hour of Day

Usage by Users

Usage by Users in %

Queries: Averages

Usage OLAP

Performance OLAP

Usage Aggr. (Query)Roll-Up

Usage WHM

Cube OLAP/WHM

Load by Day of Year

Load by Hour of Day

Transfer Method

Usage InfoObjects

Usage Hierarchies

Usage InfoCubes

Load by InfoSource

Load by InfoCubeInfoObjects / Nav.

Illustration 3: Overview of the Diagrams and Tables for the Workbook of the BW Statistics

In the following, with the aid of certain examples, some queries and diagrams from the three areas are presented and their application described.



The values used in the following tables and graphics, such as Time and data records do not correspond to the requirements of a productive system. For demonstration purposes, specific situations have been adjusted to simplify and clarify the displayed analysis.

The diagrams of the BW STATISTICS use a sequence of colors, which are sometimes referred to in the text for explanation. Please also refer to this document in your word processing if you currently have it available in printed form without colors.

3.2 OLAP Server

3.2.1 Using the Business Information Warehouse (OLAP)

You get an overview of the usage and performance of the Business Information Warehouse, for example, from the chart ‘Usage by InfoCubes’ in Illustration 4, in which the use of the Business Information Warehouse (OLAP) is presented classified according to InfoCubes. Several different analyses can be carried out with this chart, as is made clear from the following examples:

8VDJH�E\�,QIR&XEHV�

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

%:�6WDWLVWLN 2/$3&RXQFLO

%HQFKPDUN

7HVWFXEH�I�U%HVWlQGH

%HVWDQG�I�U.ODXV�XQG(ULFK

&66�&XEH &XEH��I�U6WRQH\

,QWHUQDWLRQDO

.HLQ�7H[WYHUI�JEDU

.RVWHQVWHOOHQ3UDWW�+ROGLQJ&XEH

,QIRFXEH��IRU

9HULILFDWLRQ

,QIRFXEH��I�U�3RUWLHUHU�

,QIRFXEH�� 7HVW�&XEHPLW

:lKUXQJHQ

run

tim

e in

sec

on

ds

0

500.000

1.000.000

1.500.000

2.000.000

2.500.000

3.000.000

3.500.000

nu

mb

er o

f re

cord

s

Zeit, Initialisierung OLAP-Prozessor Zeit, OLAP-Prozessor Zeit, Lesen auf der DatenbankZeit, Verarbeitung im Frontend Zeit, Berechtigungsprüfung Zeit, Lesen von StammdatenSätze, selektiert auf Datenbank Sätze, übertragen von Datenbank Zellen, übertragen an ExcelFormatierungen, übertragen an Excel Sätze, gelesene Stammdaten01.01.1998 01.01.1998 bis

01.01.2000 01.01.2000

Illustration 4: Example of an Analysis: Using BW classified according to InfoCubes



• On the one hand, it is apparent that three InfoCubes have been used especially frequently in the test system, and on the other hand that the other InfoCubes are rarely of much importance. Put in general terms – the graphical representation offers a quick overview of which InfoCubes have been frequently used (height of the stack represents total runtime, time in seconds on the left axis), or how great the number of data records was per InfoCube (lines, number of records on the right axis).

• Not only the horizontal bars of the times, but also the lines of the data records are made up of several parts, that, when all added together, give the total height. The total time is arrived at in Illustration 4 out of the following times: Initializing the OLAP processor when starting the query (red), processing using the OLAP processor (green), reading from the database (blue), processing in the frontend (yellow), authorization check (turquoise) and reading texts (white). Some special features stand out with this. For the first InfoCube (far left), the processing in the frontend (yellow) takes up the largest share. The cause of this was too small a memory on the PC, and, thus, frequent swapping. In addition, the times for initializing the OLAP processor (red) for all InfoCubes are disproportionately large, since the queries have been regenerated many times on the development system. These times are far less in the test and productive systems.

• The total number of data records is made up of the following articles, that are represented as lines: Records selected on the database, records transferred from the database to the application server, cells transferred to the frontend, formatting transferred to the frontend, and the number of texts that have been read. In general, the different lines should not deviate from one another very much, since then only a few records can be transferred, and even fewer displayed, compared to the records selected on the database. This is not the case with the first InfoCube (far left) in Illustration 4. Here, almost all of the selected records have also been transferred to the OLAP processor2. In such a case, drilldown should be used in the corresponding table in the workbook to find out which query (or queries) this produces, and whether or not these should be subject to a redesign.

• In addition, for each InfoCube, the total runtime of all queries can be compared to the total number of all the transferred data records. The total height of the horizontal bars indicates the total runtime, with the highest line respectively the total number of data records. For the three InfoCubes used the most, it shows that, with large total times, the amount of data that was transferred is also correspondingly large. However, some horizontal bars and lines show possible problems. While a lot of data is being transferred in a comparatively short time period for the second InfoCube (from the left), a large amount of time has accumulated for the last InfoCube (far right), although only a small amount of data has been transferred. This kind of result should be analyzed further by considering all the different times together.

2 However, the horizontal bar only firstly shows that the same number of records have been selected as have been transferred. An additional drilldown according to queries, however, shows that this is also true for the navigation step itself.



3.2.2 Capacity Utilization of the Business Information Warehouse – Historical View

As an example for historical analysis and planing, in illustration 5, the total times when executing all queries (red area) and the read records with them (blue horizontal bars) are broken down according to calendar days. Both the absolute values, as well as the relation of times to records changed greatly within the time period considered. What can be recognized clearly, for example, are the two Sundays (1.11., 8.11.) – no data is marked in due to the low level of usage.

8VDJH�E\�'D\�RI�<HDU�

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

��

tota

l ru

nti

me

in s

eco

nd

s

0

500000

1000000

1500000

2000000

2500000

reco

rds,

sel

ecte

d o

n d

atab

ase

Gesamtzeit Sätze gesamt01.01.99

Illustration 5: Example of an Analysis: Using BW classified according to date

If, in such a chart, the times show a clear increase in comparison to the number of records, this could, for example, be a note that the database statistics (not to be confused with the BW STATISTICS) are obsolete for certain InfoCubes (their tables to be more precise). By drilling down in the corresponding table in the BW STATISTICS workbook, you can determine the InfoCube(s) and then update the database statistics (in the Administrator Workbench, see documentation).



3.2.3 Runtimes for Queries

An important goal when operating the Business Information Warehouse is to keep the execution time as low as possible. For this, there is generally a subjective limit, from which a user sees a query as no longer suitable for online operation. With the analysis in Illustration 6, all queries are listed, whose mean processing time per navigation step is larger than the fast value (30 seconds here), that is set in the end node. By sorting according to runtime in seconds (rounded up to 1,2,3,...10,20,30,...100,200,300... seconds), the largest values appear at the top. In addition, all amounts, that have exceeded its respective share of the value limit, are selected (on the right hand side of the window displayed).

The values entered in the example are, however, made up – they are generated by debugging or batch printing very long lists.

BW System ID Time threshold in seconds:

Anwender 30

LaufzeitkategorieQuery

Zeitraum 01.10.1998 01.10.1998 bis 01.01.1999 01.01.1999

Laufzeitkategorie Query +lXILJNHLW��1DYLJDWLRQ� 0LWWOHUH�=HLW��JHVDPW��1DYLJDWLRQ� *HVDPW]HLW

�� /DXI]HLW�4XHU\ 1 1.258,7813 1.259

�� 1HXH�4XHU\ 1 288,2500 288

�� 1XW]XQJ�2/$3�MH�,QIR&XEH 1 270,5625 271

�� %DWFK3ULQWLQJ�*UDI�� 23 245,8371 5.654

�� 1 231,8125 232

�� $OOHV�LP�hEHUEOLFN 1 228,6875 229

�� (5,&+B68057 7 177,2366 1.241

�� 1HXH�4XHU\ 1 164,4375 164

�� 1XU�%HVWDQGVJU|�HQ 1 164,1250 164

�� 1XW]XQJ�2/$3 1 149,6094 150

�� QDWWHVW�YDULDEOH�MDKU 1 142,6250 143

�� /DXI]HLW�4XHU\ 1 131,9063 132

�� $OOHV�LP�hEHUEOLFN��.RSLH� 1 173,7188 174

�� 1 97,5469 98

�� WHVW 4 88,0547 352

�� 68BILOHWHUBLQLWLDO 1 81,5469 82

�� (LQ]HOSRVWHQ�$3 1 75,0000 75

�� /DXI]HLW�4XHU\ 2 71,6172 143

�� 48(5<B$11(77(� 1 71,2656 71

�� 1 59,1250 59

�� 2 56,6563 113

�� hEHUVLFKW 2 53,8906 108

�� /HVH45% 3 53,7031 161

�� $1'5(6B48(5< 5 53,0984 265

�� (5,&+B68057 5 48,8625 244

�� HLQIDFKHU�7HVW�I�U�9DULDEOHQ 1 48,0938 48

8VDJH�E\�5XQWLPH

Illustration 6: Runtimes for Queries



3.2.4 Classifying Usage according to Users

The BW STATISTICS can, however, not be brought into play for analyzing the current situation of the Business Information Warehouse. From the chart in Illustration 7, for example, you can determine which users have used which resources. Since hierarchies are allowed for InfoObject 0TCTUSERNM, corresponding queries can also be produced, in which a user hierarchy (departments) is analyzed. In addition, the output of the texts (names) in this example has been made anonymous.

8VDJH�E\�8VHUV

Query Runtime

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:HLWHUH

��ELV��

Records Selected on Database

;;;;;;;;

;;;;;;;;

;;;;;;;;;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

:HLWHUH

��ELV��

Refresh Chart

Overview

Illustration 7: Example of an Analysis: Classifying BW Usage according to Users (Names made Anonymous)



3.3 Aggregates

Aggregates should reduce the runtime of queries (see section 1.1). For this, it is also important to find out which aggregates have not been used frequently, or the other way round, for a long time. In Illustration 8, the frequency, as well as the date and time of the last usage for an aggregate when executing a query, is listed.

BW System IDInfoCubeAggregat

Aktualität der Daten 26.01.1999 16:00:14Zeitraum bis InfoCubes bis

Aggregat $Q]DKO�1DYLJDWLRQHQ /HW]WH�9HUZHQGXQJ��7DJ� /HW]WH�9HUZHQGXQJ��8KU]HLW�

67$7�� 83 22.01.1999 06:18:55

67$7�� 137 26.01.1999 08:19:07

67$7�� 1 26.01.1999 18:47:31

67$7�� 11 26.01.1999 05:07:07

67$7�� 10 25.01.1999 20:48:24

$JJU��EHU�.XQGH�XQG�0DWHULDO 1 25.01.1999 07:25:13

67$7�� 6 21.01.1999 21:58:20

67$7�� 5 14.01.1999 02:10:39

67$7�� 10 22.01.1999 17:57:12

1LFKW�]XJHRUGQHW 503 26.01.1999 08:31:59

Gesamtergebnis 767 26.01.1999 08:31:59

8VDJH�RI�$JJUHJDWHV��4XHULHV�

Overview

Illustration 8: Example of an Analysis: Using Aggregates when Executing Queries

To suggest new aggregates, the InfoObjects used per navigation step can also be analyzed. The automatic analysis and creation of aggregates in the Business Information Warehouse is described in section 4.3.



3.4 Warehouse Management

Parameters about the transport of data from the area of Warehouse Management (monitor) are also available in the framework of BW STATISTICS. The charts and tables, that are already mentioned for the OLAP server in section 3.2 – so long as there are equivalents – are also available for Warehouse Management.

Illustration 9, for example, shows a listed comparison of the transfer times and transfer quantity (in records) for the InfoSources of the system. For some InfoSources, the relationship of required time and transferred records is very bad. In a productive system, research on the causes for these InfoSources should be carried out. In this case, however, the cause had been easy to determine – debugging of transfer programs during development.

The time duration and number of data records for the different processes in Warehouse Management respectively, meaning, for example, for reading data in the source system using ODS up to saving in the InfoCube, are available in the InfoCube. In addition, the total duration, the start date and start time for the entire process (from the source system until into the InfoCube), is stored. By doing this, you can also compare, for example, the different load methods (IDOC, TRFC) (see Query in the Workbook).

/RDG�%\�,QIR6RXUFH��:+0�

0

500

1000

1500

2000

2500

3000

3500

.RVWHQVW��.RVWHQ

�/,6B��B6�� EHVWlQGH EHVWlQGH %HVWDQGNHGHOWDIRUWV

%HVWDQGNH,QLWLDOLVL

,QIRVRXUFH�I�U&66�&

(DV\ HULFWHVWVRXUFH /XW]�,QIR6RXUFH��

6WDQGDUG

tota

l lo

ad t

ime

in s

eco

nd

s

0

200

400

600

800

1000

1200

reco

rds

tran

sfer

ed

Sätze (Vorgang WHM) Zeit (Vorgang WHM)01.11.98 01.11.98 bis 01.01.99 01.01.99

Illustration 9: Example of an Analysis: Loading Data (Records and Time) classified according to InfoSources



3.5 Valuating InfoCubes (Usage vs. Work)

Illustration 10 can serve as an example for valuating InfoCubes. Here, an InfoCube is positively valuated if many more data records are read in total when executing queries than are loaded into the InfoCube. Expressed more concisely: Each data records loaded should be read several times. Correspondingly, the total time for the executed queries of an InfoCube should be clearly greater than the time required for loading.3 In Illustration 10, the relationship of the number of read records (OLAP) and the number of written records (WHM) is logarithmically applied, separately for each InfoCube (blue). In general, the more intensively an InfoCube is used, and the more positively it is valuated, the higher up the horizontal bars extend. Horizontal bars pointing downwards indicate a low usage of the InfoCube. The corresponding quotient for the times is shown respectively as a slightly narrower horizontal bar (red) in front of the blue bars. By the logarithmic application, the same size horizontal bars display the same relationships (factor 10) above as factor 0.1 below

5DWLR�2/$3��UHDG��:+0��ZULWH��HDFK�,QIR&XEH

0,0000

0,0000

0,0001

0,0010

0,0100

0,1000

1,0000

10,0000

100,0000

1000,0000

10000,0000

100000,0000

1000000,0000

%:�6WD

WLVWLN

.HLQ�7H[W�YHUI�J

EDU

6DOHV��0

DUNHWLQ

J

7HVW�$X

WRV

.RVWHQVWHOOHQ��JH

VSO

.RVWHQVWHOOHQ��$E

ZHL

&66�&

XEH�7HVW��%�'R

&XEH��I�

U�6WRQH\�,Q


EDU


EDU

)ODW�)LOH�&

XEH

LPVGDWXP

�/,6B�

�B6��

�B/,6B��B

6��

3HULRGLVFK

H�:HUNEHV

W

6'��9HUNDXIVE�

UR

6'��0

DWHULDO

6'��9HUWULHEVEH

DXIWPDUWLQ�

'DWHQ�EH

UQDPH��EHU�5


EDU

WHVWFXEH�RPBFFDB�

D�S

7HVWFXEH�20

BFFDB�

�GL

35$77�+

ROGLQJ�&XEH

385��&XEH�QXU�V��

40��5

HWDLO


EDU

7HVW�&XEH

�23$B&

�

7HVW�38

5��QXU�V�

�


EDU


EDU

YEDN�B

�

,06�'D

WHQ

rati

o r

ead

/wri

te r

eco

rds

0,0001

0,0010

0,0100

0,1000

1,0000

10,0000

100,0000

1000,0000

10000,0000

rati

o r

ead

/wri

te t

imes

Sätze OLAP/WHM Zeit OLAP/WHM01.01.1998 01.01.1998 bis 01.01.1999 01.01.1999

Illustration 10: Example of an Analysis: Valuating InfoCubes

If, for example, an InfoCube is, however, no longer – or rarely - used by users, but data is still loaded periodically, then the horizontal bar will always be beneath 1.0. In the chart displayed (Illustration 10), roughly a half of the InfoCubes have been created and data has initially been loaded. When drawing up the chart, however, no queries had yet been defined nor executed. In this case, values equal to zero are each set to one. The relationship is then exactly 1 / number of loaded data records.

3 The exception also confirms the rule here of course: A balance sheet query is possibly only carried out a few times, although a large amount of data has been loaded into the InfoCube in the past.



The ‘quality’ of an InfoCube can certainly still be determined in a completely different way. Additional criteria and charts are – if so desired – added to the workbook later.

4 Selecting Aggregates

4.1 Procedure for Selecting Aggregates

If no queries have yet been created for an InfoCube, you do not have any extensive information for the automatic selection of aggregates at your disposal4. Aggregates can, however, be created manually, as is described in the next section, since the business meaning of the InfoObjects, or InfoCubes and therefore also of the structure of the anticipated data, is a known fact. This also requires, however, a certain understanding of the technical implementation of the Data Warehouse.

Since aggregates are chiefly created to speed up the execution of queries, the selection of aggregates depends heavily on which queries are used how often and which ones require data. Therefore, as soon as the important queries (for the later productive operation) have already been already created, they can be analyzed (section 4.3). Then the suggestions can be optimized and the most important aggregates activated.

If queries have already been worked with, data from the BW statistics can be analyzed (section 4.3). ). These suggestions can also be subsequently optimized, and the most important aggregates activated.

From time to time, it also makes sense to do this in the productive operation to further optimize the choice of aggregates, especially if new queries have been created. By doing this, the aggregates, that have not been used at all (or not for a long while) also appear. These can then be deleted (or firstly deactivated) to release memory space, and to reduce rollup times.

4.2 Creating Aggregates Manually

Since release 1.2A, it has been possible to create and evaluate aggregates in the Business Information Warehouse. You can find more detailed information on this in the documentation for 1.2A under the section ‘Administrator Workbench’.

The selection and definition of aggregates, however, required a certain business-related knowledge of the anticipated data structure, as well as of how to store on the database.

You get to the aggregate maintenance from the Administrator Workbench via the symbol for aggregates or – if no aggregates have yet been created for an InfoCube – via the menu ‘Maintain aggregates’. The following example in Illustration 11 and Illustration 12 refers to InfoCube ‘0FIAP_C02’ in the InfoArea ‘Accounts Payable’. You can find detailed information on maintaining aggregates in the documentation and under F1 help5.

4 If you have not yet defined any queries, then no usable information exists yet in the OLAP server. The (business-orientated) meaning for the InfoObjects of an InfoCube and, derived from this, the anticipated structure of the data and queries can give information, but can itself only be used in a very restricted sense for objects of the Business Content. 5 The F1 help is completed and more detailed in release 1.2B.



Illustration 11: Maintaining Aggregates: Overview of the Aggregates for an InfoCube

In Illustration 11, several aggregates have been activated for the InfoCube. Three of them have been initially filled with data. The first aggregate ‘Account number’ has been changed again after it was activated and filled (status is yellow). This modified definition is saved, but the active version is still used with the old definition when executing queries. The third aggregate ‘Company code, all’ contains a total of 47 records and has been used twice previously when executing queries. All of the other aggregates have not been used previously. The difference in size between the aggregates and the InfoCube is quite small in these examples (values 1, 5 and 6).

Illustration 12 shows the components for the aggregate ‘Company code 3000’. For demonstration purposes, the various types of components are chosen here. The characteristic value ‘3000’ with the text ‘a company code’ has been chosen as a fixed value (aggregation level ‘F’) for the characteristic ‘Company Code’. Thus the aggregate only contains data for this one company code. Accordingly, only data is contained for level 2 of the hierarchy ‘FIRST’, validity until 31.12.9999 for the characteristic 0VENDOR ‘Account number of the vendor’. If, when it is executed, a query requires another company codes or another part of the hierarchy, or other characteristic values than 0VENDOR, this aggregate cannot be used. On the other hand, the data for all characteristic values from ‘Fiscal year / period’ is broken down in the aggregate. The aggregate can, thus, also be used for individual values, intervals or for all values from ‘Fiscal year / period’. In this case, the fiscal year variant ‘Fiscal year variant’ has to be included with ‘*’ since ‘Fiscal year / period’ and this characteristic are compounded.

modified after activation

activated and filled with data

just activated for demonstration

used 2 times by queries

number of records in aggregate



Illustration 12: Maintaining Aggregates: Definition of an Aggregate

Summarization takes place in this aggregate across all the other characteristics (‘Currency type’, ‘Posting period’ and ‘Fiscal year’). With this aggregate, the transaction data can, therefore, no longer be broken down according to these characteristics. In general, this is also preferable since the aggregates contain fewer details than the InfoCube, and should be considerably smaller than it.

4.3 Creating Aggregates Automatically (Release 1.2B)

With the enhancements for release 1.2B, the first steps on the road towards the completely automatic selection and optimization of aggregates have been taken.

For each query, you are firstly able to analyze the usage of characteristics, attributes, and hierarchies per navigation step in the framework of the BW statistics (contained in the BW statistics workbook, see also section 3.3). This gives an assessment of the definition of especially suitable aggregates – not only at InfoCube level as a whole, but also detailed right down to individual navigation steps. The aggregates must then,however, still be manually created.

In addition, as indicated in the lower part of Illustration 1, data for the BW STATISTICS and for the created queries can be read from release 1.2B. The new functionality can be reached via the pushbutton in the aggregate maintenance, that has been added recently (Illustration 13).

selected hierarchy of characteristic

Keep all values of ‘Fiscal year / period’ in the aggregate (‘not-summaritzed’)

selected fixed value of characteristic



Illustration 13: The Aggregate Maintenance has been Enhanced by the Feature for Automatically Suggesting Aggregates

By pressing the pushbutton ‘Suggest Aggregates’, you get to the optimization for aggregate selection, Illustration 14.

Suggest suitable aggregates by analysing queries or the recorded BW statistics



Illustration 14: Automatic Suggestion of Aggregates and Optimization of Suggestions

The window is correspondingly subdivided up into three actions. At the top left, all the suggested aggregates are listed. At the top right, you can find the list of all the aggregates, that are already activated but are marked for deletion. An aggregate is included in this list if it has either never been used when executing a query (calls = 0), or if its last usage (not visible on the screen, but can be reached by scrolling) is further back than one month ago. Finally, the third list (below) contains all the activated and filled aggregates, to which you do not need to make any more changes.

At the start, at least the window for suggestions (top left) will be empty, since no suggestions exist yet. These can be determined in two ways (you can use also both methods alternately later on):

19 queries analyzed, 17 OK

Aggregates activated, filled and in use

not used

Suggested e.g. by query analysis



1. Using the pushbutton ‘Queries’ , all the created queries for the selected InfoCube can be analyzed, and a minimum as well as a maximum aggregate can be suggested respectively. The name for the suggested aggregates is made up of ‘MIN’ or ‘MAX’ and a sequence number. The minimum aggregate corresponds to the aggregate, that has been used without additional navigation when executing the query6. The consequence of activating such a query is to accelerate the drilldown defined in the BEX Analyzer. The other aggregate results from the assumption that a drilldown is made across all characteristics (meaning all the free characteristics as well). If it should rarely occur in practice, this aggregate can, however, be used with all the possible navigations for this query. In a certain sense, it consequently displays the ‘maximum’ aggregate for this query. If the components of such a recently determined aggregate are the same as those for one, that has already been suggested, then it is not added to the list, but the number of callups is increased by one. The list of suggested aggregates is sorted according to the number of callups. As a general rule, the greater the number of callups, the more useful the aggregate is. In comparison to this, the number of existing queries and the number of queries, that can be evaluated, are displayed at the bottom on the left. If query definitions are missing, then the displayed number of queries, that can be evaluated, is less than the number of those that already exist. The number of components is also listed. By double-clicking on the line, a window appears with the components for the aggregate, meaning the characteristics and attributes, that have not been summarized.

2. Using the pushbutton ‘Statistics’ , the data saved in InfoCube 0BWTC_C01 for the BW STATISTICS can be evaluated. The analysis for this can be restricted to a subset of data by entering an interval for the start time or runtime for queries. The runtime for queries is respectively rounded up to the power of ten on the database. With the time interval, you should take care to save the date and the time separately7. After the data has been read from the InfoCube, the respective optimum aggregate for each navigation step is determined, and a list of all the different aggregates is compiled8. The number of read records for the BW STATISTICS, the number of aggregate definitions determined from this, and the number of different aggregates are subsequently displayed in the bottom on the right. The list of suggested aggregates takes the same structure as for the query analysis, that is described above. In general, however, the list is longer. The length of the list can be smaller than the value entered at the bottom right if one or more suggestions concur with already existing, filled aggregates.

If the analysis of the queries or of the BW STATISTICS resulted in a large number of suggestions for aggregates, it is not necessarily a good idea to activate all of them. Although doing this reduces the runtime for the queries, and optimizes the aggregate roll up in such a way that already existing rolled up aggregates are used, the required memory space for all aggregates is generally too large. Therefore, besides the runtime for the queries, a complete optimization must also take into account the dependencies of the aggregates, their memory requirement, the costs of rolling up new data, and additional factors. Thus, the number of all the possible aggregates is astronomically high (see below). For the first time in release 1.2B, in place of this complicated and costly optimization, a simplified optimization is available via the pushbutton ‘Optimize’.

6 For this the query has to be set to read, which is the default. 7 If the date is restricted, for example, from 1.1.1998 to 1.1.1999 and th time from 8 to 17 o‘clock, then only dates from 8 to 17 are chosen for each day. The only information to be evaluated is that which is considered meaningful. 8 For aggregates, that only differ in the aggregation level in a component: All of them with aggregation level hierarchy (‚H‘) or fixed value (‚F‘) are replaced by one with not summarized (‚*‘), provided that this has also already been suggested.



For this optimization, it is assumed by the heuristics that the number of aggregates should first of all be restricted. For this, the aggregates are selected, that have been called up the least and together produce 20% of all callups. For these aggregates, a check is made one after the other to see whether there are any aggregates with exactly one additional component. If several of these are found, the one with the largest number of callups is selected. The aggregate (from the 20% quantity) is then deleted from the list of suggestions and its number of callups is added on to the one selected with the additional component. This only actually happens, however, if the number of callups for the aggregate is not more than double those of the callups for the aggregate with the additional component. This stops aggregates being replaced by aggregates, that are used considerably less, that are generally also in the 20% quantity. This restriction can be removed, however, if you check the ‘Ignore number of calls’ box after the pushbutton ‘Optimize’ in the window.

If at all, aggregates are, thus, only extended by one component at each respective optimization step. The optimization can keep being called up so as long as the number of aggregates is small enough, or so long as no more aggregates can be grouped together anymore.

Since this simple optimizer does not have any information about the structure of the data, the suggestions should be checked once again before filling with data. An aggregate, for example, can contain a characteristic as a component, whose cardinality corresponds to that of the InfoCube. In practice, a copy of the InfoCube would be created when filling the aggregate, which is generally not a good idea.

For an InfoCube, that has more than a few characteristics and navigation attributes, and many different queries, the list of suggested aggregates soon becomes unclear. This is really in the nature of things, since the number of possible aggregates is so huge. For example, for an InfoCube with

N=50 characteristics and attributes, there are ( ) 000.000.000.10!!

! ≈− nnN

N possible aggregates

with n=10 components9. With N=25 components, you already have more than 100.000.000.000.000 possibilities.

You can see an overview of the hierarchical relationship between the aggregates in the hierarchical display in illustration 15, that can be reached to via the pushbutton ‘Display proposals’. You can also interactively change this display, for example, to move aggregates or regions.

9 Compounds and other conditions are not taken into account here, but this does not fundamentally change the scale.



Illustration 15: Visualization of the Hierarchy for Aggregates (activated and suggested)

Besides the suggested aggregates (blue symbol), the already activated aggregates (yellow symbol), as well as the aggregates suggested for deletion (red symbol), are also marked in. In each aggregate symbol, there is the name (top), the components coded with letters (middle) and the number of components (below). For suggested aggregates (blue symbol), the number of callups is also entered (below, right). The coding for the aggregate components can be found in the window at the bottom left of the screen. All aggregates, that each have the same number of components, are grouped together in a region (yellow rectangle). On the other hand, the regions are arranged hierarchically, beginning with aggregates with only one component and going up to the largest available number of components. In the top left corner, the number of components is given for each region (as text and in the green symbols). Red lines join two aggregates to one another if one can be replaced, or can be filled, by the other.

aggregates ‘test’ encoded as ‘BD’ can be substituted by ‘STAT 8’ encoded by ‘BCD’

abbreviations of infoobject names

abbreviation of aggregate components (infoobjects) e.g. ‘CD’

aggregates with same number of components in same yellow region

aggregate name

number of calls

number of components

Overview



5 Loading Data

5.1 Delivered Program (Release 1.2B)

Data for BW STATISTICS is loaded in the InfoCube via an internal InfoSource. The program ‘RSDDK_STA_WRITE_IN_CUBE’ is delivered for this (Illustration 16)10.

Illustration 16: Program for Loading Data into the BW Statistics InfoCube

When starting the program, the delivered InfoCube 0BWTC_C01 for the BW STATISTICS is entered in the field InfoCube as a default value.

You have two different options for loading the data:

1. Complete Load

If you select the radio button “Complete load”, all data for the database tables is loaded in the entered InfoCube.

The data, that is to be loaded, can be chosen for a time period. The fields “to date” and “to time” indicate the end of the time interval for this, and the “from time” and “from date” indicate the start. The current date is automatically entered for the “to date”, and the current time is automatically entered for the “to time”. The “from date” and “from time” are blank.

10 In a later BW release, this takes place via an extractor, that carries out the connection from a BW to itself.



2. Delta Update

The delta transfer process firstly has to be initialized. For this, choose the radio button “Delta upload initialization”, and start the program. All the available data in the database tables up to the current time is then loaded.

At later time periods, the radio button “Delta upload” should be chosen. All the new data, that has come in since the last load, is then transferred.

If such a delta packet has to be transferred again from the data, for example, because the load was unsuccessful, the same transfer can be started afresh with the radio button “Repeat last delta”.

The default value for the field “Do not hide user data” is blank, and all data records are written in the InfoCube anonymously. Both the keys and the texts for the InfoObject 0TCTUSERNM are then filled with ‘XXXXXXXX’. If the checkbox “Do not hide user data” is set when loading, the respective user ID is entered as a key. By doing this, the data from the user data (full name and telephone number in the long text) can be read in the queries as texts for 0TCTUSERNM.

6 Installing BW Statistics

BW STATISTICS are delivered as a part of the technical content. When installing, carry out the following steps:

1. Transfer the technical content. The procedure for this is the same as for the business content.

1.1. If you have not yet transferred all the available InfoObjects with the business content, please transfer all the InfoObjects, whose technical name begins with 0TCT, as well as the time characteristic 0CALDAY, and activate them.

1.2. Please transfer and activate the InfoObject catalogs 0BWTCT_CHA01 and 0BWTCT_KYF01.

1.3. Please transfer and activate the InfoCube 0BWTC_C01.

1.4. Please transfer all query objects. It is sufficient to transfer all those queries, that begin with 0BWTC_C01_Q. In this way, all dependent objects (such as calculated/restricted key figures, templates) are automatically transferred. You should then transfer all those variables, that begin with 0TCT.



7 Appendix

7.1 Anticipated Data Volume

It is hard to estimate the anticipated data volume for the BW STATISTICS, since it is very strongly dependent on the usage of the Business Information Warehouse. The data in Table 9, however, helps to estimate the data volume for the statistics data of the OLAP server dependent upon usage. Consequently, the anticipated number of users working at the same time is put in the columns, and the mean number of navigation steps per user every hour in the rows. The basis of this is a mean usage time for BW of 5 hours per day and 275 days per year, as well as 1000 bytes of data per navigation (Bring the values in the table into line with your ratios, and calculate the results anew!)

data each day [MByte]navigation steps / hour

1 5 10 50 100 500 10001 0,005 0,024 0,048 0,238 0,477 2,384 4,768

5 0,024 0,119 0,238 1,192 2,384 11,921 23,842

10 0,048 0,238 0,477 2,384 4,768 23,842 47,684

50 0,238 1,192 2,384 11,921 23,842 119,209 238,419

100 0,477 2,384 4,768 23,842 47,684 238,419 476,837

Data each navigation step [Byte 1000

working time each day [h] 5

data each year [GByte]navigation steps / hour 1 5 10 50 100 500 1000

1 0,001 0,006 0,013 0,064 0,128 0,640 1,281

5 0,006 0,032 0,064 0,320 0,640 3,201 6,403

10 0,013 0,064 0,128 0,640 1,281 6,403 12,806

50 0,064 0,320 0,640 3,201 6,403 32,014 64,028

100 0,128 0,640 1,281 6,403 12,806 64,028 128,057

working day / year: 275

number of concurrently active users

number of concurrently active users

Table 9 Estimating the Size of the Delivered InfoCube for the BW Statistics

For a larger installation, if all data is completely recorded and no data is deleted, you can consequently count on a data amount in Mbytes per day and Gbytes per year. You should, therefore, consider to what extent the recording of data should only be switched on at times for certain InfoCubes.

Documents

How to BW_Statistics