You are on page 1of 200

BW360 Business Information Warehouse – BW

Performance & Administration


 
   !


 
 



 SAP AG©2003
SAP AG 2003

R/3 System, Release 3.0B


2003/Q1

Material number 50055942

© SAP AG BW360 Preface-1


Copyright

Copyright 2003 SAP AG. All rights reserved.


No part of this publication may be reproduced or transmitted in
any form or for any purpose without the express permission of
SAP AG. The information contained herein may be changed
without prior notice.

All rights reserved.

 SAP AG 2003

Trademarks:
Some software products marketed by SAP AG and its distributors contain proprietary software
components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered
trademarks of Microsoft Corporation.
IBM®, DB2®, DB2 Universal Database, OS/2®, Parallel Sysplex®, MVS/ESA, AIX®, S/390®,
AS/400®, OS/390®, OS/400®, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner,
WebSphere®, Netfinity®, Tivoli®, Informix and Informix® Dynamic ServerTM are trademarks of
IBM Corporation in USA and/or other countries.
ORACLE® is a registered trademark of ORACLE Corporation.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.
Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,
VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of
Citrix Systems, Inc.
HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide
Web Consortium, Massachusetts Institute of Technology.
JAVA® is a registered trademark of Sun Microsystems, Inc.
JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for
technology invented and implemented by Netscape.
MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and Commerce One.
SAP, SAP Logo, R/2, R/3, mySAP, mySAP.com, and other SAP products and services mentioned
herein as well as their respective logos are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other product and service names
mentioned are the trademarks of their respective companies.

© SAP AG BW360 Preface-2


Prerequisites

"##
"
 Knowledge of the subject matter
covered by BW310 (BW Data
Warehousing) dealing with the BW
Administrator Workbench

!!#
 -

 SAP AG 2003

© SAP AG BW360 Preface-3


Target Audience

$
 Project team members with extensive BW knowledge in
the area of the Administrator Workbench

%#&
%#& !'

 SAP AG 2003

User notes
These training materialsare not a teach-yourself program. They complement the explanations
provided by your course instructor. Space is provided on each page for you to note down additional
information.
There may not be sufficient time during the course to complete all the exercises. The exercises
provide additional examples that are covered during the course. You can also work through these
examples in your own time to increase your understanding of the topics.

© SAP AG BW360 Preface-4


BW360 Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 Preface-5


Architecture and Customizing


 Basic customizing of BW
 General administrative tasks
 Settings for improving performance

 SAP AG 2003

© SAP AG BW360 1-1


Architecture and Customizing: Unit Objectives

 

       
 Perform the basic customizing for a BW system
 Customize ICM
 Discuss the basics about memory management in SAP BW
 Make performance relevant settings in BW

 SAP AG 2003

© SAP AG BW360 1-2


Architecture and Customizing: Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 1-3


Overview Diagram

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-4


BW Releases

    

GUI 4.6D GUI 4.6D GUI 6.10 GUI 6.20 GUI 6.20

ou
BW 3.1

t
BW 2.0B BW 2.1C BW 3.0A BW 3.0B

of
BI CONT 3.10

ma
ABA 4.6C ABA 4.6D ABA 5.0 ABA 6.20 ABA 6.20

inte n
Basis 4.6C Basis 4.6D Web AS 6.10 Web AS 6.20 Web AS 6.20

an
ce
Kernel 4.6D Kernel 4.6D Kernel 6.10 Kernel 6.20 Kernel 6.20

    

 SAP AG 2003

End of maintenance for BW 2.0B and 2.1C will be the 31.08.2003

© SAP AG BW360 1-5


Support Packages / Patches

!" #
! " #
" # $
!
 $
!%
$
!%
 SPAM/SAINT update (SAPKD*)
 SAP Basis Support Package (SAPKB*)
 SAP ABA Support Package (SAPKA*)
 SAP BW Support Package (SAPKW*)
 SAP PI Basis Support Package (SAPKIPY*)
 Optional (for Early Watch services):
ST–PI with TCC Tools (note 69444)
##   ! &'
 SAP BW-SEM Support Package (SAPKGS*)
 SAP FIN BASIS Support Package (SAPK-10B*FINBASIS)
