Performance Tuning

Query Performance
Loading Performance

Performance Tuning
Query Performance

Query Execution Process

Performance Tuning
Query Execution Process

Info Cube
Aggregate
s

Performance Tuning
Note:- [Parameters to Measure the performance of the BEx
Queries]

Total Time Taken by the Query

= DB time + OLAP Time + Front End Time
Aggregation Ratio:
No of Records Selected from the Database /
No of records transferred to Front End
For Ex:- In the Previous Slide:
Aggregation Ratio = 4 / 2 2

Performance Tuning
*** How to see the Statistics of the BEx queries by using 4 ways :

By using the T-code [RSRT]

By seeing the contents of the Database Table RSDDSTAT
By using the T-code ST03
By using the Business content queries on Info Provider
OBWTC_C10 [Multiprovider]
Queries:
- Utilization OLAP report per Query
- Utilization OLAP report per Info Cube
- Mean time of the query

Performance Tuning
How to Install BW statistics Content delivered by SAP?

Performance Tuning

Steps to Install the Technical content for BW

statistics:
Install the Business content Data Sources - RSA5
Replicate the Data Sources with Myself connection - RSA1
Install the complete Data flow using (grouping as Indata
flow Before and After (IS,TR,UR,IC,MP,Queries)
Schedule the loads (Running Info Packages)

Performance Tuning
Analyzing BW statistics and formulate action plan based on the below chart

Performance Tuning

Modeling Aspects :
-Info Cube / ODS
-Aggregate the data in the Info provider as much as possible
- Multiprovider {Parallel Execution of the BEx Query}
- Info Cube Design
-Repairing Objects (Analyzing Objects) RSRV
Query Design:
- Prefer Include rather than Exclude
- Reduce the Result set of the Report
- Do not use Virtual Key figure & Virtual characteristic RSR00002
- Reduce the usage of ABAP/4 code.
-Reduce the usage of exceptions
- Use More variables in the BEx query

Performance Tuning
Compression:
* /F AND /E are the 2 fact tables.
* when we load data into the Info Cube it goes into /F table and when
we compress the Cube it deletes the request id dIMENSION kEY
information and aggregates the records based on the Characteristic
value OR Dimension Key Value combination and transfers the Data into
the /E table.
* When we do reporting on the Info Cube data comes from /F and /E
tables.
* Once compress is done in the Info Cube we cannot delete data based
on the request in the Info Cube, But we can solve the problem by doing
"request reverse posting" only if data is available in PSA.
* In Collapse Tab when we specify a request and compress the cube - it
only compresses the specified request and all the request below it.
* With Zero Elimination - after compression if it finds any records with all
its keyfigure values being zero it deletes those records.10

Performance Tuning
Partitioning of Info Cube:
* /F table is by default partitioned based on the request number.
* when we partition a cube by default it partitions the /E table.
* we can partition a cube based on "calender year/month" and "Ficsal year
Period".
* we cannot partition a cube if it contains data in it.
* We cannot Re-partition an Info Cube till BW 3.5 but in BI 7.0 we can do
Re-partition.
* We cannot partition an Info Cube if the backend Database is SQL Server.
- RSZC To copy queries from One Info Provider to another Info Provider

11

Performance Tuning
Read Mode of the Query:
3 read modes:-----------1) Query to read all data at once (A)
2) Query to read data during Navigation (X)
3) Query to read data on demand when Navigating/Expanding Hier (H)
* RSRT - READ MODE FOR A QUERY.
* RDMD - Read mode for all the queries on a particular Info Provider.

12

Performance Tuning
Indices:
Indices are like Index page of a book

13

Performance Tuning
Types of Indices:1) Primary Index
2) Secondary Index
2.a. Bitmap Index
2.b. B-Tree Index
2.a. Bitmap Index:* When the cardinality of Dimension table is less than the 20% of the Fact
table.
2.b. B-Tree Index:* When the cardinality of Dimension table is more than the 20% of the
Fact table.
NOTE : RSDEW_INFOCUBE_DESIGNS - will give the cardinality of the
dimension tables.
* Card Height ( check box )
Note :- When we Build indices on a Info Cube it improves Query
Performance but it Degrades Loading Performance subject to Data
Volume.
14

