Professional Documents
Culture Documents
!
SAP AG©2003
SAP AG 2003
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.
"##
"
Knowledge of the subject matter
covered by BW310 (BW Data
Warehousing) dealing with the BW
Administrator Workbench
!!#
-
SAP AG 2003
$
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.
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
Basic customizing of BW
General administrative tasks
Settings for improving performance
SAP AG 2003
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
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
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
!"
#
! "
#
"
# $
!
$
!%
$
!%
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
Alias: patches
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 2003
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.
,
, #+
#
,
BW-database Datastructure and Design
Web Application Server Query design
IGS Caching and buffering
Sizing Precalculation
SAP AG 2003
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
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
Redo logs
Harddisk Large:
Temp area > 15 GB
SAP AG 2003
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
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!)
.!
.!
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.
!
!"$!
$
!
!"$!
$
!"$!
$
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 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 2003
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.
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 2003
.
%%##
,! 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!
HTTP
Internet
RFC/HTTP
RFC
HTML + Java
Chart-
Engine
IGS
GIS
Engine
SAP AG 2003
(*/&,
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 2003
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
Result should be …
SAP AG 2003
Server
Virtual memory
Shared memory Local memory
1:1
1:n
Work Work Work
SAP roll file process process
...
process
SAP paging file
SAP AG 2003
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
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.
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.
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
1:1
1:n
Work Work Work
SAP roll file process process
...
process
SAP paging file
SAP AG 2003
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
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
SAP AG 2003
Actions
Write
Delete
Read
Management
SAP AG 2003
SAP AG 2003
SAP AG 2003
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
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??)
%$!
%$!
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
%$!
%$!
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
SAP AG 2003
SAP AG 2003
SAP AG 2003
General Overview
Reorganization
BW Database Settings
Sizing
WebApplicationServer Settings
Appendix
SAP AG 2003
/.%
/ .%!+
.%!+
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
SAP AG 2003
RSCUSTV8
RSCUSTV9
RSCUSTVA2
RSCUSTV16
RSCUSTV6
RSCUSTV1
RSCUSTV3
RSBWREMOTE
RSCUSTV12
RSCUSTV2
SAP AG 2003
RSCUSTV2
RSCUSTV5
RSCUSTV4
RSCUSTV14
RSCUSTV11
RSCUSTV13
RSCUSTV15
SAP AG 2003
SAP AG 2003
Check: System Status (DB Release, SAP Kernel, Support package level)
SAP AG 2003
Check active flag at least for each of your performance critical cubes
SAP AG 2003
SAP AG 2003
Performance traces
SAP AG 2003
SAP AG 2003
Requirements Modeling
SAP BW Data Model
Extended Star Schema
Dimension Modeling
SAP AG 2003
Describe the SAP data model and the star schema
Explain the role of dimensions
Handle various data modeling issues
SAP AG 2003
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
SAP AG 2003
Dimension
Table
Master Text
Dimension Dimension
SID Table Hierarchy
Hierarchy Table Table
Fact
Table
Master Text Master Text
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.
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
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
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.
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
1 01.01.2002 1 100
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.
(2) Dimension
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 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 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 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 2003
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?
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
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!
System landscape in BW
Object versioning
Transports in R/3 source systems
Specific transport objects in BW
SAP AG 2003
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
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
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
BW
R/3
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 2003
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.
BW
3
RFC 2 RFC RFC
1
R/3
SAP AG 2003
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 2003
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)
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.
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 2003
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 2003
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
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.
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 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.
1. Select one or
3.Write to transport
several objects
request
New Objects
(Package $TMP) are
marked
automatically
SAP AG 2003
SAP AG 2003
Create and use your own packages, don‘t use SAP packages.
If there are dependent objects already written to other transport requests make sure those other
requests are released in time.
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.
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 2003
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 2003
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 2003
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 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.
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
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 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.
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
System copy
BW
R/3
Development Consolidation Production
O1 O2 O3
System copy
SAP AG 2003
: QAS-BW is refreshed by homogeneous system copy
(e.g. restore of offline backup from PRD-QAS)
BW
SAP AG 2003
: 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
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
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
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
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, ...)
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
SAP AG 2003
!
Perform transports in BW landscapes
Decide when standard or BW transport system should be
used
SAP AG 2003
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)
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.
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-5 Create an update rule from your InfoSource T_BW360_sflight## to your InfoCube
TRANSP##. Acitvate your update rule without any change.
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?
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?
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##’
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’
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.
##
propose transfer
rules
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.
Right mouse click on your source system IDES R/3 , choose create InfoPackage…
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?
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?
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
Overview Indexes In General
Indexing In BW
SAP AG 2003
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
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
DB Statistics
Index Overview
Index Handling in BW
SAP AG 2003
SAP AG 2003
Index A
Full
table
scan
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 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)
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.
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.
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.
!"#$
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
DB Statistics
Index Overview
Index Handling in BW
SAP AG 2003
SAP AG 2003
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 2003
SAP AG 2003
&'
&'
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.
(
)*
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
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).
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.
Index entry (value)
Block number Block x I1 I2 I3 I4
&'
&'
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.
!
!
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.
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.
+ 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 2003
SAP AG 2003
DB Statistics
Index Overview
Index Handling in BW
SAP AG 2003
.$ (
"$
/$
,%
,%
,%
,%
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.
(
.
,-
$
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.
(
.
,-
$
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.
((
( (
&(
&(
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 2003
((
( (
High cardinality
&(
& (
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.
((
((
partitioning column
&(
&(
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 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.
.
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.
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.
,%
,%
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 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.
DB Statistics
Index Overview
Index Handling in BW
SAP AG 2003
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
6
7
7
7
Transaction RSRV
Provide technical name of InfoCube
Tabstrip database "indices ..."
SAP AG 2003
:
Tablespace,
Extent sizes, ...
'
;
;
"Current (DB)"
"Technical settings"
"For new creation"
!
$
!
$
77
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"
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 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 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.
DB Statistics
Index Overview
Index Handling in BW
SAP AG 2003
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.
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
B 7
B 7
'
7B
'
7B
See SE14 slide
Check OSS note 335725
6
'
OSS note 383325
'
OSS note 402469
SAP AG 2003
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 2003
Business Information Warehouse Statistics
SAP AG 2003
Describe how statistical information is collected in BW
Switch on the BW statistics
Analyze the BW statistics
SAP AG 2003
Transport Management
ODS Objects
Indexing
Process Chains
BW Statistics
Extraction and Dataload
Reporting Performance
Partitioning
Aggregates
SAP AG 2003
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.
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’.
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 2003
Recommendation: BW statistics (OLAP and WHM) should be switched on for all or at least critical
InfoProviders.
#f the BW statistics are turned on, the systems collects data. This
data is inserted in different tables:
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 2003