(())*+ 
((
 Kernel Patch for SAP Kernel (OS-level)
 SAPGUI Patch, SAP BW Addon Patch (for GUI)

 SAP AG 2003

© SAP AG BW360 1-6


BW Support Packages / Patches

Alias: patches

Newest IGS Installation version

 SAP AG 2003

All types of patches are found on the SAP Service Marketplace (alias: patches)
Frontend maintenance: apply SAP GUI Patch and SAP BW Addon Patch

See note 535308: How to apply a SAP Front End patch.

IGS (Internet Graphic Server):
Patching of IGS means installation of new IGS from ‚patches‘.

No patches available for IGS, just installation version

Don‘t use installation version on Server component CD, because usually it is not the actual

version. Use the newest version from swcenter-main.

© SAP AG BW360 1-7


Architecture

 SAP AG 2003

© SAP AG BW360 1-8


OLTP versus OLAP

CHARACTERISTICS OLTP OLAP


Primary Operation Update Analyze

Amount of data per transaction Very small Very large

Updates to data Frequently Less frequent, new data only

Data Model Unique structures Recurrent structures

Response time Quick Reasonable

Type of processing Well defined Ad hoc

 SAP AG 2003

OLTP (OnLine Transaction Processing), refers to the type of processing typically done on an R/3
system.
Average response time in SAP BW is larger than in SAP R/3. Furthermore there is a strong
dependency to the design of queries an Infocubes/ODS. Therefore basing SLAs on response time is
quite difficult.
With SAP BW, enterprise query processing is more efficient. The technical environment and data
structures are designed for answering strategic business questions.
SAP BW supports loading data from a variety of source systems, including R/3 OLTP systems,
third-party industry data suppliers, non-R/3 systems, and other BW systems.
The data from various source systems is combined and stored in a way that is easily retrieved, and
the variety of data sources provides a rich environment for decision-support queries and analysis.

© SAP AG BW360 1-9


Performance Critical Areas


 ,

 , #+
# ,
 BW-database  Datastructure and Design
 Web Application Server  Query design
 IGS  Caching and buffering
 Sizing  Precalculation

 SAP AG 2003

System performance in SAP BW depends on different items:


Basic settings and customizing (parameters, etc.)

Advanced settings (e.g. design of the application, which is predominantly self-created)

For both areas you have to define responsible persons, which are caring for one or both of this areas.
It is not possible to split both areas strictly
Especially for the advanced settings deep knowledge of the architecture of BW are necessary
Datastructure and design: optimized star schema of InfoCubes

Query design: Complexity, ...

Caching and buffering: read mode, global cache, ....

Precalculation: avoid long running database activities via precalculation.


© SAP AG BW360 1-10


BW Database Settings: Overview Diagramm

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-11


BW Database

enerally: Database gets much more important in SAP BW

ith SAP BW, activity on database is much higher than with


SAP R/3.

(ptimal configured database is prerequisite for good load and


reporting performance.

hare of memory and CPU consumption of database instance


against SAP Instances is higher than in SAP R/3 systems.

-or large SAP BW environments (>200GB) storage subsystems


are recommended.

 SAP AG 2003

For a typical landscape with database and central instance: the database needs up to 50% of the
configured ressources.
Additional information to storage subsystems:

Cache capacity is up to 64 GB (with 2GB, 4GB, 8GB, or 16GB cache boards)

Disc space configurable for several Terabytes

Highly integrated control unit with powerful CPUs and Cache (several GBytes)

Distribution of data is done automatically by control unit

Scalable capacity

Redundant design (each Chip exists twice)  failover possible

Data integrity logic

System-wide Error Checking and Correction

Partitioned Cache for parallel access

© SAP AG BW360 1-12


BW Database Settings

Database Data Buffer SQL Area Sort +


Server (main Hash Area
memory) Larger than for
SAP R/3

Fast storage area

Redo logs
Harddisk Large:
Temp area > 15 GB

 SAP AG 2003

Important setting for BW databases:



Large datablock buffer or corresponding parameter depending on the type or vendor of the
database
(hit ratio (transaction ST04) should be around 99%)

Large sort area because a lot of sorts have to be done during query execution

Large SQL area because SQL statements for reporting are very complex and long.

Redo logs and the number of redo logs should be large.

Large and (very fast) temporary database area (typically 15 – 20 GB)
Typical setting for a productive SAP BW system using database Oracle (200 – 500 named user):

Databuffer: around 2 GB

SQL Area: araound 800 MB – 1 GB

© SAP AG BW360 1-13


WebApplicationServer Settings: Overview Diagramm

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-14


New Basis: Web Application Server (Overview)

SAP Web
AS
DIAG
Dispatcher

Workprocess
HTTP Workprocess
Workprocess
HTTP(S) ICMan Workprocess

HTTPs

J2EE Engine
File I/O

intern
CGI
New with 6.20:
HTTP(s) port +
necessary

infrastructure

 SAP AG 2003

New terms:


ICMAN = Internet Communication Manager

ICF = Internet Communication Framework
In the pastusually communication took place via SAP-specific DIAG port. Since WebAS 6.10 there
is also a HTTP, HTTPS or SMTP port availaible
Full SAP Application Server (not just a gateway) with ABAP runtime, Database, DDIC, Security...
Runtime and Development Environment for page based Web programming model (Business Server
Pages)
HTTP Server and Client functionality
Native support for open protocols; HTTPS, SSL, SSO, Server and Client Certificates (X.509)
XML/XSLT engine, “integrated” J2EE Engine
Data transfer between ICMAN (threads) and SAP work processes with memory pipes (very fast!)

© SAP AG BW360 1-15


Web Application Server: Work Processes (1)

ypical configuration of work process types (SM50)

.!
 
.!
 
 Not more than 60-100 workprocesses (64-bit operating system)
should be configured for one SAP instance (due to administration
overload on dispatcher and semaphore lock situations)

 SAP AG 2003

Typical configuration:

25 DIA

2 UPD

1 UPD2

5 BGD

1 ENQ

2-5 SPO
Sometimes it is useful to configure operation mode ’load‘ with more than 8-10 BTC processes and
operation mode ‘reporting‘ with just a few BTC processes (e.g. 4).
Theoretically: there is no restriction to 100 for the number of work processes per instance, but due to
administrative overhead, it makes no sense to configure more than 100 WP/Instance (see note:
9942).
In BW additionally semaphore lock wait situations can occur, if more than 60 work processes are
configured.

© SAP AG BW360 1-16


Web Application Server: Work Processes (2)

!   !"$!
$
!    !"$!
$
!"$!
$
 For dataload and reporting mainly dialog work
processes are used
 UPD and UPD2 are not (!) used for dataload (only
for customizing, etc.)
 BTC-Work processes are mainly used for deletion
of data, aggregation and compression of requests
 It is not possible (yet) to use spool work
processes for printing query results

 SAP AG 2003

© SAP AG BW360 1-17


ICF: ICM Admin and Monitoring

#%  !  


 Tcode: SMICM and SICF
ICM status: runs
 Command line monitor: Trace Level (0-3) 1
icmon{.exe} Created threads: 10 / 10 50 (current / peak / maximum)
Connections used: 10 / 10 50 (current / peak / maximum)
/! /
/!  /!%! Queue entries used: 10 / 10 50 (current / peak / maximum)

 See Reference guide


for details. (icm/*)
 Online help
(help.sap.com)

 SAP AG 2003

ICMAN.EXE starts the ICM (usually automatically via startsap). There is just one process running
on OS level, because of multi threaded architecture.
Similiar to disp+work.exe you have to patch periodically icman.exe in order to fix bugs and to get
new functionality
SMICM


Similiar to Work Process monitor

Status information, traces, logfiles, services, ... threads

Temporary configuration of additional services possible
SICF:


Activatation, modification or creation of services

Switch on http compression
Administration: profile parameters

icm/HTTP/server_cache<xx>/max_entries

icm/HTTP/server_cache<xx>/expiration

etc.

© SAP AG BW360 1-18


ICF: Internet Communication Manager (ICM)

&xternal Process (icman{.exe}) controlled by Dispatcher


'ultithreaded architecture with thread pool and dynamic number
of threads
 Managed from ICM Monitor: transaction SMICM
/rotocol independent due to dynamic plugins (HTTP, HTTPS,
SMTP, NNTP, …)
 Plugins are delivered with SAP executables or downloadable
/latform independent
 Available on all R/3 platforms (NT, Unix, AS/400, etc)
upports both server and client role
0ses memory based communication (Memory Pipes = MPI) to
enable copy free data transport (I/O) to and from the work
process.
'

 SAP AG 2003

© SAP AG BW360 1-19


Activation of Services in SICF

 Activation of ICF-services
after installation necessary
in order to work with the
ICM (e.g for webreproting).
 Due to security aspects
only activiation of really
necessary services is
recommended.
right
 After installation all ICF
services are not active per
default.

 SAP AG 2003

For Web Reporting only activation of the subtree ‘BW‘ including all subnodes is necessary.
Deactivation and activation during runtime of the SAP instance is possible.

© SAP AG BW360 1-20


ICF: Services

ransaction SICF
 services defines
URL for HTTP
handlers
 Default user
settings for public
sites
 Default client,
language
 Definition of Aliases
 Individual ICF
Services for BSP and
HTTP Applications Attend to
 BW services delivered note
550669
as standard

 SAP AG 2003

After installation all services are inactive  required services have to activate manually.
Due to security aspects activate only really necessary services.
SAP kernel 6.20 Patchlevel: 251  http compression works for all plattforms ( note 542576).
After applying http compression you have to invalidate the http server cache ( note 550669).

© SAP AG BW360 1-21


ICF Services Definition

Ability to define default


User-id/password, client,
and Language

Service Data Handler List Error Pages


Ability to define user
authentication for Anonymous Logon Data Service Options
execution of the service Logon Data Required Server Group:
Client SAP Authorization ErrorType 0
User Session Timeout 00:00:00 (HH:MM:SS)
Password still initial Compression (if possible)
Language
Internal SAP security user
authentication Security Requirements
Standard
SSL
Client Certificate w. SSL
Server group: selection for load
balancing. Basic Authentification
Standard R/3 User
SAP Authorization: Check for value in Internet Users
users S_ICF authorizations and the
message type to send
Session timeout: timeout for user
session otherwise profile parameter
rdisp/plugin_auto_logout is used
Compression: gzip compression option

 SAP AG 2003

© SAP AG BW360 1-22


Web Application Server – Settings for BW

.
%%## ,! 1.23
 rdisp/max_wprun_time: >3600 (or 0)
0 means unlimited
 icm/server_port_0: PROT=http, PORT=xxxx, TIMEOUT=900
 SAPLOCALHOSTFULL: <fully qualified name>
e.g. p54054.sap-ag.de
 icm/host_name_full: <fully qualified name>
 Additionally you have to activate the ICF (T-Code: SICF)

 SAP AG 2003

Online queries allocate dialog work processes, webqueries additionally ICM threads.
Default value for max_wprun_time are 600s. Usually too small for BW!
Default value for timeout on server_port_x are 60s. Usually too small for BW Web reporting!

© SAP AG BW360 1-23


IGS: Overview

calable Server-based infrastructure


 Multiprocessor (multi-process, multi-threaded solution)
 Distributed
-ront end-independent
arget: Platform-independent
 Even in mixed environments
 Runs on:
 Windows 2000, / NT 4.0,
 portable to any UNIX platform (future release)
Note: For BW 3.0B, Windows 2000 or NT 4.0 is currently the only supported
platform.
enerates any type of content
 Supports various data formats for graphical output:
JPEG, BMP, WBMP, SVG, VML
&xtensible
 Integration of new components
 SDK available for new interpreter
upport for various protocols
 RFC and HTTP
 Data from SAP or external systems
 Example: GIS maps (from ESRI) used in BW web reporting
 SAP AG 2003

© SAP AG BW360 1-24


The IGS Landscape for BW

HTTP

Internet


RFC/HTTP
RFC
HTML + Java
Chart-
Engine
IGS
GIS
Engine

SAP Dialog-Protocol and Automation-Calls


EP 5.0
External HTTP Protocol, for HTML, JavaScript, Java
System Applets, etc. – planned, but not yet implem.

RFC – RFC/HTTP for admin access

 SAP AG 2003

The BW System needs to know about the IGS!


Maintain RFC Server program (programid) in IGS

Can be configured during IGS installation.

Can be viewed IGS configuration file (example in previous slide)
Maintain RFC destination in the BW System

Via transaction SM59

Create RFC destination “IGS_RFC_DEST”

Type: T for TCP/IP

Enter host information if IGS is to run on a separate server

Select “Registered server program”

Specify destination as Program ID
- This Program ID must be the same as specified in IGS config file

Save and test connection.

© SAP AG BW360 1-25


IGS Data Flow

(*/&, 
Results
Chart
Request

RFC HTTP
Query Listener Listener

MUX
Multiplexer
?
Configuration
File

PW Portwatcher

BW Chart Interpreter
Interpreter for GIS

Chart
Geocoder
Control
 SAP AG 2003

Listeners (RFC or HTTP): Convert incoming request from source format to IGS format. Each
Listener is started in its own thread and process/memory space
Multiplexer (Mux): The central dispatcher and communication manager. Manages connections to
and how work received from listeners is distributed to Portwatchers. Load balancing is achieved via
a round-robin approach. Only one Mux can be installed per server.
Portwatcher(s): coordinates work requests from Mux with the application Interpreters. Portwatchers
are registered with one Mux
Interpreters:
Converts IGS request into native component format and issues work request to
component and vice versa.
Components: Specialized processes

© SAP AG BW360 1-26


Hardware / Software Requirements

/erformance test results


 Generating a graphic on a Pentium 800 MHz PC
 Maps: 600 ms
 Business graphics: 300 ms
 Memory requirements of multiplexer: roughly 64 MB
 Memory requirements per portwatcher: roughly 64 MB
 Note: Server equipment should achieve better results
 Sizing example for a Pentium 400 MHz generating 2000 maps
and 5000 business graphics:
 2000 * 1.2 sec + 5000 * 0.6 sec = 5400 seconds
 Performance option would be to use 2 portwatchers:
2 Options:
1. One PC with 2 CPUs: 3 * 128 = 384 MB
2. Two PCs each with one CPU:
2 * 128 = 256 MB
1 * 128 MB
 Graphics card with at least 64K colours
 SAP AG 2003

© SAP AG BW360 1-27


Monitoring and Administration

he IGS web administration interface:

alled via URL:


http://<hostname>:<http listener port>

he following information can be selected via a


hyperlink or directly:
Status
http://<hostname>:<http listener
port>/ADM:STATUS
Statistics
http://<hostname>:<http listener
port>/ADM:STATISTIC
Adminpage
http://<hostname>:<http listener
port>/ADM:ADMINPAGE
Muxlog file
http://<hostname>:<http listener
port>/ADM:GETLOGFILE

 SAP AG 2003

Changing the configuration



Network settings and trace level settings are stored in the config file

Note: Changes to the config file require a restart of the IGS
Adding / removing Portwatcher

Portwatcher can be started / stopped without restarting the IGS
service.
Connection to R/3


The RFC connection to an R/3 system is automatically restored
should IGS or BW be stopped/started.
- Parameter ‘recontime’ in example configuration file
Monitoring


Using CCMS
- Monitoring method is made available in 6.10

Using the web administration interface

© SAP AG BW360 1-28


Testing an IGS Installation

o test the IGS installation:


 Perform a connection to the IGS:

URL: http://<hostname>:<http listener port>

 Perform an IGS self test:

URL: http://<hostname>:<http listener port>/ADM:SELFTEST

 Generate a test BW chart request

Execute ABAP BW_IGS_CHART_TEST

RFC Destination for the IGS:


IGS_RFC_DEST

Result should be …

Or the stress test ABAP


GRAPHICS_IGS_CHART_TEST

4 Execute ABAP BW_IGS_ADMIN

 SAP AG 2003

© SAP AG BW360 1-29


Application Server: Memory Configuration

Server
Virtual memory
Shared memory Local memory

SAP buffers Heap memory


Roll buffer (programs, (temporary)
tables)
Extended
SAP Paging
memory (user
buffer
contexts) Local Local Local
...
memory memory memory

1:1
1:n
Work Work Work
SAP roll file process process
...
process
SAP paging file

 SAP AG 2003

More details  BC 315 SAP R/3 Workload Analysis


Virtual memory
Virtual memory = sum of shared and local memory which is configured for the instance
The operating system determines itself, if the allocated memory area resides in the physical memory
or in the operating system swap space.
Virtual memory < 1,5 * available physical memory (depending on the operation system)
Memory areas
SAP memory areas are located in one or more of the following:

Local memory

Shared memory

File system
Extendend memory (EM)
Most important area for processing data. Swapping should never happen!!.
With swapping the performance goes absolutely down.
Recommendation: Max use of EM < 80 % of EM ‚in memory‘
SAP buffer:
Usually the program buffer is the largest object (less swapping allowed)

© SAP AG BW360 1-30


Memory Allocation for Dialog WPs (1)

   4
Extended memory Heap memory
Roll memory Roll memory:
up to up to
up to remainder of
ztta/roll_extension abap/heap_area_dia
ztta/roll_first ztta/roll_area
or EM exhausted or HM exhausted

Time

Strategy for memory management:


Store as much data as possible in
extendend memory, because it is PRIV Mode
shared memory. Avoid to use local If a dialog workprocess
memory areas, because then copying have to use HEAP memory,
is necessary. then workprocess goes to
PRIV mode

Local Data in local memory is copied


memory during context switch

Shared Data in extended memory is mapped


memory during context switch.

 SAP AG 2003

To keep the usage of the roll area to a minimum and make more use of extended memory, only a
small portion of the roll area is used initially. The size of this portion is set by the parameter
ztta/roll_first.
ztta/roll_first usually is set to 1. This means a minimum of roll memory is used for administrative
data at the beginning of memory allocation for the workprocess. This amount is approximately
100KB.
The user quota defines the maximum amount of extended memory that can be used by any user, and
is set with the parameter ztta/roll_extension.The user quota thus prevents one user from occupying
all available extended memory.
Heap memory allocated by one work process is not accessible to any other work process. This means
that a user is unable to continue the transaction in a different work process.
The user is now effectively locked to the work process (close connection). This situation is called
PRIV mode. Data in heap memory can never leave the work process. If heap memory is allocated,
the work process is exclusively assigned to one user in PRIV mode.

© SAP AG BW360 1-31


Memory Allocation for Dialog WPs (2)

BW user  BW user  BW user  BW user 4

loose connection close connection


Process private memory Process private memory

Work Roll Roll Work


process 1 area area process 2
/.5%#
Pointer Pointer
Paging Paging
area area

ng
Ma

pi
pp

ap
Heap
ing

M
memory

Extended
memory
(shared)
2003
 SAP AG 2002

BW user 1,2,3 are sharing work process 1 each other (typical, favoured situation)
BW user 4 needs too much memory. Work process 2 goes to PRIVATE Mode and the BW user 4
is binded to this work process until the transaction is finished. During this time nobody else could
use work process 2.

© SAP AG BW360 1-32


Memory Management Parameters

DIA
ztta/roll_first Roll
area Roll buffer
ztta/roll_area rdisp/roll_SHM

Heap
memory
Roll file rdisp/roll_MAXFS

abap/heap_area_dia
abap/heap_area_total
ztta/roll_extension

Extended
memory
(shared)

em/initial_size_MB

 SAP AG 2003

Memory parameter (typical setting for 75 concurrent user):


(=1 , means minimal, around 170 kB):
ztta/roll_first:
Defines the first part of the roll area that is allocated to a dialog process
ztta/roll_area: (6 500 000 (in byte))
Defines the total roll area per work process
rdisp/roll_SHM: (15000 (in 8kB) (= ca. 120 MByte)
Defines the size of the roll buffer
rdisp/roll_MAXFS: (30000 (in 8kB) (= ca. 240 MByte)
Defines the size of roll buffer and roll file
em/initial_size_MB: (3000 – 4000 (MB))
Defines the fixed size of extended memory
ztta/roll_extension(500 000 000 – 1 000 000 000 (byte))
Defines the user quota for extended memory
abap/heap_area_dia: (800 000 000 – 1 500 000 000 (byte))
Defines the limit for the amount of local memory allocated to dialog work processes
abap/heap_area_nondia: (800 000 000 – 1 500 000 000 (byte))
Defines the limit for the amount of local memory allocated to non-dialog work processes
abap/heap_area_total: (1 500 000 000 (byte))
Defines the limit for the total amount of heap memory allocated to all work processes.

© SAP AG BW360 1-33


Application Server: Buffers (1)

Program buffer Generic key


Export/import Single record Others ...
buffer buffer
Server
Virtual memory
Shared memory Local memory

SAP buffers Heap memory


Roll buffer (programs, (temporary)
tables)
Extended
SAP Paging
memory (user
buffer
contexts) Local Local Local
...
memory memory memory

1:1
1:n
Work Work Work
SAP roll file process process
...
process
SAP paging file

 SAP AG 2003

Important SAP buffers:


Single record buffer: any master data in BW is single record buffered
Generic key buffer: customizing tables are buffered generic or full.
Program buffer: some swapping allowed (if a lot of different queries or InfoPackages are used). For
every query a program is generated for query execution.
Export/import buffer (e.g. used by ALV List viewer) (note 373986)
Exp./Imp.SHM :export/import shared memory buffer. New with WebAS 6.20.
In BW used for global Query cache.
Remark:
No buffer-swapping (push out last recently used objects) should occur, except program buffer (up to
5000 per day) and exp/imp buffer.

© SAP AG BW360 1-34


Application Server: Buffers (2)

Correct
configuration:
no swaps
Nametab (NTAB)
Table definition
Field description
Short NTAB
Initial records
Program
CUA
Screen
Calendar
OTR
Tables Generic key
Generic key buffer too
Single record
small!
Export/import
Exp./Imp. SHM ‘Max. Use’ of
SAP memory extended memory
Roll area should be always
Paging area smaller than ‘In
Extended Memory
Heap Memory memory’!!!
 SAP AG 2003

© SAP AG BW360 1-35


Reorganization: Overview Diagram

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-36


Application Log

W uses frequently the application log


pplication log: tables: BAL* (mainly BALDAT)
/roblem: with huge application log tables read and write activities to the
related tables are slow
olution:
 1. Method: Delete specific time range of application log with Tcode SLG2
(no restore possible!)
 2. Method: archiving application log with archiving object:
BC_SBAL with Tcode SARA

BC_SBAL Archiving Object for


Application Log
Actions
Write
Delete
Management

 SAP AG 2003

Two methods for reorganizing possible:



Tcode SARA: archive data backup of application log information on a optical drive, etc. possible

Tcode SLG2: direct deletion of application log information possible, no restore possible
Display application log: Tcode: SLG1
Heavy use of application log in BW in all WHM acitivities (data load, rollup, compress, ...)
Check size of table BALDAT periodically

© SAP AG BW360 1-37


Deletion of Info IDocs

&ach IDoc is stored in tables EDI* (mainly EDI40)


6eavy usage of Info IDocs in data load activities
ith huge IDoc tables: starting of detailed view in data load
monitor takes a long time
olution: archive and delete IDocs: Tcode SARA, archiving
object: IDOC

IDOC IDOC – Intermediate Document

Actions
Write
Delete
Read
Management

 SAP AG 2003

It is not possible to delete these IDocs without archiving


In Tcode SARA: Fixed sequence: First archive IDocs and then delete IDocs from table EDI40, etc
Because of less importance of old Info Idocs, achiving to filesystem is quite enough (usually no
optical drive, etc. necessary)

© SAP AG BW360 1-38


BW Statistics

f BW statistics switched on for a certain infoprovider tables


RSDDSTAT* are filled.
ables are growing continuosly
7o archiving object for these tables available

Manual deletion necessary


(e.g. yearly)

 SAP AG 2003

Details later in chapter ‚BW Statistics‘


For reorganisationof these tables use deletion button in RSA1  Tools  BW Statistics  delete.
You have to specify the time range. Entries from all statistic tables RSDDSTAT* will be deleted.
‚RSA1  Tools  BW Statistics  delete‘ refers to tables RSDDSTAT, RSDDSTATAGGR,
Tool
RSDDSTATAGGRDEF, RSDDSTATWHM. RSDDSTATCOND

© SAP AG BW360 1-39


Table Reorganisation

.easons for table reorganization


 Performance for accessing data
 Reuse of diskspace for other tablespaces (issue for upgraded
systems)
 Change of physical locations (tablespace)
 Change of storage parameters
 Archiving

 SAP AG 2003

© SAP AG BW360 1-40


Sizing: Overview Diagram

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-41


Sizing BW

ifficulties with sizing of BW Systems


 Datastructure and Design is not predefined (like in R/3)
 Very generic application
 Individual behaviour of queries (in R/3: usually standard
transactions are used)
 Work load caused the system by reporting depends on the
navigation behaviour of reporting users

Before Going Live: Perform stress test for verification of sizing!!!

 SAP AG 2003

Usually data flow depends very much on the data quality delivered by the source system (e.g. For
merging data from different sources, sometimes different ODS Objects on more than one level are
necessary for getting the right data quality).
There are two opposite types of queries possible: Small and simple versus large and complex
queries.
Type of query affects the workload on the application server or database server.
Typical reasons for bottleneck expected with dataload:

huge amount of data has to be loaded in a small time window in the BW system

Complex ODS operations necessary

Master data changes permanently and changerun is necessary

A lot of aggregates have to rolled up
Typical reasons for bottleneck expected with reporting:

Peak times (e.g. at the beginning of a month)

A lot of long running queries (list reporting??)

© SAP AG BW360 1-42


Sizing BW

%$!

%$!


Disk space:
1. How many InfoCubes?
2. How many key figures, dimension(tables)and data records are used
for each InfoCube?
3. How much data should be stored in PSA tables?
(life time of data in PSA)
4. Do you use ODS? How many data records, key figures an
characteristics are used for each ODS?

 SAP AG 2003

© SAP AG BW360 1-43


Sizing BW

%$!

%$!


CPU:
Where do you expect the bottleneck: with dataload or with
reporting?
 Dataload: specifiy the time window for dataload and the amount of data
for each load session. Do you need complex ODS scenarios?
 Reporting: split up in different groups of user which are working
concurrently (information – executive – power user)  see ‘quicksizer’

RAM:
 no accurate formula for sizing of RAM possible yet
 Database usually needs a lot of RAM because of big sort and hash areas
in main memory

 SAP AG 2003

Typical configuration of DB/CI server for 100 active reporting user:



6 - 10 CPU, 8 -12 GB RAM

© SAP AG BW360 1-44


Process of Sizing

6ardware Partners are responsible for sizing


6ardware partners are familiar with data from quicksizer
AP Basis Consultants can only give recommendations

 SAP AG 2003

Basically: sizing is an issue of the hardware partner


Hardware partner know about the quicksizer and are able to interpret the data which is calculated by
the quicksizer
Quicksizer isoptimized for typical scenario with many reporting user and performance bottleneck
caused by reporting (not by data load).

© SAP AG BW360 1-45


Quicksizer on Service.sap.com (1)

 SAP AG 2003

Quicksizer for BW is separated in two different areas:



CPU sizing
Input: number of concurrent reporting user split into three different groups

Disc sizing
Input: detailed data about InfoCubes and ODS (number of dimensions, keyfigures, number of data
records, ...)

RAM sizing: not yet (Dec. 2002) available.

© SAP AG BW360 1-46


Quicksizer on Service.sap.com (2)

 SAP AG 2003

© SAP AG BW360 1-47


Appendix: Overview Diagram

General Overview

Reorganization
BW Database Settings
Sizing

WebApplicationServer Settings
Appendix

 SAP AG 2003

© SAP AG BW360 1-48


SAP Remote Services

/.%
/ .%!+

.%!+

 GoingLive Check
 EarlyWatch Check
(don‘t mix up with EWA
(EarlyWatchAlert))
 Remote Performance
Optimization
 Going Live Functional Remote Service
Upgrade Check - Solution Optimization
- GoingLive Check
 OS/DB Migration Check
- EarlyWatch Check
- Remote Performance Optimization
- Upgrade Services
- GoingLive Functional Upgrade Check

- OS/DB Migration Check


- OS/DB Migration Check

 SAP AG 2003

© SAP AG BW360 1-49


Important BW Customizing Settings

RSCUSTV8

RSCUSTV9

RSCUSTVA2

RSCUSTV16

RSCUSTV6

RSCUSTV1

RSCUSTV3

RSBWREMOTE

RSCUSTV12

RSCUSTV2

 SAP AG 2003

© SAP AG BW360 1-50


RSCUSTV* Transactions

RSCUSTV2

RSCUSTV5

RSCUSTV4

RSCUSTV14

RSCUSTV11

RSCUSTV13

RSCUSTV15

 SAP AG 2003

© SAP AG BW360 1-51


Administration Table in BW

0& Directory of all InfoCubes and aggregates


. 0&:
 Find basic InfoCube for aggregate
 Information about all
 Table with lots of includes (many data fields)
. . More details about aggregates
. .:
(: Directory of all ODS objects
. ( (
.: Directory of all InfoSources
.
(8: Directory of all InfoObjects
. (8
.: Directory of all queries
...&/ .
&913 Directory of all Excel
..7 &913:
workbooks

 SAP AG 2003

© SAP AG BW360 1-52


Analysis Roadmap: SAP BW Configuration (1)

SAP Basis settings

? Check: System  Status

Check: System  Status (DB Release, SAP Kernel, Support package level)

? SM51: SAP application server information

Identify available SAP instances, check distribution of workprocesses on


each instance (SM50)

? ST02: Detailed analysis of SAP memory


Check SAP memory configuration in the Setups/Tune Buffers monitor
• extended memory is configured too small, if Max. used > 80% in memory
• Swaps in buffers except program

? ST06: OS Monitor (CPU usage, Swapping)

? ST04: database monitor (data buffer, hit ratio, …)

 SAP AG 2003

© SAP AG BW360 1-53


Analysis Roadmap: SAP BW Configuration (2)

SAP Application settings

? BW statistics: AWB  tools- BW statistics for infoprovider

Check active flag at least for each of your performance critical cubes

? ST03: expert mode: BW system load

Identify expensive cubes, more detailled data in tables RSDDSTAT

? Index rebuild and Statistic refresh


Check if indexes of cubes are deleted before large DML statements
(e.g. dataload) and recreated after that; check if statistics will be
refreshed after large DML statements (process chain)

? Check Tcodes RSCUSTV6, RSCUSTV8, RSCUSTA2, RSLGMP

? Maintain data transfer parameters in BW and all connected SAP systems


(SBIW  general settings  data transfer parameter)

 SAP AG 2003

© SAP AG BW360 1-54


Analysis Roadmap: SAP BW Configuration (3)

General database settings

? DB13: DB statistics: Refresh scheduled periodically (daily or at least weekly)

Oracle: check log file of brconnect

? Temporary tablespace: 10 – 20 GB (see note 359835)

Oracle: locally managed Temp tablespace?

? Index check via report SAP_INFOCUBE_INDEXES_REPAIR


Check if SAP_INFOCUBE_INDEXES_REPAIR is scheduled periodically

 SAP AG 2003

© SAP AG BW360 1-55


Analysis Roadmap: SAP BW Configuration (4)

Performance traces

? Data load monitor, BW statistics

AWB -> Monitoring; ST03: Expert Mode -> BW system load

? ST05: SQL Trace

For analysis of currently long running DB processes


Monitoring of the database interface possible

? SE30: ABAP Trace


Very detailed analysis of abap reports possible (including memory
consumption, size of internal tables, etc)

 SAP AG 2003

© SAP AG BW360 1-56


Architecture and Customizing: Unit Summary

7   


 Perform the basic customizing for a BW system
 Customize ICM
 Discuss the basics about memory management in SAP BW
 Make performance relevant settings in BW

 SAP AG 2003

© SAP AG BW360 1-57


InfoCube Data Model


 Requirements Modeling
 SAP BW Data Model
 Extended Star Schema
 Dimension Modeling

 SAP AG 2003

© SAP AG BW360 2-1


InfoCube Data Model: Unit Objectives

 

       
 Describe the SAP data model and the star schema
 Explain the role of dimensions
 Handle various data modeling issues

 SAP AG 2003

© SAP AG BW360 2-2


InfoCube Data Model: Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 2-3


Importance Data Model

on‘t underestimate the importance of the data model

 It‘s the basis of all BW application tuning


 Make the blueprint very carefully
 Effects of a bad data model are visible first with mass data load

 SAP AG 2003

© SAP AG BW360 2-4


SAP BW: Extended Star Schema

Master Text Master Text

SID Table Hierarchy


Hierarchy SID Table Hierarchy
Hierarchy

Dimension Master Text Master Text


Table
SID Table Hierarchy
Hierarchy SID Table Hierarchy
Hierarchy
Dimension Dimension
Table Fact Table
Master Text
Table
SID Table Hierarchy
Hierarchy
Master Text
Dimension Dimension
Table Table
SID Table Hierarchy
Hierarchy

Dimension
Table
Master Text
Dimension Dimension
SID Table Hierarchy
Hierarchy Table Table
Fact
Table
Master Text Master Text

SID Table Hierarchy Dimension Dimension


SID Table Hierarchy
Hierarchy Hierarchy
Table Table

 SAP AG 2003

The BW extended star schema is different to the basic star schema. It is subdivided into a solution-
dependent part (InfoCube) and a solution-independent part (attribute tables, text tables, and hierarchy
tables) that is also shared among the other InfoCubes.
The dimension attributes of the dimension tables are called characteristics.
The attributes located in the master data table of a characteristic are called the attributes of the
characteristic.
The great challenge when designing a solution is to decide whether to store an attribute in a
dimension table (and therefore in the InfoCube) or in a master data table.
Data is loaded separately into the master data tables (attribute tables) text tables and hierarchy tables.
The SID table is the link between the master data and the dimension tables.

© SAP AG BW360 2-5


Attributes

isplay attribute
 Is an attribute to an InfoObject, can be displayed together with this
InfoObject
 Can’t be used on it’s own
avigational attribute
 Is an attribute to an InfoObject, has to be switched on for that
InfoObject
 Can be used on it’s own like other characteristics directly on the
Dimension Tables of the Cube.
 Is not contained in an InfoCube, but has to be switched on for an
InfoCube
 Naming convention: <InfoObject>__<Attribute>, e.g.
0customer__0country

 SAP AG 2003

© SAP AG BW360 2-6


Design Phase: Golden Rules

1. Small dimensions
2. Few dimensions (less important than small dimensions)
3. Only as many details as necessary
4. Characteristics in the “right“ order
(technical order >>>> most selective first)
5. Hierarchies only if necessary
6. Time dependent structures only if necessary
7. Avoid MIN, MAX - Aggregation for key figures in huge
InfoCubes

 KISS: keep it small and simple

 SAP AG 2003

If MIN or MAX Aggregation is used in key figures, no delta changerun in Aggregates is possible.
For each change run a total rebuild of the aggregate is done.

© SAP AG BW360 2-7


Design Phase: Tradeoffs

Analysis
Aspects

Global
Performance
Data Warehouse
Aspects
Design Aspects

 SAP AG 2003

When modeling real world processes, different interests generally conflict with one other. A good
design is therefore a compromise that allows the most important parts of each aspect to be
represented without disregarding the other aspects.
Some questions to ask when determining requirements:
Will delivered business content meet many requirements?

What granularity of data do the users really need to access most frequently?

Which user requirements are, in reality, exception reporting?

Are users basing their requirements on simply replicating reports from a legacy system?
Granularity isthe level of detail of your data. A decision about the granularity of your modeling is
one of the main results of the data modeling phase. Granularity deeply influences:

Reporting capabilities

Performance

Space needed

Data load performance

© SAP AG BW360 2-8


Compressing the InfoCube

Request IDs Lost !!!

Request Date Record Cost

1 01.01.2002 1 100

1 02.06.2002 2 200 Request Date Record Cost

0 01.01.2002 1 300

0 02.06.2002 2 200
Request Date Record Cost
0 04.10.2002 2 300
2 01.01.2002 1 200

2 04.10.2002 2 300
E-Fact table

F-Fact table

COMPRESSION

 SAP AG 2003

Compressing an InfoCube means that the request ID will be deleted, and all rows with the same key
will be summarized (for non-cumulative key figures).
This function is critical, because it means that you are no longer able to use the request IDs to delete
data from the InfoCube. Before you proceed, make sure that the data in the InfoCube is correct.
You must compress the InfoCube at regular intervals. This saves space.

© SAP AG BW360 2-9


Line-Item Dimensions: The Star Schema

(1) Fact table

(2) Dimension

(3) Time-independent SID


Time-dependent SID
Traditional SID Char

(4) SID Attr

With line-item dimension

Without line-item dimension


designated

Join of two large tables is bad for


performance!

 SAP AG 2003

If the line-item dimension is not designated, the dimension and SID tables become extremely large
(number of records). When a query is executed, this huge dimension table must be joined to the fact
table. This results in very poor performance.
Once the characteristic is defined in a dimension that is a line-item dimension, the dimension table
no longer exists. This is because the document number (sequence number, …) is stored in the fact
table. The join of large tables is avoided.

© SAP AG BW360 2-10


Line Item

nly possible if exactly one characteristic is in dimension


or data load and reporting only performance benefit
erformance loss might occur for F4-Help

 SAP AG 2003

F4 Help usually uses dimension table for selection, in a line item dimension there is no dimension
table, hence the S-table has to be used. An InfoCube can for example only use 4 material numbers,
but the BW system knows 10.000 material numbers. The material numbers which are stored in the
InfoCube can be found in the dimension table, all material numbers of the BW system can be found
in the S-table. Thus means the F4-help access a table with 10.000 entries instead of a table with 4
entries.

© SAP AG BW360 2-11


Cardinality and Index Type

ardinality refers to the number of distinct values in the column of a


table.
xample:
 Column Gender can have only 2 values – M or F this is low cardinality
 A column holding a unique document number has a high cardinality
here are two types of indexes in BW on Oracle: bitmap and b-tree
 Bitmap indexes are best for read performance when the cardinality in a
column is low
 Single-column bitmap indexes are created by default on each dimension
column of a fact table
 If the number of distinct values in a dimension are very high, then a b*tree
index is best for performance
ou can change the bitmap index on the fact table dimension column
to a b-tree index by setting the high cardinality flag
 You also can change the index type in SE14 (see note 383325)

 SAP AG 2003

Note that in BW 3.0, there is a separate cardinality flag for a dimension. Setting high cardinality
changes the dimension column index to type B*tree. Thus, index type can be maintained separately
from the line-item dimension setting.
When a line item dimension is set, a B-tree index is created instead of the bitmap index that is
normally created in the InfoCube.
Check the record volume to see if it is small enough, and if it is, if you can manually create a

bitmap index (SE14). If the line item dimension is more than about 100 000 records, you may do
better to stay with the B-tree type index.

© SAP AG BW360 2-12


Dimension Flag – High Cardinality

se to adjust indexing for a dimension


 Low cardinality (Bitmap)
 High cardinality (B-tree)
 Only pertains to an Oracle DB
 Switch on the flag if the dimension size is > 10% of the fact
table
 Should be used in conjunction with Line Item dimension

 SAP AG 2003

The High Cardinality flag providesan opportunity for the System Administrator to define which
index type (Bitmap where values are often repeated, B-tree where the values are not often repeated).

© SAP AG BW360 2-13


InfoCube Data Model: Unit Summary

   


 Describe the SAP data model and the star schema
 Explain the role of dimensions
 Handle various data modeling issues

 SAP AG 2003

© SAP AG BW360 2-14


Exercises

Unit: Data Modeling


Topic: Examine data model

At the conclusion of this exercise, you will be able to:


• Examine the data model of InfoCubes

Check for the data model of an existing InfoCube

1-1 Examine the data model of InfoCube T_PU_SLOW (technical name)


1-1-1 Find and display the data model of the InfoCube
1-1-2 Transaction LISTSCHEMA
Open another window to call up the schema viewer for InfoCubes
What is the name of the database table for the InfoCube F fact table?
Expand to view the names of the dimension tables.
1-1-3 Analyze the InfoCube’s F fact table and dimension tables
Go to transaction RSRV and determine the number of records for the F fact
table and dimension tables, write down the number of records.
Which one of these dimensions tables is the best candidate to be a "High
Cardinality" dimension and/or a “Line-Item” dimension?

2-1 Learn more about an InfoCubes data model, chose the InfoCube with the
technical name “T_ATTR”. For this InfoCube two queries exist, run both
queries (technical names “T_ATTR1” and “T_ATTR2”). Describe what you
see, why do you see this difference?

© SAP AG BW360 2-15


© SAP AG BW360 2-16
Solutions

Unit: Data Modeling


Topic: Examine data model

1-1 Examine the data model of InfoCube T_PU_SLOW (technical name)


1-1-1 Goto transaction RSA1 choose Modeling then InfoProvider. Goto InfoArea
BW Training → BW Customer Training  BW360 Performance and
Administration  Unit02. Highlight the InfoCube, right-click (context
menu), and choose Display Data Model.
Expand the Key Figures folder, and note the key figures that make up this
InfoCube’s fact table. Expand each dimension (three triangles icon), to see
what characteristics make up each dimension table of the InfoCube. List the
dimensions that were built by the designer of the InfoCube.

1-1-2 In the box at the top left of the screen, type in “/oLISTSCHEMA”. In the
field InfoCube Type, type in “B”, and type in the technical name
T_PU_SLOW of the InfoCube, then select the Execute icon.
The name of the database F fact table for the InfoCube is
/BIC/FT_PU_SLOW
These are the dimension and their tables:
T_PU_SLOWP: /BIC/DT_PU_SLOWP
T_PU_SLOWT: /BIC/DT_PU_SLOWT
T_PU_SLOWU: /BIC/DT_PU_SLOWU
T_PU_SLOW1: /BIC/DT_PU_SLOW1
T_PU_SLOW2: /BIC/DT_PU_SLOW2
T_PU_SLOW3: /BIC/DT_PU_SLOW3
T_PU_SLOW4: /BIC/DT_PU_SLOW4
T_PU_SLOW5: /BIC/DT_PU_SLOW5
T_PU_SLOW6: /BIC/DT_PU_SLOW6
T_PU_SLOW8: /BIC/DT_PU_SLOW8
T_PU_SLOWA: /BIC/DT_PU_SLOWA

© SAP AG BW360 2-17


1-1-3 Goto transaction RSRV. Goto to Tests in Transaktion RSRV →
All Elementary Tests  Database . Highlight the Test Database
Information about InfoProvider Tables, right-click (context menu), and
choose Select Test.
On the right side, expand the test and make the parameter entry InfoProvider
T_PU_SLOW. Choose the button “Transfer”. Execute the test by selecting
the “Execute” button in the top of the left side. Display the protocol with the
button “Display”. Expand your whole protocol. Now you can see the tables
with their records.
The dimension T_PU_SLOW8 with 188557 entries (23% of F fact table) in
the table /BIC/DT_PU_SLOW8 is the best candidate to be a "High
Cardinality" dimension and a “Line-Item” dimension. It can be a line item
dimension because, as you have seen in the data model, there is only one
characteristic inside that dimension. All dimensions with only one
characteristic can be a good candiadate for a line item dimension.

2-1 Open the BEx Analyzer (call transaction RRMX). Open  Query  InfoAreas 
BW Training  BW Customer Training  BW360 Performance and
Administration  Unit 02  Query with attribute country 1  OK.

Open the second query “Query with attribute country 2” the same way you did for
the first query. The first query displays EN for the country. The second query
displays DE for country. Both queries look the same, to see the difference (it
doesn’t matter if you can open the change dialog only in display mode): Change 
Change Query (global definiton)  Technical Names on.

The “country” characteristic used in query one is the country InfoObject itself. The
“country” characteristic used in query 2 is the navigational attribute of InfoObject
Airport. Hence the second query displays the country from the master data table
(/BIC/PT_AIRPORT) and the first query takes the value for the country out of the
InfoCube.

The queries themselves display in both cases just “country” as the name of the
object, in order to avoid mistakes always choose a different name for the
navigational attribute!

© SAP AG BW360 2-18


Transport Management


 System landscape in BW
 Object versioning
 Transports in R/3 source systems
 Specific transport objects in BW

 SAP AG 2003

© SAP AG BW360 3-1


Transport Management: Unit Objectives

 

       
 Know about differences between standard transport
system (e.g. in R/3) and the BW transport system.
 Use the object collector for creating BW transports
 Develop your own customer content

 SAP AG 2003

© SAP AG BW360 3-2


Transport Management: Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 3-3


System Landscape: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-4


Recommended System Landscape

Development Consolidation Production


B1 B2 B3

BW

RFC RFC RFC

R/3

Development Consolidation Production


O1 O2 O3

BW 3.0 uses the standard transport tools delivered with WebAS 6.20
(configuration with STMS). In the background tp and R3trans are used.

 SAP AG 2003

A typical system landscape consists of a development, consolidation and production system both on
the R/3 and on the BW side.
BW uses the basis transport system (configuration with STMS)
Transports only between R/3 systems or between BW systems.
Communication between R/3 and BW systems via RFC.
System changeability in consolidation and productive BW and R/3 system is set to ‚not modifiable‘
(SE06 and SCC4).
PI must be installed on R/3 (most current version recommended) (Alias: r3-plug-in)
Defaultsystem setting: New BW objects are created as local objects (package: $TMP). Transports of
new objects have to be done with the “Transport connection” in the AWB.
During metadata upload the metadata will not be assigned to any package, the uploaded metadata
can’t be transported between BW system. The metadata upload has to be done for each pair of
systems (R/3 OLTP – BW) separately (no transportation possible!).

© SAP AG BW360 3-5


System Settings

ypical transport system settings in a three system landscape:


 Development system:
Use default BW transport setting (new BW objects are assigned to
$TMP).
 Quality assurance system:
Set system to ‚not modifiable‘ in SCC4 and SE06. You may want to
create some objects in the quality assurance / consolidation system in
exceptional cases. Activation of automatic transport connection for
keeping track of all such objects / changes may be a good approach.
 Productive system:
Set system to ‚not modifiable‘ in SCC4 and SE06. Possibly open system
for certain BW objects like queries, workbooks, ... in AWB.
In the productive system you typically don‘t create objects to be
transported except queries, workbooks, aggregates, Infopackages, ... .
Using default BW setting (no automatic recording of changes) is usually
the best option (independent of settings in development or consolidation
systems).

 SAP AG 2003

© SAP AG BW360 3-6


Maintain Source System Mapping (Target System)

Example: B1 B2 B3
In the system B2 you have to map source
BW
system dependent objects from O1 to O2.
If the logical system name of O1, O2 are
TB3CLNT003, QB3CLNT003 respectively,
R/3
mapping in B2 is pictured below.
O1 O2 O3

 SAP AG 2003

Before transferstructures can be transported between BW systems you have to maintain the
conversion table RSLOGSYSMAP (via menu in RSA1  Tools  Mapping of the source system
names). The conversion table is maintained in the target BW system, into which the transport will be
imported. InfoSources mapped to a source system are converted during the transport using this
conversion table.
Mapping not only of R/3 OLTP systems might be necessary, but also it might be necessary to map
DataMart source systems and flat file source systems.
Before the first transport between the BW systems (B1, B2 and B3) takes place, a metadata upload
from the connected R/3 systems to the BW systems should be done in order to avoid possible errors
in the transports. For example: If a Transfer Structure is transported it can only be activated if the
relevant DataSource already exists in the target system.

© SAP AG BW360 3-7


Sequence of Transport Process

Development Consolidation Production


B1 B2 B3

BW
3
RFC 2 RFC RFC

1
R/3

Development Consolidation Production


O1 O2 O3

 SAP AG 2003

The BW development system is connected to the R/3 development system.


Ensure that the development systems are identical to the production systems with respect to
customizing settings and metadata content. Adjustments to the R/3 production system must be
reflected in the R/3 development system. Extractor enhancements (like view names used in RO*
tables) and metadata changes are recorded automatically in transport requests. These changes have to
be transported from the development system to the consolidation system and further on into the
production system.
The BW consolidation system is connected to the R/3 consolidation system.
As the consolidation systems are for consolidation issues only, the servers on which these systems
are installed can be servers with smaller configuration. The customer can check / test in these
systems the influence of transports to the functionality of the system. Ensure that the consolidation
systems are identical to the production systems with respect to customizing settings and metadata
content.
The BW production system is connected to the R/3 production system.
If available,the extractor enhancements from the R/3 development / consolidation system must be
imported into the R/3 production system. A metadata upload must be carried out in order to make
any new metadata available in the BW production system. It is not possible to transport the uploaded
metadata from the development BW system into the following systems. This is done because a
transport of these metadata could lead to inconsistencies in the target system if later a meta data
upload will be performed in the target system.
The no change switch for the R/3 system ensures that no repository objects can be changed in the
production system.

© SAP AG BW360 3-8


Object Versions: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-9


Object Versions

ive object versions in BW:


 D – SAP Delivered version
 M – Modified or Changed version
 A – Active version
 T – temporary version for source system dependent objects
(like M-Version, details in note 411574)
 N – New (temporary)

he Active version is the one exported in a transport


request – make sure that the correct version is active
before transporting!
o version database for BW objects is available.

 SAP AG 2003

In BW there is no versioning database for BW-objects.


After activation a modified version the previous ‚active‘ version is gone and there is no way to
recreate this version again.
After activation the modified version resides (take a look in the RSD* -Tables).
Inorder to get an overview for all active BW objects, take a look at table RSDCUBE,
RSDODSO,RSDIOBJ, RSRREPDIR, RSIS.

© SAP AG BW360 3-10


SAP BW Object Versions

n upgrade of the Business Content does not affect the objects


which are in productive use.

Version

M(odified) 11 11 11 22 22

A(ctive) 11 11 11 22

D(elivery) 11 11 22 22 22
11 install BC
2nd install
delivery from SAP (match) BC

2nd delivery
from SAP (e.g. via
 SAP AG 2003
Support Package, upgrade)

The objects of the Business Content are delivered in delivery version.


Changes are stored in modified version.
Active Business Content is stored in active version.
Only objects in the active version are exported from the development system. When importing to the
target system, these objects are either imported directly to the active version, or to the modified
version, depending on the type of object.
Currency translation types and InfoObject catalogs are examples of objects that are imported in
active version.
InfoObjects and InfoCubes are examples of objects that are first imported to modified version and
then activated after the import.

© SAP AG BW360 3-11


Metadata: Versions and Transport

ll BW meta objects are activated by the common After Import


Method RS_AFTER_IMPORT
Source system
M(odified) 11 11 22
export
A(ctive) 11 11

create activate change


import
TLOGO
Target system objects
M(odified) 11 11 44
A(ctive) 33 11 11

After
import method change
 SAP AG 2003

After releasing a
change request the active versions of the contained objects (TLOGO objects) are
exported from the source system to the file system. Just metadata (defined in TLOGO objects) is
exported.
When the change request is imported to the target system: at first the modified version of the objects
is generated.
After the import is finished the so called “After Import Methods” are executed. These methods
activate the imported objects. Dependencies between the objects (e.g. InfoObjects have to be
activated before InfoCubes are activated) are resolved in this step.
If the after import activation fails, the ‚old‘ active version of the object is still available.

© SAP AG BW360 3-12


TLOGO Objects (1)



 

Only logical transport objects
are assigned to transport
requests (e.g. IOBJ, CUBE, ...)
 Most of the objects are
assigned directly to the
transport request (and not
to the task)
 With T-Code: SOBJ you find
info about the tables that are
really read during export and
the after import methods.

 SAP AG 2003

When checking the object list of transport requests, most of the assigned objects are not objects
exiting in the data dictionary. These objects are logical objects. Information about these logical
objects and the tables that are really read in background is listed in transaction SOBJ.
During export, only (!!!) meta data to BW objects is collected from these customizing tables listed in
transaction SOBJ. No master or transactional data could be transported. Therefore it is not possible
to transport hierarchies that have been created manually in the development system.
With the AFTER_IMPORT_METHOD the BW objects are created with the meta data that was
imported with the transport. Therefore most of the time during transportation is used for the
AFTER_IMPORT_METHOD, because the same activities have to be done like during manual
activation of BW objects.

© SAP AG BW360 3-13


TLOGO Objects (2)

here are two TLOGO (logical transport) objects for each


BW object:

Object A TLOGO Object D TLOGO Object

InfoCube R3TR CUBE R3TR DCUB


InfoObject R3TR IOBJ R3TR DIOB
Query R3TR ELEM R3TR DELM
...

 SAP AG 2003

© SAP AG BW360 3-14


Transports in the Source System: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
Customer Content
Transporting Objects in BW
System Copy
BEx Objects
Transport Strategy &
Trouble Shooting

 SAP AG 2003

© SAP AG BW360 3-15


Transports in the Source System

here are only two objects (DataSource and application


hierarchy for DataSources) to be transported on the source
system side
 DataSources have an automatic transport connection
 The application hierarchy needs to be transported manually.
Assign transport request with object R3TR APCO in SE09/SE03
(note 382471).

on‘t forget to transport enhancements (user exits)


ake care for the right sequence: at first transports in the
source system, then replication of metadata (BW), then
perform transports in BW.

 SAP AG 2003

© SAP AG BW360 3-16


Transporting Objects in BW: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-17


Grouping

n the menu Grouping you can determine how Grouping Collection mode
many objects should be taken into Only necessary objects
consideration. The groupings summarize all In data flow before
the objects of an area. In data flow afterwards
In data flow before and afterwards
Save for system copy

Setting Meaning
Only necessary objects Only those objects that are really necessary for the action,
that is, the transport of the selected objects, are only
taken into account (minimal selection).
In data flow before All objects are collected that submit data to a collected
object.
In data flow after All objects are collected that obtain data from a collected
object.
In data flow before and after All objects are collected that submit and collect data.

n the case of dataflow before, the BW system collects the


Datasources in the source system.

 SAP AG 2003

The setting “Save for system copy” means that the source system dependent objects are collected in
a transport request. This request can be imported after a system copy (of BW or source system) in
order to map those objects to the correct source system (with mapping table described above).
Details about system copies of BW systems are described in note 184754.
If the user chooses „In data flow before“ the BW system collects the DataSources in the source
system. In the source system the aleremote user will create a transport request. This transport request
has to be transported before the transport on the BW system.

© SAP AG BW360 3-18


Maintain Source System Assignment for
Object Collector

 SAP AG 2003

Source system dependent objects are only collected (for transport) if the corresponding source
system is assigned here.
At least one source system needs to be assigned.
In general all source systems should be assigned that have a corresponding source system in the
target BW system, however, this is only a default for the object collector.
Incase of different number of source system connected to DEV-BW and <Target> BW this setting is
very useful.

© SAP AG BW360 3-19


Transports Connection

1. Select one or
3.Write to transport
several objects
request

New Objects
(Package $TMP) are
marked
automatically

2.Drag & Drop


objects (or use
context menu)

 SAP AG 2003

© SAP AG BW360 3-20


Transport BW Objects for the First Time

Replace ‘$TMP’ with a relevant


package (customer: Y*, Z*)

Create a request or choose an


existing one

 SAP AG 2003

Create and use your own packages, don‘t use SAP packages.

© SAP AG BW360 3-21


Check Transport Status

Check status of transport


 SAP AG 2003

If there are dependent objects already written to other transport requests make sure those other
requests are released in time.

© SAP AG BW360 3-22


Transporting Changes after First Transport

fter assignment of a  


 BW objects
have an automatic transport connection.
till they can be transported again with the BW transport
connection (they could be locked, though!)
WB objects are handled in the standard way
or BEx objects there is a 
     – see
next section

 SAP AG 2003

After anobject has been assigned to a transportable package (usually after the first transport)
changes to those objects are automatically recorded.
BEx obejcts are then handled in a special way but AWB objects are treated in the standard way, i.e.
the user is asked for a change request when changing such objects.
Stillthose objects can be transported manually using the transport connection. By default they are
not marked for transport but they are collected and you can mark them manually to be transported.

© SAP AG BW360 3-23


BEx Objects: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-24


BEx Objects

Ex objects relevant to transport are:


 Workbooks
 Queries
 Structures
 Restricted Key Figures
 Calculated Key Figures
 Variables
 Infoset Query
 Crystal Report
 Web Template
 WEB Item
 Query View

 SAP AG 2003

© SAP AG BW360 3-25


Transport of BEx Objects

ince BEx Objects (once they are assigned to a transportable


package) are transported there are special considerations:
ll changes of BEx objects (in one package) in a certain period are
assigned to one transport request (unless standard transport
system is activated)
!ou can also specify the CTS Request by Packages.
" ranularity of package for BEx objects is important for flexibility in
transports,
 ransport management of BEx requests
 Agreement on when transport request is released
 Creation of a new one immediately after releasing the old one

 he end user is not prompted for the Request at all.

 SAP AG 2003

Assign BeX objects to different packages is the only way of grouping BEx objects in different
transport requests. So you have to determine the granularity you need for transporting BEx objects
and set up package accordingly.
No changes to BEx objects are possible if
No BEx request exists

The old BEx request is released and no new one is created

A new BEx request is already assigned but the old one has not been released

Granularity of packages for BEx objects is important for flexibility in transports, e.g.
On project level

On data target level

Several ones for each data target

One for each query


© SAP AG BW360 3-26


BEx Request

To change the Standard


BEx or the transport
request for special
packages

 SAP AG 2003

© SAP AG BW360 3-27


Transporting a Role: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-28


Transporting Roles

 # 

Business Content Roles Manually defined roles

Transporting via AWB Transporting via role maintenance


(RSA1) (PFCG) or AWB

Workbooks can be saved in roles. The workbook is only visible for a


user if the user is assigned to that role.

 SAP AG 2003

Each role can be transported via the Transport connection in AWB.


Workbooks that are assigned to a role are transported in a BEx request, so both requests (request
with role and request with workbook) need to be transported in order to have a valid link between
role and workbook in the target system.
Attention:

Workbooks are linked to a role. The role contain information about the links. Therefore: after

transportation of a role from the source system to the target system only these workbooks are
visible, that already exit in the source system. Workbooks that are only defined in the target
system are gone after the transport. (note: 385219)

© SAP AG BW360 3-29


Transporting Workbooks

wo steps necessary for transporting a workbook


 Assign and transport the workbook to a transport request (Object
type: XLWB) via transport connection (Workbench request)
 Transport the link between workbook and role by transporting
the role (customizing or workbench request)

fter step 1 the workbook is not visible for anybody, because


of missing reference to role.
n order to identify workbooks that are not referenced in roles
use RSWB_ROLES_REORG (see note 385219) .

 SAP AG 2003

Sometimes workbooks are only existing in the PRD Systems, e.g. because of ‚Ad Hoc‘-Reporting in
the productive System. If the workbook is referenced to a role which is also including authorizations,
be careful with transporting this role.
Due to missing references to workbooks in Development system, the references are gone after
transporting this role to the productive system, because the entire role including the existing
references is replaced during transport.
Recommendation:

In order to avoid this problem create empty roles in the productive system just for referencing

workbooks. These roles are not existing in development system and therefore they are not able for
transporting.

© SAP AG BW360 3-30


Standard Transport System: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-31


Standard Transport System Activation in BW

he developers should choose a package and a request, immediately when creating a new object.
(automatic transport connection for all objects)
dvantages:
 Maintenance with object collector not required
 Change authorizations via tasks
 Easier maintenance for several packages  complex system landscapes
CAUTION!
$nly the newly created objects are recorded from now on. You might still have to transport the old
objects via the transport connection of the Administrator Workbench.
 SAP AG 2003

You want to activate the standard transport system in BW. In BW, new objects first are created
automatically as local with package $TMP. Consequently, no dialog box is displayed first when you
create a new object in which you could write the object to a transport request. When you transport
the objects for the first time, these objects and dependent objects must be collected in the transport
connection of the Administrator Workbench first. A transportable package is assigned after this and
the objects are written to a request.
This procedure has the advantage that first you need not take care of the transport during the
development of new scenarios. After the scenario has been completed , you only have to collect the
objects that are required in the production system in the transport connection and write them to a
request. The objects not required remain there as internal objects and are not transported. If you write
all objects immediately to requests, it can happen that test objects and productive objects are mixed
on one request. In this case, it is complicated to clean up the requests.
If you activate the standard transport system you don’t have to use the object collector but you still
have to take care of releasing transport requests in the right order. Authorizations can be handled by
tasks in the standard way. The users might not have the authorizations to create requests /tasks, so
they can only change objects if the administrator has created a task for them. Especially when
working with different packages the standard transport system makes correct assignments easier
because you decide your assignment for each single object.

© SAP AG BW360 3-32


Object Changeability

 SAP AG 2003

Use these settings for system that are “not modifiable” in SCC4 and SE06. Afterwards, the specified
objects can then be changed despite the system settings.
More details and latest information in note 337950.

© SAP AG BW360 3-33


System Copy: Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-34


System Copies

System copy

Development Consolidation Production


B1 B2 B3

BW

RFC RFC RFC

R/3
Development Consolidation Production
O1 O2 O3

System copy
 SAP AG 2003

For refreshing e.g. a QA System there are different ways to do that:


Homogenous system copy (e.g. using offline backup or R3load)

- Advantage: fastest method
- Disadvantage: Same disk space as for the productive system is necessary.
Install new, empty system and transport all BW-Objects

- advantage: afterwards no deletion of data from infocubes, etc. necessary
- Disadvantage: long running process, fault-prone method

© SAP AG BW360 3-35


Typical Process of BW System Copy


 : QAS-BW is refreshed by homogeneous system copy

 
(e.g. restore of offline backup from PRD-QAS)

General process: !!! Please read note 184754 !!!


1. Create special transport with source system dependent objects in
the old QAS BW (transport collector  grouping: system copy) for
each R/3- or datamart source system
2. Import the (Database-) copy
3. Rename or delete immediately RFC-connection to ‚old‘ source
systems in the copied BW System
4. Change logical system name and perform Transaction BDLS.
5. Delete old R/3- and external Datamart source systems in AWB.
6. Create new R/3- and Datamart source system in AWB
7. Import transport(s) with source system dependent objects

BW
 SAP AG 2003

Detailed information in note 325525 and 184754.


General recommendation:
Never delete the Myself source system!! The Myself source system is created automatically when
starting AWB first time.
Rename or delete immediately RFC-connection in the copied BW System in order to avoid
unintentional dataloads, etc.:
Possibility 1: start database and delete critical RFC-connection in Table RFCDES on database

level

Possibility 2: modify SAP instance profile and set temporary rdisp/wp_no_btc = 0. Start SAP
system. Modify RFC-connection. Set rdisp/wp_no_btc to previous value.
Depending on the situation it might be necessary not to create the transport with source system
dependend objects in the old QAS but in the PRD. The problem for the decision is, that depending
on the scenario the transfer structure is suitable for the source system or for the communication
structure.
The transportwith the source system depended objects does not contain RRI connections, these
connections have to be fixed manually.
Restore of a
source system connection recreates the source system connection with the parameters in
RSBASIDOC.

© SAP AG BW360 3-36


Typical Process of R/3 System Copy


 : QAS-R/3 is refreshed by homogeneous system copy.

 
Both R/3 systems are connected to BW systems.

Special steps:
1. Rename immediately RFC-connection in the copied R/3 System
2. Change logical system name and perform Transaction BDLS.
3. Restore existing source system in connected BW system (AWB)

R/3
 SAP AG 2003

Detailed information in note 325525 and 184754

© SAP AG BW360 3-37


Transport Strategy & Trouble Shooting:
Overview Diagram

System Landscape
Transporting Roles &
Workbooks
Object Versions
Standard Transport System
Transports in the & Object Alterability
Source System
System Copy
Transporting Objects in BW
Transport Strategy &
Trouble Shooting
BEx Objects

 SAP AG 2003

© SAP AG BW360 3-38


Build up System Landscape

   
Landscape with only one system for development. The project
ask you for a QA-System.
%
& 
 Install a new QA-System
 Transport data sources and application hierarchy in source systems
from DEV to QAS
 Create source system connections (this will replicate meta data
automatically) in the new QAS
 Transport all BW objects from DEV to QAS
 Create ‘small’ transport requests. Therefore:
 Collect all necessary for a few InfoCubes (e.g. 3)
and assign them to a transport request.
 Collect dataflow before and afterward for the same
InfoCubes and assign them to a second transport
request.

 SAP AG 2003

© SAP AG BW360 3-39


Standard Transport Management

   
The transport connection will not be used, all objects will be
assigned to transportable package. The question is: What will be
the best way to transport all objects which belong to a certain
scenario.
%
& 
 Assign each scenario to a separate package
 Collect all objects belonging to one package
 Depending on the situation you need a cross-scenario package
which contains objects like 0calmonth
 Transport of all objects of one package may lead to a transport with
too many unnecessary objects

 SAP AG 2003

© SAP AG BW360 3-40


Complexity of Scenarios


 

 
  Create small transport requests, this means e.g.:
 Not more than a few hundred InfoObjects in one transport request
 Not more than 3 – 5 InfoCubes in one transport request
 In case of problems split up transports (into parts of the data flow:
only necessary objects, ...)

ctivating automatic transport connection ensures that no objects are


forgotten but the order of the imports is then very important.
he object collector helps you find the dependent objects but transport
requests may contain many objects.

 SAP AG 2003

© SAP AG BW360 3-41


Responsibility

f you have complex scenarios / system landscape / several projects


organizing transport may be a crucial issue

entral management may be necessary to decide


 Which object is assigned to which package
 Which objects are collected in one transport request
 In which order and when do the transports take place

 SAP AG 2003

Disadvantages of not centralized transport management:


Locked objects result in incorrect transports

Experience, tips and tricks are distributed among different people.


© SAP AG BW360 3-42


Transport Problem when Saving Queries

n the BEx Analyzer, a user attempts to change a query and receives


the following error:
 A dependent object is being locked by the transport system

heck whether the BEx default transport request or the package


dependent transport request is maintained or released.
he error only occurs for query objects which already have a
transportable package.

 SAP AG 2003

© SAP AG BW360 3-43


Problem with Source System Dependencies

'rror messages: “DataSource doesn’t exist” or “field not delivered


by source system” might come up.
ctivate Data Source (again) from Business Content (if applicable)
or
ransport DataSource (again)
#eplicate DataSource
mport your transport again
n case of a file source system create another transport request
containing also the DataSource (select all).

 SAP AG 2003

More details in note 360951

© SAP AG BW360 3-44


Problems Creating Change Request

$bjects already assigned to a transportable package could be locked


(already contained in an unreleased request).
#elease transport request which locks the object or remove locked
object manually (SE03) from that transport request.

 SAP AG 2003

More details in note 407485


In planning: display of information about locking, etc. after collection process.

© SAP AG BW360 3-45


Activation Problems after Import

nalyze transport protocol, check for error messages in after import


method
f objects are missing or not in the latest version assign them again
to a new transport request.
f objects are not activated because of potential loss of data, delete
data if possible.
ry manual activation in target system (e.g. if table conversion is
necessary or number range objects are missing)

 SAP AG 2003

Manualconversion of an InfoObject is only necessary if characteristics are deleted from


compounding or fields from text table, attribute changes are done automatically.
More details in notes
125499 Activation error after transport of BW objects (manual conversion of tables with SE14 might
be necessary)
381924 The InfoObject import terminates (BRAIN049)
411574 Method execution with RSDG_AFTER_IMPORT_FOR_CORR

© SAP AG BW360 3-46


Problems Transporting a DataSource

ometimes transports of self-created DataSources (RSA6) cause


problems, because of missing extract structure in the transport
request.
(error message in target system: Only transparent tables and
database views can be extracted)
ind corresponding extract structure in table ROOSOURCE and
include it in a transport (TLOGO: R3TR TABU)

 SAP AG 2003

© SAP AG BW360 3-47


Additional Remarks (1)

(ierarchies are considered data (not metadata)


 So they can be loaded (normal staging)
 They can not be transported

f you have problems with tree display in the administrator


workbench (InfoArea Hierarchy, etc.), you can transport the
hierarchies (RSA1  Tools  Hierarchy Transport)
urrency exchange rates are also loaded from the source system(s),
not transported
nfoObject catalogs are not automatically collected with the
corresponding InfoObjects.
'xport DataSources are generated in the target system, they are not
transported separately

 SAP AG 2003

© SAP AG BW360 3-48


Additional Remarks (2)

ssignments of reporting authorization objects to InfoCubes /


ODS objects and hierarchy authorizations need to be transported
manually in transaction RSSM
 Press button “(Transport) Additional Info”
 Choose the reporting object(s) you want to transport information for
 Select hierarchy authorization(s) you want to transport if applicable
 Create or choose a transport request for this information

 SAP AG 2003

© SAP AG BW360 3-49


Transport Management: Unit Summary

!  
 Perform transports in BW landscapes
 Decide when standard or BW transport system should be
used

 SAP AG 2003

© SAP AG BW360 3-50


Exercises

Unit: Transport Management


Topic: Create and Analyse Transport Requests

At the end of this exercise, you will be able to:


• Use the transport connection
• Analyse transport log files

In each system landscape with more than one system, all BW objects
ought to be transported via CTO from development system to the
subsequent system (e.g. QAS, PRD)

Create DataSource, InfoObjects, InfoSource and InfoCube for later transportation

1-1 Create your own generic DataSource for transactional data on the table SFLIGHT
in source system IDES R/3
1-1-1 Create your generic DataSource T_BW360_sflight## (description:
T_BW360_sflight##) for transactional data and assign it to application
component BW Training  BW360. Create your own transport request
‘BW360 group##’ and assign the DataSource to package ‘Z_TRAIN’
1-1-2 Hide all fields except CARRID, CONNID, CURRENCY, FLDATE, PRICE
in the extract structure. Save it.
1-1-3 Replicate application component ‘BW360’ in BW (only this application
component!!!).

1-2 Create your own InfoObject catalog and your own InfoObjects in BW
1-2-1 Goto InfoArea: BW Training  BW customer training  BW360 
Unit03. Create your own InfoArea ‘Group##’ (description: group##)
1-2-2 Create InfoObject catalog ‘Group##_char’ (description: Group##
characteristics) for characteristics. Activate!
1-2-3 Create InfoObject ‘T_carid##’ in your InfoObject catalog. Choose Template
‘T_carid98’. Change description to T_carid##. Activate it.
1-2-4 Create InfoObject ‘t_conid##’ in your InfoObject catalog. Choose template
‘T_conid98’. Change description to T_conid##. Activate it.

© SAP AG BW360 3-51


1-3 Create your own InfoSource
1-3-1 Goto RSA1, choose modeling and goto InfoSources.

Goto BW Training  BW customer training  BW360 Performance and


Administration  Unit 03 and create InfoSource ‘T_BW360_sflight##’
(description: T_BW360_sflight##’)
1-3-2 Goto InfoSource ‘T_BW360_sflight##’: double click. Enter the following
InfoObjects into the communication structure:
T_CARID##
T_CONID##
0CALDAY
T_FLPRICE
0CURRENCY

The following description is visualized in the screen shot below.


Goto Transfer rules and assign the source system: T90CLNT090 IDES R/3
and DataSource: T_BW360_sflight##.

On the right window enter the right group number for the InfoObjects
T_CARID## and T_CONID##. The system will show the group number of
the group which assigned the fields CARRID and CONNID.
Now propose transfer rules.
Activate the InfoSource.

##

propose transfer
rules

1-4 Create InfoCube ‘TRANSP##’ for InfoSource ‘T_BW360_SFLIGHT##’. Create


two line item dimensions, ‘CARID’ and ‘CONID’.

1-5 Create an update rule from your InfoSource T_BW360_sflight## to your InfoCube
TRANSP##. Acitvate your update rule without any change.

© SAP AG BW360 3-52


1-6 Create InfoPackage ‘InfoPack_sflight##’ and start it immediately.
1-6-1 Check load monitor.

Assign your InfoCube to a transport request

2-1 Check settings for transport connection in AWB


2-1-1 Check the default setting for grouping and set it to ‘only necessary objects’
2-1-2 Check source system assignment. Objects for T90CLNT090 should be
collected.
2-1-3 Choose collection mode ‘automatically’and choose Display mode
‘hierarchy’.
2-1-4 Check mapping table RSLOGSYSMAP
In which phase of the transport process is this table used?

2-1-5 You have a 3-system landscapes for BW (DBW, QBW and PBW) and for
R/3 (D01, Q01 and P01). BW and R/3 are connected in the common way. In
which systems do you have to maintain table RSLOGSYSMAP?

2-2 Assign your InfoCube to a transport request.


2-2-1 Collect ‘all necessary objects’ for your InfoCube ‘TRANSP##’.
2-2-2 Check Column ‘transport’ Which objects are proposed for transportation?
Why?
2-2-3 Press ‘Transport icon’
2-2-4 Assign package Z_TRAIN to the objects and create your own transport
request ‘BW360_##_1’.
2-2-5 Repeat 2-2-1 to 2-2-5 for grouping ‘dataflow before and afterwards’ and
create a new transport request ‘BW360_##_2’.
2-2-6 Release both requests.

Analysis of transport logs


This exercise is done completely by the instructor. The mentioned transport requests are
not the requests which you have created. This exercise is only done once for the complete
class.

3-1 The instructors starts the import of transport request 1. Analyze the log of this
transport activity. What is the problem?

3-2 The instructors starts the import of transport request 2. Analyze the log of this
transport activity. What is the problem?

© SAP AG BW360 3-53


© SAP AG BW360 3-54
Solutions

Unit: Transport Management


Topic: Create and Analyse Transport Requests

Create DataSource, InfoObjects, InfoSource and InfoCube for later transportation

1-1 Create your own generic DataSource on the table SFLIGHT in source system IDES
R/3.
1-1-1 Create your generic DataSource T_BW360_sflight## (description:
T_BW360_sflight##) for transactional data and assign it to application
component BW Training → BW360. Save it. Create your own transport
request ‘BW360 group##’ and assign the DataSource to package
‘Z_TRAIN’
Goto transaction RSA1 and choose modeling → source systems. Right
mouse click on source system ‘IDES R/3’ choose Customizing of
extractors. Goto Business Infomation Warehouse → Generic
DataSources → Maintain Generic Datasources. Execute. Create new
transactional DataSource ‘T_BW360_sflight##’

Field Name Values


Appl component BW Training → BW360
Table SFLIGHT
Short description T_BW360_sflight##
Medium description T_BW360_sflight##
Long description T_BW360_sflight##
Save the settings and assign the DataSource to package Z_TRAIN. Create
a new transport request ‘BW360_group##’.

1-1-2 Mark all fieldes in column ‘hide fields’ except CARRID, CONNID,
CURRENCY, FLDATE and PRICE

1-1-3 Go back to the BW system. Goto RSA1 and choose modeling  source
systems. right mouse click on ‘IDES R/3’ and choose ‘DataSource
overview’. Goto IDES R/3  BW Datasources  BW Training 
BW360: right mouse click: choose ‘Replicate DataSource’

© SAP AG BW360 3-55


1-2 Create your own InfoObject catalog and your own InfObjects in BW
1-2-1 In transaction RSA1 choose InfoObjects and goto InfoArea: BW Training
 BW customer training  BW360  Unit03.
Create your own InfoArea ‘Group##’ (description: group##)
1-2-2 Create InfoObject catalog ‘Group##_char’ (description: Group##
characteristics) for characters. Activate!
1-2-3 Create in your InfoObject catalog an InfoObject ‘T_carid##’. Choose
Template ‘T_carid98’. Change nothing and activate it.
1-2-4 Create in your InfoObject catalog an InfoObject ‘t_conid##’. Choose
template ‘T_conid98’. Change nothing and activate it.

1-3 Create your own InfoSource


1-3-1 Goto RSA1, choose modeling and go to InfoSources.

Goto BW Training  BW customer training  BW360 Performance


and Administration  Unit 03 and create InfoSource
‘T_BW360_sflight##’ (description: T_BW360_sflight##’)
1-3-2 Goto InfoSource ‘T_BW360_sflight##’: double click. Enter the following
InfoObjects into the communication structure:
T_CARID##
T_CONID##
0CALDAY
T_FLPRICE
0CURRENCY

The following description is visualized in the screen shot below. Goto


Transfer rules and assign source system: T90CLNT090 IDES R/3 and
DataSource: T_BW360_sflight##.

On the right window, enter the right group number for the InfoObjects
T_CARID## and T_CONID##. The system will show the group number
of the group which assigned the fields CARRID and CONNID.

Now propose transfer rules.

Activate the InfoSource.

© SAP AG BW360 3-56


##

##

propose transfer
rules

1-4 Create InfoCube ‘TRANSP##’ for InfoSource ‘T_BW360_SFLIGHT##’. Create


two line item dimension ‘CARID’ and ‘CONID’.

Goto RSA1, choose Modeling  InfoProvider. Goto InfoArea BW Training 


BW customer training  BW360 Performance and Administration  Unit 03.

Right mouse click Create InfoCube ...

Field Name Values


InfoCube TRANSP##
Description TRANSP##
Create!
Tabstrip: ‘Characteristics’:
You can restrict the InfoObjects in the template by using the button ‘Template
InfoSource’ (the button with the yellow InfoSource icon). Then select your
InfoSource for transactional data (T_BW360_SFLIGHT##) and the necessary
InfoObjects will be transferred automatically to the InfoCube structure.

Press ‘Dimensions’ (Answer with “No” if you will be asked if you want to create
the dimensions with regards to a template) and define two dimensions ‘CARID’
and ‘CONID’ as line item dimensions.

Then assign ‘T_CARID##’ to dimension ‘CARID’ and ‘T_CONID##’ to


dimension ‘CONID’. Press Enter in order to leave the dimension definition.

1-5 Create update rule.

AWB  Modeling  InfoProvider: right mouse click on your InfoCube


‘TRANSP##’  Create update rules.
Select your Infosource ‘T_BW360_SFLIGHT##’, press <Return>.
Next Screen: Activate Update rules.

© SAP AG BW360 3-57


1-6 Create InfoPackage ‘infopack_sflight##’ and start it immediately.

RSA1  Modeling  Infosources  BW Training  BW360 Performance and


Administration  unit03  T_BW360_sflight## :

Right mouse click on your source system IDES R/3 , choose create InfoPackage…

Start load procedure!


1-6-1 Check load monitor.
Goto the ‘Monitor Icon’.

Assign your InfoCube to a transport request

2-1 Check settings for transport connection in AWB


2-1-1 Check the default setting for grouping and set it to ‘only necessary objects’
2-1-2 Check source system assignment. Objects for T90CLNT090 should be
collected.
2-1-3 Choose collection mode ‘automatically’and choose Display mode
‘hierarchy’.
2-1-4 Check mapping table RSLOGSYSMAP
In which phase of the transport process is this table used?
It is not necessary to maintain this table in the development system
2-1-5 You have a 3-system landscapes for BW (DBW, QBW and PBW) and for
R/3 (D01, Q01 and P01). BW and R/3 are connected in the common way.
In which systems do you have to maintain table RSLOGSYSMAP?
The mapping table has to be maintain only in QBW and PBW with the
logical system names of the connected R/3 systems.

2-2 Assign your InfoCube to a transport request.


2-2-1 Collect ‘all necessary objects’ for your InfoCube ‘Transp##’.
2-2-2 Check Column ‘transport’ Which objects are proposed for transportation?
Why?
Only $TMP objects are proposed for transportation.
2-2-3 Press ‘Transport icon’
2-2-4 Assign package Z_TRAIN to the objects and create your own transport
request ‘BW360_##_1’.
2-2-5 Repeat 2-2-1 to 2-2-5 for grouping ‘dataflow before and afterwards’ and
create a new transport request ‘BW360_##_2’.
2-2-6 Release both requests.
Either use the icon in the icon bar or T-Code SE09.

© SAP AG BW360 3-58


Analysis of transport logs

This exercise is done completely by the instructor, the mentioned transport requests are not
the request which you have created. This exercise is only done once for the complete class.

3-1 The instructors starts the import of transport request 1. Analyse the log of this
transport activity. What’s the problem?

Goto STMS  Import Overview  <SID of the BW System>: double click.

Choose according transport request and take a look in the log file.
Problem: InfoObject T_CARID99 is missing.
The instructor applies a correction transport. After this the first request is imported
again. Status: successful

3-2 The instructors starts the import of transport request 2. Analyse the log of this
transport activity. What’s the problem?

Goto STMS  Import Overview  <SID of the BW System>: double click.

Choose the appropriate transport request and take a look in the log file.
Problem: Datasource T_BW360_sflight99 not active
The instructor activates the missing datasource and replicates the meta data. After
this the transport request is imported again. Status: successful

© SAP AG BW360 3-59


Indexing


 Overview Indexes In General
 Indexing In BW

 SAP AG 2003

© SAP AG BW360 4-1


Indexing: Unit Objectives

 

       
 Explain what indexes are and how they are used
 Explain the usage of indexes in BW
 Analyze and fix index related problems

 SAP AG 2003

© SAP AG BW360 4-2


Indexing: Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 4-3


Indexing Overview: Overview Diagram

DB Statistics

Index Overview

Indexes on the BW Star Schema

Index Handling in BW

Appendix – Typical Errors with Indexes

 SAP AG 2003

© SAP AG BW360 4-4


BW Database

enerally: Database gets much more important in SAP BW

ith SAP BW, activity on database is much higher than with


SAP R/3.

ptimal configured database is prerequisite for good load and


reporting performance.

 SAP AG 2003

© SAP AG BW360 4-5


Optimizer Determination of Access Path

Possible access paths

Index A

SELECT * FROM /BIC/P..... Database


WHERE Index B table
name =“Schneider”
???
AND pnum = “69126”
AND city = “Heidelberg”

Full
table
scan

The optimizer determines the optimal access path

 SAP AG 2003

The optimizer determines the most effective way for an SQL statement to access data. The data
access strategy used in executing an SQL statement depends on information in:
The queried table (or, for a view or join, the queried tables)

The fields specified in the WHERE clause of the SQL statement

The indexes defined for the queried tables

All databases used with SAP BW use a cost-based optimizer. The cost-based optimizer calculates the
cost of several strategies for accessing the data, and chooses the most efficient one. To calculate the
cost of a strategy, the optimizer requires statistical information about the tables and indexes of the
database, such as the number of:
Table or index rows, and blocks allocated for the object

Distinct values in each column of the table


© SAP AG BW360 4-6


DB Statistics for the Optimizer

he optimizer requires statistical


information. For generation of an
Execution plan
optimal database statements, a cost-
based optimizer requires information
about the size of a table.
utdated table statistics may lead to
incorrect optimizer decisions and
inefficient table accesses.

Details for the different databases in


the appendix to this chapter

 SAP AG 2003

Wrong statisticaldata about such characteristics like sizes of tables and the distribution of values in a
table column results in non optimal database accesses (e.g. not usage of index, because DB statistic
reflects much smaller table)
DB statistics for a certain table can always be refreshed or created manually (DB20)

© SAP AG BW360 4-7


DB Statistics for the Optimizer


  
 Purely database functionality
 Each ‘state of the art’ database needs statistical information about
database tables, in order to calculate the optimal access path
cost-based optimized (I/O, CPU).
 Database statistics including information about size, number of
records, selectivity, etc.
 MS SQL: mainly autorefresh
 Oracle, SAPDB, IBM DB2, IBM OS390/DB2, AS400: refresh has to
be scheduled manually (Oracle: brconnect, DB2: runstats,
Informix: sapdba, SAPDB: UPD_UNCOND or UPD_COND )

 SAP AG 2003

After DML statements (Update, Insert, Delete) with large data changes, it is useful to refresh the
database statistics.

© SAP AG BW360 4-8


Check of DB Statistics

Checktool
RSRV Display

Database
Database Indices of an InfoCube and ist
Check Database Parameter(s)
Database Statistics for an InfoCube and

 SAP AG 2003

With Transaction RSRV or ‘Manage Data target‘  Goto  Data Target Analysis, a lot of different
checks can be performed on a specific InfoCube. For instance, ‘Database Indices of an InfoCube and
its aggregates‘ or ‘Database statistics for an InfoCube and its aggregates‘.
Disadvantage: just time stamp is check. This means for InfoCubes with no change of data for a
longer time the RSRV transaction says that the statistics are ‘not actual‘, even though they are actual!
More precise check tool for Oracle database: brconnect. Because brconnect counts the number of
changes.

© SAP AG BW360 4-9


DB Statistics of Fact Tables

Refresh DB statistics after each data load


Also refresh statistics after delta upload

With usage of
process chains,
these settings are
ignored by the
system!

 SAP AG 2003

‚Manage Data target‘  Performance  Create Statistics (Batch): Apply these settings whenever if
possible.
Reason for ‘not applying‘ these settings:

Huge InfoCube and more than one InfoPackage that is loaded in the InfoCube.

With usage of process chains these settings are ignored.

© SAP AG BW360 4-10


Manual Refresh of DB Statistics


 

    
   
 !"#$
   
 Sometimes (default) accuracy for DB statistics is too low
 For Oracle, DB2, Informix:
 Immediately after DML statements (Update, Insert, Delete) with
large data changes
 During initial masterdata load: refresh of DB statistics for
concerning SID Tables improves the load performance
significantly.
 After detection of long running SELECT statements, refresh of DB
statistics for the regarding table should be one of the first steps.
 Depending on the compexity of indexes, ... refresh of DB statistics
for a huge table can take some time (range: 1s – 1h).

 SAP AG 2003

Certain levels of accuracy for DB statistics possible



With Oracle: compute or eststimate

With MSSQL:low, medium, high

© SAP AG BW360 4-11


Indexing Overview: Overview Diagram

DB Statistics

Index Overview

Indexes on the BW Star Schema

Index Handling in BW

Appendix – Typical Errors with Indexes

 SAP AG 2003

© SAP AG BW360 4-12


Overview Index

n Index is a data structure sorted by attribute values containing


pointers to data records of a table.
%ndex functionality is available in all RDBMS in different flavors.

 SAP AG 2003

© SAP AG BW360 4-13


Index Performance Impact

n Index can improve reading performance when data is searched


for values of fields contained in the index.
%ndexes are maintained during writing to a table and thus decreases
writing performance (unless used for the write access itself).

 SAP AG 2003

Indexes contain information about the data stored in the table. If the table contents changes then the
index also needs to be changed in order to ensure that the new information is available in the index
as well.
This information can be used to access data faster whereas its maintenance slows down changes to
data.

© SAP AG BW360 4-14


Usage Of An Index

n Index can improve the following operations:


 Select...where <table fields> = <values>
 Update...where <table fields> = <values>
 Delete...where <table fields> = <values>
 Table Joins (<table1.field1> = <table2.field2>)

 SAP AG 2003

© SAP AG BW360 4-15


Usage of an Index – Influences

The database optimizer decides if an index is used and selects


the appropriate index based on these criteria:
 Fields in the index compared to fields in the statement
 Order of the fields in the index
 Selectivity of the fields
 Quality of the index
 Size of the table ...
Size, Quality, Selectivity, etc. information is stored in DB
Statistics. Combination of the right indexes and up to date DB
Statistics usually gives the best performance.

 SAP AG 2003

An index can be useful if:


fields in the index are used for selections / joins

The fields in the index are selective, i.e. they have a reasonably high cardinality (exception:

bitmap index)
The quality (e.g. clustering factor) is good

The table is reasonably large because for small tables reading the entire table is usually cheaper

than additionally reading an index.
The database collects statistical information about the tables and uses this information to decide on
the best indexes to be used.
The database might not find the best execution plan if the DB statistics are not up to date.

Even if they are, the database may make a “wrong” decision. In this case a hint can help.


© SAP AG BW360 4-16


Dropping Indexes

%f a large amount of data is written to a table, dropping of indexes


before and recreation afterwards may be faster.

&'
 
&'
 
 Index is needed in write transactions, e.g.

 
 
     
 
 
   
  

&' 
&' 
 Index on SIDs in Dimensions

 SAP AG 2003

Dropping of indexes improves writing performance because then the indexes don‘t need to be
maintained. Recreation of an index will usually be faster than single record maintenance if large
amounts of data are written to the table.
An Index needed in a loading process must not be dropped. Typically a table that is updated or read
during a loading procedure will be read with a (unique) key. If the record with a specific key doesn‘t
exist, it will be created. In BW, this is done e.g. for dimension tables (key not necessarily unique),
ODS tables for active data, and in the E-Fact table.

© SAP AG BW360 4-17


Binary Search

(  )*
Sequential read requires 13 accesses
Binary Search requires 4 accesses (maximum for all entries):

1 2 4 3

2 6 10 18 19 23 27 33 35 36 39 73 75 92 97

 SAP AG 2003

Finding an entry in a sorted array can be done with binary search.


In order to perform binary search, the array to be searched should be first sorted. We start by looking
at the middle component. If the value it holds is too high, go to the middle of the bottom half of the
array and look again. If the middle component value was too low, go to the middle of the top half
instead. Then, repeat this 'split the remainder' step until you find the value you want, or decide that it
doesn't exist.

© SAP AG BW360 4-18


Binary Tree

2 6 10 18 19 23 27 33 35 36 39 73 75 92 97

33

18 73

6 23 36 92

2 10 19 27 35 39 75 97

 SAP AG 2003

In order to support such a binary search, a sorted structure can be stored as a binary tree.
In a tree, records are stored in locations called leaves. This name derives from the fact that records
always exist at end points; there is nothing beyond them. Branch points are called nodes. The order
of a tree is the number of branches (called children) per node. In a binary tree, there are always two
children per node, so the order is 2. The number of access operations required to reach the desired
record is called the depth of the tree.
Binary trees are used when all the data is in random-access memory (RAM).

© SAP AG BW360 4-19


Unbalanced Binary Tree vs. Maintenance Effort

2 6 10 18 19 23 27 33 35 36 39 73 75 92 97 98 99

33

18 73

6 23 36 92

2 10 19 27 35 39 75 97

98

99

 SAP AG 2003

Maintenance of a binary tree can become expensive if it should be balanced. If it is not maintained to
be balanced, searches in the deeper parts of the tree become expensive.

© SAP AG BW360 4-20


B-Tree Index Overview


 Index entry (value)
Block number Block x I1 I2 I3 I4

Pointer to next block


In Hierarchy (black)
Pointer to data records (blue)

&' 
&' 
Block 4 19 36 97

Block 5 98 99

Block 1 2 6 10 18
Block 3 39 73 75 92

Block 2 23 27 33 35

 SAP AG 2003

B-trees are preferred when decision points, called nodes, are on disk rather than in random-access
memory. It takes thousands of times longer to access a data element from hard disk as compared
with accessing it from RAM. B-trees save time by using nodes with many branches (children),
compared with binary trees, in which each node has only two children. When there are many
children per node, a record can be found by passing through fewer nodes than if there are two
children per node.

© SAP AG BW360 4-21


B-Tree Index (Add Entry 24)

!
!
Block 4 19 36 97

Block 5 98 99

Block 1 2 6 10 18
Block 3 39 73 75 92

Block 2 23 27 33 35


Block 4 19 27 36 97
Change Block 4
Block 5 98 99

Block 1 2 6 10 18
Block 3 39 73 75 92

Block 2 23 24 Block 6 33 35

Split Block 2
 SAP AG 2003

Adding new values into a B-Tree is done by adding them to the right block in the sort order if there
are still vacancies. Otherwise the block is split up into two blocks.

© SAP AG BW360 4-22


Bitmap Index

  ! % '+ 


'+ 
Record Quarter Record / Q1 / Q2 / Q3 / Q4 /
Quarter 2003 2003 2003 2003
1 Q1 / 2003 1 1 0 0 0
2 Q3 / 2003 2 0 0 1 0
3 Q4 / 2003 3 0 0 0 1
4 Q1 / 2003 4 1 0 0 0
5 Q2 / 2003 5 0 1 0 0
6 Q3 / 2003 6 0 0 1 0
7 Q2 / 2003 7 0 1 0 0
8 Q4 / 2003 8 0 0 0 1
9 Q1 / 2003 9 1 0 0 0
10 Q3 / 2003 10 0 0 1 0
11 Q2 / 2003 11 0 1 0 0
12 Q2 / 2003 12 0 1 0 0
13 Q3 / 2003 13 0 0 1 0
14 Q4 / 2003 14 0 0 0 1
15 Q2 / 2003 15 0 1 0 0
16 Q1 / 2003 16 1 0 0 0
17 Q4 / 2003 17 0 0 0 1
18 Q4 / 2003 18 0 0 0 1
19 Q4 / 2003 19 0 0 0 1
 SAP AG 2003

A bitmap index has one bit for every record / value combination. The bit is 1 if the record has this
value in the column(s) otherwise it is 0.
The size of the bitmap index depends on the number of values.

© SAP AG BW360 4-23


Bitmap Index

+  Q1 / Q2 /
Record / Q3 / Q4 /
All records of Quarter 3/2003. Quarter 2003 2003 2003 2003
1 1 0 0 0
2 0 0 1 0
,   0 0
3 0 1
All records with „1“ in the third 1 0 0 0
4
column of the bitmap Index. 5 0 1 0 0
6 0 0 1 0
7 0 1 0 0
8 0 0 0 1
9 1 0 0 0
10 0 0 1 0
11 0 1 0 0
12 0 1 0 0
13 0 0 1 0
14 0 0 0 1
15 0 1 0 0
16 1 0 0 0
17 0 0 0 1
18 0 0 0 1
19 0 0 0 1

 SAP AG 2003

© SAP AG BW360 4-24


B-Tree vs. Bitmap Index

! % ' ! % '


 Useful on columns with high  Useful on columns with low
cardinality cardinality
 Typically only one index  Several indexes can be used on
used (exception: dynamic the same table for one SQL
bitmap index creation, higher statement, “bitmap merge join”
costs) with lower costs
 More robust during changes  Susceptible for degeneration /
(degeneration possible) deadlocks
 Size of the index independent  Size of the index depends on
of the number of distinct the number of distinct values
values (usually smaller than B-Tree)
 Clustering factor for  No clustering factor
evaluation of quality

 SAP AG 2003

© SAP AG BW360 4-25


Clustered Index

 Clustered Index is used to physically sort a table


-erformance impact
 Higher maintenance effort
 Faster access to data if selected by the cluster index
 Less I/O (less physical blocks read)
 Faster I/O (physical blocks located close to each other)

 SAP AG 2003

© SAP AG BW360 4-26


Indexes on the BW Star Schema: Overview Diagram

DB Statistics

Index Overview

Indexes on the BW Star Schema

Index Handling in BW

Appendix – Typical Errors with Indexes

 SAP AG 2003

© SAP AG BW360 4-27


An InfoCube's Star Schema

 
 


.$ (
  
"$   
/$  
    
,%
   
  ,%
  ,% 
   ,%  
0$ ,%
,%

 SAP AG 2003

This slide illustrates the star schema of an InfoCube. An InfoCube is a multi-dimensional reporting
scenario built out of

characteristics, such as "month“, "product“, "city“, "sales organization" etc. and key figures,
such as "costs“, "profit“, "sales" etc.
Physically,an InfoCube is a set of DB tables that are related to one another in a star schema. This is
a very common technique in data warehousing and many database vendors have tuned their various
DBMS products to recognize star schema scenarios by providing techniques such as star joins and
bitmap indexing schemes.
The boxes in this slide represent various tables; the lines show the foreign key – key relationships
between those tables. In the center of a star schema lies the fact table which contains a huge amount
of data; in particular it holds all the information on the key figures. All the other tables are relatively
small in comparison to the fact table. The dimension tables group related characteristics such as
"city", "region" and "country". Finally, the master data tables hold information on the characteristics,
for example, attributes like the "color" or the "price" of a product.
In thisexample, there are dimensions on time, region, product and sales organization. Thus the fact
table holds information on sales figures, profit, costs etc. per day, product, city and sales
organization.
Each query on such a star schema uses/materializes a certain subset of those relationships.

© SAP AG BW360 4-28


Example: InfoCube IUSALES

(
  

  .

,-  $
1 $

 SAP AG 2003

Here we see a subset of tables of the InfoCube IUSALES's star schema. The red arrows connect the
respective forreign key column (end of the arrow) with the corresponding key column (head of
arrow):

The fact table contains one foreign key column per InfoCube dimension and a column per key
figure (of the InfoCube).

The dimension table consists of a dimension id (DIMID) column which constitutes the primary
key of the dimension plus a column per characteristic in that dimension. Those columns hold SID
(surrogate id) values of the corresponding characteristic.

In the 3rd layer there is are SID-tables of the characteristics. This can be a standard S-table
(contains only relationship between SID and characteristic key), an X-table (SID-key relationship
plus SID columns per time-independent navigational attribute) or a Y-table (SID-key relationship,
timestamp, SID columns per time-dependent navigational attribute) .

In the 4th layer there are standard S-tables for navigational attributes.

© SAP AG BW360 4-29


Indexing Common For All Databases

(
  

  .

,-  $
1 $
non-unique, Oracle: Bitmap Index
unless „high cardinality
dimension“ or transactional
InfoCube, DB2/400: EVI, other
databases: B-Tree, DB2/390: not on
first column (P-Dimension)
B-Tree (unique)
 SAP AG 2003

This slide shows the indexing scheme for an InfoCube common for all databases:
In the standard case, the fact table in Oracle has single column indexes on the dimension columns.
For Oracle these are usually bitmap indexes

- An exception are columns of high cardinality dimensions which have a (non-unique) B-tree
rather than a bitmap index.
BW on DB2/400 uses the so called Encode Vector Indexes (EVI). EVIs are a further development

of bitmap indices for DB2/400 which are compact in size, fast to build and very efficient for the
access to the table data. EVIs are important in an ad hoc query environment where combining
multiple indixes is a bigger requirement than having perfect index just for one pre-canned query.
More detailed information on EVIs:
http://www-919.ibm.com/servers/eserver/iseries/developer/bi/evi.html
- How to setup the EVIs for the fact tables?
Please refer to the following SAP notes:
- 501572 “EVI stage 2 support”
- 541508 “Checking the system parameters”
A dimension table has a primary index (i.e. a unique B-tree) on its DIMID column.
X- and Y-tables only have a primary key.
S-tables have a primary key index – the primary key comprises the characteristic key column(s) –
and a unique index on the SID column. The uniqueness of the latter is a kind of additional check to
assert the uniqueness of the SIDs.

© SAP AG BW360 4-30


Fact Table Indexing

((

( (
  

&(

&(
  

non-unique, Oracle: Bitmap Index


,ingle column indexes: queries unless „high cardinality
dimension“ or transactional
--index: compress InfoCube, DB2/400: EVI, other
databases: B-Tree, DB2/390: not on
first column (P-Dimension)
B-Tree
 SAP AG 2003

This slide shows the indexing scheme of the standard InfoCube fact tables. Both fact tables do not
have primary indexes but a so called "P-index" (e.g. /BIC/EIUSALES~P). It comprises all dimension
columns of the fact table. However, it does not enforce a unique constraint. This is the only
difference with the originally existing primary index.
On the E fact table the P-index is specifically designed to support the InfoCube compression process.
In such a situation, BW has to check the E fact table for existing dimension id combinations in order
to decide whether the currently processed record (which originates in the F fact table) is to be
inserted (when ist dimension id combination does not exist in the E fact table so far) or updated (in
the other case). A missing P-index can therefore cause a very considerable decrease in compression
performance.

© SAP AG BW360 4-31


Fact Table Indexing – Details

%ndex over all dimensions keys


 Usually non-unique “P-Index” (/BIC/F<InfoCube>~P,
/BIC/E<InfoCube>~P)
 Oracle and Informix
 Not on F-Fact table
 MSS
 Non-clustered
 Unique 0-Index on E-Fact table
 DB2/UDB
 Clustered index
 Order: Time Dimension, Dimension 1, Dimension 2, …
 DB2/390
 Unique 0-Index on E-Fact table

 SAP AG 2003

© SAP AG BW360 4-32


InfoCube (Transactional, Oracle)

((

( (
  

High cardinality

&(

& (
  




!itmaps replaced by B-trees to support


concurrent write & read operations
Bitmap Ind. (Oracle)
B-Tree (unique)
B-Tree (non-unique)
 SAP AG 2003

This slide shows the indexing scheme of a transactional InfoCube for Oracle. Such InfoCubes are
currently only used in the context of SEM – check OSS note 333260 for details. The only difference
with a standard InfoCube lies in the indexing of the F fact table. Here, bitmap indexes are replaced
by standard B-tree indexes. The reason behind this is that such InfoCubes are used in a transactional
context with many concurrent users reading from and writing into the InfoCube (i.e. into the F fact
table). Bitmap indexes cannot support such a scenario because Oracle provides no row-level locking
for bitmap indexes. This leads to deadlock situations (ORA-60) if users concurrently update a bitmap
indexed fact table.

© SAP AG BW360 4-33


InfoCube (Partitioned, Oracle only)

((

((
  

partitioning column
&(

&(
  




dditional bitmap index on F fact table


pplies also to transactional InfoCubes Bitmap Ind. (Oracle)
amed: /BIC/F...~900 B-Tree (unique)

 SAP AG 2003
B-Tree (non-unique)

This slide shows the indexing scheme of fact tables of a partitioned InfoCube. The siginificant
issue here is an additional bitmap index on the column of the F fact table that corresponds to the
partitioning column (time characteristic the InfoCube is partitioned by) of the E fact table (see red
box). This index's name is "900", i.e. "/BIC/F...~900" on the database.
The reason behind that index is to support restrictions that are likely to exist on this column. In case
of a partitioned E fact table, the BW SQL-generator translates time restricitions into restrictions on
the partitioning column whenever possible. This allows the Oracle query optimizer to prune the
query to the relevant partitions on the E fact table. The "900" index allows the F fact table to benefit
from those additional (and redundant) restrictions too.
There is no difference between standard and transactional InfoCubes. However, in the case of
transactional InfoCubes it is assumed that this is the only bitmap index on the F fact table.
Otherwise, transactional write accesses would result in deadlock situations. Please refer to the
discussion of deadlocking on the transactional InfoCube slide.

© SAP AG BW360 4-34


Star Join Execution Plan (Example)

 SAP AG 2003

Here a typical star query execution plan for a BW query is shown. The single column bitmap indexes
are used to propagate query restrictions to the fact table, thereby minimizing the amount of relevant
facts at a very early stage of query processing. This is the reason why those operations are found in
the lower part of the execution tree.
The execution plan on this slide is a typical example. Almost every BW query should show this kind
of execution pattern. Obviously, it highly depends on using bitmap indexes. If those indexes are not
employed for whatever reason (they do not exist, there are no restrictions, Oracle's query optimizer
chooses an execution plan without bitmap indexes etc.) then you will typically experience very high
run times.
In the case of transactional InfoCubes and single column B-tree indexes, Oracle is supposed to
transform the relevant B-tree indexes into bitmap indexes at run time ("B-tree to bitmap
conversion"). This is an additional computational step which consumes resources, thus star queries
on B-tree indexed fact tables are less efficient than similar queries supported by bitmap indexes.

© SAP AG BW360 4-35


Indexing of a Dimension Table

  .

B-Tree (unique)
B-Tree (non-unique)

 
   
 Is determined by the order in the InfoCube


 !"20##
 No index on every SID column (additional indexes can be helpful,
though)
3,,
 Individual index on all SID columns
 No common index over all SID columns

 SAP AG 2003

A dimension table has the primary index and the following secondary indexes:

Index over all SID columns supporting loading

Index on each individual column but the first one supporting querying. The first SID column
doesn’t need a single index because it is the first column in the index over all SID columns.

The order of the fields in the dimensions is determined by the order of the InfoObjects in the
InfoCube which depends on the transactional data load.

© SAP AG BW360 4-36


Indexing of Master Data (X-, Y-) Tables

1 $

2BIC/XIUCITY~0
rimary index  hese indexes are not defined by BW
4.. but can be helpful
4.. depending on the actual queries
& .g. if there are restrictions on nav. attr.
an be bitmap or B-tree indexes
 SS note 402469
 SAP AG 2003

This slide shows an example of a master data table, in this case an X-table (characteristic SIDs and
SIDs of time-independent navigational attributes). What is said about the X-table similarly applies to
the Y-table (characteristic SIDs and SIDs of time-dependent navigational attributes).
An X-table only has a primary index. However, depending on actual queries it might be useful to set
up additional indexes:

on the column(s) of the characteristic values, in this example on the column /BIC/IUCITY,

single column indexes on the columns of the naviagtional attributes.
The decision whether to create such additional indexes or not depends on the actual queries and
whether those queries impose restrictions on the respective characteristics or navigational attributes.
BW usually translates restrictions to SID-based restriction.
Thus, indexing the characteristic value column(s) is rarely necessary, e.g. if the restriction is interval-
based as such restrictions usually cannot be mapped to an equivalent SID-based restriction. Single
column indexes on restricted navigational attributes are more likely to be helpful. Depending on the
cardinality of the attribute you might decide to use a bitmap index (low cardinality, e.g. an attribute
"color" with a handful of values) or a standard B-tree index (medium or high cardinality, e.g.
population numbers as in the example on the slide).
Obviously one has to find a good trade-off when defining a number of supportive indexes: too many
additional indexes can harm data upload processes as those indexes have to be maintained.
Therefore, it is not recommended that such indexes are defined arbitrarily. On the other hand, such
new indexes can enhance the query performance.

© SAP AG BW360 4-37


Indexing of Master Data SID-Tables

,% 
,%

2BIC/SIUCITY~0 2BIC/SIUCITY~001
-rimary index 5nique (to enforce unique SIDs)
,upports value  SID conv. ,upports SID  value conversion
,upports restrictions on SIDs

 SAP AG 2003

An SID-table for a characteristic has two unique B-tree indexes: the primary index on the
characteristic value column(s) and an index on the SID column. The unique constraint on the SID
column is a double-check to avoid a SID value being inserted twice (multiple SID entries for the
same value can have terrible effects in BW's OLAP engine). Both indexes support the frequently
used function that converts a given SID into the corresponding characteristic value and vice versa.
There is no need for additional indexes on SID-tables.

© SAP AG BW360 4-38


APO-Indexing-Specifics

-ossible additional secondary index on F fact table


 OSS note 363092
 Supports APO-mass-update jobs
 Index name contains a letter, e.g. /BIC/FIUSALES~A12
-rimary index for APO InfoCubes
 APO InfoCubes = InfoCubes with "BW application" APO
 APO cannot cope with duplicates in InfoCubes
 APO InfoCubes have a primary index "P" on F fact table
5nique (rather than non-unique) index on dimension tables
 Same reason as for primary index

 SAP AG 2003

APO includes a BW-system: APO 2.0 is based on BW 1.2, APO 3.0 is based on BW 2.0. There are
three APO-specific issues related to indexing an InfoCube:

In order to support a mass-update job it might be useful to define an additional secondary index on
the F fact table of the respective InfoCube. OSS note 363092 describes how to define such an
index. Normally, it is not necessary to define additional indexes on InfoCube fact tables and we
strongly discourage customers to do that. However, this APO-specific situation is a notable
exception. Please note that additionally defined indexes should contain at least one letter in ist
name. In that way, such indexes are excluded from the regular index dropping and recreation
during data uploads (see OSS note 157169).

APO InfoCubes cannot – like BW's OLAP engine – cope with duplicates in the fact tables. This
imposes unique constraints on the F- and E-fact tables. While BW compression algorithm
guarantees uniqueness in the E-fact table, a primary index on the F-fact table is required.
Therefore APO InfoCubes have F-fact tables with a primary index (whose name is "P" rather than
the standard "0"). Note: APO InfoCubes are InfoCube whose "BW application" is set to "APO".
You can check column BWAPPL in table RSDCUBE to be sure if an InfoCube's BW application
is APO.

For the same reason, one has to avoid multiple dimension Ids for the same combination of
characteristic values. This can be achieved by defining the concatenated index on a dimension
table to be unique. See slide about indexing of dimension tables.

© SAP AG BW360 4-39


Index Handling in BW: Overview Diagram

DB Statistics

Index Overview

Indexes on the BW Star Schema

Index Handling in BW

Appendix – Typical Errors with Indexes

 SAP AG 2003

© SAP AG BW360 4-40


RSA1 – Admin Workbench

6 7 


7 
7 
 InfoCube
 Right mouse menu
 "Manage"
 Tabstrip
"Performance"

   
 Secondary F- and E-fact table indexes (except dropping during loading only
on F)
 But not to user-defined indexes containing a letter, e.g. /BIC/FIUSALES~A12
 And not to primary indexes
 
8Checks
 
8 status (mainly existence, index type)
 
 Drops
 indexes
9 
9  re-creates
 non-existing indexes, coalesces existing indexes
 SAP AG 2003

Theeasiest user interface for index handling can be found in the BW admin workbench (transaction
RSA1):

go to the respective InfoCube

click on the right mouse button and choose "Manage" in the menu that shows up

go to the tabstrip "Performance"
This will provide you with the screen that is shown on the slide. The operations that are offered on
this screen apply to

all secondary indexes on an InfoCube's F- and E-fact tables

but not indexes that have been defined by a user, i.e. that contain at least a letter in their name

and not primary indexes.
In thecontext of aggregates, they apply to the corresponding indexes on fact tables of all the
aggregates of that InfoCube. The following operations are available:

check: this checks the status of the indexes, in particular whether they exist and if yes then if they
are of the expected type (bitmap or B-tree). Typically non-existing indexes will lead to a red light
whereas wrong index types lead to a yellow light. More details of the checks can be seen via
transaction RSRV (see below)

delete: this will drop all the indexes

repair: this operation will recreate non-existing indexes; for Oracle on existing indexes it will
perform a coalesce operation which is supposed to tackle the problem of degenerated indexes

© SAP AG BW360 4-41


RSRV – BW Check Routines

-erforms a check on fact


table and aggregate indexes
-rovides a detailed list of the
analysis
9epairs the indexes

6 
7 
7 
7 
 Transaction RSRV
 Provide technical name of InfoCube
 Tabstrip database  "indices ..."

 SAP AG 2003

You get to this screen by



calling transaction RSRV

clicking on the node "Database"

dragging the check "Indices of ...“ to the right hand side

providing the technical name of the respective InfoCube
There are buttons to

check the indexes: press "Analysis" (or F8)

list the messages that has been collected by the check routine: press "Results" (or F6)

repair the indexes: press "Repair" (or Strg + F6)
The check and repair operations have been described in the context of RSA1 (Admin Workbench).

© SAP AG BW360 4-42


SE14 – Customizing Indexes via ABAP Dictionary

  :
 Tablespace,
 Extent sizes, ...
 ' 
  ;
 ;
 
 
 "Current (DB)"
 "Technical settings"
 "For new creation"
!
$ 


!
$ 

 7 7  
 7 ,,.)<")*$
1. SE14 "For new creation" settings, if not ...
2. Those imposed by the TABART, if not ...
3. Default settings
% 
7     8
  8 ,&.0

 SAP AG 2003

Transaction SE14 is not BW-specific but a general transaction provided by the ABAP data
dictionary to customize technical settings of database tables and indexes. This transaction is not easy
to handle. It is therefore recommended only for experienced users. Here is how to get to the situation
that index parameters are to be changed:
 call transaction SE14
 provide the name of the database table and press "Edit"
 press "Indexes" (or F5)
 choose the respective index from the pop-up
 press "Storage parameters" (or Strg + F6)
This will lead you to the screen as shown above. Typically, the parameter values as currently set on
the database are shown. There are two more options available:
 the parameters as they were originally set ("technical settings")
 the parameters as they have been set by a user ("For new creation")
If you want to change a parameter value, e.g. the tablespace, then you need to do the following
(assuming no user has previously changed anything for that index):
 press "For new creation"
 mark an index
 press "Create parameter values" (or Strg + F4)
 possibly choose the template for the user-defined values, e.g. use the current DB settings
 now you can change the parameter
 press "Save"

© SAP AG BW360 4-43


Now the parameters are set for the next time the index is created. That means that the current setting
remains. In order to activate the new settings you have to drop the index and re-create it.
BW employs a cascading algorithm to determine the parameters for an index:
use the settings provided in SE14 under "For new creation"
if such settings are not available then use the settings provided by the underlying TABART (only
applies to the tablespace)
if such settings are not avaliable then use the default settings.
If one parameter has been changed then option 1. applies to all other parameters too!

© SAP AG BW360 4-44


DB02 – Missing Indexes On the Database

B02  button "missing indexes"


%f many fact table indexes are missing then ...
9un ABAP reports (OSS note 157918):
 SAP_UPDATE_DBDIFF
 SAP_INFOCUBE_INDEXES_REPAIR
heck DB02 again

 SAP AG 2003

Transaction DB02 is frequently used by administrators to check for missing indexes: simply call
transaction DB02 and press the button "Missing Indexes". This will lead you to the screen shown in
the lower left-hand corner of the slide. If many fact table primary or secondary indexes are missing
then you might apply OSS note 157918. Then run the ABAP reports:

SAP_UPDATE_DBDIFF, and

SAP_INFOCUBE_INDEXES_REPAIR
and check DB02 again. Details of the reports are provided on the following slide.

© SAP AG BW360 4-45


ABAP Reports (delivered by BW)

,-=5-&=!%(( updates table DBDIFF


 Fact tables without primary index
 Temporary views
 Other temporary objects (see OSS note 308533 for temp. obj.)
 Needs to be run only once
,-=%(5!&=%&1&,=9&-%9
 Applies to all active InfoCubes and aggregates
 Drops existing primary index (BW 1.2 left-overs)
 Re-creates missing P-indexes
 Re-creates missing secondary indexes
 Should be run as a batch job
 
8,,
 
8,, .*)>.<

 SAP AG 2003

BW provides two ABAP reports that are relevant for indexing problems. Further details of the
context are described in OSS note 157918.
SAP_UPDATE_DBDIFF


This report updates the table DBDIFF which lists tables or tablespaces that do not comply with
ABAP dictionary standards. In the context of BW these are fact tables withouth primary index and
temporary objects (tables, views, triggers, ...). This report will make sure that fact tables and
temporary objects are properly listed in DBDIFF which – in turn – is used by DB02. DB02 will
take differences into account that are listed in DBDIFF and therefore will not list those differences
as errors. The report has to be run only once in order to make up for differences that originate from
BW 1.2 or BW 2.0A and that remained when the system was updated to BW 2.0B. All objects that
are created in BW 2.0B or above should be tracked DBDIFF when they are activated.
SAP_INFOCUBE_INDEXES_REPAIR


This report applies to all active InfoCubes and their aggregates. It removes existing primary
indexes – these might be left-overs from BW 1.2 – recreate missing P-indexes and recreate
missing secondary indexes. This report can be used to repair InfoCube indexes system-wide, i.e.
without looking at each InfoCube individually. This is particularly interesting for administrators.
The report should be run as a batch job as it might run for a while.

© SAP AG BW360 4-46


Appendix: Overview Diagram

DB Statistics

Index Overview

Indexes on the BW Star Schema

Index Handling in BW

Appendix – Typical Errors with Indexes

 SAP AG 2003

© SAP AG BW360 4-47


Index-Related Errors (1)

9."<#.
9
 Error during parallel index rebuild
 Actual error has occurred before
 Check system log or alert files for actual error

9?##@"##<'A9
9 ?##@"##<'A9"<?#0
 Fragmentation
 Check OSS notes 159779, 356333

9.0.<
9
 Actually, this is no error
 Refer to OSS note 337830
9?##@?#*#A9
9 ?##@?#*#A9"*#."
 Failing COALESCE statement
 Check OSS note 373188

 SAP AG 2003

This and the following slides list some typical errors whith indexes under Oracle. Please check the
corresponding OSS notes for details.

© SAP AG BW360 4-48


Index-Related Errors (2)

B!  
B!   ' 7 

7 
B
7 
 B
 OSS note 178275

B3  7 
B3  7  'B
'B
 See DB02 slide
 Check OSS note 157918

B7   '
'B
B
 Affect performance
 Situation 1: regular upload of the same hierarchy (I-table)
 Situation 2: regular deletion of requests (InfoCube F fact table)
 Situation 3: regular rollups (aggregate fact tables)
 Check OSS notes 323090, 304861

 SAP AG 2003

© SAP AG BW360 4-49


Index-Related "Consultancy"

B 7 
B 7  ' 7B
' 7B
 See SE14 slide
 Check OSS note 335725

6   
   '
 OSS note 383325

    
    '
 OSS note 402469

 SAP AG 2003

© SAP AG BW360 4-50


Error Handling

Check the  7,3".$ to track down the SQL error

or – if appropriate –

use 9,9C
9,9C7   why a traffic light is
7     
yellow or red

 
8,,0#."0"    
'  
 ' .

 SAP AG 2003

© SAP AG BW360 4-51


Indexing: Unit Summary

   


 Explain what indexes are and how they are used
 Explain the usage of indexes in BW
 Analyze and fix index related problems

 SAP AG 2003

© SAP AG BW360 4-52


BW Statistics


 Business Information Warehouse Statistics

 SAP AG 2003

© SAP AG BW360 5-1


BW Statistics: Unit Objectives

 

       
 Describe how statistical information is collected in BW
 Switch on the BW statistics
 Analyze the BW statistics

 SAP AG 2003

© SAP AG BW360 5-2


BW Statistics: Overview Diagram

Architecture and Customizing

InfoCube Data Model Transactional Data Targets

Transport Management
ODS Objects

Indexing
Process Chains

BW Statistics
Extraction and Dataload

Reporting Performance
Partitioning
Aggregates

 SAP AG 2003

© SAP AG BW360 5-3


Workload Analysis: R/3 Compared to BW

 
 Many totally different  Execution of queries is the
transactions (e.g. VA01, dominant type of processing
FD01, batchinput, ...). with a clearly defined sequence,
 99 % SAP Standard but customer-defined content.
transactions, which  99 % Customer defined queries,
have been tuned by which have to be tuned by the
SAP before. customer.
 Mixture of read and  More detailed data necessary
write activities. about the different steps of a
query execution for tuning
activities.

ST03  average response time: ST03  average response time:


good measure for performance of not useful in BW, because too rough.
system
Separation on query level necessary

 SAP AG 2003

Difference to R/3: the standard workload monitor (ST03 – Administrator) or the detailed statistical
records (STAD) are not useful in BW.
Special BW statistics are necessary for tuning BW Queries
The average response time itself isnot a valuable value for performance measurement in BW,
because the structure of a query and design of the corresponding InfoProvider strongly influences the
runtime and therefore the response time.
It makes no sense, for example, to define a maximal ‘average response time’.

© SAP AG BW360 5-4


Stastistics for Queries
BEx Web
Analyzer Browser
Front-end  Amount of
Query data
execution transferred to
the frontend? Frontend
time?

Number of rows OLAP



transferred to the time?


application
server?

Application Server Database


 Number of rows time?
Database Server selected on the
database?

Aggregates
InfoCube
Data

 SAP AG 2003

For each query the OLAP processor collects statistical data from several levels:

Statistical data for the activities on database level (e.g. database time, number of rows selected,
number of rows transferred, ...)

Statistical data for activities on the application server (e.g. OLAP init time, OLAP time, number of
cells...)

Statistical data for activities on the frontend (e.g. frontend time, ...)

© SAP AG BW360 5-5


BW Statistics

!pecial statistics are available for BW


 Adapted to the special BW process (e.g. query execution, data load, ...)
 Including:
 Detailed information about amount of records that are transferred
 Split up of runtimes in read times, insert times, OLAP times, frontend times, ...
 Data about frontend operation (amount of cells which have to be filled, runtime on
the frontend, ...)
"ou have to turn on these statistics for each InfoProvider manually

OLAP means: collecting of


statistical information for
OLAP activities (Query
execution/navigation)

WHM means: collecting of


statistical information for
WHM activities (load
processes, changerun, ...)

 SAP AG 2003

Recommendation: BW statistics (OLAP and WHM) should be switched on for all or at least critical
InfoProviders.

© SAP AG BW360 5-6


Consequences

#f the BW statistics are turned on, the systems collects data. This
data is inserted in different tables:

Tables, which are filled Tables, which are filled


by OLAP: by WHM:
RSDDSTAT RSDDSTATWHM
RSDDSTATAGGR RSDDSTATCOND
RSDDSTATAGGRDEF RSDDSTATDELE, ...

BW Statistics: Entry Mode


InfoCube Description

Partner: ID Numbers

 SAP AG 2003

After applying the special buttons for turning on BW statistics, for each WHM or OLAP activity new
statistical records are created an stored in the corresponding tables.
For WHM there are just a few records inserted in the table RSDDSTATWHM, ...
For OLAP much more statistical data is generated (many inserts in RSDDSTATAGGRDEF) 
deletion of entries periodically!
Negative influences on the OLAP/WHM performance are not noticed yet.
If BW statistics switched on for InfoCubes, tables RSDDSTAT* are filled. If you use RSRT in
“Debug-Mode” and you set the flag “Display Statistics Data”, the tables RSDDSTAT* are filled for
ODS objects too.
Tables are growing continuously
No archiving object for these tables available
Solution:
For reorganization of these tables use deletion button in RSA1  Tools  BW Statistics  delete.
You have to specify the time range. Entries from all statistic tables RSDDSTAT* will be deleted.

© SAP AG BW360 5-7


Analysis of BW Statistics

Technical content Direct analysis of tables RSDDSTAT*

  
!!$!%%& 
!!$!%%& 

Collecting information from table ST03 – BW System Load Restriction of ST03:


RSDDSTAT
#nformation about
query performance
and aggregate
maintenance available,

Function module 'o information about


RSDDCVER_RFC_BW_ load processes
STATISTICS
 SAP AG 2003

To analyze BW OLAP/WHM performance, the following tools can be used:



Tables RSDDSTAT*

Queries of BW statistics InfoCubes (Technical content cubes are filled by InfoSources that extract
data from tables RSDDSTAT*)

ST03 for BW

With BW3.0B ST03 = ST03N

Function module RSDDCVER_RFC_BW_STATISTICS not user friendly, but it is available
for RFC

© SAP AG BW360 5-8


Technical Content – Activation

Administrator Workbench: Business Content

 SAP AG 2003

For activation of technical


content use the description from online help (search for item “technical
content”) and check note 309955.
Activation and collection takes a long time. Therefore execute both activities in background.

© SAP AG BW360 5-9

You might also like