Performance Tuning
Line-Item Dimension:
* When only one characteristic is assigned to the Dimension
( and ) the cardinality of Dimension table is more than the 20%
of the Fact table. we make the dimension as Line Item
Dimension
* when we make a Dimension as Line Item Dimension the
Dimension ID in the Fact Table will be replaced with the SID of
the corresponding characteristic and this field Refers to the SID
Table and the respective Dimension Table is converted as
'Database View'.
* Line item dimension will improve Query performance as it
reduces the joins in the Schema.
NOTE : RSDEW_INFOCUBE_DESIGNS - will give the cardinality
of the dimension tables
Ex:- 0doc_number ( Sales Document Number ), Finance
Document Number, Material Document Number.
15

Performance Tuning
OLAP Cache:
-RSRT

16

Performance Tuning
Aggregates:
- It is a smaller Cube built on a Cube to Improve the performance of the
query.
- Thumb rule for Aggregate :- DB time is grater than 30% of the Total
Time and Aggregation ratio is grater Than 10.
- Multiple Aggregates on one Cube - Yes
- Initial Fill
- Roll Up
- Structure of Aggregate is similar to Info Cube
- By default data is compressed in Aggregates
-RSRT
- Small change in the Query Execution Process
17

Performance Tuning
Different Ways of Building a Aggregate / Different flexibilities in Defining
aggerates:
Sample:-1
--------with a Single Characteristic.
Sample:-2
---------Maintain Aggregates with Selective Values of a Characteristic.
Sample:-3
--------Aggregate with Multiple Characteristics
Sample:-4
--------To Maintain Aggregates with Multiple Selective Values of a Characteristic
is not possible. So to overcome with this problem we have to build
multiple aggregates with different selections.
18

Performance Tuning
Sample:-5
We can use Navigational Attributes in Building Aggregates.
- Attribute Change Run
Sample:-6
We can use Hierarchies while Building Aggregates

19

Performance Tuning
Different Options with aggregates:
-----------------------------------1) Switch on / off : When we switch of an Aggregate, The Structure of the Aggregate is
present and Data is also Present but not identified by the OLAP
Processor for Reporting.
2) Activate / Deactivate:
Activate will fill the Data from Info Cube to the Aggregate Deactivate
will Delete Data in the Aggregate.
3) Delete:This deletes the Aggregate
4) Roll Up hierarchy:It is the Sequence of the aggregates how they are filled from the cube.
20

Performance Tuning
Limitations of Aggregates:
-------------------------Redundancy of data.
Note:
If the request is not rolled up to the Aggregates, the request will not
be available for reporting.
-Aggregates by Proposal
- Multi Provider ON A SINGLE CUBE (RSADMINA) - NOPARALLEL
* We can only build the Aggregates on basic Cube or Transactional
Cube.

21

Performance Tuning

Reporting Agent:
DB Statistics

22

Performance Tuning

Loading Performance

23

Performance Tuning
* If we have Indices Built on a Info Cube, It Degrades the Loading
Performance. So in order to overcome with this problem every time
we load data into the cube, Drop the Indices - load the data - Build the
Indices.
* If we are loading to the ODS, if we selct the check box (BEx
Reporting) it degrades the loading performance because the system
will have to generate the SID's during the Activation Process.
* Load Master data First and Then Load Transaction Data.
* prefer loading with - Delta Updates
* Deploy Parallelism where ever it is Possible.
* Timing of the Load is Very important.
* Utilization of the Work Process - [ SM50,SM51 ]
* Data Packet Size : - 50000 - [ RSU7 ] OR
VIEW [ V_IDOCPRMS ]

24

Performance Tuning
* Processing Tab:
Prefer -> PSA and Data Target in Parallel
(To improve the Loading Performance )
Prefer -> Only PSA (Update Subsequently
in Data Targets) when we want to reduce the
workload on to the server.
* Load Distribution among Multiple Server
Instances.

25