Basis week5

© SAP AG 1999
TABC30 Technical Consultant Training Week 5:
Performance Analysis & Tuning
Technical Consultant Training:
Technical Consultant Training:
TABC30R/3 Release 4.6C 50039594
TABC30R/3 Release 4.6C 50039594
Week 5Week 5
Oct-19-2000

© SAP AG 1999
Copyright 2000 SAP AG. All rights reserved.
Neither this training manual nor any part thereof may
be copied or reproduced in any form or by any means,
or translated into another language, without the prior
consent of SAP AG. The information contained in this
document is subject to change and supplement without prior
notice.
All rights reserved.
Copyright
n Trademarks:
n Some software products marketed by SAP AG and its distributors contain proprietary software components of other
software vendors.
n Microsoft®, WINDOWS®, NT®, EXCEL®, Word® and SQL Server® are registered trademarks of Microsoft
Corporation.
n IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®,
and OS/400® are registered trademarks of IBM Corporation.
n ORACLE® is a registered trademark of ORACLE Corporation, California, USA.
n INFORMIX®-OnLine for SAP and Informix® Dynamic ServerTM are registered trademarks of Informix Software
Incorporated.
n UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of The Open Group.
n HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium,
Laboratory for Computer Science NE43-358, Massachusetts Institute of Technology, 545 Technology Square, Cambridge,
MA 02139.
n JAVA® is a registered trademark of Sun Microsystems, Inc. , 901 San Antonio Road, Palo Alto, CA 94303 USA.
n JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and
implemented by Netscape.
n SAP, SAP Logo, mySAP.com, mySAP.com Marketplace, mySAP.com Workplace, mySAP.com Business Scenarios,
mySAP.com Application Hosting, WebFlow, R/2, R/3, RIVA, ABAP™, SAP Business Workflow, SAP EarlyWatch, SAP
ArchiveLink, BAPI, SAPPHIRE, Management Cockpit, SEM, are trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the world. All other products mentioned are trademarks or registered
trademarks of their respective companies.
n Design: SAP Communications Media

Contents
Course Overview......................................................................................................................................................................1
Target Group ........................................................................................................................................................................2
Course Prerequisites............................................................................................................................................................3
Course Goals ........................................................................................................................................................................4
Course Composition............................................................................................................................................................5
TABCUO - Sections...........................................................................................................................................................6
TABCNS - Sections............................................................................................................................................................7
TABCNO - Sections...........................................................................................................................................................8
Section: Workload Analysis ...................................................................................................................................................9
Introduction to Workload Analysis ................................................................................................................................10
Introduction to Workload Analysis ............................................................................................................................11
Introduction: Performance Bottlenecks .....................................................................................................................12
Typical Tuning Measures ............................................................................................................................................13
R/3 Basis Tuning Tasks ...............................................................................................................................................14
R/3 Application Tuning Tasks ....................................................................................................................................15
Multi-Tier Client/ Server Architecture ......................................................................................................................16
Dialog Step: Wait Time ...............................................................................................................................................17
Dialog Step: Roll-in time .............................................................................................................................................18
Dialog Step: Database Time ........................................................................................................................................19
Dialog Step: Access to SAP Buffers..........................................................................................................................20
Dialog Step: Response time ........................................................................................................................................21
Dialog Step: Roll out time ...........................................................................................................................................22
Summary: Response Time Components ...................................................................................................................23
CPU Time .......................................................................................................................................................................24
Workload Statistics (1).................................................................................................................................................25
Workload Statistics (2).................................................................................................................................................26
Initial Analysis Roadmap (1) ......................................................................................................................................27
Initial Analysis Roadmap (2) ......................................................................................................................................28
Analysis Roadmap: Using the Workload Monitor..................................................................................................29
Performance Monitors for the R/3 Basis ...................................................................................................................30
Transaction Profile ........................................................................................................................................................31
Statistical Records.........................................................................................................................................................32
Analysis Roadmap: Using the Transaction Profile .................................................................................................33
Performance Monitors for R/3 Applications............................................................................................................34
Availability of the New Workload Transactions.....................................................................................................35
Workload Statistics (until 4.6B) .................................................................................................................................36
Transaction Profile (until 4.6B) ..................................................................................................................................37
Summary of this Unit ...................................................................................................................................................38
Performance Analysis Monitors......................................................................................................................................39
Performance Analysis Monitors .................................................................................................................................40
Performance Monitors for the R/3 Basis ...................................................................................................................41
Work Process Overview...............................................................................................................................................42
Analysis Roadmap: Using the Work Process Overview ........................................................................................43
Operating System Monitor ..........................................................................................................................................44
OS Monitor: TOP CPU Processes..............................................................................................................................45
Setups / Tune Buffers Monitor (1).............................................................................................................................46
Setups / Tune Buffers Monitor (2).............................................................................................................................47
Getting Started Exercise...............................................................................................................................................48
Workload Analysis Exercise.......................................................................................................................................49
Work Process Overview...............................................................................................................................................50
Workload Monitor.........................................................................................................................................................51
Setups / Tune Buffers Monitor...................................................................................................................................52
Poor Configuration Example .......................................................................................................................................53
Optimal Configuration .................................................................................................................................................54
Workload Monitor.........................................................................................................................................................55
Setup / Tune Buffers Monitor.....................................................................................................................................56
Reasons for Program Buffer Swaps...........................................................................................................................57
Summary of this Unit ...................................................................................................................................................58
R/3 Memory Management ...............................................................................................................................................59
R/3 Memory Management...........................................................................................................................................60
R/3 Memory Management...........................................................................................................................................61
First Topic in Unit .........................................................................................................................................................62

R/3 Memory Areas........................................................................................................................................................63
Physical and Virtual Memory .....................................................................................................................................64
R/3 Memory I: Local Memory for Work Processes................................................................................................65
R/3 Memory II: R/3 Buffers ........................................................................................................................................66
R/3 Memory III: Extended Memory ..........................................................................................................................67
R/3 Memory IV: Heap Memory .................................................................................................................................68
R/3 Memory V: Roll Memory ....................................................................................................................................69
R/3 Memory VI: Paging Memory ..............................................................................................................................70
R/3 Memory - System Point of View........................................................................................................................71
R/3 Memory Areas - Summary...................................................................................................................................72
Next Topic in Unit ........................................................................................................................................................73
User Context Data.........................................................................................................................................................74
Roll Out (1) ....................................................................................................................................................................75
Roll Out (2) ....................................................................................................................................................................76
Roll In..............................................................................................................................................................................77
Roll Area and Paging Area..........................................................................................................................................78
Roll Buffer and Paging Buffer....................................................................................................................................79
R/3 Extended Memory .................................................................................................................................................80
Allocation Concepts - Summary (1) ..........................................................................................................................81
Allocation Concepts - Summary (2) ..........................................................................................................................82
Allocation Sequence for Dialog WPs (1)..................................................................................................................84
Heap Memory and PRIV Mode (1)............................................................................................................................90
Heap Memory and PRIV Mode (2)............................................................................................................................91
Allocation Sequence for Dialog WPs - Overview...................................................................................................92
Allocation Sequence for Dialog WPs - Summary ...................................................................................................93
Allocation Sequence for Non-Dialog WPs ...............................................................................................................95
Freeing Heap Memory (1) ...........................................................................................................................................97
Parameter ABAP/HEAPLIMIT...............................................................................................................................100
Memory Management Parameters ..........................................................................................................................101
Demonstration: Testing Memory Limits (1) .........................................................................................................102
Demonstration: Testing Memory Limits (2) .........................................................................................................103
R/3 Memory Consumption.......................................................................................................................................104
Mode List.....................................................................................................................................................................105
Work Process Overview............................................................................................................................................106
Analysis Roadmap: R/3 Memory Configuration..................................................................................................107
Workload Analysis Exercise....................................................................................................................................108
Workload Analysis Exercise: Solution...................................................................................................................109
Insufficient Extended Memory ................................................................................................................................110
Sufficient Extended Memory ...................................................................................................................................111
Next Topic in Unit .....................................................................................................................................................112
Zero Administration Memory Management..........................................................................................................113
R/3 Extended Memory on UNIX (1)......................................................................................................................114
R/3 Extended Memory on UNIX (2)......................................................................................................................115
Benefits of 64-Bit Address Space for R/3..............................................................................................................116
R/3 Extended Memory on NT..................................................................................................................................117
Summary of this Unit ................................................................................................................................................118
Appendix: Menu Paths for R/3 Memory Management .......................................................................................119
Hardware Capacity Verification ..................................................................................................................................120
Hardware Capacity Verification..............................................................................................................................121
Hardware Capacity Verification..............................................................................................................................122
First Topic in Unit ......................................................................................................................................................123
What is a Hardware Bottleneck? .............................................................................................................................124
Hardware Bottlenecks ...............................................................................................................................................125
Hardware Analysis Roadmap (1) ............................................................................................................................127

Response Time Components ....................................................................................................................................129
Exercise Analysis: Work Process Overview .........................................................................................................132
Exercise Analysis: Workload Monitor...................................................................................................................133
Exercise Analysis: Operating System Monitor.....................................................................................................134
Exercise Analysis: Top CPU Processes .................................................................................................................135
Exercise Analysis: Conclusion (1)..........................................................................................................................136
Exercise Analysis: Conclusion (2)..........................................................................................................................137
Checking Tuning Results (1) ...................................................................................................................................138
Optimizing Memory Configuration (1) ..................................................................................................................142
Optimizing Memory Configuration (2) ..................................................................................................................143
Checking R/3 Virtual Memory Allocation ............................................................................................................144
Configuring CPU (1) .................................................................................................................................................145
Configuring CPU (2) .................................................................................................................................................146
Appendix: 32 Bit Configuration Example (1) .......................................................................................................148
Appendix: 32 Bit Configuration Example (2) .......................................................................................................149
Appendix: Quick Sizing (1) .....................................................................................................................................150
Expensive SQL Statements...........................................................................................................................................154
Expensive SQL Statements ......................................................................................................................................155
Expensive SQL Statements ......................................................................................................................................156
Topics Covered Elsewhere .......................................................................................................................................157
What is an Expensive SQL Statement?..................................................................................................................159
Consequences of Expensive SQL Statements.......................................................................................................160
Detecting Expensive SQL Statements....................................................................................................................162
Monitors for Detection and Analysis......................................................................................................................163
Detection Using the Transaction Profile ................................................................................................................164
Detection Roadmap (1) .............................................................................................................................................165
Detection Using the Work Process Overview.......................................................................................................166
Detection Using the Database Monitor..................................................................................................................167
Detection Using the Database Process Monitor....................................................................................................168
Detection Using the Database Lock Monitor........................................................................................................169
Monitoring Buffer Gets / Disk Reads (1)...............................................................................................................171
Detection Using the SQL Trace (1) ........................................................................................................................174
Detection Using the SQL Trace (2) ........................................................................................................................175
Detection Using the Where-Used List....................................................................................................................176
SQL Statement Exercise (1) .....................................................................................................................................178
SQL Statement Exercise (2) .....................................................................................................................................179
Exercise Solution for 1st SQL Statement...............................................................................................................180
Exercise Solution for 2nd SQL Statement.............................................................................................................181
Two Types of Expensive SQL Statements ............................................................................................................183
Detailed Analysis of Expensive SQL Statements.................................................................................................184
Detailed Analysis of Expensive SQL Statements.................................................................................................185
Index Use in SQL Statements (1) ............................................................................................................................186
Rules for Creating a Secondary Index (1)..............................................................................................................189
Rules for Creating a Secondary Index (2)..............................................................................................................190
Additional Tips for Creating a Secondary Index..................................................................................................191
Optimizer Determination of Access Path...............................................................................................................192

Table Statistics for the Optimizer............................................................................................................................193
Checking the Optimizer using EXPLAIN .............................................................................................................194
Why Optimizer Decisions May Cause Performance Problems ..........................................................................195
Tips for Optimizing ABAP Coding (1) ..................................................................................................................196
Tips for Optimizing ABAP Coding (2) ..................................................................................................................197
Tuning Roadmap ........................................................................................................................................................199
Workload Analysis Exercise: Detection ................................................................................................................201
Workload Analysis Exercise: Solution...................................................................................................................202
Before-and-After Comparison.................................................................................................................................203
Appendix1: Optimizing ABAP Database Programming.....................................................................................205
ABAP Database Programming ................................................................................................................................206
Creating Efficient SQL Statements.........................................................................................................................207
Tuning Checklist for ABAP Coding (1) ................................................................................................................208
Appendix 2: Database Locks and R/3 Enqueues..................................................................................................211
Exclusive Lock Waits (1) .........................................................................................................................................212
R/3 Enqueues versus Database Locks ....................................................................................................................215
Using R/3 Enqueues and Database Locks..............................................................................................................216
Locking and Performance.........................................................................................................................................217
OS Monitor and Top CPU Processes......................................................................................................................218
The Database Process Monitor................................................................................................................................219
R/3 Table Buffering .......................................................................................................................................................220
R/3 Table Buffering...................................................................................................................................................221
R/3 Table Buffering...................................................................................................................................................222
Table Buffers in R/3 ..................................................................................................................................................224
Why Use Table Buffe rs in R/3? (1) ........................................................................................................................225
Why Use Table Buffers in R/3? (2) ........................................................................................................................226
Table Buffering Types...............................................................................................................................................227
Buffer Synchronization (1) .......................................................................................................................................228
Granularity of Invalidation .......................................................................................................................................231
Setting the Buffering for a Table .............................................................................................................................232
SQL Statements Bypassing the Buffer (1).............................................................................................................233
SQL Statements Bypassing the Buffer (2).............................................................................................................234
SQL/Buffering Exercise............................................................................................................................................235
SQL/Buffering Exercise Solution (1) .....................................................................................................................236
SQL/Buffering Exercise: 2nd Run of ZZBUFFER.............................................................................................243
Buffering Strategy: Technical Criteria ...................................................................................................................245
Buffering Strategy: Application Criteria ................................................................................................................246
Buffering Strategy: Condition Tables.....................................................................................................................247
Buffering Optimization .............................................................................................................................................248
Analysis Roadmap: Using the Transaction Profile ..............................................................................................250
Table Call Statistics (Transaction ST10) ...............................................................................................................251
Analysis Roadmap: Using Table Call Statistics ...................................................................................................252
Detection Roadmap: Monitoring Table Buffering ...............................................................................................253
Example: Monitoring Table Buffering...................................................................................................................254
Example: Table Analysis (1)....................................................................................................................................255
Example: Table Analysis (2)....................................................................................................................................256
Example: SQL Cursor Cache...................................................................................................................................257

Summary......................................................................................................................................................................258
Appendix: ATP Server..............................................................................................................................................259
Introduction: Availability Checks with ATP Logic .............................................................................................260
First Topic in Appendix............................................................................................................................................261
Material Locking (1)..................................................................................................................................................262
Material Locking (2)..................................................................................................................................................263
Database Accesses .....................................................................................................................................................264
Next Topic in Appendix............................................................................................................................................265
Overview of ATP Related Techniques...................................................................................................................266
Locking with Quantities (1) .....................................................................................................................................267
Locking with Quantities (2) .....................................................................................................................................268
ATP Server (1)............................................................................................................................................................269
ATP Server (2)............................................................................................................................................................270
ATP Server (3)............................................................................................................................................................271
Next Topic in Appendix............................................................................................................................................272
Monitoring the Export/Import Buffer.....................................................................................................................273
Monitoring R/3 Enqueues.........................................................................................................................................274
Monitoring SQL Statements.....................................................................................................................................275
Setting ATP Server Parameters ...............................................................................................................................276
Interface Monitoring ......................................................................................................................................................277
Interface Monitoring..................................................................................................................................................278
Processing Modes.......................................................................................................................................................279
mySAP.com Interfaces..............................................................................................................................................280
Remote Function Calls (RFCs)................................................................................................................................281
'Simple’ Transaction Step.........................................................................................................................................282
Transaction Step with Synchronous RFC..............................................................................................................283
RFC Monitoring : Statistical Records.....................................................................................................................284
RFC Monitoring : Statistical Sub-Records (1) ......................................................................................................285
RFC Monitoring : Statistical Sub-Records (2) ......................................................................................................286
RFC Monitoring: RFC Destinations.......................................................................................................................287
RFC Monitoring: Performance Trace .....................................................................................................................288
R/3 Release 4.6: Enjoy SAP.....................................................................................................................................290
Interaction Model: Controls Technology...............................................................................................................291
Interaction Model: Implications for Performance ................................................................................................292
Transaction Step with Roundtrip .............................................................................................................................293
Example (I): ST03 - High Roll Wait Time ............................................................................................................294
Example (II): STAD - Statistical Record ...............................................................................................................295
RFC Monitoring: Performance Trace .....................................................................................................................296
Trouble Shooting : High GUI Time ........................................................................................................................297
Example (III): ST06 - Network Check by Ping ....................................................................................................298
Trouble Shooting : High GUI Time (2)..................................................................................................................299
Trouble Shooting: New Visual Design...................................................................................................................300
Trouble Shooting: LOW Speed Connection..........................................................................................................301
Trouble Shooting: SAP Easy Access Menu..........................................................................................................302
Remote Function Calls (RFC and aRFC) ..............................................................................................................304
Troubleshooting: Incoming RFC Load (Problem) ...............................................................................................305
Troubleshooting: Incoming RFC Load (Monitoring)..........................................................................................306
Troubleshooting: Incoming RFC Load (Solution) ...............................................................................................307
Troubleshooting: Outgoing RFC Load (Monitoring) ..........................................................................................308
Troubleshooting: High RFC Load...........................................................................................................................309
Remote Function Calls: tRFCs ................................................................................................................................310
Exercise: Work Process Monitor.............................................................................................................................313
Exercise: User Overview ..........................................................................................................................................314
Exercise: Workload Monitor (RFC Profile) ..........................................................................................................315
Exercise: Transactional RFC Monitor....................................................................................................................316
Conclusion | Appendix..................................................................................................................................................317
Conclusion...................................................................................................................................................................318
Further Documentation .............................................................................................................................................319
Analysis Roadmap: Using the Workload Monitor...............................................................................................320
Analysis Roadmap: Using the Transaction Profile ..............................................................................................321
Analysis Roadmap: Using the Work Process Overview (1) ...............................................................................322

Analysis Roadmap: Using the Work Process Overview (2) ...............................................................................323
Analysis Roadmap: Using the Operating System Monitor (1)...........................................................................324
Analysis Roadmap: Using the Operating System Monitor (2)...........................................................................325
Analysis Roadmap: R/3 Memory Configuration..................................................................................................326
Analysis Roadmap: Using Table Call Statistics ...................................................................................................327
Section: Technical Optimization of ALE Processing...................................................................................................328
Technical Optimization of ALE Processing..............................................................................................................329
Goals.............................................................................................................................................................................330
Intent of ALE..............................................................................................................................................................331
Distributing Data ........................................................................................................................................................332
Business Scenario.......................................................................................................................................................333
Typical Scenario .........................................................................................................................................................334
Technical Background of ALE ....................................................................................................................................335
How ALE Works - Step 1.........................................................................................................................................336
Sender Details - Three Ways to an IDOC..............................................................................................................339
Sender Details - First Way to an IDOC..................................................................................................................340
Sender Details - Second Way to an IDOC............................................................................................................341
Sender Details - Third Way to an IDOC................................................................................................................342
Communication Methods..........................................................................................................................................343
TRFC Details 1 ...........................................................................................................................................................344
TRFC Details 2 ...........................................................................................................................................................345
TRFC Communication Error Handling..................................................................................................................346
Communication Details - Sender FTP....................................................................................................................347
Communication Details - Receiver FTP ................................................................................................................348
R/3 Communications to Ext. Programs ..................................................................................................................349
R/3 Communications.................................................................................................................................................350
Receiver Details - Unwrapping an IDOC ..............................................................................................................351
IDOC Processing Options.........................................................................................................................................352
Sender Details .............................................................................................................................................................353
IDOC Processing Options.........................................................................................................................................354
Update Details ............................................................................................................................................................356
Basic Functions used by ALE 1...............................................................................................................................357
ARFC: usage of RFC groups...................................................................................................................................358
ARFC: Resource determination...............................................................................................................................359
Basic Functions used by ALE 2...............................................................................................................................360
Structure of an IDOC.................................................................................................................................................361
Customizing ................................................................................................................................................................362
Batch Administration.................................................................................................................................................363
Administration............................................................................................................................................................364
Analysis Tools and Optimization Methods................................................................................................................365
IDOC Lists Overview................................................................................................................................................366
Time Distribution of IDOC Creation......................................................................................................................367
IDOC Trace.................................................................................................................................................................368
TRFC Monitor............................................................................................................................................................369
Monitoring Transactions...........................................................................................................................................370
Job List of ALE User on Sender Side.....................................................................................................................371
Dialog Work is Disturbed at Receiver....................................................................................................................372
Outbound Processing Options..................................................................................................................................373
Inbound Processing Options (1) ..............................................................................................................................374
Inbound Processing Options (2) ..............................................................................................................................375
RFC Customization....................................................................................................................................................376
The 10 Golden ALE Rules (1).................................................................................................................................377
Analysis Flow Chart.......................................................................................................................................................380
Possible Performance Problems ..............................................................................................................................381
Analysis and Tuning Flowchart (1).........................................................................................................................382
Application Data Does not Arrive (Subchart 1)....................................................................................................383
Application Data Does not Arrive (Subchart 1.1) ................................................................................................384
Application Data Does not Arrive (Subchart 1.2) ................................................................................................385
Application Data Arrive too Late (Subchart 2).....................................................................................................386
Application Data Arrive too Late (Subchart 2.1) .................................................................................................387

Application Data Arrive too Slow (Subchart 3)....................................................................................................390
Dialog Work is Disturbed (Subchart 4)..................................................................................................................391
Dialog Work is Disturbed at Sender (Subchart 4.1).............................................................................................392
Dialog Work is Disturbed at Receiver (Subchart 4.2).........................................................................................393
Exercises - Technical Optimization of ALE Processing..........................................................................................394
Solutions - Technical Optimization for ALE Processing........................................................................................396

© SAP AG 1999
Course Overview

© SAP AG 1999
Target Group
l Audience:
n future SAP R/3 Technical Consultants
n experienced System Administrators
n experienced Database Administrators
n with no or less R/3 knowledge
l Duration: 5 weeks

© SAP AG 1999
Course Prerequisites
l In-depth knowledge of the UNIX or NT operating system,
the ORACLE or MS SQL Server database and TCP/IP
network administration.
l Practical experience with these issues is essential for
passing the SAP R/3 Certified Technical Consultant exam.

© SAP AG 1999
Course Goals
l Course participants receive comprehensive expert level
training in R/3 System management
l The course prepares participants for the “SAP R/3 Certified
Technical Consultant” exam.

© SAP AG 1999
Course Composition
UNIX/ORACLE: TABCUO = TABC10 + TABC20 + TABC30
NT/ORACLE: TABCNO = TABC11 + TABC20 + TABC30
NT/MS SQL Server: TABCNS = TABC11 + TABC21 + TABC30
5 weeks = 3 weeks + 1 week + 1 week

© SAP AG 1999
TABCUO - Sections
TABC10
Section SAP Basis Technology
Section Technical Core Competence - UNIX
Section Software Logistics
Section R/3 Technical Implementation and Operation Management
Section Advanced R/3 System Administration
Section Ready-to-Run
Section Technical Core Competence - Workplace
TABC20
Section Database Administration ORACLE
Section SQL Cache Analysis - CBO - ORACLE
TABC30
Section Workload Analysis
Section Technical Optimization of ALE Processing

© SAP AG 1999
TABCNS - Sections
TABC11
Section Technical Core Competence - NT
Section R/3 Technical Implementation and Operation Management
TABC21
Section Database Administration MS SQL Server
Section SQL Cache Analysis - CBO - MS SQL Server
TABC30

© SAP AG 1999
TABCNO - Sections
TABC11
Section Technical Core Competence - NT
Section R/3 Technical Implementation and Operation
Management
TABC20
Section Database Administration ORACLE
Section SQL Cache Analysis - CBO - ORACLE
TABC30

© SAP AG 1999
Section: Workload Analysis
1. Introduction to
Workload Analysis
6. R/3 Table Buffering
2. Performance Analysis
Monitors
7. Interface Monitoring
3. R/3 Memory
Management
4. Hardware Capacity
Verification
5. Expensive SQL
Statements

© SAP AG 1999
Introduction to Workload Analysis
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements

© SAP AG 1999
Contents:
l Review of multi-tier R/3 architecture
l Workload analysis theory
Objectives:
At the end of this unit you will be able to:
l Outline multi-tier R/3 architecture
l Interpret the Workload Monitor
l Outline the tuning potential of an R/3 System
l Explain the standard methods for approaching
a performance problem
Introduction to Workload Analysis

© SAP AG 1999
Introduction: Performance Bottlenecks
System bottlenecks
l Hardware (CPU, RAM, I/O,
network)
l Configuration
(memory/buffer
configuration,
process configuration)
Long-running programs
l Unnecessary functionality
l Non-optimal implementation
n Technical implementation (e.g.
database indexes, table
buffering, ABAP coding)
n Logical implementation (non-
optimal use of SAP standard
functionality
Long-running
programs may cause
system bottlenecks
System bottlenecks may
cause long-running
programs

© SAP AG 1999
Basis Tuning
l Goal:
n Distribute the given workload
optimally to avoid performance
bottlenecks
l Responsible persons:
n Technical team leader
n System/database administrator
n Technical consultant
Application Tuning
l Goal:
n Avoid unnecessary workload
by optimised programs and
optimal usage of applications
l Responsible persons:
n ABAP developers
n Application consultant
n System/database administrator
n Technical consultant
Typical Tuning Measures

© SAP AG 1999
l Optimize system parameters (S)
n R/3 parameters (for example, for memory management)
n Database parameters (for example, for database buffer sizes)
n Operating system and network parameters
l Optimize database disk layout through I/O balancing (S)
l Optimization of workload distribution (S)
n Number of work processes, background scheduling, log-on groups
l Verify hardware sizing by detecting hardware bottlenecks (S)
____________________________________
: Covered in this course
S: Performed by the R/3 System administrator
R/3 Basis Tuning Tasks

© SAP AG 1999
l Find and apply SAP Notes from SAPNet (D,S)
n Bug fixes, corrections, patches, hints
l Optimize the SAP Customizing (D)
n For example, in SD and PP
l Optimize ABAP-coding of customer’s modifications (D)
n For example, Z reports, user exits
l Create, change or drop indexes (D,S)
l Design table buffering (D,S)
___________________________________
S: R/3 System administrator
D: R/3 developer, R/3 application consultant
R/3 Application Tuning Tasks

© SAP AG 1999
LAN / WAN
Presentation
Application
Database
Create
Production
Orders
Release
Production
Orders
Schedule
Production
Accept
Customer
Order
Confirm
Delivery
Build
Products
Explode
Bill-of-
Material
Reserve
Material
Customer
Service
Rep
Plant
Personnel
Production
Order
Customer
Order
Part Material Task
Internet
LAN
LAN / WAN
Multi-Tier Client/ Server Architecture
n The diagram shows a common way of setting up the hardware components for a multi-tier system
architecture.
n One larger machine contains the database as well as the central application server that is mainly used
for administration and monitoring work.
n A number of application servers, each on its own machine, allow the connection of users and form
the application layer.
n The internet layer translates SAP screens to HTML readable format. It consists of SAP Internet
Transaction Servers and Web Servers (such as the Microsoft Internet Information Server or Netscape
Enterprise Server).
n The presentation layer consists of the SAP GUIs or Web browsers that run on user PCs.

© SAP AG 1999
Database
Layer
Network
Application
Layer
Presentation
Layer
Network
Wait queue
(memory)
. . .
Work process
Dispatcher
Wait time
Presentation server
Dialog Step: Wait Time
n This and the following slides describe the sequence of actions that contribute to total response time
in multi-tier architecture.
n To complete the logon process, the presentation server connects with a dispatcher.
n When the user tries to run a transaction, the user's request comes from the presentation server to the
dispatcher and is put into the local wait queue.
n When the dispatcher recognizes that a work process is available, the user's request is taken from the
wait queue and sent to the work process.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Dispatcher
Roll buffer
Roll fileRoll file
Roll memory
. . .
Work process
ExtendedExtended
memorymemory
Roll-in time
Dialog Step: Roll-in time
n When a user is dispatched to a work process, "user context" data – the user's logon attributes,
authorizations, and other relevant information – is transferred from the roll buffer, extended memory,
or the roll file into the work process. This transfer (by copying or mapping, as appropriate) of user
context data into work process memory is the mechanism known as a "roll in".
n Transaction processing then begins.

© SAP AG 1999
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Roll buffer
Roll fileRoll file
Roll memory
Dispatcher
ExtendedExtended
memorymemory
Database
Layer
Database
buffers
. . .
Work process
Database
process
Database
interface
Database time
Dialog Step: Database Time
n If data from the database is required to support transaction processing, a request for data is sent to the
database interface, which in turn sends a request through the network to retrieve the information
from the database.
n When it receives the request, the database searches its shared memory buffers. If the data is found, it
is sent back to the work process. If the data is not found, it is loaded from the disk into the shared
memory buffers.
n After being located, the data is taken from the shared memory buffers and sent back across the
network to the requesting database interface. Transaction processing resumes.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Database
buffers
Roll buffer
Roll fileRoll file
Dispatcher
Database
process
Extended memoryExtended memory
Database
interface
Roll memory
. . .
Work process
R/3 shared pool buffers
Dialog Step: Access to SAP Buffers
n Before accessing the database service, the database interface searches for the data in the R/3 buffers.
If the data is found, it is relayed back to the work process where processing resumes. If the data is
not found, the database interface sends a request over the network to retrieve the information from
the database (as described on the last slide).
n If the data loaded from the database is eligible for R/3 buffering, it is placed in the R/3 buffers.
Transaction processing resumes.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Database
buffers
Roll buffer
Roll fileRoll file
Database
interface
Roll memory
. . .
Work process
Dispatcher
SAP shared pool buffers
Database
process
ExtendedExtended
memorymemory
Response time
Dialog Step: Response time
n When transaction processing is completed, the dispatcher is notified of its completion. The results of
the transaction are then sent back to the presentation server.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Database
buffers
Dispatcher
Database
process
Roll buffer
Roll fileRoll file
Database
interface
Roll memory
. . .
Work process
ExtendedExtended
memorymemory
Roll out time
Dialog Step: Roll out time
n After the transaction finishes and the work process is no longer required, the user context data is
rolled out of the work process.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Database
buffers
Roll buffer
Roll fileRoll file
Database
interface
Roll memory
. . .
Work process
Dispatcher
Database
process
ExtendedExtended
memorymemory
Response time
Database request time
Roll-in time
Wait time
Summary: Response Time Components
n This slide summarizes the previous slides describing the sequence of actions that contribute to total
response time in multi-tier architecture.

© SAP AG 1999
Database
Layer
Network
Network
Application
Layer
Presentation
Layer
Wait queue
(memory)
Database
buffers
Roll buffer
Roll fileRoll file
Database
interface
Roll memory
ABAP processing
. . .
Work process
Dispatcher
Database
process
Extended memoryExtended memory
CPU time
CPU Time
n CPU time is the amount of time during which a particular work process has active control of the
central processing unit (CPU).

© SAP AG 1999
CPU time
Presentation
Server
Roll
in
Load
time
Processing timeWait
time
Database time
Response time
Application Server Database Server
NetworkNetwork
NetworkNetwork
Workload Statistics (1)
n Workload time statistics include:
Ÿ Response time in milliseconds: Starts when a user request enters the dispatcher queue; ends when
the next screen is returned to the user. The response time does not include the time to transfer from
the screen to the front end.
Ÿ Wait time in milliseconds: This is the time a user request sits in the dispatcher queue. It starts
when user request is entered in the dispatcher queue; and ends when the request starts being
processed.
Ÿ Roll-in time in milliseconds: The amount of time needed to roll user context information into the
work process.
Ÿ Load time in milliseconds: The time needed to load from the database and generate objects like
ABAP source code, CUA, and screen information.
Ÿ Processing time : This is equivalent to response time minus the sum of wait time, database request
time, load time, roll time, and enqueue time.
Ÿ Database request time : Starts when a database request is put through to the database interface;
ends when the database interface has delivered the result.
Ÿ CPU time in milliseconds: This is the CPU time used by the R/3 work process
n Roll-wait time and GUI time are covered in the unit Interface Monitoring.

© SAP AG 1999
Workload Statistics (2)
SAP Transaction ST03N,
the Workload Monitor,
summarizes statistics
n To access the Workload Monitor, use Transaction code ST03N. or, from the R/3 initial screen,
choose Tools → Administration → Monitor → Performance → Workload → Analysis. Choose
Performance database and make the selections required by the dialog boxes. The Performance:
Workload Overview for Server is displayed.
n In the “Administrator’s Mode” that is chosen by default the time frame of the workload analysis is
the current day.
n Important for this training:
Ÿ Change to “Expert Mode”. Choose under “Detailed Analysis” -> “Last minutes load”
Ÿ During a workload exercise, restrict the time period to the time when the exercise is running.
n Under Analysis views, you can access, for example:
Ÿ Workload overview - Workload statistics according to work process type
Ÿ Transaction Profile - Workload statistics according to transaction.
Ÿ Time Profile - Workload statistics according to hour
n See also the R/3 Knowledge Product CD, System Monitoring.
n Note: Roll wait time and GUI time are explained in section 7, Interface Monitoring.

© SAP AG 1999
AllAll
transactionstransactions
affected?affected?
Program
analysis
No
Yes
(Cont.)
Performance
problem?
Check:
WorkloadWorkload
on all serverson all servers
Problem symptoms:
Large load timeLarge load time
Processing timeProcessing time
much larger thanmuch larger than
CPU timeCPU time
Large databaseLarge database
request timesrequest times
(Average)Large CPU timesLarge CPU times
Large roll-wait timeLarge roll-wait time
Initial Analysis Roadmap (1)
n If a problem is detected, the data in the Workload Monitor (Transaction ST03N) can be used as
follows to identify the area of the system where the problem is located.
n First check for general performance problems affecting all transactions. Good general performance
is normally indicated by:
Ÿ Wait time < 10% response time
Ÿ Main menu (choose Transaction Profile) < 100 ms
n In the Workload Monitor, the following values normally indicate good performance:
Ÿ Average roll-in time < 20 ms
Ÿ Average roll wait time < 200 ms
Ÿ Average load (and generation) time < 10 % of response time (<50 ms)
Ÿ Average database request time < 40 % of (response time - wait time)
Ÿ Average CPU time < 40 % of (response time - wait time)
Ÿ Average CPU time Not much less than processing time
Ÿ Average response time - Depends on customer requirements – there is no general rule

© SAP AG 1999
Program buffer, CUA buffer, or screen buffer too smallLarge load timeLarge load time
CPU bottlenecks, network problems,
communication problems
Processing timeProcessing time
much larger thanmuch larger than
CPU timeCPU time
CPU/memory bottleneck on database server, network
problems, expensive SQL statements, database locks,
missing indexes, missing statistics, small buffers
Large databaseLarge database
request timesrequest times
(Average)Large CPU timesLarge CPU times Expensive ABAP processing, for example, processing
large tables, frequent accessing of R/3 buffers
Communication problem with GUI
or external system
Large roll-wait timeLarge roll-wait time
Initial Analysis Roadmap (2)
n These are some of the more common problems indicated by Workload Monitor statistics.

© SAP AG 1999
Analysis Roadmap: Using the Workload Monitor
R/3 Workload Monitor (ST03N)
High database time: database time > 40% (response time - wait time)
Detailed analysis of the database
Processing time > CPU time x 2
Detailed analysis of hardware bottlenecks
? Wait time > 10% of response time
General performance problem
Load time > 50 ms
Detailed analysis of R/3 memory configuration (is the program buffer
too small?)
Roll-wait time or GUI time > 200 ms
Detailed analysis of interfaces and GUI communication
Transaction Profile (Transaction ST03) sorted by “Response time total”
Programs with high CPU time: CPU time > 40% (response time - wait time)
!
?
?
?
?
?
n For more detail on analyzing:
Ÿ The database, see the unit Expensive SQL statements
Ÿ R/3 memory configuration, see the unit R/3 Memory Management
Ÿ Hardware bottlenecks, see the unit Hardware Capacity Verification
Ÿ Interfaces and GUI problems, see the unit Interface Monitoring

© SAP AG 1999
Database
Monitor
Setups
Buffers
Operating System
Monitor
Work Process
Overview
Workload Monitor
… Details in the following units
Transaction
ST04
Transaction
ST02
Transaction
ST06
Transaction
SM50 / SM66
Transaction
ST03 or
ST03N
Performance Monitors for the R/3 Basis
n To begin a workload analysis, use the Workload Monitor (Transaction ST03 or ST03N).
n If you find statistics that indicate a performance problem, use the other monitoring tools to
obtain further data on the problem.

© SAP AG 1999
Transaction Profile
n In the Workload Monitor, choosing Transaction Profile enables you to find out:
Ÿ The most-used transactions. Tuning these transactions creates the greatest improvements in overall
performance.
Ÿ The average response times for typical R/3 transactions.

© SAP AG 1999
Statistical Records
n To access the statistics records for a specific server:
Ÿ As of R/3 Release 4.5, use transaction STAD
Ÿ Prior to R/3 Release 4.5, use transaction STAT or, from the R/3 initial screen, choose Tools
→ Administration → Monitor → Performance → Workload → Statistics Records.

© SAP AG 1999
Analysis Roadmap: Using the Transaction Profile
R/3 Workload Monitor (transaction ST03N)
? Programs with high CPU time: CPU time > 40% (response time - wait time)
...
Transaction Profile (Transaction ST03N) sorted by “Response time total”
Programs with high database time (databases time > 40% (response time - wait time)
Detailed analysis with ABAP-Trace
Detailed analysis of SQL statements
?
? Problems with high GUI times (> 200 ms)
Network check
n To analyze transactions with a large CPU time, use an ABAP trace.
n To analyze transactions with a high database time, use an SQL trace.
n To analyze transactions with a high GUI time, use a network check.

© SAP AG 1999
Statistical
records
SQL trace Application
Monitors
ABAP trace
Workload Monitor
Transaction
ST03N
… Details in the following units
Transactions
ST07 / ST14
Transaction
SE30
Transaction
ST05
Transaction
STAT / STAD
Performance Monitors for R/3 Applications
n Transactions ST07, ST14, and SE30 are not covered in this course.

© SAP AG 1999
4.5B 4.6B4.0B 5.0
STAD
First
availability
Full
functionality
4.6C/D
STAT
General
availability
Last functional
enlargement
Planned last
availability
General
availability ST03
ST03N
First
availability
Planned full
functionality
Availability of the New Workload Transactions

© SAP AG 1999
Workload Statistics (until 4.6B)
SAP Transaction ST03,
the Workload Monitor,
summarizes statistics
n To access the Workload Monitor, use Transaction ST03 or, from the R/3 initial screen, choose
Tools → Administration → Monitor → Performance → Workload → Analysis. Choose Performance
database and make the selections required by the dialog boxes. The Performance: Workload
Overview for Server is displayed.
n To display the 40 slowest dialog steps by response time, choose Top time.
n Under Goto → Profiles, you can access, for example:
Ÿ Task Type Profile - Workload statistics according to work process type
Ÿ Time Profile - Workload statistics according to hour
Ÿ Transaction Profile - Workload statistics according to transaction.
n The proportion of database calls to database requests gives an indication of the efficiency of table
buffering. If access to information in a table is buffered in the R/3 pool buffers, then database calls to
the database server are not needed and performance is better. Thus, the fewer database calls result in
database requests, the better.
n See also the R/3 Knowledge Product CD, System Monitoring.
n Note: Roll wait time and GUI time are explained in section 7, „Interfaces“

© SAP AG 1999
Transaction Profile (until 4.6B)
n In the Workload Monitor, choosing Transaction Profile enables you to find out:
Ÿ Which transactions are used most? Tuning these transactions creates the greatest improvements in
overall performance.
Ÿ What are the average response times for typical R/3 transactions?

© SAP AG 1999
Summary of this Unit
Now you are able to:
l Outline multi-tier R/3 architecture
l Interpret the Workload Monitor
l Outline the tuning potential of an R/3 System
l Explain the standard methods for approaching
a performance problem

© SAP AG 1999
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements
Performance Analysis Monitors

© SAP AG 1999
Contents:
l Monitors: Work Process Overview, Operating System Monitor,
Setups/Tune Buffers
l Getting Started Exercise
l Workload Analysis Exercise
Objectives:
l Use the performance monitors
l Analyze the performance of an R/3 System
l Find performance bottlenecks
Performance Analysis Monitors

© SAP AG 1999
Setups/
Buffers
Database
Monitor
Operating System
Monitor
Work Process
Overview
Workload Monitor
Transaction
ST04
Transaction
ST02
Transaction
ST06
Transaction
SM50 / SM66
Transaction
ST03N
Performance Monitors for the R/3 Basis
n To begin a workload analysis, use the Workload Monitor (transaction ST03).
n If you find statistics that indicate a performance problem, use the other monitoring tools to
obtain further data on the problem.
n The Database Monitor (transaction ST04) will be discussed in the unit Expensive SQL statements.

© SAP AG 1999
Work Process Overview
n To display a snapshot of the current activities on the instance you are logged on to, use the Work
Process Monitor. Call transaction SM50, or, from the R/3 initial screen, choose Tools
→ Administration → Monitor → System monitoring → Process overview.
n The information displayed includes:
- Type of work process
- Name of the ABAP program running
- Operating system PID number
- Client being used
- Name of the job executing
- Current action
- Number of detected errors in the work process
- Table being utilized
- Semaphore resource being used
- CPU accumulation
- Time in process accumulation
- User holding the resource
n If all work processes are being blocked by long running transactions, the above information is also
available on operating system level by using program dpmon.
n In an R/3 System with more than one instance, you can access a global work process overview using
transaction SM66.

© SAP AG 1999
Analysis Roadmap: Using the Work Process
Overview
Work Process Overview (transaction SM50 / SM66)
Work processes in status “running”?
Action: “Dir. Read”, “Seq. Read”, “Insert”, “Update”, “Delete”, “Commit”
Action: “Load program”?
Action: “Roll In” / “Roll Out”?
Detailed analysis of R/3 memory configuration (problems with extended
memory or roll buffer)
Work processes in status “stopped”?
Reason: “PRIV”?
Reason: “CPIC”?
Problems with CPIC connections such as "All work processes blocked in
destination system"?
Detailed analysis of R/3 memory configuration (program buffer too small?)
?
?
?
?
?
?
?
?
n The diagram shows the procedures for analyzing the current workload using the Work Process
Overview (transaction SM50).

© SAP AG 1999
Operating System Monitor
n To call the Operating System Monitor, use transaction ST06, or, from the R/3 initial screen, choose
Tools → Administration → Monitor → Performance → Operating System → Local [or Remote]
→ Activity.
n Important statistics displayed in the Operating System Monitor include:
Ÿ CPU load average and % CPU utilization
Ÿ Operating system swapping and % memory utilization
Ÿ % disk utilization
Ÿ Operating system configuration parameters
n CPU bottlenecks are indicated during several snapshots by:
Ÿ Idle CPU < 10 %
Ÿ Load Average: N processes waiting in front of the CPU
n Note: you must refresh your screen several times, as each display is a momentary snapshot.
n Memory bottlenecks are indicated during several snapshots by:
Ÿ An increase in page outs for UNIX or page ins for NT.
Ÿ This topic is covered in more depth in unit Hardware Capacity Verification.

© SAP AG 1999
OS Monitor: TOP CPU Processes
n "Disp+work" signifies an R/3 work process.
n "ORACLE80" signifies a database process.
n "DOC_SNYDER" is an external processes which does not belong to an R/3 instance or to the
database. External processes may affect performance critically.
n On detecting hardware bottlenecks, see the unit Hardware Capacity Verification.

© SAP AG 1999
Setups / Tune Buffers Monitor (1)
n For the instance on which the user is logged on, the Setups / Tune Buffers monitor shows the
percentage usage of buffers and memory. To access the monitor, use transaction ST02 or, from the
R/3 initial screen, choose Tools → Administration → Monitor → Performance → Setup/buffers
→ Buffers.
n The Setups / Tune Buffers monitor displays data on:
Ÿ Buffer sizes
Ÿ Buffer qualities (hit ratios)
n Bottlenecks may be indicated if buffer swaps occur.
n Choose Detail analysis menu to display other data, such as :
Ÿ Memory usage
Ÿ Semaphores usage
Ÿ Table calls

© SAP AG 1999
Setups / Tune Buffers Monitor (2)
n Max. use (in KB) should be less than In memory (in KB).
n The lower part of the Setups / Tune Buffers monitor displays data on:
Ÿ Extended memory size and usage
Ÿ Usage and configuration of the roll mechanism
n Bottlenecks may be indicated if:
Ÿ For extended memory: Max use. = In memory
Ÿ For roll area: Max use. > In memory
n For a detailed analysis of R/3 memory management, see unit R/3 Memory Management.

© SAP AG 1999
Objectives:
In this exercise you will learn how to:
l Use the R/3 performance monitors
Activities:
l Log on to the training system
l Determine:
n CPU load
n Size of allocated memory and available physical memory
n Which transactions were executed in which R/3 modules
n Response times for these transactions
n Whether there are buffer swaps and
operating system paging
Getting Started Exercise
To perform the Getting Started exercise, enter the required data:
CPU Load ........................
Allocated Memory ........................MB
Physical Memory ........................MB
Top 5 transactions ................., .................., .................., .................., ..................
- Related R/3 modules ................., .................., .................., .................., ..................
- Related response times................., .................., .................., .................., ..................
Buffer Swaps:
Buffer: .............................. Amount: .............................
Buffer: .............................. Amount: .............................
Buffer: .............................. Amount: .............................
Buffer: .............................. Amount: .............................
Buffer: .............................. Amount: .............................
Operating system paging: Yes/No Amount .............................KB/s

© SAP AG 1999
Objectives:
l Analyze a workload problem related to the program buffer
l Distinguish an optimal system configuration from a poor system
configuration with respect to its effect on the program buffer
Activities:
After your trainer starts the workload simulation:
l Use the workload monitors to identify the problem
l Make recommendations
Workload Analysis Exercise

© SAP AG 1999
n To access the Work Process Overview, use transaction SM50.

© SAP AG 1999
Workload Monitor
n To access the Workload Monitor, use transaction ST03 and choose Performance database. Make the
selections required by the dialog boxes. The screen Performance: Workload Overview for Server is
displayed.

© SAP AG 1999
Setups / Tune Buffers Monitor
n To access the Setups / Tune Buffers monitor, use transaction ST02.

© SAP AG 1999
Work
Process
Work
Process
Work
Process
Work
Process
Memory
Code Code
Program buffer
PERFORM Costing.
ENDIF.
SELECT * FROM
MARA
PERFORM Costing.
ENDIF.
SELECT * FROM
MARA
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT
. . .. . .
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT
DATA: A TYPE I,
B TYPE I.
PERFORM DOIT
USING A B.
. . .. . .
REPORT RFBIBL00.
PARAMETERS: A.
SUBMIT RFBIBL01
Change cost center
?? é
éé é
3333
Cost center
Profitfrom
Change cost center
?? é
éé é
3333
Cost center
Profit from
Change cost center
?? é
é é é
3333
Cost center
Profit from
Change cost center
?? é
éé é
3333
Cost center
Profit from
Change cost center
?? é
éé é
3333
Cost center
Profit from
Change cost center
?? é
éé é
3333
Cost center
Profit from
PresentationPresentationApplicationserverApplicationserverDatabaseDatabase
Poor Configuration Example
n The program buffer is set to 110 MB (the SAP instance profile parameter Buffersize is set to
110,000), and the simulation of 10 users for each of MM, SD and PP is started.

© SAP AG 1999
PresentationPresentationApplicationserverApplicationserver
Work
process
Work
process
Work
process
Work
process
Memory
Code
Program buffer
DatabaseDatabase
Code CodeCode
. . .. . .
PERFORM Costing.
ENDIF.
SELECT * FROM
MARA . . .. . .
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT . . .. . .
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT
. . .. . .
PERFORM Costing.
ENDIF.
SELECT * FROM
MARA . . .. . .
SELECT * FROM.
VBAK.
CALL FUNCTION
ENDSELECT. . .. . .
DATA: A TYPE I,
B TYPE I.
PERFORM DOIT
USING A B. . . .. . .
REPORT RFBIBL00.
PARAMETERS: A.
SUBMIT RFBIBL01
Change cost center
??
é
éé é
3333
Cost center
Profit from
Change cost center
??
é
éé é
3333
Cost center
Profit from
Change cost center
??
é
éé é
3333
Cost center
Profitfrom
Change cost center
??
é
éé é
3333
Cost center
Profit from
Change cost center
??
é
é é é
3333
Cost center
Profit from
Change cost center
??
é
é é é
3333
Cost center
Profit from
Optimal Configuration
n The program buffer is set to 400 MB (the SAP instance profile parameter Buffersize is set to
400,000), and the simulation started. The program buffer is now big enough to hold all necessary
code.

© SAP AG 1999
Workload Monitor

© SAP AG 1999
Setup / Tune Buffers Monitor

© SAP AG 1999
Buffer size is too small:
Programs are swapped out, and the reloads cause high load and long DB request times
è Solution: Increase buffer size
Frequently changed programs:
Programs are changed frequently and have to be reloaded, causing buffer swaps
è Solution: Avoid frequent transporting and development in the production system
Reasons for Program Buffer Swaps

© SAP AG 1999
l Use the performance monitors
l Analyze the performance of an R/3 System
l Find performance bottlenecks

© SAP AG 1999
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements
R/3 Memory Management

© SAP AG 1999
Contents:
l R/3 memory areas
l R/3 memory allocation
n Concepts
n Allocation sequence for dialog work processes
n Allocation sequence for non-dialog work processes
n Freeing heap memory
l Demonstration: testing memory limits
l Workload analysis exercise
l Implementing R/3 extended memory
n R/3 memory areas introduces the various R/3 memory areas, which may be physically located in one
or more of the following:
Ÿ Local memory
Ÿ Shared memory
Ÿ File system
n R/3 memory allocation explains what the different memory areas are used for.
n After the demonstration and exercise, the topic Implementing R/3 extended memory compares
memory management for different hardware platforms:
Ÿ UNIX versus Windows NT
Ÿ 32 bit versus 64 bit architecture
n This unit does not explain how large you should make the various memory areas. This is explained
in the following unit, Hardware Capacity Verification.

© SAP AG 1999
Objectives:
l Outline the types of memory in R/3 memory
management
l Explain how these types of memory work together
l Use R/3 memory management monitors
l Configure parameters as part of R/3 memory
management

© SAP AG 1999
First Topic in Unit
l R/3 memory areas
n Concepts
è

© SAP AG 1999
R/3 Memory
Roll memory
Extended
R/3 buffers
WP
WP
R/3 Memory Areas
Users need two
kinds of memory:
n R/3 buffers
Memory accessible to all users, for:
w Programs
w Table and field definitions
w Customizing tables
n User context
Memory attached to individual users, for:
w Variables, lists, internal tables
w Administrative data (such as authorizations)

© SAP AG 1999
Physical and Virtual Memory
Server
Virtual memory
Physical
memory
Maximum virtual memory ≤
physical memory +
operating system swap space * Do not confuse
with R/3 paging !
Operating system
paging file* =
operating system
swap space
n Unlike physical memory, virtual memory can be allocated. The operating system determines if the
allocated memory area resides in the physical memory or in the operating system swap space.
n Depending on the operation system, the maximum size of the virtual memory may vary between the
size of the operating system swap space and the sum of physical memory and operating system swap
space.
n See relevant R/3 Notes in the Online Service System (OSS), for example:
Ÿ R/3 Note 38052, System panic, terminations due to low swapspace
Ÿ R/3 Note 36410, AIX: early versus late swapspace allocation

© SAP AG 1999
R/3 Memory I: Local Memory for Work Processes
Server
Virtual memory
Shared memory Local memory
Work
process
Work
process
Work
process
...
Local
memory
Local
memory
Local
memory
...
1 : 1
Local work process memory is for:
l Executables
l Data, stack
l Buffer for database transfer
l Local roll area
l Local paging area
Local memory
is associated with
individual work
processes

© SAP AG 1999
R/3 Memory II: R/3 Buffers
Server
Virtual memory
Work
process
Work
process
Work
process
...
1 : n
R/3 buffers contain global objects for all
users and work processes, such as
programs, and Customizing tables
Shared memory is
associated with
all the processes of
one instance
R/3 buffers

© SAP AG 1999
R/3 Memory III: Extended Memory
Server
Virtual memory
Work
process
Work
process
Work
process
...
1 : n
Extended memory contains
user contexts – that is, objects
associated with individual
users, such as variables, lists,
and internal tables
Extended
memory

© SAP AG 1999
R/3 Memory IV: Heap Memory
Server
Virtual memory
Work
process
Work
process
Work
process
...
Local
memory
Local
memory
Local
memory
...
Heap memory
(temporary)
1 : 1
Heap memory:
l Contains user contexts, for
example, when extended
memory is full
l Is allocated and released
on demand
Allocated at instance start
Allocated on demand
n In the course of time, none of the memory areas varies in size except R/3 heap memory.

© SAP AG 1999
R/3 Memory V: Roll Memory
Server
Virtual memory
Work
process
Work
process
Work
process
...
1 : n
R/3 roll file
Roll memory contains the
initial part of user contexts
Roll buffer

© SAP AG 1999
R/3 Memory VI: Paging Memory
Server
Virtual memory
Work
process
Work
process
Work
process
...
1 : n
R/3 paging file
R/3 paging memory contains:
l ABAP objects such as extracts
l Context-independent objects such as exports
R/3 paging
buffer

© SAP AG 1999
R/3 Memory - System Point of View
Server
Virtual memory
Work
process
Work
process
Work
process
...
Local
memory
Local
memory
Local
memory
...
Heap memory
(temporary)
1 : n
1 : 1
R/3 roll
file R/3 paging
file
Extended memory
(user contexts)
R/3 buffers
(programs, tables)
R/3 Paging
buffer
Roll buffer

© SAP AG 1999
R/3 Memory Areas - Summary
The six R/3 memory areas are:
l Buffers
l Extended memory
l Heap memory
l Roll memory
l R/3 paging memory
Not to be confused with operating system paging!
l Local work process memory

© SAP AG 1999
Next Topic in Unit
l R/3 memory areas
n Concepts
è

© SAP AG 1999
R/3 userR/3 userR/3 user
111 222 333
R/3 user
444
Data
for user 1
Data
for user 3
Dialog
work
process 1
Dialog
work
process 2
User Context Data
n In an R/3 system, many frontend users are connected to one or more application servers. The work
that users request from the system is performed in work processes. Normally, there are fewer work
processes than frontend users.
n A work process is dedicated to a frontend user only while a specific dialog step is being processed by
the application server. A user can be dispatched to one work process in one dialog step, and to
another work process in the following dialog step. Over the course of time, users are dispatched to
different work processes.
n In the course of their work in dialog work processes, users accumulate various pieces of data, such as
pointers to programs they are using. This accumulated data is called the "user context". A user
context enables, for example, the material number you are working on to be remembered by the
system and proposed as the default in a following transaction.

© SAP AG 1999
111 222 333
R/3 user
444
Data
for user 1
Data
for user 3
Dialog
work
process 1
Dialog
work
process 2
User 2 cannot overwrite the
user context data of user 1
Roll Out (1)
n The mechanism known as a "roll out" ensures that when user 2 needs to use the work process which
has just been used by user 1, the user context data of user 1 is not be lost or overwritten.

© SAP AG 1999
111 222 333
R/3 user
444
Data
for user 1
Data
for user 3
Dialog
work
process 1
Dialog
work
process 2
Copy
Exit
Roll Out (2)
n The roll out saves the user context data for the dialog user when he or she exits the work process.

© SAP AG 1999
111 222 333
R/3 user
444
Data
for user 3
Data
for user 1
Dialog
work
process 1
Dialog
work
process 2
Copy
Roll In
n Work process 1 is occupied by another user. When user 1, who was formerly working in work
process 1, is therefore dispatched to work process 2, the user context data is copied into work process
2 by the mechanism known as a "roll in". User 1 can thus continue from where he or she stopped in
the earlier work process.

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
Paging
area
Memory for specific
ABAP commands
Dialog
work
process 1
User context objects such as:
– Authorizations
– Set/get parameters
– Internal tables
– Report lists
Roll Area and Paging Area
n The data processed in work processes is stored in two memory areas:
Ÿ The roll area, in which user context data is stored. User context data may include pointers to
active programs, set/get parameters (related to the most recent input of the user), authorizations,
internal tables, and report lists.
Ÿ The paging area, which stores the application program data that correspond to specific ABAP
commands including EXTRACT, IMPORT TO MEMORY, EXPORT FROM MEMORY, and
CALL TRANSACTION.
n The size of these areas is configurable using R/3 profile parameters.

© SAP AG 1999
111 222 333
R/3 user
444
Copy
Dialog
work
process 1
Dialog
work
process 2
Paging file
Paging buffer
Roll file
Roll buffer
Roll
area
Paging
area
Roll
area
Paging
area
Roll Buffer and Paging Buffer
n Where there is buffer space available, the roll area and the paging area are held in the respective
buffers in the application servers. When there is not sufficient buffer space, the roll area and the
paging area must be stored in the respective physical disk files (roll file and paging file).
n Thus, the user data processed in work processes is stored in two areas:
Ÿ The roll file and its associated buffer
Ÿ The page file and its associated buffer

© SAP AG 1999
M
apping
111 222 333
R/3 user
444
Swap
Extended
memory
(shared)
Dialog
work
process 1
Dialog
work
process 2
Roll
area
Paging
area
Roll
area
Paging
area
R/3 Extended Memory
n User contexts are not only stored in roll files and the corresponding buffers. As of R/3 Release 3.0,
they are primarily stored in R/3 extended memory.
n In R/3 extended memory, a large area of memory shared by all available work processes can be
accessed through pointers. Using extended memory as well as roll files thus reduces the amount of
copying from roll areas that is required during user context switches, and avoids the overhead caused
by large roll-in or roll-out tasks.

© SAP AG 1999
l In R/3 memory management:
n Work processes serve a large number of frontend users
n Each work process must be capable of loading the user context data
for successive frontend users
l The roll data and paging data is copied to the roll buffer and
paging buffer and the corresponding files when a user
leaves the work process.
Allocation Concepts - Summary (1)

© SAP AG 1999
Allocation Concepts - Summary (2)
l R/3 extended memory uses mapping instead of copying
and therefore allows:
è Fast access to internal tables and lists through pointers
è Quick context switches
è Usage of hardware with large memory
è Reduced load on CPU and disk
l R/3 extended memory requires sufficient physical memory

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
Paging
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
A defined initial portion of
the roll area is used
1st :11stst ::
Allocation Sequence for Dialog WPs (1)
n 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.
n Note: Independent of parameter ztta/roll_first, there is a minimum amount of roll area that is always
used. For example, if ztta/roll_first is set to 1, not just one byte is allocated, but the minimum
amount required for administrative data. As of R/3 release 4.6, this amount is approximately 170KB.

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
Paging
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process
2Extended memory is used
until ...
2nd :22ndnd ::
Mapping
n Extended memory enables the data to be stored in your system, where it is efficiently accessed by
pointers rather than by a copy process.
n The extended memory per user may vary from 1 MB to several 100 MB.

© SAP AG 1999
111 222 333
R/3 user
444
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process
2
Roll
area
Paging
area
... the extended memory is full
or ...

© SAP AG 1999
111 222 333
R/3 user
444
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
... until the user quota is reached
Paging
area
Roll
area
n The user quota defines the maximum amount of R/3 extended memory that can be used by any one
user, and is set with the parameter ztta/roll_extension.
n The user quota thus prevents one user from occupying all available extended memory.

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
Paging
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
3rd:33rdrd:: The rest of the
roll area is used
n The remaining portion of R/3 roll memory is used when the system can no longer allocate R/3
extended memory, either because R/3 extended memory is full or because the quota has been
reached.
n The reason for using the remaining portion of R/3 roll memory is to avoid using heap memory,
which is local memory, and avoid entering PRIV mode (see below).

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
Heap
memory
The system is forced
to use local heap memory Paging
area
4th:44thth::
n If the work process requires still more space after using up all available roll area and extended
memory, the system is forced to allocate R/3 heap memory locally.

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
Roll
area
Paging
area
Dialog
work
process 1
Heap
memory
Paging
area
Heap Memory and PRIV Mode (1)
n 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.
n The user is now effectively locked to the work process. This situation is called PRIV mode.

© SAP AG 1999
111 222 333
R/3 user
444
Roll
area
ExtendedExtended
memorymemory
(shared)(shared)
Dialog
work
process 2
Dialog
work
process 1
Heap
memory
(local)
PRIV mode
Roll
area
Paging
area
Paging
area
Heap Memory and PRIV Mode (2)
n A dialog process that was forced to allocate R/3 heap memory automatically enters PRIV mode.
n While a user is in a transaction which caused the work processes to enter PRIV mode, no other user
can access the work process.
n Since R/3 architecture uses a limited number of work processes to satisfy a larger number of
frontend users, other users suffer when a user goes into PRIV mode.
n If several users go into PRIV mode, they can work well, but other users can hardly work at all.

© SAP AG 1999
Shared
memory
Local
memory
Roll memory
up to
ztta/roll_first
Extended memory
up to
ztta/roll_extension
or EM exhausted
Roll memory:
remainder of
ztta/roll_area
Heap memory
up to
abap/heap_area_dia
or HM exhausted
• ‚ ƒ „
Time
Allocation Sequence for Dialog WPs - Overview
n Data in R/3 roll memory is copied during context switch.
n Data in R/3 extended memory is mapped during context switch.
n Data in R/3 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.
n Note: the sequence in which memory is used by work processes is not determined by the amount
memory initially allocated. Thus, while the entire roll memory is allocated on work process start, it is
not initially used up completely.

© SAP AG 1999
l The memory allocation strategy for dialog work processes
aims to prevent work processes from allocating R/3 heap
memory and thus entering PRIV mode.
l When a work process enters PRIV mode, it remains
connected to the user until the user ends the transaction.
Allocation Sequence for Dialog WPs - Summary

© SAP AG 1999
Allocation Sequence for Non-Dialog WPs
Roll memory
up to
ztta/roll_first
Extended memory
up to
ztta/roll_extension
or EM exhausted
Roll memory:
Remainder of
ztta/roll_area
Heap memory
up to
abap/heap_area_dia
or HM exhausted
• ‚ ƒ „
Time
Roll memory
up to
ztta/roll_area
Extended memory
up to
ztta/roll_extension
or EM exhausted
Heap memory
up to
abap/heap_area_nondia
or HM exhausted
• ‚ ƒ
Shared
memory
Local
memory
Allocation
sequence for
non-dialog WPs
on NT and for
dialog WPs on
all platforms
Allocation
sequence for
non-dialog
WPs on all
platforms
except NT
n As of R/3 Release 4.0A (with implementation of the Zero Administration Memory Management),
Windows NT uses the same allocation sequence for non-dialog work processes as for dialog work
processes.

© SAP AG 1999
Heap memory is
released after use
111 222 333
R/3 user
444
Swap
ExtendedExtended
memorymemory
(shared)(shared)
Work
process 2
Roll
area
Paging
area
Work
process 1
Roll
area
Heap
memory{
Paging
area
Freeing Heap Memory (1)

© SAP AG 1999
But used swap space
is not freed by the
operating system
111 222 333
R/3 user
444
Swap
ExtendedExtended
memorymemory
(shared)(shared)
Work
process 2
Roll
area
Paging
area
Work
process 1
Roll
area
Heap
memory
Paging
area
{

© SAP AG 1999
111 222 333
R/3 user
444
Swap
ExtendedExtended
memorymemory
(shared)(shared)
Work
process
2
Roll
Paging
Work
process
1
Roll
Paging
When the limit set in
abap/heaplimit is
reached, the work
process is flagged for
automatic restart
n If the heap memory consumption of a work processes exceeds abap/heaplimit, after ending the
transaction, the heap memory is automatically released and the work process restarted to release the
swap space.

© SAP AG 1999
Used memory WP 1abap/heaplimit
Swap space of WP 1 Swap space WP 2
Used memory for WP 2
t
Memory/swapspace Restart
of WP 1
Parameter ABAP/HEAPLIMIT
n Operating system swap space is saved through parameter abap/heaplimit.

© SAP AG 1999
Extended
memory
(shared)
DIA
em/initial_size_MB
ztta/roll_extension
abap/heap_area_dia
ztta/roll_first
Roll
area
ztta/roll_area
Heap
memory
abap/heap_area_total
rdisp/roll_SHM
rdisp/roll_MAXFS
Roll file
Roll buffer
Memory Management Parameters
n ztta/roll_first:
Defines the first part of the roll area that is allocated to a dialog process
n ztta/roll_area:
Defines the total roll area per work process
n rdisp/roll_SHM:
Defines the size of the roll buffer
n rdisp/roll_MAXFS:
Defines the size of roll buffer and roll file
n em/initial_size_MB:
Defines the fixed size of extended memory
n ztta/roll_extension:
Defines the user quota for extended memory
n abap/heap_area_dia:
Defines the limit for the amount of local memory allocated to dialog work processes
n abap/heap_area_nondia:
defines the limit for the amount of local memory allocated to non-dialog work processes
n abap/heap_area_total:
Defines the limit for the total amount of heap memory allocated to all work processes

© SAP AG 1999
Objectives
In this demonstration you will:
l See how R/3 memory management monitors are used
l Learn more about the R/3 memory allocation sequence
Activities
l Your trainer restarts the system and executes report
ZBC315_USE_MEM to allocate different amounts of R/3 memory
l Your trainer shows you how the Setups/Tune Buffers monitor
(Transaction ST02) and the Work process Overview (Transaction SM50)
are used to monitor the amounts of allocated R/3 memory
.
Demonstration: Testing Memory Limits (1)
REPORT zbc315_use_mem .
* report for checking memory limits
PARAMETERS mb TYPE i.
DATA itab(1024) TYPE c OCCURS 0.
DATA str(1024).
DO mb TIMES.
DO 1024 TIMES. APPEND str TO itab. ENDDO.
ENDDO.
SKIP.
WRITE: / 'Currently', mb, 'MByte memory in use for this transaction.'.

© SAP AG 1999
Demonstration: Testing Memory Limits (2)
l Parameters to be set:
n em/initial_size_MB 250
n ztta/roll_extension 180 000 000
n abap/heap_area_dia 150 000 000
l Problems:
n Processes in mode PRIV
n ABAP program terminates when no more R/3 memory is
available (error message TSV_TNEW_PAGE_ALLOC_FAILED)
n Your trainer restarts the system with the above parameters.
n These parameters can be displayed in the screen Current parameters. Use the Setups/Tune Buffers
monitor (Transaction ST02) and choose Current parameters.
n To cause a specified amount of memory to be used, the trainer uses report ZBC315_USE_MEM.
First the trainer allocates 50MB of memory to be used. This can be monitored using the Mode List.
Function. Use the Setups/Tune Buffers monitor (Transaction ST02),and choose Detail analysis menu
→ SAP memory → Mode list.
n Next, the trainer allocates another 200 MB of memory. As can be seen in Mode List, the newly
opened session is now also using heap memory. As can be seen in the Work Process Overview
(Transaction SM50), this causes the corresponding work process to enter PRIV mode.
n Your trainer allocates 400 MB of memory. The lack of sufficient R/3 memory causes the report to
terminate and a dump log to be written.

© SAP AG 1999
R/3 Memory Consumption
n In the Setups / Tune Buffers monitor (Transaction ST02), you can see that the R/3 extended memory
is completely in use.

© SAP AG 1999
Mode List
n Call the Setups / Tune Buffers monitor (Transaction ST02), and choose Detail analysis menu → SAP
memory → Mode list. You can see that several work processes need to allocate R/3 heap memory.

© SAP AG 1999
n The Work Process Overview (Transaction SM50) shows that the work processes that need to allocate
R/3 heap memory enter PRIV mode. These work processes are locked to one particular user.

© SAP AG 1999
Analysis Roadmap: R/3 Memory Configuration
Check R/3 memory configuration in the Setups/Tune Buffers monitor (Transaction ST02)
Many R/3 buffer swaps
If enough physical main memory is available, increase R/3 buffer size
R/3 extended memory is full if Max. used > 80%In memory
ST02: Detailed analysis of SAP memory using the Mode List
Single users with very high extended memory consumption
Identify and analyze respective reports/transactions
If enough physical main memory is available, increase R/3 extended memory
ztta/roll_first > 1024?
ztta/roll_first = 1
Roll buffer is full if for Roll memory, Max. used > 80%In memory
If enough physical main memory is available,
increase roll buffer (rdisp/ROLL_SHM)
?
?
?
?
?

© SAP AG 1999
Objectives
In this exercise, you will:
l Monitor current R/3 memory usage in the system
Activities
l Your trainer starts the workload simulation
l Use the relevant monitors to identify the performance problem
l Provide recommendations for solving the problem

© SAP AG 1999
Workload Analysis Exercise: Solution
Identifiable problems:
l One program uses 150 MB of extended memory (60%)
l Insufficient memory is available for other users
l Processes enter mode PRIV
l Blocked work processes may cause system-wide wait time

© SAP AG 1999
Roll
memory
Extended memory Heap memory
Memory used
Shared
memory
Local
memory
Roll memory
Insufficient Extended Memory
n The parameter settings for roll memory and extended memory allocate only a small amount of
memory and thus force the work process to allocate heap memory too soon.

© SAP AG 1999
Roll memoryExtended memory Heap memory
Memory used
Shared
memory
Local
memory
Roll
memory
Sufficient Extended Memory
n To avoid the problem of insufficient extended memory, you may need to increase the size of the
extended memory.

© SAP AG 1999
Next Topic in Unit
l R/3 memory areas
n Concepts
n Freeing Heap memory
l Implementing R/3 extended memoryè

© SAP AG 1999
Zero Administration Memory Management
l This strategy simplifies
R/3 memory management by:
n Reducing the number of parameters
n Making manual settings unnecessary
l Dynamically allocated extended memory:
n Dynamically adapts to users' memory requirements
n Allows extended memory to enlarge to em/max_size_MB or until
the operating system paging file is full
l New R/3 parameter: PHYS_MEMSIZE
n Provides the basis for other memory management parameters
n Makes it unnecessary to configure several R/3 memory management
parameters – such as em/initial_size_MB, and
abap/heap_area_total
See also
R/3 Note 88416
n With R/3 Release 4.0A, the Zero Administration strategy has been introduced for Windows NT. In
subsequent R/3 Releases, it will be introduced on other operating systems.
n Since on Windows NT the parameter em/max_size_MB has a default value of 20 000, the size of R/3
extended memory is limited by the size of the address space of the NT paging file.

© SAP AG 1999
R/3
work
process
Address space (2 to 3.8 GB)
User-independent data User context
Extended memory Heap memoryR/3 buffers
Local
WP
Address space restriction
due to 32 bit architecture
em/initial_size_MB abap/heap_area_(non)dia
Shared
memory
Local
memory
Roll
memory
R/3 Extended Memory on UNIX (1)
n The parameter em/initial_size_MB is operating system-dependent in that it is restricted by the
address space of the work process.
Ÿ For 32 bit architecture, the address space is < 4 GB (in some operating systems even smaller).
Ÿ For 64 bit architecture, the address space is < 1.8*1018
bytes.
n For 32 bit architecture, SAP recommends using em/initial_size_MB <= 2GB, (and even less for
some operating systems). For detailed recommendations, see SAP Notes 97497 (for R/3 Releases
3.x) or 103747 (for R/3 Releases 4.x).
n The amount of extended memory should be proportionate to the amount of physical memory.

© SAP AG 1999
R/3
work
process
Address space (2 to 3.8 GB)
User-independent data User context
Local
WP
Address space restriction
due to 32 bit architecture
em/initial_size_MB abap/heap_area_(non)dia
Shared
memory
Local
memory
Roll
memory
R/3 Extended Memory on UNIX (2)
n For general recommendations, see:
Ÿ SAP Note 97497 Memory Management Parameter (3.0/3.1)
Ÿ SAP Note 103747 Performance 4.0/4.5: Parameter recommendations
Ÿ SAP Note 146528 Configuration of R/3 on hosts with much RAM
n For AIX, see:
Ÿ SAP Note 28992 AIX: Number of shared memories exceeds 10
Ÿ SAP Note 95454 A lot of extended memory on AIX
Ÿ SAP Note 117267 AIX 4.3.x: Shared memory segments larger than 256MB
Ÿ SAP Note 124555 AIX: Recommendation for maximum extended memory
Ÿ SAP Note 128935 AIX 4.3, large memory configuration
n For HP-UX, see:
Ÿ SAP Note 43427 HP-UX: Shared memory Limits
Ÿ SAP Note 106819 More than 1.75GB Shared memory for R/3 on HP-UX
n For Tru64-UNIX, see:
Ÿ SAP Note 30606 Entries in /etc/sysconfigtab under Digital UNIX
Ÿ SAP Note 32915 OSF1 Kernel Parameters for 3.0x memory management

© SAP AG 1999
Benefits of 64-Bit Address Space for R/3
l Much more extended memory available
n No need to save shared address space
n Increases only swap space requirements
l No exclusive work process allocation by inactive users
(PRIV modes)
l Minimal use of roll memory
l Significantly reduced administration
n General purpose setup possible
n Uniform, optimal setup for both dialog and background
processing
n No performance loss due to sub-optimal setup
l Note 146289: Recommendations for 64-Bit R/3 Kernel

© SAP AG 1999
R/3 work
process
Address space (approx.. 1.8 GB)
Shared
memory
Local
memory
Local
WP
abap/heap_area_(non)diaem/address_space_MB
em/initial_size_MB
Extended memory (initial total)
n Parameter em/address_space_MB is for the amount
of extended memory per work process
n Parameter em/initial_size_MB can be very large
Roll
memory
R/3 Extended Memory on NT
n The default value of ztta/roll_extension is 2 000 000 000, which effectively deactivates this
parameter. The limit for the user quota is given by the parameter em/address_space_MB (as part of
the new Zero Administration strategy).
n On instance start, the extended memory is allocated by em/initial_size_MB
n With NT, the amount of extended memory can increase dynamically up to em/max_size_MB, as long
as the maximum virtual memory (that is, physical memory plus swap space) is not yet exhausted.
n There are no address space restrictions for extended memory, which is restricted only by the
maximum virtual memory.
n With NT, the recommendations for R/3 extended memory are more generous than under UNIX.
However, parameter em/address_space_MB determines the user quota (that is, the amount of R/3
extended memory, which may be used by one single user context).
n For up-to-date recommendations, please see related R/3 Notes in the Online Service System (OSS):
Ÿ R/3 Note 68544, Memory management under Windows NT
Ÿ R/3 Note 88416, Zero Administration memory management from 4.0A/NT
n The amount of extended memory should be proportionate to the amount of physical memory.

© SAP AG 1999
l Outline the types of memory affected by R/3
memory management
l Explain how these types of memory work together
l Use R/3 memory management monitors
l Configure parameters as part of R/3 memory
management

© SAP AG 1999
Appendix: Menu Paths for R/3 Memory
Management
l R/3 memory consumption:
Use transaction code ST02.
l Current parameters:
In transaction ST02, choose Current parameters.
l Mode list:
In transaction ST02, double-click Extended memory, and choose Mode list.
n To access transaction ST02 from the SAP Easy Access menu, you can choose Tools →
Administration → Monitor → Performance → Setup/Buffers → Buffers.

© SAP AG 1999
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements
Hardware Capacity Verification

© SAP AG 1999
Contents:
l Definition and consequences of hardware bottlenecks
l Analyzing hardware bottlenecks
l Making the most of existing hardware
l Appendixes:
n Configuration example
n Quick sizing tool

© SAP AG 1999
Objectives:
l Explain why hardware bottlenecks may harm the performance of the
whole R/3 System
l Identify possible reasons for hardware bottlenecks, such as:
n Inappropriate hardware (CPU, RAM, disks, network)
n Non-optimal workload distribution
n Expensive programs (inside or outside R/3)
l Prevent, detect, and solve hardware bottlenecks

© SAP AG 1999
First Topic in Unit
l Definition and consequences of hardware
bottlenecks
è

© SAP AG 1999
What is a Hardware Bottleneck?
l From a user’s point of view:
n Lengthy response time for transactions
l From the system’s point of view:
n CPU utilization is nearly 100 %
n High average number of processes waiting for CPU (load
average)
n High paging rates
n Lengthy disk response times
n Lengthy network response times (ping)
n To check the system values, use the Operating System Monitor (transaction ST06).

© SAP AG 1999
l Types of hardware bottlenecks
n High paging rates
n High CPU utilization
n Lengthy disk read/write (I/O) times
n Lengthy network response times
l Reasons
n Incorrect sizing (physical main memory, CPU)
n Incorrect workload distribution
n Expensive programs (SQL statements, external programs)
n Incorrect disk layout or slow disks
n Incorrect network topology
Hardware Bottlenecks
n This unit deals mainly with bottlenecks related to memory and CPU (as indicated by the check marks
above).

© SAP AG 1999
Next Topic in Unit
bottlenecks
è

© SAP AG 1999
Hardware Analysis Roadmap (1)
High paging rate (> 20% of RAM per hour)?
Operating System Monitor (transaction ST06)
CPU idle <20%?
Is there CPU capacity on other servers that is idle?
Redistribute R/3 work processes and users
Operating System Monitor (transaction ST06): Top CPU Processes
R/3 work processes with high CPU utilization?
Work Process Overview (transaction SM50) or Systemwide Work Process
Overview (transaction SM66)
Detailed analysis of report or transaction
Database process monitor (transaction ST04; for example ORACLE session)
Database processes with high CPU utilization?
External processes with high CPU utilization?
Stop or redistribute
?
?
?
?
?
?
n This roadmap guides you in analyzing your hardware capacity. First, call the Operating System
Monitor (transaction ST06). If the idle CPU is indicated as being less than 20 %, there is a CPU
bottleneck. In an optimal configuration, more than 35 % CPU capacity is idle.
n If there is a CPU bottleneck:
1. If possible, redistribute load to other servers.
2. To find out which processes are using the most CPU, in the Operating System Monitor choose
Detail analysis menu → Top CPU processes. If the processes have high CPU utilization, proceed
as follows:
- For R/3 work processes ("disp+work"): Using the process ID indicated in Top CPU processes,
identify the corresponding program name and user name in the Work Process Overview
(transaction SM50).
- For database processes (for example, "ORACLE8.0"): Identify corresponding long running
SQL statements in the Database Process Monitor. To access this monitor, call transaction ST04
(Database Overview), and choose Detail analysis menu. Then choose, for example, Oracle
Session.
- For external processes, find out whether the process can be stopped or redistributed.

© SAP AG 1999
Memory capacity free on other servers?
File system cache > 10 % of RAM?
Reduce file system cache
Setups/Tune Buffers monitor (transaction ST02): Mode List
Programs / transactions with high memory consumption
CPU idle < 20%?
...
?
?
?
?
?
n In the Operating System Monitor (transaction ST06), note the amount of memory indicated beside
Physical memory available. Compare this figure with the paging rate. To obtain the paging rate,
double-click Pages in/s. The paging rates for the last 24 hours are displayed in the columns Paged in
[Kb/h] and Paged out [Kb/h]. If 20% of the total amount of physical memory is greater than the
amounts indicated in these columns, you can normally be sure there is no memory bottleneck.
n If there is a memory bottleneck:
2. Check the size of the file system cache – See SAP Note 78498 in SAPNet. If necessary, reduce
file system cache to < 10% of the total physical memory.
3. To identify users and their programs with a high memory consumption, call the Mode List for
the extended memory. To do this, in the Setups/Tune Buffers monitor (transaction ST02), choose
Detail analysis menu → SAP memory → Mode List.

© SAP AG 1999
The total response time consists of:
l Wait time
l Database request time
l Roll time
l Load time
l Enqueue time
l Processing time, including:
n ABAP processing time (part of total CPU time)
n Work process waiting for CPU
n Waiting for I/O
Response Time Components
n Time spent in R/3 work process = Response time - Wait time
n Processing time is the actual time required to process the dialog step inside the R/3 work process.
Processing time = Response time - wait time - database request time - roll time - load time - enqueue
time.
n Processing ABAP statements requires CPU. The more statements there are, the more CPU time is
required. Ideally, most of the processing time is used for processing ABAP statements. To achieve
this, you require:
Ÿ A low operating system overhead (the time that an R/3 work process waits for CPU)
Ÿ Short I/O wait times, which occur, for example, when accessing external files, or as as result of
network time (RFC/CPIC)
n CPU time is also required for database access time, roll time, load time, and enqueue time.

© SAP AG 1999
Workload Monitor (transaction ST03N)
High database time: Database time > 40% (response time - wait time)
Detailed analysis of database
Processing time > CPU time x 2
Detailed analysis of hardware bottleneck
? Wait time > 10% of response time
General performance problem
Load time > 50 ms
Detailed analysis of R/3 memory config. (program buffer too small?)
Roll in / roll out time > 20 ms
Detailed analysis of R/3 memory configuration (problems with
extended memory or roll buffer?)
!
?
?
?
?
n This part of the roadmap guides you in analyzing workload data when looking for hardware
bottlenecks:
1. Call the Workload Monitor (transaction ST03N). In expert mode, choose detailed analysis → Last
minute load. Select the current application server.
2. In the statistics displayed, a hardware bottleneck may be indicated if the following figures are
significantly high:
- Average wait time
- Average load time and average roll time
- Average database time
n A high average wait time means all programs are running slowly and blocking the work processes
for a long time. A high average load time and high average roll time mean that loading and rolling
are slow. A high average database time means the database is running slowly and may indicate a
hardware bottleneck on the database server.
n From the statistics displayed, you can calculate the processing time as equivalent to response time
minus the sum of wait time, database time, roll time, load time, and enqueue time. A large
processing time means the work processes are waiting for CPU while processing ABAP programs.

© SAP AG 1999
Objectives:
l Analyze a hardware bottleneck
Activities:
l Analyze the performance problem
l Use transactions SM50, ST03N, and ST06
l Make suggestions for tuning
n Transaction SM50 is the Work Process Overview.
n Transaction ST03N is the Workload Monitor.
n Transaction ST06 is the Operating System Monitor.

© SAP AG 1999
Exercise Analysis: Work Process Overview
n To access the Work Process Overview, use transaction SM50.

© SAP AG 1999
Exercise Analysis: Workload Monitor
n To access the Workload Monitor, use transaction ST03N.
n Calculate the processing time as follows:
n Processing time = Response time - Wait time - Database time - Roll time - Load time
= 6073 - 1562 - 2254 - 248 - 169
= 1840 ms
The processing time is thus more than twice the average CPU time:
1840 (processing time) / 546 (average CPU time) = 3.4
n This indicates a resource bottleneck. In this example, the CPU bottleneck is caused by external
operating system processes consuming CPU.
n Notice the large wait time, database time, and load time.

© SAP AG 1999
Exercise Analysis: Operating System Monitor
n To check for problems at operating system level, use the Operating System Monitor (transaction
ST06).
n Notice the high % CPU utilization: user 96 %, system 4 %, idle 0 %.
n Why is the CPU usage at almost 100 % capacity?

© SAP AG 1999
Exercise Analysis: Top CPU Processes
n From the Operating System Monitor (transaction ST06), choose Detail analysis menu >> Top CPU
processes.
n Notice that the first listed CPU processes are currently using most of the CPU:
Process ID Command CPU Util %
630 DR_WATSON 76.34
382 DR_WATSON 73.84
n The DR_WATSON processes are not related to the R/3 system or to the database and therefore are
external processes.

© SAP AG 1999
R/3 wait
CPU wait
CPU
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
é éé é
3333
Cost center
Profitfrom
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
éé é é
3333
Cost center
Profit from
Change cost center
??
ééé é
3333
Cost center
Profit from
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
éé
é
é3333
Cost
center
Profitfrom
Work
process
Work
process
Work
process
Database
process
Database
process
Database
process
External
process
External
process
External
process
Work
process
External
process
Database
process
Change cost center
??
éé é é3333
Cost
center
Profitfrom
Change cost center
??
éé é é
3333
Cost
center
Profitfrom
Exercise Analysis: Conclusion (1)
n We may conclude that external processes are causing a CPU bottleneck on the database server.
n Consequently, the operating system is too slow in executing R/3 work processes and database
processes. R/3 dialog steps are spending too much time waiting for CPU inside the R/3 work process
or the database processes.

© SAP AG 1999
l External processes that may be creating
an unnecessary load on the CPU:
w Second Instance or another R/3 System
w External system / external database
w Looping processes
w Running backup tool
w Other external tools or programs (for example, screen savers)
l Solution:
Check if these processes are required to run the R/3 System
n If yes Use other machines, extend the hardware (CPU),
tune the processes
n If no Terminate the processes
l In this example, the processes can be terminated
Exercise Analysis: Conclusion (2)
n One way of tuning the system in this case is to terminate the external processes that are creating an
unnecessary load on the CPU.
n Verify the solution by terminating the external processes and restarting the workload simulation.

© SAP AG 1999
R/3 wait
CPU wait
CPU
Work
process
Work
process
Database
process
Work
process
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
é éé é
3333
Cost center
Profitfrom
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
éé é é
3333
Cost center
Profit from
Change cost center
??
ééé é
3333
Cost center
Profit from
Change cost center
??
é éé é
3333
Cost center
Profit from
Change cost center
??
é é
é
é3333
C o s t
center
Profitfrom
Database
process
Database
process
Database
process
Work
process
Checking Tuning Results (1)
n Typically, not external processes but only the following processes run on the database server:
Ÿ R/3 work processes of the central instance
Ÿ The database processes required for the database
n These processes have to share the available CPUs.
n As the database server is being accessed from all application servers, the performance associated
with database access is critical for overall system performance.

© SAP AG 1999
Operating System Monitor
n To check CPU usage, display the Operating System Monitor (transaction ST06).
n The CPU is less heavily loaded (47 % idle).

© SAP AG 1999
Workload Monitor
n In the Workload Monitor (transaction ST03N), a comparison of the times before and after tuning
indicates:
Ÿ Response time: 6037 > 955 ms
Ÿ Wait time: 1562 > 11 ms
Ÿ Database time: 2254 > 107 ms
n Note that the average CPU time has not changed significantly:
CPU time: 546 is approximately the same as 592 ms
This is as you would expect, since the dialog step uses the same amount of CPU time in both
simulations.

© SAP AG 1999
bottlenecks
l Making the most of existing hardwareè
Next Topic in Unit

© SAP AG 1999
Memory for database (once per R/3 system)
n Rule of thumb: 20% of the total physical memory (of all servers)
Memory for R/3 buffers (once per R/3 instance)
n Approx. 500 to 800 MB (depends on applications used)
Memory for R/3 work processes
n Approx. 12 MB per work process
R/3 extended memory
n Approx. 10 to 20 MB per user
Optimizing Memory Configuration (1)

© SAP AG 1999
Physical main memory (RAM)
n Virtual memory should be < 2* the physical memory
Swap space
n 3 x physical memory
n At least 2 GB
Workload
n Number of active users
n R/3 applications used
Optimizing Memory Configuration (2)

© SAP AG 1999
Checking R/3 Virtual Memory Allocation
n To check R/3 virtual memory allocation for a specific instance, in the Setups/Tune Buffers monitor
(transaction ST02), choose Detail analysis menu → Storage. The total memory allocated for this
instance is displayed beside Virtual memory allocated. To this figure, add the virtual memory
allocated to any other R/3 instance or database running on this server.
n Compare the total virtual memory with the total physical memory. If the ratio is less than 3:2, you
can normally be sure that there is no memory bottleneck.
n If the ratio is greater than 3:2, check how much of the allocated virtual memory is really being used,
especially in extended memory and the program buffer. To do this, in the initial screen of transaction
ST02, look at the columns Max. use [KB] and In memory [KB].

© SAP AG 1999
l For the database:
n Rule of thumb: 10 - 30% of the total CPU for all servers
n Ensure that there is never a CPU bottleneck
on the database server
l For update processing
n Rule of thumb: 10 - 20% of the total CPU for all servers
l For dialog / background processing:
n No general recommendation for CPU per user
n CPU required depends on applications used (see next slide)
Configuring CPU (1)

© SAP AG 1999
9%
13%
78%
18%
16%
66%
11%
14%
75%
14%
16%
70%
6%
7%
86%
13%
9%
78%
0,00
0,50
1,00
1,50
2,00
2,50
3,00
3,50
4,00
4,50
5,00
FI WM MM SD PS PP
Configuring CPU (2)
R/3 application
CPU
usage
per
dialog
step
Database
Update
Dialog
Platform and release dependent
n This graph is from the R/3 Standard Application Benchmarks. For the complete documentation, in
SAPNet, perform a search for Benchmarks.
n CPU consumption per user differs substantially according to application. The calibration of the
vertical axis is defined by regarding the total CPU usage of an FI user as having a value of 1.
n The lowest part of the columns in the graph shows the database share of CPU consumption (10% to
15%); the middle part of the columns shows the update processing share (10% to 15%).
n Note that this graph does not take into account background processing or reporting activity. Thus, in
a normal system:
Ÿ The "dialog" part of the bar is split into dialog and background processing
Ÿ Reporting activity consumes more database resources.
n Normally the database uses between 10% and 30 % of the total CPU of all servers.

© SAP AG 1999
l Explain why hardware bottlenecks may harm the
performance of the whole R/3 System
l Identify possible reasons for hardware bottlenecks:
n Inappropriate hardware (CPU, RAM, disks, network)
n Non-optimal workload distribution
n Expensive programs (inside or outside R/3)
l Prevent, detect, and solve hardware bottleneck
problems

© SAP AG 1999
For the current recommendations, see
SAP Note 103747 in SAPNet
On a server with 2 GB memory:
l R/3 buffers (without roll and paging): 750 MB
n Program buffer: 500 MB
n R/3 table buffers: 110 MB
Appendix: 32 Bit Configuration Example (1)
n The following R/3 parameter settings are configured in the R/3 System used in this course:
Ÿ Nametab buffers:
- rsdb/ntab/entrycount: 30 000
- rsdb/ntab/ftabsize: 30 000
- rsdb/ntab/irbdsize: 4000
- rsdb/ntab/sntabsize: 2500
Ÿ Program / CUA / presentation buffers:
- abap/buffersize: 500 000
- rsdb/cua/buffersize: 5000
- zcsa/presentation_buffer_area: 20 000 000
- sap/bufdir_entries: 4500
Ÿ Table buffers:
- zcsa/table_buffer_ area: 70 000 000
- rtbb/buffer_length: 40 000

© SAP AG 1999
On a server with 2 GB memory:
l R/3 buffers (without roll and paging): 700 MB
l Extended, roll and paging
in shared memory 1500 MB
l 18 work processes 120 MB
l Virtual memory allocated for R/3 2.3 GB
l Memory allocated for database 500 MB
Appendix: 32 Bit Configuration Example (2)
For the current recommendations, see
SAP Note 103747 in SAPNet
n PHYS_MEMSIZE: 1.5 GB
n The following values are calculated by the Zero Administration memory management from a
PHYS_MEMSIZE of 1.5 GB:
Ÿ Extended Memory: 1400 MB (em/initial_size_MB = 1400)
Ÿ Roll buffer: 80 MB (rdisp/ROLL_SHM = 10100)
Ÿ R/3 Paging buffer: 40 MB (rdisp/PG_SHM = 5040)
n Number of work processes:
Ÿ Dialog: 10
Ÿ Update: 4
Ÿ Background: 2
Ÿ Enqueue: 1
Ÿ Spool: 1
Ÿ Update: 2

© SAP AG 1999
Appendix: Quick Sizing (1)
QUICK SIZINGQUICK SIZING
Registration
Customer Number
Project name
Please note: For help on the above input fields, e.g. Customer Number, click on the field name.
By pressing the I agree - button you confirm that you have read and understood the disclaimer, especially the assumptions and
limitations of the tool.
This application is based on the results of publicly available SAP Standard Application benchmarks and considers the dialog workload
only. It can, therefore, only reflect the standard components of the SAP® R/3 ™ system. As sizing for an R/3 system depends heavily
on factors such as peak versus average workload, number of users, user behavior, amount of batch processing, user Customizing and
reporting, only the absolute standard dialog usage of an R/3 system is considered. The output of this tool is given in categories (CPU,
memory and net disk). Within these limits the information is valid within certain boundaries and represents
likely probabilities.
This tool is based on the most current level of the R/3 System and will be updated if applicable.
This tool is copyrighted by SAP AG, all rights reserved. No parts of this program may be reproduced, transmitted or copied in any form or
for any purpose without the express permission of SAP AG. The information contained herein may change without prior notice. SAP AG
makes no warranties or representations with respect to the content hereof and specifically disclaims any implied warranties of fitness for
any particular purpose.
SAP AG assumes no responsibility for any errors that may appear in this program. The information contained in this application is subject
to change without notice. SAP AG reserves the right to make any such changes without obligation to notify any person of such revision or
changes. SAP AG makes no commitment to keep the information contained herein up to date.
(c) SAP AG. All rights reserved.
Preview I agree

© SAP AG 1999
Number of users by system usage
FI-AA Asset Accounting
CO Controlling
BC Basis Components
EC Enterprise Controlling
FI Financial Accounting
PA PersonnelAdministration
and Payroll Accounting
PD Personnel Planning and
Development
MM MaterialsManagement
TR Treasury
PM PlantMaintenance
PP Production Planning
PS Project System
QM Quality Management
SD Sales & Distribution
PM-SMA Service Management
MM-WM Warehouse Management
Low Medium High
Project name
Country
Status
Quality Structure
Preliminary Final
BERLIN
Quantity-Structure-Dialog
DE

© SAP AG 1999
QUICK SIZINGQUICK SIZING
Quantity - Structure - Dialog
High load Phase
Comp- Sub- Name of Object Number of objects creations Name of Sub-Object Average No. of RetentionPeriod Number of Objects Creations Execution Time % of Object % of Object
onent Comp. per Year Sub-Objects [months] per day [hh:00 -hh:00] Changes Display
High load Phase
Printed Documents
Line items
Reports Lines
Documents 100000 Line items 4 12 20000 05 100 100
06
Material Movement 30000 Line items 3 6 200
Purchase Order 35000 Line items 8 12 200 100
Transfer Order Line items
Name of Object Number of object Name of Sub-Object Average No. of Retention Period Number of Object creations Execution Time % of Object % of Object
creations per year Sub-Objects [month] per day [hh:00- hh:00] Changes Display
Time Data
Receipts Line items

© SAP AG 1999
Result
MEMORY (in MB)
DB-Min 00256 DB-Opt 00256
AP-Min 00512 AP-Opt 00768
User based input
(at 33% Dialog CPU Utilization)
CPU Sizing Category DISK Sizing Category
4 3
Quantity Structure Input
(at 65% CPU Utilization)
CPU Sizing Category DISK Sizing Category
9 2
Customer Number: 0000188213
Project Name: BERLIN
Request Sizing from... or from...
ll AmdahlAmdahl
ll BullBull
ll CompaqCompaq
ll DigitalDigital
ll FujitsuFujitsu
ll Hewlett-PackardHewlett-Packard
ll IBMIBM
ll NCRNCR
ll SiemansSiemans--NixdorfNixdorf
ll SunSun
ll TandemTandem
ll Data GeneralData General
ll DellDell
ll HitachiHitachi
ll IntergraphIntergraph
ll NECNEC
ll SequentSequent
ll UnisysUnisys
These partners already provide
WEB pages especially customized
0 5 10 15 20 23
2000
4000
6000
8000
SAPS
CPURequirement

© SAP AG 1999
1. Introduction to
Workload Analysis
Monitors
7. Interfaces
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements
Expensive SQL Statements

© SAP AG 1999
Contents:
l Definition and consequences of expensive SQL statements
l Monitors for detecting and analyzing expensive SQL statements
l SQL statement exercise
l Detailed analysis and tuning
l Appendixes:
n Efficient database programming with ABAP
n Database locks and R/3 enqueues

© SAP AG 1999
Objectives:
l Explain why even a few expensive SQL statements may reduce
performance for the whole R/3 System
l Use the monitors:
n Work Process Overview (transaction SM50)
n Transaction Profile (transaction ST03N; transaction profile)
n Shared SQL Area (transaction ST04; SQL request)
n SQL Trace (transaction ST05)
l Explain the most important tuning measures:
n Creating or changing an Index
n Checking the database optimizer decisions
n Optimizing ABAP coding

© SAP AG 1999
Topics Covered Elsewhere
l The BC5xx Database Administration courses
for the respective database platform cover:
n General database tuning, such as tuning database
buffers, I/O, and redo logging
n Using ST04, state on disk, file system requests,
database message log, database wait situations
l The BC490 ABAP Performance Tuning course
covers:
n Avoiding expensive SQL statements
by efficient ABAP coding and indexing
n Using SQL trace, ABAP trace, ABAP debugger
n SQL statement tuning is a small part of database tuning, and is performed by many different people:
R/3 System administrators, database administrators, ABAP developers, certified technical
consultants.

© SAP AG 1999
First Topic in Unit
l Definition and consequences of expensive SQL
statements
l Monitors for detecting and analyzing expensive SQL
statements
l Detailed Analysis and Tuning
è

© SAP AG 1999
l From a user’s point of view:
n Lengthy response time of transaction using the statement
l From the system’s point of view:
n Many data blocks are scanned to find the selected records
What is an Expensive SQL Statement?
n Lengthy response times result if the database needs a long time to return the requested data to R/3,
and R/3 needs a long time to return the next screen to the user.

© SAP AG 1999
Consequences of Expensive SQL Statements
Application
Server
Database instance
ABAP program
Database interface
Database
process
Database
Database buffer
n Database is busy reading many
data blocks
n High CPU load on database server
n Work process is blocked by report
èWait times for other processes
n Many blocks are displaced from
database buffer
èCache hit rate for other SQL
statements suffers
Expensive SQL statements
reduce performance of the
entire R/3 System
n For all databases, and both SAP and NON-SAP applications, expensive SQL statements can exhaust
hardware capacity and cause severe performance problems.

© SAP AG 1999
Next Topic in Unit
statements
statements
l Detailed Analysis and Tuning
è

© SAP AG 1999
l What to detect:
n Reports or transactions where the database request time is a large
fraction of response time
n SQL statements with a high number of buffer gets
l For each expensive SQL statement find out:
n Table name
n WHERE clause
n Indexes used
n Name of the report or transaction containing the statement
Detecting Expensive SQL Statements
For each expensive SQL statement:
n To find out the name of the report or transaction that uses the SQL statement, use the:
Ÿ Work Process Overview (transaction SM50)
Ÿ Transaction Profile (transaction ST03N)
n To find out the names of the tables accessed, use:
Ÿ SQL trace (transaction ST05)
Ÿ Shared SQL Area (transaction ST04 → Detail analysis menu → SQL request)
Ÿ Work Process Overview
Ÿ Database Process Monitor (transaction ST04 → ORACLE session)
n To find out the indexes involved, use the EXPLAIN function in:
Ÿ SQL trace
Ÿ Shared SQL Area
Ÿ Database Process Monitor

© SAP AG 1999
Transaction
profile
SQL traceShared SQL
area
Where-used
list
8 ST03N
Transaction
profile
8 ST05 8 SE12 →
Utilities →
Where-used list
Learn the
report /
transaction
name
Learn the
table name
and the
index used
Report /
transaction
name or user
name required
GNo information
about report
name
G GTable name
required
GSometimes
a table is
used in many
different places
Work
Process
Overview
8 SM50 or
SM66
Learn the table
name, and the
report / trans-
action name
GCritical
transaction
must be run at
the same time
8 ST04 → Detail
analysis menu →
SQL request
Learn the
table name
and the
index used
Learn the
report /
transaction
name
Monitors for Detection and Analysis
n Performance monitoring methods other than those based on checking statistics have drawbacks. The
methods described here are all based on checking statistics.

© SAP AG 1999
Detection Using the Transaction Profile
n To access the Transaction Profile, call the Workload Monitor (transaction ST03N) and choose
analysis view Transaction profile.
n The screen shows an example where the database request time makes up more than 95% of the
overall response time.
n The excessively large request time is likely to be due to expensive SQL statements. If so, an SQL
trace (Transaction ST05) would be useful. Alternatively, the large request time may indicate a
problem with the database server.
n Depending on the workload caused by the expensive statements, other transactions may also be
affected. These transactions show a large wait time and possibly also a large database request time.

© SAP AG 1999
Detection Roadmap (1)
Workload Monitor (transaction ST03N)
In ST03N, go to the Transaction Profile (sorted by Response time total)
Programs where CPU time > 40% (response time - wait time)
Detailed analysis using ABAP trace (transaction SE30)
Programs where database request time > 40% (response time - wait time)
...
SQL Trace
Detailed analysis of SQL statement
?
?
n This detection roadmap shows the procedure for using the Transaction Profile, accessed through the
Workload Monitor (transaction ST03N).
n Large database request times often indicate expensive SQL statements. Study the underlying SQL
statement in detail using the SQL trace (transaction ST05).

© SAP AG 1999
Detection Using the Work Process Overview
n To access the Process Overview, use transaction SM50. Refresh the data displayed at intervals of
several seconds.
n In the Process Overview, look for work processes with database actions such as sequential read,
direct read, update, insert, delete, and commit.
n The amount of time that a work process is occupied by a report is indicated if greater than one
second. If work processes are occupied for a long time by reports, the report name occurs repeatedly
in the Process Overview, as well as the table accessed by the report. In this example, ZZSELECT is
listed repeatedly in conjunction with table ZLIPS.
n If work processes are occupied for a long time by reports, check for expensive SQL statements using
the Database Process Monitor (Transaction ST04 ; ORACLE session), and check for exclusive lock
waits using the Database Lock Monitor (Transaction DB01).

© SAP AG 1999
Detection Using the Database Monitor
n To check for expensive SQL statements and other database problems, use the Database Monitor.
There is a Database Monitor for every database system. To call the Database Monitor, use
Transaction ST04, or, from the SAP Easy Access menu, choose Tools → Administration → Monitor
→ Performance → Database → Activity.
n Important statistics displayed in the Database Monitor include:
Ÿ Reads (logical reads)
Ÿ Physical reads
Ÿ Data buffer size and quality
Ÿ Shared pool size and quality
Ÿ Ratio of user calls to recursive calls
Ÿ Ratio of reads to user calls
n NOTE: Detailed database tuning is specific to the database platform and is therefore covered in the
respective Database Administration course (BC5xx).

© SAP AG 1999
Detection Using the Database Process Monitor
n To call the Database Process Monitor, use Transaction ST04, or, from the SAP Easy Access menu,
choose Tools → Administration → Monitor → Performance → Database → Activity.
Then choose Detail analysis menu → ORACLE session (or Informix session or SQL processes, as
appropriate).
n In the Database Process Monitor for an ORACLE database, beside each ORACLE process listed in
column ORA proc, you find the following information:
Ÿ Client process (column Clnt proc)
In this column, the number before the colon is the PID of the related R/3 work process. Use the
PID to identify the related R/3 work process in the Work Process Overview (transaction SM50).
Ÿ Client System (column Clnt system)
This column identifies the application server on which the related R/3 work process is running
Ÿ Status
In this column, SQL statements currently being executed on the database are marked active. Use
the filter option to show only the active statements.
n To find out the text of the full SQL statement, position the cursor on the relevant row and double-
click. From the subsequent screen, you can execute an EXPLAIN.

© SAP AG 1999
Detection Using the Database Lock Monitor
lock holder lock waiter
n Database locks are set by, for example, the SQL commands select for update and update. Exclusive
lock waits can suddenly reduce system performance. To detect exclusive lock waits, use the
Database Lock Monitor: use transaction DB01, or from the SAP Easy Access menu, choose: Tools
→ Administration → Monitor → Performance → Database → Exclusive lock waits.
n If an exclusive lock wait occurs:
Ÿ Monitor the program which is holding the lock, using, for example, the Database Process Monitor
(Transaction ST04; ORACLE session). Is the program executing expensive SQL statements after
setting a database lock? As rule of thumb, all expensive SQL statements must be executed before
setting the first lock.
Ÿ Find out the user holding the lock so it can be released. If this is not possible, delete the lock so
that other users can work. This will roll back the transaction of the lock holder. The transaction
may need to be repeated. For example, the seller may need to take the order a second time.
n Database locks are generally released at the end of a dialog step or by an explicit commit.
n Your trainer will demonstrate an exclusive lock wait situation on the training system using report
ZBC315_LOCK.

© SAP AG 1999
Work Process Overview (transaction SM50 or transaction SM66)
Work process in status running
Action/reason: “Dir. Read”, “Seq. Read”, “Insert”, “Update”, “Delete” , “Commit”
Database Lock Monitor (transaction DB01)
Wait situations due to database locks (“Exclusive lock waits”)?
Analyse lock holder
Database process monitor (transaction ST04: ORACLE Session)
Detailed analysis: SQL statement
SQL Trace (transaction ST05)
Identify and analyse the SQL statement in detail
?
?
?
n This detection roadmap shows the procedure for using the Work Process Overview.

© SAP AG 1999
Application server A
Table buffer
SELECT * FROM MARA
WHERE ...
R/3 database interface
ABAP program
DBMS
DBMS
process
Database
buffer
12 Logical reads
( = buffer gets)
Database
3 Physical reads
( = disk reads)
3 Records processed
Monitoring Buffer Gets / Disk Reads (1)
n The SQL statement specifies a set of records in tables that it tries to locate. To find these records, the
database must scan the corresponding data blocks.
n All blocks that are not yet in the database buffer must be read on the disk. Logical reads or buffer
gets are blocks that are scanned in the database buffer. Physical reads or disk reads are the blocks
that are read from disk.
n A statement is efficient, if the optimizer can use an index that limits the number of blocks that must
be scanned, thus reducing the number of buffer gets.
n A statement is expensive if many blocks must be read to find the required records.

© SAP AG 1999
1. Sorted by
Number of
executions
3. Number of
buffer gets
per record
2. Number of
buffer gets
per execution
n To access the Shared SQL Area, use transaction ST04, or, from the SAP Easy Access menu, select
Tools → Administration → Monitor → Performance → Database → Activity. Then choose Detail
analysis menu. For an R/3 System with an ORACLE database as in this example, choose SQL
request. For other database systems, choose as follows: SQL statement for Informix; Stored proc.
stats for MS SQL Server; Diagnosis monitor for SAP DB.
n Buffer Gets: This column refers to the total number of buffers accessed by the statement.
To find the statements with the highest database load, sort the display using this column.
n Bgets/row: This column refers to the average number of buffers accessed per record retrieved.
Find statements with a high number of buffer gets per record. These statements can normally be
tuned.
n Executions: This column refers to the number of times the SQL statement was executed.
n The program to which the SQL statement belongs can be identified using either:
Ÿ The WHERE-USED list option in the ABAP Dictionary (transaction SE12).
Ÿ The Systemwide Work Process Overview (transaction SM66) in conjunction with the Database
Process Monitor (Transaction ST04; ORACLE session)
Ÿ ORACLE only: To display the last call point of the SQL statement in an ABAP program from
within the Shared Cursor Cache, choose Goto → Display call point in ABAP program.

© SAP AG 1999
1. Sorted by
Number of
executions
3. Number of
buffer gets
per record
2. Number of
buffer gets
per execution
n Your goal is to identify SQL statements which can be tuned. To display the actual statement being
executed, go to the Shared SQL Area (also known as the shared cursor cache) by calling Transaction
ST04, choosing Detail analysis menu, and making the selection appropriate for your platform. In the
Shared SQL Area, double-click the appropriate row.
n Statements generated by an ABAP program are displayed in upper case and quotation marks. For
example: SELECT "MANDT" , "VBELN" , "POSNR” FROM ”LIPS” WHERE …
n Statements not generated by an ABAP program cannot be tuned in R/3. These include:
Ÿ Statements used by database administration tools accessing administration tables. These
statements are displayed in upper case without quotation marks. They stem, for example, from
check report RSORATDB, or from SAPDBA (options such as -check, -next). If such statements
generate the highest database load, schedule the DBA tool to be executed less frequently.
Example: SELECT SEGMENT_NAME, … FROM DBA_SEGMENTS
Ÿ Statements selecting from R/3 basis tables such as DDNTT, DDNTF, D010L, D010INF, and
ATAB. These statements are displayed in upper case. If such statements generate the highest
database load, there may be problems with the R/3 buffers. Check the buffers for swaps. Example:
SELECT TABNAME, TABFORM, REFNAME FROM DDNTT WHERE ...
Ÿ Recursive statements (with ORACLE). These statements are displayed in lower case. Example:
select file#, block#, ts# from seg$ where type# = 3.

© SAP AG 1999
Application server A
Table buffer
SELECT * FROM T001
WHERE ...
R/3 Database interface
ABAP program
DBMS
DBMS
process
Database
buffer
Records
Database
SQL trace
file
For each SQL
statement, SQL trace
audits:
• Records processed
• Runtime
Runtime
Detection Using the SQL Trace (1)
n The database interface generates SQL statements that are transferred to the database, which
processes the statements and responds by sending data records to the database interface. If you
activate the SQL trace (transaction ST05), a record of the SQL statements, the response time of the
database, and the number of records is written to the SQL trace file.
n One trace file is written for each R/3 instance on an application server. Therefore, you cannot run
more than one SQL trace at the same time in the same R/3 instance.
n A large amount of data is written to the trace file. The standard size of the SQL trace file, which is
800 KB, is too low and should be increased to 16 MB (using parameter rstr/max_diskspace
= 16 384 000).
n Note: The network time contributes to the response time. Therefore, network problems between the
application server and the database server are detected by an SQL trace.

© SAP AG 1999
Detection Using the SQL Trace (2)
n In R/3, transaction ST05 allows you to activate and view SQL, enqueue, RFC, and buffer traces.
n If the SQL trace was activated, to view the trace results, choose List trace. A screen is displayed like
the one shown above, indicating the:
Ÿ Time and duration of the respective database operation
Ÿ Table accessed
Ÿ SQL statement used
n The lines with FETCH are part of the SQL statement in the previous row. For each FETCH, the
number of records transferred between application and database servers as a result of the SQL
statement are indicated in column Rec.
n To find out which fields and indexes exist for the table accessed, choose DDIC info.
n To find out which index has been used by the database optimizer for the SQL,
choose Explain SQL.

© SAP AG 1999
Detection Using the Where-Used List
n The where-used list helps you to find expensive ABAP statements for a specific table. You may, for
example, learn that a specific table is associated with performance problems by looking at the Work
Process Overview (transaction SM50), the Statistical Records monitor (transaction STAD), or SQL
trace (transaction ST05).
n If a table is used in many programs, the where-used list may not be useful.
n To obtain the where-used list:
Ÿ Call the ABAP Dictionary with transaction SE12.
Ÿ Enter the name of the table
Ÿ Choose Utilities → Where-used list
Ÿ To view the program lines of a specific program displayed, double-click the program name.

© SAP AG 1999
Shared
SQL
area
Work process
overview
SQL
trace
Transaction
profile
EXPLAIN SQL
statement
EXPLAIN SQL
statement
Index used Index used
Table name
transaction /
report name
Transaction code
Wait time
Database time
Table name
WHERE clause
Table name
WHERE clause
Expensive
SQL statement
Database
monitor
WHERE clause
Go to Tuning
Roadmap
n In the exercise that follows, use all of the analysis tools discussed in this unit to find expensive SQL
statements.
n You can only detect expensive SQL statements using the Work Process Overview during the running
of the transaction using the SQL statement.

© SAP AG 1999
SQL Statement Exercise (1)
Objectives
In this exercise, you will learn how to:
l Perform and analyze an SQL trace and an EXPLAIN
Activities
After your trainer executes report ZBC315_SELECT_ZMARA,
and creates an SQL trace for this report:
l Monitor the trace activated by your trainer
l Perform an EXPLAIN on the expensive SQL statements

© SAP AG 1999
SQL Statement Exercise (2)
l Table ZMARA
n MANDT Client
n MATNR Material
n MFRNR Manufacturer number
n MATKL Material group
n BISMT Old material number
l Existing index: ZMARA~T on (MANDT, MATKL)
l SQL statement 1:
n SELECT * from zmara where bismt = 'A00000000000999999'.
l SQL statement 2:
n SELECT * from zmara where bismt in ('00000000000099999',
‘00000000000099991') and matkl = ' '.
n SQL Trace:
Duration Object Database op. Rec. RC SQL statement
1.195 ZMARA REOPEN 0 0 SELECT WHERE
"MANDT" = '900' AND "BISMT" = 'A00000000000999999'
3.830.731 ZMARA FETCH 0 1403
59 ZMARA REOPEN 0 0 SELECT WHERE
"MANDT" = '900' AND "BISMT" IN ( '99999' , '99991' ) AND
"MATKL" = ' '
4.001.023 ZMARA FETCH 0 1403
n EXPLAIN for SQL Statement 1:
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ZMARA
INDEX RANGE SCAN ZMARA~T
n EXPLAIN for SQL Statement 2:
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID ZMARA
INDEX RANGE SCAN ZMARA~T

© SAP AG 1999
l Without index on BISMT
n INDEX RANGE SCAN ZMARA (MANDT, MATKL)
n Runtime 3500 ms
l With index on BISMT
n INDEX RANGE SCAN ZMARA (BISMT)
n Runtime 3 ms
Exercise Solution for 1st SQL Statement
n Note: The times indicated above may differ from the times revealed in your training system.

© SAP AG 1999
Exercise Solution for 2nd SQL Statement
l Without index for BISMT & without statistics
n Runtime 3500 ms
l With index for BISMT & without statistics
n Runtime 3500 ms
l With index on BISMT & with statistics
n INDEX RANGE SCAN ZMARA (BISMT)
n Runtime 3 ms
l Without index on BISMT & with statistics
n TABLE ACCESS FULL ZMARA
n Runtime 1300 ms
n It is important to create table statistics regularly. If you do not create current table statistics:
Ÿ In some situations, the database optimizer will take the optimal index (as for statement 1)
Ÿ In other situations, the optimizer will choose a non-optimal index (as for statement 2 with index on
BISMT and without statistics)
n Do not spent too much time trying to understand optimizer decisions, as they are strongly database
dependent.
n Note: The times indicated above may differ from the times revealed in your training system.

© SAP AG 1999
Next Topic in Unit
statements
statements
l Detailed Analysis and Tuningè

© SAP AG 1999
Two Types of Expensive SQL Statements
Appl.-
Server
DBMS
ABAP program
Database interface
DBMS
process
Database
Database buffer
Appl.-
Server
DBMS
ABAP program
Database interface
DBMS
process
Database
Database buffer
Buffer
gets
Disk
reads
Records
processed
Few recordsMany records
Many blocks Many blocks
1 2
n Distinguish between two types of expensive SQL statements:
n Type I: The statement scans many data blocks in the database and is expensive because many
records are transferred to the ABAP program. Database performance is optimal.
n Type II: The statement scans many data blocks in the database but transfers only few records to the
ABAP program. Database performance is not optimal – for example, due to an inefficient search
strategy.

© SAP AG 1999
1
2
Expensive Statements Type 1:
n Large number of records processed but performance OK
n Suitable access path
n For example: SQL Trace: > 10 fetches per statement
n Small number of records processed, but large number of reads per
record or high response time per record
n Inefficient search strategy, unsuitable access path
n For example:
w Shared SQL Area: > 100 buffer gets per record
w SQL trace: FETCH duration > 500 ms
Detailed Analysis of Expensive SQL Statements
n Analyzing the two types of SQL statements using SQL traces (transaction ST05) reveals:
n For type I: Average duration of < 5 ms per record or < 100 ms per FETCH. Data are transferred with
optimal performance.
n For type II: FETCH duration is more than 500 ms
n If you look at the Shared SQL Area (transaction ST04; Detail analysis menu; SQL request) for the
two types of SQL statements, you find:
n For type I, bufgets per record < 5. This is the optimal relation between the number of records
processed and the number of data blocks scanned.
n For type II, bufgets per record > 5. This non-optimal relation between the number of records
processed and the number of data blocks scanned is caused by an inefficient search strategy.

© SAP AG 1999
1
2
n Problem: Too many records are transferred
n Solution: Rewrite ABAP coding
n Problem1: No suitable index exists
n Solution: Create or change secondary index
w or:
n Problem2: Optimizer does not use the right access path
n Solution: Check table statistics; if WHERE clause is too complex
rewrite ABAP coding
Detailed Analysis of Expensive SQL Statements

© SAP AG 1999
Total Buffer Bufgets per
execution gets record
Total Buffer Bufgets per
execution gets record
28 1.333.625 666.812,5
TABLE MARA
Full table scan
If table growth = n,
access effort = O(n)
Index MARA~M
Index scan
If table growth = n,
access effort = O(log n)
l SELECT * from MARA where MATNR = 10001
Index Use in SQL Statements (1)
n A poorly qualified SQL statement is one which does not use an index correctly to access data. To
identify poorly qualified SQL statements, in the Shared SQL Area (transaction ST04; Detail analysis
menu), look for expensive statements with a high number of bufgets per record.
n In general, using indexes is recommended because they make data access more efficient.
n Statements are regarded as poorly qualified if:
Ÿ No appropriate index is associated with the table being accessed
Ÿ An incorrect index is being used
Ÿ An index is being used but a full table scan is more effective (for example, for small tables or
where a large number of records are retrieved)
n Note: Do not change the standard R/3 index design unless this is recommended in an SAP Note.

© SAP AG 1999
l Results of using EXPLAIN:
l Use EXPLAIN TO find out whether:
n A full table scan is used
n Index fields do not match fields in WHERE clause
•No index being used
•Full Table Scan
SELECT STATEMENT
TABLE ACCESS FULL MARATABLE ACCESS FULL MARA
( Estimated costs = 1)
Execution Plan
n To find out whether an SQL statement uses an index to access the database, use the EXPLAIN
function on the SQL statement. EXPLAIN can be accessed from any of the following:
Ÿ SQL trace (transaction ST05)
Ÿ Database Process Monitor (transaction ST04; ORACLE session)
Ÿ Shared SQL Area (transaction ST04; Detail analysis menu)
n After choosing Explain, to find out the index structure or the structure of the table and all associated
indexes, double-click on the index or table name. This also reveals information about the statistics
used by the cost-based optimizer, such as when the statistics were last refreshed.
n For example, a statement is expensive if an index is missing, thus making it necessary to use a full
table scan.
n Even an index range scan can be expensive if the index is not selective or not utilized properly.

© SAP AG 1999
SQL statement
execution plan
EXPLAIN output:
l Access path
n Table access full
n Index range scan
n Index unique scan
n Concatenation
n Sort
n Index used
l Join method
n Nested loops
n Hash join
n Sorted merge
n Using the EXPLAIN function tells you which techniques are used by the database when executing an
SQL statement. For example:
Ÿ When using an index range scan, the database retrieves a number of records using an index to
limit the results before going to the data pages. This may not make access more efficient, for
example, if only non-selective columns are evaluated by the index, or if the wrong index is used.
Ÿ When using an index unique scan, the database retrieves a single row from an index. This access
method is very efficient.
Ÿ When using full table scan, the database retrieves all rows from the table to build the set of
results. This is normally inefficient, unless, for example, the table is small or the application
genuinely needs all the rows in the table.
Ÿ When using concatenation, the database makes a union of a set of rows retrieved for the query.
For OR or IN statements, concatenation normally makes access more efficient.
Ÿ When using a sort, the database sorts the data before returning it.
Ÿ When the database uses an index to retrieve data, EXPLAIN tells you the index name. This helps
you to recognize whether the database is choosing the wrong index.

© SAP AG 1999
1. Use only selective fields in the index:
n A selective field may be, for example, material,
personal number, or customer number
n A non-selective field may be, for example, client,
company code, plant, or document type
2. Use few fields in the index, for example, 5 or less
3. Position the most selective fields at the beginning of
the index
Rules for Creating a Secondary Index (1)
n Use selective fields in the index:
The fields in the index must significantly reduce the set of results selected by the SQL statement,
thus causing the SQL statement to read less than, say, 5% of the table. If more than approximately
5% is read, the cost based optimizer chooses a full table scan as the most effective access method.
n Use few fields in the index – as a rule, no more than 5 fields :
If you use too many fields in the index:
Ÿ Each added field requires additional operations to adapt the index when the value of the field is
changed.
Ÿ The amount of data to be stored and read is increased. This decreases the efficiency of the index
and of the probability that the optimizer chooses an index.
Ÿ The optimizer has a greater chance of making mistakes.
Ÿ The time necessary to prepare the statement increases considerably, especially when tables with
many indexes are tied together using a JOIN operation.
n Position the most selective fields at the beginning of the index:
Examples of selective fields can be document numbers, material numbers, or customer numbers.
Examples of non-selective fields are normally client, company code, main account. Thus, if an index
has the fields for plant and material number, position the field material number at the beginning of
the index.

© SAP AG 1999
4. Exceptions to rules 1 to 3:
n May sometimes be necessary to convince the optimizer to
choose the correct index
n For example: adding non-selective fields to the index
5. Use few indexes per table, for example: ≤ 5
Rules for Creating a Secondary Index (2)
n Exceptions to rules 1 to 3:
Due to the behavior of the Oracle rule-based optimizer used in R/3 Releases prior to 4.0, R/3
standard indexes normally start with fields like MANDT (client), BUKRS (company code), or
WERKS (plant). The Oracle rule-based optimizer chooses the index with the largest number of fields
specified in the WHERE clause with an “=”.
n Only few indexes per table– as a rule, no more than 5 indexes:
This rule does not apply to tables used mainly for reading, for example, tables containing master
data. The ABAP Dictionary defines the upper limit as 16 indexes per table, but this is usually too
many. The problems which arise with too many indexes per table are the same as those for indexes
with too many fields. Avoid overlapping indexes (indexes which consist of the same fields).

© SAP AG 1999
1. Avoid creating indexes for transaction data tables:
n For example, tables VBAK, MKPF, or BKPF
n Instead, use SAP matchcodes and index tables, for example:
matchcode VMVA, delivery due index VEPVG
2. Do not use indexes on R/3 Basis tables, for example: DD*,
D010*, NAST
3. Before creating a new index:
n Check for missing indexes in transaction DB02
n Read the performance hints for the relevant table
in R/3 Notes in the Online Service System (OSS)
Additional Tips for Creating a Secondary Index
n Avoid creating secondary indexes for transaction data tables:
Transaction data tables and any indexes associated with them grow linearly over time. Therefore,
SAP creates almost no secondary indexes for transaction data tables, but instead provides a large
number of index tables and matchcode tables for searching in transaction data tables. Use these SAP
standard search methods instead of creating your own indexes for transaction data tables. For details,
see SAP Notes 185530, 187906, and 191492.
n An experienced database administrator should support the application development team with his or
her knowledge of how the optimizer works and how to design effective indexes.

© SAP AG 1999
??????
The optimizer determines the optimal access pathThe optimizer determines the optimal access path
Database
table
SELECT * FROM ADDRSELECT * FROM ADDR
WHEREWHERE
name =”Schneider”name =”Schneider”
AND pnum = ”69126"AND pnum = ”69126"
AND city = ”Heidelberg"AND city = ”Heidelberg"
Possible access pathsPossible access paths
Index A
Full
table
scan
Index B
Optimizer Determination of Access Path
n 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
n As of R/3 Release 4.0, all databases used with R/3 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 1999
Execution plan
Table Statistics for the Optimizer
l The optimizer requires statistical
information. For example, the cost-based
optimizer needs to know the number of
entries in a table or index.
l Outdated table statistics may lead to
incorrect optimizer decisions and
inefficient table accesses.
l Schedule the periodic update of table
statistics using the DBA planning
calendar (transaction DB13).
n The sizes of tables and indexes and the distribution of values in tables can change. If the current
number of rows of a table has changed greatly since the last time the statistics were updated, the
optimizer may choose an ineffective strategy that increases the time required for database access.

© SAP AG 1999
Checking the Optimizer using EXPLAIN
•No index being used
•Full table scan
Click to see “Table and
Index Information"
screen
SELECT STATEMENT ( Estimated costs = 1)
Execution Plan
Up-to-date
statistics?
Check the optimizer
execution plan using EXPLAIN
TABLE ACCESS FULL MARATABLE ACCESS FULL MARA
n To find out the index structure (or the structure of the table and all associated indexes), in the screen
Display Execution Plan for SQL Statement, click on the index or table name. This also reveals
information about the statistics used by the cost-based optimizer, such as the number of distinct
values, and when the statistics were last refreshed.

© SAP AG 1999
Why Optimizer Decisions May Cause Performance
Problems
SYSTEM
Statistics
tables
To refresh the statistics, only use SAP tools
l Statistics are outdated or have
the wrong level of accuracy
l Incorrect assumptions of
cost-based optimizing
n The statistical information for a table or index is stored in the data dictionary of the database.
n To ensure that statistics are regularly updated (at least once a week), schedule the update statistics
function by using the DBA planning calendar (transaction DB13). For details on how to perform
scheduling for your particular database system, use the R/3 Online Documentation. To update
statistics for one table, use transaction DB20. Note: Running update statistics is a process that
consumes considerable system resources.
n The decisions of the cost-based optimizer may cause performance problems if:
Ÿ Statistics are outdated or have the wrong level of accuracy
Ÿ The assumptions of cost-based optimizing (such as uniformly distributed data within the object)
are incorrect in a particular case
n Performance problems deriving from outdated statistics or insufficient accuracy can easily be fixed
by restarting the analysis with a higher accuracy for some objects.
n To refresh the statistics of the R/3 tables, use only the relevant SAP tools. SAP tools ensure that the
update is performed using the frequency and accuracy defined for the table in the control table
DBSTATC. Statistics updates not performed by SAP tools can create severe performance problems
by incorrectly setting the accuracy level for the update.

© SAP AG 1999
Tips for Optimizing ABAP Coding (1)
n To access the developer help and the guidelines for efficient ABAP programming in the ABAP
Runtime Analyzer, choose System → Utilities → Runtime analysis → Execute → Tips & Tricks.
These guidelines are illustrated with examples taking into account performance-critical aspects of
ABAP programming, such as:
Ÿ Database accesses
Ÿ String manipulation
Ÿ Internal table processing
n Before accessing Tips & Tricks, you must use report SAPBC_TOOLS_GENERATOR_NEW to fill
the tables of the ABAP flight data model (tables SBOOK, SFLIGHT, and so on).

© SAP AG 1999
Tips for Optimizing ABAP Coding (2)
n In Tips & Tricks, types of SQL statements are listed. Clicking a type causes a comparison of two
sample statements of that type to be displayed. The two statements are differently formulated but
have an equivalent goal.
n To find out which variant is the most efficient, measure the runtime for both variants. The lower
section of the screen contains comments on the two variants. You can also enter and test a variant of
your own. The most efficient solution is displayed in the right part of the screen. To display the data
accessed by all examples, including the variants you entered, choose Display data.

© SAP AG 1999
Shared
SQL
area
Work process
overview
SQL
Trace
Transaction
profile
EXPLAIN SQL
statement
EXPLAIN SQL
statement
Index used Index used
Table name
transaction /
report name
Transaction code
Wait time
Database time
Table name
WHERE clause
Table name
WHERE clause
Expensive
SQL statement
DB Process
Monitor
WHERE clause
Go to Tuning
Roadmap

© SAP AG 1999
Tuning Roadmap
Detailed analysis of SQL statement
Many records transferred?
Optimize ABAP coding
Use EXPLAIN
Is the optimal index used?
Special database tuning methods
?
?
Are there missing indexes?
Recreate missing indexes
Is it possible to create a new index that matches the WHERE clause?
Create new indexes
Are table statistics up-to-date?
Refresh statistics
WHERE clause of SQL statement too complex?
Rewrite WHERE clause
An optimal index exists but is not used by the optimizer?
?
?
?
?
?
n The Tuning Roadmap summarizes the procedures to be used in tuning expensive SQL statements.

© SAP AG 1999
Objectives:
In this exercise you will:
l Analyze and tune an R/3 system with performance problems
caused by expensive SQL statements
l Use the Detection Roadmaps and the Tuning Roadmap for
analyzing SQL statements
Activities:
l Use the monitors described in the Detection Roadmaps to
identify expensive SQL statements
l Use Tuning Roadmap to find solutions for the problem
l Determine which recommendations
should be made
n Analyze the system and give recommendations for performance tuning. To express your
recommendations, fill in the blanks in the following text:
Recommendation:
We found an expensive SQL statement on table ______.
This SQL statement causes ____% of the whole database load (in terms of buffer gets).
The SQL statement originates from report _________.
To tune the execution of the SQL statement, we recommend applying the following changes:
1. Create an index on table ________, comprising fields _______, _________ ...
2. ...

© SAP AG 1999
Workload Analysis Exercise: Detection
l Process Overview:
n Critical report ZZSELECT accessing table ZLIPS
l Database Process Monitor:
n Find the SQL statement accessing table ZLIPS
l Transaction Profile:
n Lengthy database request time for transaction VA01
l Shared SQL Area:
n Huge number of buffer gets for an SQL statement on table ZLIPS
l EXPLAIN:
n Full table scan is used
l Trace of VA01 (performed by trainer):
n SQL statement accessing table ZLIPS
w Specifying MANDT, MATNR, WERKS and LGORT
n Your use of the monitors during the exercise should yield the results listed above, and enable you to
detect an expensive SQL statement.
n The next step is to determine what should be done to improve the performance of the expensive SQL
statement.
n The size of table ZLIPS is 15 MB.

© SAP AG 1999
Workload Analysis Exercise: Solution
l Solution:
n Create a secondary index for table ZLIPS (MATNR)
l Verification:
n Trainer restarts workload simulation and
trace of transaction VA01
n View the results of tracing VA01:
SQL statement shows improved performance
n Create a secondary index for table ZLIPS containing the field MATNR. Use the ABAP Dictionary
(transaction SE11).
n Verify that the new index was created properly.
n To verify that there is a performance improvement:
Ÿ Run and view an SQL trace (transaction ST05) for transaction VA01
Ÿ Check the Transaction Profile (transaction ST03N)

© SAP AG 1999
Before-and-After Comparison
l Before
l After
n As you can see in the relevant screens, access times have been improved considerably.

© SAP AG 1999
l Explain why even a few expensive SQL statements may reduce
performance for the whole R/3 System
l Regarding SQL statements, find out:
n Report and table name and database action: in the Process Overview
n High database request times: in the Transaction profile
n Table and index name: in the Database Process Monitor
n Statements with lengthy response time: through an SQL Trace
n High number of buffer gets: in the Shared SQL Area
l Tune expensive SQL statements by:
n Creating or changing an index
n Checking the database optimizer decisions
n Optimizing ABAP coding
n An experienced database administrator should monitor the database performance and detect
expensive SQL statements.
n ABAP developers, application consultants, and business process owners are responsible for tuning
expensive SQL statements.
n An experienced database administrator should support the application development team with his or
her knowledge of how the optimizer works and how to design effective indexes.
n Generalrules:
Ÿ Specify the WHERE clause as precisely as possible.
Ÿ The application development team must ensure that indexes are optimally designed
Ÿ Ensure that the statistics are up-to-date

© SAP AG 1999
Appendix1: Optimizing ABAP Database
Programming
Optimizing
ABAP Database
Programming
Appendix 1

© SAP AG 1999
SELECT field1 field2 field3 field4
FROM ( table1 INNER JOIN table2 ON
table1~field1 = table2~field1 )
WHERE ... AND field1 IN ('A','B','C') AND field3 LIKE 'T%'
SELECT
clause
WHERE clause
FROM clause
Appropriate indexes
Transfers data
Finds records
Specifies one or more tables
Limit the logical reads
ABAP Database Programming
n SQL is statement oriented. An SQL statement specifies data required by an application.
n The SELECT clause determines the fields to be transferred between the database server and the
application server.
n The WHERE clause specifies a number of records in tables by means of a criterion. The WHERE
clause determines the number of records accessed.
n The area searched in the database tables is determined by the optimizer which analyzes the SQL
statement and available indexes.
n The FROM clause specifies the number of tables to be read, thus determining the maximum amount
of data to be read during the search.

© SAP AG 1999
Creating Efficient SQL Statements
1. Data accessed by the SQL statement
2. Transferred data
3. Transfers
4. Overhead
5. Load on the database
To create efficient SQL statements, keep the
amounts of the following small:

© SAP AG 1999
ý Does the program use “SELECT *” statements?
þ Convert the statements to SELECT <column1>< column2> or
use a projections view
ý Do “SELECT ... ENDSELECT” routines contain CHECK
statements for table fields?
þ Replace the CHECK statement with an appropriate WHERE
clause
ý Do SQL statements on fields other than key fields use an
appropriate database index or is the table buffered?
þ Create an index for tables in the ABAP Dictionary unless they
are mainly intended for read access (Read Only or Read Mostly),
in which case, buffer the tables.
ý Does the program use SQL statements within SQL
statements?
þ Covert the inner SQL statements to database views or joins
Tuning Checklist for ABAP Coding (1)

© SAP AG 1999
ý Are there SQL statements without appropriate WHERE
clauses affecting tables that are growing constantly, such as
BSEG, MKPF, or VBAK?
þ The program design is incorrect
ý Does the program use SELECT .. APPEND ITAB ..
ENDSELECT to buffer internal tables?
þ Change the way accesses are processed by using an array fetch
to read the data into an internal table (for example: SELECT
CARRID CONNID FLDATE ... INTO TABLE I_SFLIGHT ...)
ý Does the program use SELECT ORDER BY... statements?
þ The data should initially be read into an internal table and sorted
- unless there is an appropriate index for the fields of the
ORDER BY clause

© SAP AG 1999
ý Does the program execute calculations?
ý Check whether the calculations are aggregate calculations such
as MIN, MAX, AVG, or COUNT), which you can have the
database perform
ý Does the program change data in dialog mode through
update, insert, modify, or delete?
ý Ensure that the program contains a COMMIT WORK statement
after one or more Logical Units of Work (LUWs) have been
completed

© SAP AG 1999
Database Locks
and R/3
Enqueues
Appendix 2: Database Locks and R/3 Enqueues
Appendix 2

© SAP AG 1999
Exclusive Lock Waits (1)
A
B
n To demonstrate the effects of an exclusive lock wait situation on the database, execute
program ZBC315_LOCK in two different user sessions. The first session, session A, will create an
exclusive lock on table NRIV by using the SQL statement ”SELECT SINGLE FOR UPDATE”.
After this SQL statement is executed, the program is stopped by a breakpoint.
n While session A is debugged, the session remains in the work process. This means that no COMMIT
or ROLLBACK is sent to the database.
n In the second session, session B, start program ZBC315_LOCK. All you see is the hourglass. The
program is not responding. The same result occurs when two different users start programs that lock
the same table entry.
n Note: Parameter "rdisp/wpdbug_max_no" must be set to ">= 1".

© SAP AG 1999
Session A
Session B
Host with lock, PID
session A
Host, PID waiting
session B
Locked resource
n In the Work Process Overview (transaction SM50), you can see that session B is not responding
during a DIRECT READ for table NRIV. R/3 work process 405 has sent a SELECT SINGLE for
table NRIV to the database and is now waiting for the database to return the requested data.
n In the monitor for database locks (Transaction DB01), you can see why there is no response to the
database request. Session B, which is run by work process 405, tries to create a lock on table NRIV,
which is already locked by the R/3 work process 494. In the Work Process Overview, you can see
that work process 494 is processing session A.
n To resolve the lock situation, session A must either release the lock or be cancelled.
n The waiting session B causes SAP work process 405 to be blocked, which may cause wait situations
for other users.
n Situations like the one described are typically not caused by breakpoints, but by lengthy processing
of ABAP statements or SQL statements after they set a database lock. The lock on the database is
released after the dialog step of session A is completed, and triggers a COMMIT or ROLLBACK.

© SAP AG 1999
A
B
n The diagram shows session B waiting for session A in the ABAP Editor screen (transaction SE38).
n In session A, choosing Continue means that session B receives the lock and is stopped at the
breakpoint. Restarting program ZBC315_LOCK again in session A means that you will again
receive an exclusive lock situation, with session A now waiting for session B.

© SAP AG 1999
R/3 enqueues:
l Logical locks in R/3
l 'Contract' between application
programs
l CALL FUNCTION 'ENQUEUE..'
l Released at the end of an R/3
LUW
l Stored in main memory
(enqueue table)
l Granularity: record, generic
area, may involve more than
one table
Database locks:
l 'Physical' database locks
l Applied automatically by the
DBMS
l INSERT, UPDATE, DELETE,
SELECT FOR UPDATE
l Released at the end of a
database LUW
l 'Stored' in the DBMS
l Granularity: record, block,
table
R/3 Enqueues versus Database Locks
n This slide summarizes the main features of R/3 enqueues and database locks.

© SAP AG 1999
l Use enqueues to:
n Explicitly exclude concurrent dialog access to data, thus preventing
logical inconsistencies
l A program using only read access does not need to use
enqueues:
n Isolation levels can be used to achieve read consistency if necessary
l Database locks:
n Are used in some special cases during the update phase
n Should not be used in a dialog program
w Exception: number ranges (SELECT Single for update)
Using R/3 Enqueues and Database Locks

© SAP AG 1999
Locking and Performance
l Enqueues and database locks on central objects can
serialize running transactions
l Avoid serialization:
n In general, perform locks only when necessary
n Keep locking times as short as possible:
w For example, use array operations instead of single record
inserts/updates
w For example, pre-aggregate data to enable one update instead
of many
n For number ranges: fewer requirements cause less serialization
n For available-to-promise quantities (ATP): additional logic can help
to reduce locking times, especially over dialog steps
l For many enqueues, use bundling in a local enqueue
container

© SAP AG 1999
OS Monitor and Top CPU Processes
A
B
n Use these two screens to detect high CPU usage on the database server.
n Screen A, the Operating System Monitor (Transaction ST06), indicates a CPU utilization of 90% for
user processes.
n Screen B, shows the top CPU processes (Transaction ST06; Detailed analysis menu → Top CPU
processes). This screen reveals that 85,2% of the 2 CPUs available are being used by the database
process with PID 142.
n High CPU usage of database processes for long periods typically indicates expensive SQL
statements.

© SAP AG 1999
The Database Process Monitor
A
B
n The Database Process Monitor (transaction ST04; ORACLE session) can be used to analyze high
CPU usage on the database server caused by expensive SQL statements. The Database Process
Monitor enables you to display:
Ÿ Database processes and the associated client processes (typically R/3 work processes).
Ÿ The SQL statement currently being processed. (To reveal the statement, double-click the
ORACLE process name.) This is useful for statements that run for at least several seconds – short-
running statements that are not expensive disappear too fast.
n Screen A, showing the Database Process Monitor, indicates that database process 296 is associated
with the client process 494 on machine TWDFMX06.
n After double-clicking the line containing this ORACLE process, the Database Process Monitor
displays the expensive SELECT on table ZLIPS: This statement is expensive because ZLIPS has
many records and the WHERE clause is not supported by a suitable index. The EXPLAIN function
for this SQL statement would indicate that a full table scan is being used.
n Screen B, showing the Work Process Overview (transaction SM50) for application server
TWDFMX06, identifies process 494 as an R/3 work process that is currently processing program
ZZSELECT.

© SAP AG 1999
R/3 Table Buffering
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements

© SAP AG 1999
R/3 Table Buffering
Objectives:
l Explain how buffering objects locally in all R/3 instances:
n Avoids database accesses and thus reduces the load on the
database server
n Reduces the load on R/3 work processes
l Detect incorrect buffering using the monitors:
n Statistical Records (Transaction STAT)
n Table Call Statistics (Transaction ST10)

© SAP AG 1999
R/3 Table Buffering
Contents:
l Buffers in R/3
l Exercise: Buffering database accesses
l Which tables should be buffered?
l Monitoring R/3 table buffering

© SAP AG 1999
First Topic in Unit
l Table Buffers in R/3
l Monitoring R/3 Table Buffering
è

© SAP AG 1999
Application Server A
SAP GUI SAP GUI
...
...
R/3 Buffers
Communication System
Database
Management
System
DBMS
Processes
Database
Cache
Database
Application Server B
SAP GUI SAP GUI
...
...
PXA Program Buffer
Presentation Buffer
CUA Buffer
Nametab Buffer
Number Range Buffer
Table Buffers
R/3 Buffers...
Table Buffers in R/3
n R/3 uses several buffers that are local to the application server and hold primarily run-time data:
Ÿ R/3 repository buffers
Ÿ Table buffers
Ÿ Program buffer
Ÿ R/3 GUI buffers
Ÿ R/3 roll and paging buffers
Ÿ R/3 calendar buffer

© SAP AG 1999
Table Buffer
DBMS
DBMS
Processes
Database
Buffer
Database
SELECT * FROM T001
WHERE ...
R/3 Database Interface
ABAP/4 Program
Why Use Table Buffers in R/3? (1)
n By specifying that a table is to be buffered, you can reduce database accesses and thus improve
performance.

© SAP AG 1999
Table Buffer
DBMS
DBMS
Processes
Database
Buffer
Database
SELECT * FROM T001
WHERE ...
R/3 Database Interface
ABAP/4 Program
8 - 600 ms
0,2 - 6 ms
Why Use Table Buffers in R/3? (2)
n The difference in the time required for local R/3 buffer accesses and that required for database
accesses is significant and affects:
Ÿ Database server load (CPU usage, size of database buffer required)
Ÿ Dispatch time for R/3 dialog steps (avoids blocking R/3 work processes)

© SAP AG 1999
key1 key2 key3 data
key1 key2 key3 data
key1 key2 key3 data
key1 key2 key3 data
Resident Buffering
(100%)
Generic buffering
1 key field
Generic buffering
2 key fields
Partial buffering
(single record)
001
001
001
001
002
002
002
002
002
002
003
003
003
003
003
003
003
003
001
001
001
001
002
002
002
002
002
002
002
002
003
003
003
003
003
003
003
003
003
003
003
001
001
001
001
001
002
002
002
002
002
002
002
002
002
002
003
003
003
003
003
003
003
003
003
003
003
003
003
A
A
B
B
A
A
B
B
B
C
D
C
A
A
A
B
B
C
C
C
D
D
D
A
A
B
B
B
A
A
A
A
B
B
B
C
D
C
A
A
A
B
B
C
C
C
C
D
D
D
D
4
2
3
1
5
1
3
6
8
1
2
3
0
5
3
2
3
6
2
4
2
3
5
8
1
2
3
4
Table Buffering Types
n There are three types of table buffering:
Ÿ Full buffering ("resident buffering"): 100% of a table's contents is loaded into the buffer on the
first access to any data from the table.
Ÿ Generic buffering: a number of generic key fields (first n key fields) is specified when setting this
option for a table. When accessing any data, all data records whose first n key fields are the same
as those in the data accessed are loaded into the buffer. The diagram shows generic buffering with
one and two fields as generic keys.
A typical case of generic buffering is client-dependent buffering, where the client name is the first
key field. If you specify resident buffering for a client-dependent table, the ABAP Dictionary
automatically uses generic buffering with one key field.
Ÿ Single record buffering ("partial buffering"): only single records are read from the database and
loaded into the buffer.
n All three table buffering types can be seen as special variants of generic buffering:
Ÿ For full buffering, n = 0
Ÿ For generic buffering, 0 < n < all key fields
Ÿ For single record buffering, n = all key fields

© SAP AG 1999
Application Server
Table Buffer
Database Management System
Database
Database is
up to date
Local buffer is
up to date
UPDATE T001...
R/3 DBIF
Buffer Synchronization (1)
n Two things happen when a buffered table is updated:
Ÿ The update is executed on the database table
Ÿ The buffer of the local R/3 instance on application server A is either updated or the contents are
marked as invalid and reloaded on the next access.

© SAP AG 1999
Table Buffer
Database
Table Buffer
Buffer is
NOT up to
date
Database is
up to date
Local buffer is
up to date
...
DDLOG
UPDATE T001...
R/3 DBIF
INSERT DDLOG
rdisp/bufrefmode
= sendon
n This example shows an R/3 System landscapes consisting of more than one R/3 instance: one R/3
instance on application server A and one R/3 instance on application server B.
n The buffer of the non-local R/3 instance (on application server B) is not updated immediately.
n The updating statement is executed by the R/3 Database Interface (DBIF), which inserts a record into
the table DDLOG indicating the change to, for example, table T001.
n There are two profile parameters which control synchronization between buffers and the database:
Ÿ rdisp/bufrefmode
Possible values of this parameter are:
- sendoff, exeauto: Used for a central system – an R/3 System with one R/3 instance
- sendon, exeauto: Used for a distributed system
Ÿ rdisp/bufreftime
Used to indicate the time interval in seconds

© SAP AG 1999
Table Buffer
Database
Table Buffer
Buffer is
invalidated
Database is
up-to-date
Local buffer is
up-to-date
...
DDLOG
R/3 DBIF R/3 DBIF
SELECT DDLOG
Buffer synchronization
occurs every 1-2 minutes
rdisp/bufrefmode
= sendon, exeauto
n A non-local R/3 instance (such as application server B in the diagram) performs synchronization
every one or two minutes (depending on how the relevant profile parameter is set). That is, the
instance reads database table DDLOG to check whether the tables in the instance buffer have been
changed in another instance. If there have been changes, the instance invalidates some or all of the
buffered tables that are affected by the changes.
n In the time period between synchronizations, users read the 'old' data. After data is invalidated, on
the next access to that data, the data is updated from the database.

© SAP AG 1999
l Fully buffered tables:
l Generically buffered
tables:
l Single-record
buffered tables:
Any change invalidates
the buffered table
Changes in work area
mode invalidate data
with the same generic
field keys
Changes in work area
mode invalidate one
buffered record
Granularity of Invalidation
n In work area mode, only one line of a table (the work area) is used to transfer data. This occurs, for
example, when using the ABAP command: UPDATE <dbtab> (where <dbtab> was defined using
command TABLES <dbtab>).
n Changes not made in work area mode invalidate the whole table. This occurs, for example, when
using the ABAP command: UPDATE <dbtab> WHERE <Field> = <Condition>.

© SAP AG 1999
Setting the Buffering for a Table
In Transaction SE13, you can set
the buffering for a table:
n No buffering
n Full buffering
n Generic buffering
n Single record buffering
n Transaction SE13 (Technical settings → Change) allows you to select the type of buffering (or no
buffering) for a specific table. The most important question is whether a table should be buffered at
all.
n A table should only be buffered if the table is read frequently and if it is acceptable from an
application or business point of view that changes to the data in the table are not immediately visible
on all other R/3 instances.
n In addition to full, partial, and generic buffering, another buffering type, "installation-dependent", is
sometimes used that enables a table to be initially not buffered, but later set to one of the above
buffering types in the running system. This buffering type is used if the table can be buffered from an
application point of view, but, for example, the size of the table and the amount of main memory
(hence the space for buffering) vary with the R/3 installation.
n Normally, the programmer has set a buffering type, which can be revealed in the access profile for
the table.

© SAP AG 1999
SQL Statements Bypassing the Buffer (1)
These kinds of SQL statements bypass all buffering types:
n SELECT ... BYPASSING BUFFER
n SELECT FOR UPDATE
n Any aggregate function (COUNT, MIN, MAX, SUM, AVG): for
example, SELECT MIN(F1) FROM T1 WHERE ...
n SELECT DISTINCT
n WHERE clause contains "IS NULL"
n ORDER BY (other than PRIMARY KEY)
n Any native SQL statement
n SQL statements that cannot be satisfied from the buffer, bypass the buffer and access the database.
n Statements that bypass any type of buffering should be avoided when programming with buffered
tables in order to optimize performance. An exception is maintenance transactions on buffered
tables, which should use an explicit SELECT ...BYPASSING BUFFER to ensure the retrieval of the
most-up-to-date data directly from the database.

© SAP AG 1999
SQL Statements Bypassing the Buffer (2)
l This kind of SQL statement bypasses partial buffering:
n A non-single select: for example,
SELECT * FROM T1 WHERE ...
l This kind of SQL statement bypasses generic buffering:
n Select without specifying the generic key: for example,
SELECT * FROM T1 WHERE ...

© SAP AG 1999
Objectives:
In this exercise you will become familiar with:
l Information in SQL traces
l When different types of buffering are used
Activities:
After your trainer creates an SQL trace of program
ZBC315_SELECT_BUFFER:
l Display the SQL trace and the program source code.
l For each SQL statement, determine whether the data is retrieved from
the database or from the buffer.
l If the data is retrieved from the buffer, determine whether partial
buffering or generic buffering is used.
SQL/Buffering Exercise

© SAP AG 1999
l SELECT * FROM RESB
WHERE RSNUM = '1234567890'
AND RSPOS = '0987654321'
AND RSART = 'A'
AND BDART = 'XX'.
ENDSELECT.
l SELECT * FROM TITLE
WHERE DDLANGUAGE = 'E'
AND PROGNAME = 'RSORA000'
AND DDNR = '110'.
ENDSELECT.
è Buffering of RESB: Not Buffered
Thus, conclude: Database access
è Buffering of TITLE: Partial Buffered
Full primary key specified
BUT NOT specified as
SELECT SINGLE * FROM ...
SQL/Buffering Exercise Solution (1)

© SAP AG 1999
l SELECT SINGLE * FROM TCOLL
WHERE RNAME = 'RSHOSTDB'.
l SELECT SINGLE * FROM T001
WHERE BUKRS = '0001'.
è Buffering of TCOLL: Buffered
Thus, conclude: Buffer access; generic buffer
è Buffering of T001: Generic (1 Field)
Field MANDT is filled automatically
Thus, conclude: Generic key is specified

© SAP AG 1999
l SELECT * FROM ZZBUF_SNGL
WHERE FIELD_1 = '1'.
ENDSELECT.
l SELECT * FROM ZZBUF_FULL
ENDSELECT.
è Buffering of ZZBUF_SNGL: Partial Buffered
Full primary key NOT specified and
NOT specified as SELECT SINGLE
è Buffering of ZZBUF_FULL : Full

© SAP AG 1999
l SELECT * FROM ZZBUF_NONE
ENDSELECT.
l SELECT * FROM ZZBUF_GEN3
WHERE FIELD_1 = '4'
AND FIELD_2 = '4'
AND FIELD_3 = '4'
AND FIELD_4 = '4'
AND FIELD_5 = '4'
AND FIELD_6 = '4'.
ENDSELECT.
è Buffering of ZZBUF_NONE : Not Buffered
è Buffering of ZZBUF_GEN3 : Generic (3 Fields)

© SAP AG 1999
l SELECT * FROM ZZBUF_FULL
ENDSELECT.
WHERE FIELD_1 = '6'
AND FIELD_2 = '6'
FIELD_3 AND FIELD_4 = '6'
NOT specified AND FIELD_5 = '6'
AND FIELD_6 = '6'.
ENDSELECT.
è Buffering of ZZBUF_GEN3 :
Generic (3 Fields)
Generic key is NOT specified

© SAP AG 1999
l SELECT SINGLE * FROM ZZBUF_FULL
WHERE FIELD_1 = '7'
AND FIELD_2 = '7'
AND FIELD_3 = '7'
AND FIELD_4 = '7'
AND FIELD_5 = '7'.
ENDSELECT.
WHERE FIELD_1 = '8'
AND FIELD_2 = '8'
AND FIELD_3 = '8'
AND FIELD_5 = '8'
AND FIELD_6 = '8'.
ENDSELECT.

© SAP AG 1999
WHERE FIELD_1 = '9'
AND FIELD_2 = '9'
AND FIELD_3 = '9'
AND FIELD_4 = '9'
AND FIELD_6 = '9'.
ENDSELECT.
BYPASSING BUFFER
WHERE FIELD_1 = '0'
AND FIELD_2 = '0'
AND FIELD_3 = '0'
AND FIELD_4 = '0'
AND FIELD_5 = '0'.
ENDSELECT.
BUT this statement is specified as
BYPASSING BUFFER

© SAP AG 1999
hh:mm:ss.mm Duration T Table Database Request
11:26:24.694 8.404 D TRDIR REOPEN 98 SELECT WHERE "NAME" = ZZBUFFER AND ROWNUM <= 11
11:26:24.703 2.182 D TRDIR FETCH 98 Array: 192 Records: 1 Return code: +1403
11:26:24.740 294 D RESB REOPEN 109 SELECT WHERE "MANDT" = 900 AND "RSNUM" = 12345678
11:26:24.742 1.629 D RESB FETCH 109 Array: 24 Records: 0 Return code: +1403
11:26:24.745 89 D TITLE REOPEN 110 SELECT WHERE "DDLANGUAGE" = E AND "PROGNAME" =
11:26:24.745 1.135 D TITLE FETCH 110 Array: 412 Records: 1 Return code: +1403
11:26:24.747 85 D ATAB-TCOLL REOPEN 74 SELECT WHERE "TABNAME" = TCOLL AND "VARKEY" = R
11:26:24.748 1.080 D ATAB FETCH 74 Records: 1 Return code: +0
11:26:24.763 94 D ZZBUF_SNGL REOPEN 111 SELECT WHERE "FIELD_1" = 1
11:26:24.764 1.114 D ZZBUF_SNGL FETCH 111 Array: 1571 Records: 0 Return code: +1403
11:26:24.766 84 D ZZBUF_NONE REOPEN 113 SELECT WHERE "FIELD_1" = 3
11:26:24.766 860 D ZZBUF_NONE FETCH 113 Array: 1571 Records: 0 Return code: +1403
11:26:24.769 102 D ZZBUF_GEN3 REOPEN 115 SELECT WHERE "FIELD_1" = 6 AND "FIELD_2" = 6 AND "F
11:26:24.769 1.052 D ZZBUF_GEN3 FETCH 115 Array: 1571 Records: 0 Return code: +1403
11:26:24.772 101 D ZZBUF_GEN3 REOPEN 116 SELECT WHERE "FIELD_1" = 0 AND "FIELD_2" = 0 AND "F
11:26:24.772 900 D ZZBUF_GEN3 FETCH 116 Array: 1571 Records: 0 Return code: +1403
SQL trace results:
SQL/Buffering Exercise: 2nd Run of ZZBUFFER
n The above SQL trace shows all statements which are sent from R/3 to the database while running the
ABAP program ZZBUFFER. These SQL statements cannot be satisfied from the local R/3 table
buffers.

© SAP AG 1999
Next Topic in Unit
l Monitoring R/3 Table Buffering
è

© SAP AG 1999
Buffering Strategy: Technical Criteria
l You can buffer R/3 tables that are:
n Relatively small, normally < 1 MB*
n Infrequently changed, for example, changes < 1% of reads
n Not immediately required to be consistent in all application
server buffers
n Accessed by primary key
l Note:
n Only buffer tables > 10 MB in special cases
n Buffer searches by secondary index are not possible
n When buffering new tables, ensure that the table buffers are
large enough
n Even if a table is technically eligible for buffering, this does not mean that buffering is acceptable
from an application or business point of view.
n Buffering of SAP standard tables requires you to obtain a modification key in the SAPNet.

© SAP AG 1999
Buffering Strategy: Application Criteria
l Transaction data is never buffered
n Examples: accounting documents in table BKPF, sales
documents in table VBUK
n Reason: These tables are too large or too often changed
l Master data is normally not buffered
n Examples: customer master in table KNA1, material master in
table MARA
n Reason: These tables are normally too large and are often
accessed by secondary indexes (not possible through R/3
table buffers)
l Customizing data is normally buffered
n Examples: company codes in table T001, exchange rates in
table TCURR
n Reason: These tables are relatively small or rarely changed
n This slide shows some of the criteria that must be met in addition to the technical criteria, in order to
make a table eligible for buffering.

© SAP AG 1999
l Condition tables include tables for pricing, material, text
determination, and partner determination
l Examples:
n Tables A<nnn>, B<nnn>, C<nnn>, D<nnn>, KOTE<nnn>,
KOTF<nnn>, and KOTG<nnn> – where "nnn" is a number
ranging:
n From 000 to 499; indicates that the table is part of the SAP
standard and is buffered as delivered
n From 500 to 999; indicates that the table is customer created,
and is often not buffered. You should check whether the table
is or should be buffered.
Buffering Strategy: Condition Tables
n The following rule of thumb can be also used to determine tables that are eligible for buffering:
Ÿ For a table size of less than 1MB, there should be no more than 1% changes per read, and there
should be at least 300 sequential reads /day.
Ÿ For a table size of between 1 and 5 MB, there should be no more than 0,1%changes per read,
and there should be at least 1000 sequential reads /day.

© SAP AG 1999
Buffering Optimization
l Task I:
n Check for tables which are not buffered, but should be.
n For example, check the customer’s:
w Customising tables, (table names beginning with Y or Z)
w Condition tables (for example, table A<nnn>, where nnn =
500 to 999)
l Task II:
n Check for tables which are buffered, but should not be.
n For example, check large and frequently changed Customising
tables, such as:
w Table TCURR (exchange rates)
w Tables A005 (prices), A017 (customer/material), and A018
(vendor/material)
n In the SAPNet, see also, for example, SAP Notes 23877, 91335, and 34910.

© SAP AG 1999
Next Topic in Unit
l Monitoring R/3 Table Bufferingè

© SAP AG 1999
Workload Monitor (Transaction ST03) for all task types dialog, and update
Programs with lengthy database time: > 40% (response time - wait time)
Choose Transaction Profile and sort by Response time total
?
Analyze table buffering using Table Call Statistics (Transaction ST10)
Detailed analysis with ABAP trace (Transaction SE30)
For programs with a lengthy database time, in ST03, choose Statistics records
? Programs with large CPU time: > 40% (response time - wait time)
? Do the statistics records indicate changes to buffered tables (with Note:
Tables were saved in the table buffer)?
Analyze SQL statements using an SQL trace (Transaction ST05)
n This roadmap shows you how to leads you to find problems with table buffering problems:
1) Display the Workload Monitor (Transaction ST03) for task types dialog and update
2) For both respective task types, choose Transaction profile and sort according to response time
3) For the programs or transactions that have a large response time, look at the adjacent columns to
find out whether they have a lengthy CPU time or a lengthy database time.
4) For transactions with database time > 40% (response time - wait time):
Analyze single records by viewing statistical records using Transaction STAD.
5) To analyze statistical records with a lengthy database time, double-click the appropriate line.
6) To find out whether a buffer reload occurred in the corresponding dialog step, choose DB and
check for the note Tables were saved in the table buffer.
7) If this note occurs for many statistical records, it indicates frequent buffer reloads.
The table buffer should be analyzed using the Table Call Statistics monitor (Transaction ST10).

© SAP AG 1999
Table Call Statistics (Transaction ST10)
n To call transaction Table Call Statistics, use Transaction ST10, or, from the R/3 initial screen choose:
Tools → Administration → Monitor → Performance → Setup/buffers → Calls.

© SAP AG 1999
Analysis Roadmap: Using Table Call Statistics
Call the monitor Table Call Statistics (transaction ST10)
Are there buffered tables with a high number of invalidations?
Consider the buffering rules – should tables be unbuffered?
Are there buffered tables with a large buffer size?
Are there buffered tables with a high number of “Rows affected” in the database?
Unbuffered tables with many “Total ABAP Processor requests”?
Consider the buffering rules – should tables be buffered?
?
?
?
?
n This roadmap helps you to decide which tables should be buffered.
n 1) Call Transaction ST10. Select all tables, since startup, and this server. Then choose Show
statistics. The screen Performance analysis: Table call statistics is displayed, and contains a list of
tables and the related statistics. To sort the list by the figures in a particular column, place the cursor
anywhere in the column and choose Sort.
n 3) Sort the list by Invalidations.
For the tables at the top of the list, consider the buffering rules and decide whether these tables
should be unbuffered.
n 4) Choose Next view and sort the list by Buffer size [bytes].
n 5) Sort the list by column Rows affected under DB activity.
n 6) Sort the list by column Total under ABAP Processor requests.
For the unbuffered tables at the top of the list, consider the buffering rules and decide whether these
tables should be buffered.

© SAP AG 1999
Detection Roadmap: Monitoring Table Buffering
l To detect incorrectly buffered tables, use:
n Table Call Statistics (Transaction ST10)
n SQL trace (Transaction ST05)
l To determine the rate of table change:
n In Table Call Statistics, look at field Changes
n Ask the developer or user
l To determine table size:
n For tables which are already buffered, use Table Call Statistics
n For tables which are not buffered, use Analysis of Table
According to Index (Transaction DB05)

© SAP AG 1999
Example: Monitoring Table Buffering
n To call the transaction Table Call Statistics, use transaction code ST10.
n Example from a customer system with R/3 Release 4.0B:
Ÿ The tables J_1BTXIC2 (Tax calculation.: ICMS rules) and A071 (Material per plant) are often
invalidated. Each invalidation is followed by a reload.
n Question: Should the buffer type for these tables be changed ?
Ÿ Both tables show a high number of invalidations. The buffer reloads causes a high database
activity (“DB activity – Rows affected”).
Ÿ The difference between the usage of both tables is the number of “ABAP/IV Processor requests –
Total”. For table J_1BTXIC, this value is 10 times greater than the number of affected rows. For
table A071, the value of “ABAP/IV Processor requests – Total” is quite small. We infer that the
small number of request are causing a high database load. Because the invalidation rate (ratio of
invalidations to total requests) for table A071 is around 6%, the buffering of the table A071
should be deactivated.
Ÿ To determine whether to change the buffering type for table J_1BTXIC2, a more detailed analysis
is necessary. To display all available information for table J_1BTXIC2, double-click the first row.

© SAP AG 1999
Table Analysis using transaction DB05
Analyzed table: J_1BTXIC2
Total number of rows: 80,914 rows
Requested bytes per row: 58 bytes per row
Requested bytes to be buffered 100%: 4,693,012 bytes
Current buffering mode: 100% buffering
Distribution between clients: Client 400 80,889 rows
Client 410 25 rows
Example: Table Analysis (1)
n The detailed analysis (transaction code DB05) of table J_1BTXIC2 delivers the size of the table and
the number of entries. It shows that all rows belonging to client 400 are buffered. Nearly the entire
table is buffered.

© SAP AG 1999
Example: Table Analysis (2)
Distribution of the generic region in table J_1BTXIC2
Rows per
Generic Key
Distinct
Values
1 to
10
11 to
100
101 to
1000
1001 to
10000
>
10000
MANDT 2 0 1 0 0 1
LAND1 2 0 1 0 0 1
SHIPFROM 18 5 3 3 4 3
SHIPTO 44 25 3 5 6 5
MATNR 80 414 80 414
VALIDFROM 80 914 80 914
n Also the analysis by DB05 delivers the distribution of the generic regions of a table.
n The above table shows the distribution of table J_1BTXIC2.
Ÿ Each row represents a type of generic buffering. For example, MANDT is relevant for generic 1
buffering. LAND1 is relevant for generic 2 buffering, and so on.
Ÿ The values in column distinct values indicates the number of different combinations between the
different keys. For example, the distinct value for SHIPFORM is 18. That means that there are 18
different combinations of the first three keys, MANDT, LAND1, and SHIPFROM.
Ÿ The following rows shows the number of entries for the combinations. For example, for
SHIPFROM, five combinations have a number of entries in the range from 1 to 10.
n With the combination of the key fields MANDT, LAND1, SHIPFROM, SHIPTO, MATNR and
VALIDFROM there are 80 914 entries. This is the total number of table entries.
n Buffering of table J_1BTXIC2:
If the table J_1BTXIC2 is fully buffered or buffered with generic 1, the table is completely buffered.
A change operation invalidates the whole table. Because of the large number of invalidations, this
buffering type is inefficient. To decide the right buffering type, you need to know the SQL
statements that are processed. To find out these statements, you can use the SQL cursor cache (see
next slide).

© SAP AG 1999
Example: SQL Cursor Cache
n Use ST04 to display the Shared Cursor Cache. Look for Selects on table J_1BTXIC2. Analyse the
fields of the WHERE clause.
n To display the Shared Cursor Cache, use transaction code ST04, and choose Detail Analysis Menu
→ SQL Requests.
n Look for SQL statements that access table J_1BTXIC2.
n Analyze the fields of the WHERE clause for all such statements.
n The analysis shows that all statements on table J_1BTXIC2 contain the key fields MANDT,
LAND1, SHIPFROM, SHIPTO and MATNR. These fields are part of the primary index.
n Solution: The table should be buffered with generic 5 buffering. This enables all the information
needed by the SQL statements to be found in the buffer (after the initial buffer loading). In case of an
invalidation, only 10 entries are invalidated (as displayed in the DB05 analysis). So the load caused
by a buffer reload is kept to a minimum.

© SAP AG 1999
l Incorrect table buffering can reduce performance for critical
transactions
l As a rule, tables can be buffered if the table buffers have
enough free space and if the tables are:
w Small
w Frequently accessed
w Rarely changed
w Not time-critical (inconsistencies between application server
buffers are acceptable for short time periods)
Summary
n Also check that the table buffer has enough free space. If necessary, increase the buffer size.

© SAP AG 1999
ATP Server
Appendix: ATP Server
Appendix

© SAP AG 1999
Introduction: Availability Checks with ATP Logic
l ATP denotes "available to promise"
l Purpose of availability checks:
Ensure reliable data on material availability covering all areas in
the logistics supply chain (for example, SD, PP, and MM)
l Tables affected:
n Tables read:
Table RESB: Material reservations per production order item
Table VBBE: Material requirements per sales document item
Other tables: Relating to purchase orders
n Tables locked:
Table MARC: Material Master
n The available-to-promise quantity is the quantity still available for new sales orders. The ATP
quantity is calculated according to the following formula:
ATP quantity = warehouse stock + planned receipts - planned issues.

© SAP AG 1999
First Topic in Appendix
l ATP check performance
l Solutions:"Locking with quantities" and ATP server
l Monitoring
è

© SAP AG 1999
Material Locking (1)
l Example:
n 8000 PCs per day delivered
n 50% are delivered with “CPU type A”
l Availability is checked 4000 times
n Material has to be locked each time
⇒ Locking limits transaction volume

© SAP AG 1999
Material Locking (2)
If decision = yes
then amnt = amnt - req
Check availability
(req <= amnt)
Enqueues
R/3 exclusive enqueue
The locking occurs if many
checks are performed
simultaneously

© SAP AG 1999
Database Accesses
l Table RESB (or View MDRS)
n Contains material reservations for PP
n Size: Up to 1 million records = 1 GB, in some cases even more
l Table VBBE
n Contains material requirements for SD
l ATP Check
n Every work process performs its own availability check
n Reads all required RESB and VBBE records
⇒ Very many read accesses to RESB and VBBE

© SAP AG 1999
Next Topic in Appendix
l Monitoring
è

© SAP AG 1999
Overview of ATP Related Techniques
Technique R/3
Rel.
Description Advantage
Locking with
quantities
≥ 2.2 Shorter material locks Less material blocking à
High transaction volume
ATP server ≥ 4.0 Central ATP check for
one R/3 System
Reduced load on database
tables RESB and VBBE
APO* server ≥ 4.5 Global ATP check for
multiple R/3 Systems
and legacy systems
Global, company wide ATP
information
*APO = Advanced Planner and Optimizer
(separate component)

© SAP AG 1999
Locking with Quantities (1)
ABAP
Exclusive enqueues:
Check availability
(req <= amnt - (req2 + …))
and store req as req1
If decision = yes
then amnt = amnt - req1
… all others check availability as
(req <= amnt- (req1 + req2 + ...))
As of R/3 Release 3.0:
Locking with quantities
If decision = yes
then amnt = amnt - req
Before R/3
Release 3.0:
Check availability
(req <= amnt)
Exclusive enqueue:
R/3 exclusive enqueue
Shared enqueue:
Store req1
ABAP
n The technique of locking with quantities is a solution to the locking problem described earlier.
n The example of ATP shows how knowledge about the application logic can be exploited to reduce
the contention due to enqueues.
n The upper figure sketches the former implementation of ATP. An enqueue has been used to lock the
amount of the requested material for the whole time from the check until the end of SAP LUW (end
of update task). This includes possibly many dialog steps and can lead to massive serialization if a
small number of materials is requested very often.
n In the current implementation, the enqueue is used only during the ATP check itself and within the
update phase. In both cases, no dialog time is included within the locking time. The information
about the requested amount is stored in the enqueue server, from there it is read for all following
checks and in the update phase to calculate the resulting amount.

© SAP AG 1999
Locking with Quantities (2)
l To activate locking with quantities:
n In Transaction SPRO, access Define checking groups and
activate the flag Block QtRq for each checking group as
required
l Advantages:
n Short exclusive R/3 enqueues
n Attempts to set R/3 enqueues have less likelihood of being
rejected. This also means less database load and less CPU
load.
l Further Information:
n Empowering Workshop: EWC10 Technical Optimization of
Availability Check
n To activate locking with quantities:
Ÿ Choose: Customizing (SPRO) → Continue → Implement. projects → SAP Reference IMG;
Ÿ In the IMG tree structure, choose: Sales and Distribution → Basic Functions → Availability check
and … Availability Check→ Availability Check with ATP Logic or Against Planning Define
checking groups
Ÿ Activate the flag Block QtRq for each checking group as required.

© SAP AG 1999
ATP Server (1)
l The ATP server:
n Provides a central ATP check
n Aggregates and buffers data on material requirements (sum
VBBE records) and reservations (sum RESB records) per
plant, material, storage location, batch and day
l Configuration:
n rdisp/atp_server = <ATP instance> in default profile
n Check that "ATP" is in List of SAP Servers (Transaction SM51)
n The ATP service should reside on the enqueue server
n Ensure that there are enough dialog work processes on the
enqueue server (≥ 5)
n As of R/3 Release 4.0A, a materials availability check based on available-to-promise (ATP) logic
can be performed using a dedicated R/3 instance, the ATP server. This server has a global memory
area for all work processes: the Shared Buffer. A delta handling mechanism ensures that the Shared
Buffer and the database are consistent with each other.
n The advantage of using an ATP server is that when you initiate an availability check, the system
reads the data of the relevant tables, such as RESB and VBBE, from the Shared Buffer instead of
from the database, thus optimizing performance.

© SAP AG 1999
ATP Server (2)
l Sizing the Input/Output buffer for the ATP server:
n For an R/3 Instance without ATP server (default):
rsdb/obj/buffersize = 4096 (KB)
rsdb/obj/max_objects = 5000
n For an R/3 Instance with ATP server:
rsdb/obj/buffersize = 20000
rsdb/obj/max_objects = 20000
n Two buffer entries are required for each material and plant in the
ATP check: RESB sum record and VBBE sum record. Therefore,
the above I/O Buffer can hold 10000 material/plant combinations.
n Each buffer organizes its data in days. The size of each buffer
entry:
w Depends on the number of days having material reservations
w Requires approximately 100 bytes per day

© SAP AG 1999
ATP Server (3)
R/3 instance 1 (ATP server)
Dispatcher
DIA
DIA
Gateway
R/3 instance 2
Dispatcher
DIA
DIA
1
2
ENQ table
Export /
import
buffer Gateway
RFC
3
Database
RESB
VBBE
Dialog work
process
Dialog work
process
n The ATP server works as follows:
Ÿ A dialog work process requiring an availability check sends an RFC call to the ATP Server. (1)
Ÿ The RFC call is dispatched to a dialog work process on the ATP server. (2)
Ÿ The availability check is performed. This involves communication with the enqueue table, the
export/import buffer, and database tables (for example, table RESB and table VBBE). (3)

© SAP AG 1999
Next Topic in Appendix
l Monitoringè
n When the ATP servers is active, the entry “Atp” is displayed in the server overview (transaction
SM51)

© SAP AG 1999
Table name Object name .. Size .. Used
[KB]
ATPSB 001ACTEST 001REWPF 000000000097009900 3.714 120
ATPSB 001ACTEST 001VBWPF 000000000230045000 3.489 34
Material
Plant
RE/VB = RESB/VBBE
Client
l Check:
n Buffer quality
n Size of each entry
n Number of accesses under Used
Monitoring the Export/Import Buffer
n To monitor the export/import buffer, use Transaction ST02 and choose Detailed analysis menu
→ Export/import → Buffered objects.

© SAP AG 1999
l Monitor enqueues in Transaction SM12
l Enqueues that are older than one day indicate a
problem
Monitoring R/3 Enqueues
Man User Time Shared Table Lock Argument
001 WÄCHTLERH 10:07:57 X ATPENQ 001TEST 001000000080830000WPF
001 WÄCHTLERH 10:07:57 AUFK 001000000787121
001 WÄCHTLERH 10:07:57 RKPF 0010008784910
n To monitor enqueues, use Transaction SM12 or, from the R/3 initial screen, choose Tools
→ Administration → Monitor → Lock entries. Then:
Ÿ In the fields Client and User name, enter an asterisk ("*")
Ÿ Choose List

© SAP AG 1999
Monitor SQL statements in the Shared SQL Area
(Transaction ST04):
n View ATP_RESB (prior to R/3 Release 4.0 called MDRS)
n View ATP_VBBE
Monitoring SQL Statements
SELECT
*
FROM
"ATP_RESB"
WHERE
"MANDT" = :A0 AND "MATNR" = :A1 AND "WERKS" = :A2 AND
"XLOEK" = :A3 AND "KZEAR" = :A4 AND "SOBKZ" = :A5 AND
"BDMNG" > "ENMNG" AND "TXTPS" = :A6 AND "SCHGT" = :A7 AND "DBSKZ" = :A8
SELECT
"LGORT", "CHARG", "VBTYP", "MBDAT", SUM("OMENG"), SUM("VMENG")
FROM
"ATP_VBBE"
WHERE
"MANDT" = :A0 AND "MATNR" = :A1 AND "WERKS" = :A2 AND "SOBKZ" = :A3
GROUP BY
"LGORT" , "CHARG" , "VBTYP" , "MBDAT" #
n To monitor SQL statements in the Shared SQL Area, use Transaction ST04 and choose Detail
analysis menu → SQL request.

© SAP AG 1999
Setting ATP Server Parameters
l Work Processes:
n Dialog work processes on the ATP server ≥ 5
l Extended memory and roll buffer:
n em/initial_size_MB ≥ 256
n rdisp/ROLL_SHM ≥ 4000 (corresponds to 32 MB)
n Check these parameters in Transaction ST02
l R/3 parameters for RFC communication:
n rdisp/tm_max_no ≥ 500
n rdisp/max_comm_entries ≥ 500
n gw/max_conn ≥ 500
n For full details, see the following SAP Notes in SAPNet:
Ÿ SAP Note 40904 Performance during availability check
Ÿ SAP Note 99999 ATP-Server: ATP server: Installation and Sizing
Ÿ SAP Note 24762 Blocking with quantities and late exclus. block

© SAP AG 1999
Interface Monitoring
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements

© SAP AG 1999
Contents
l User interfaces and system interfaces
l Monitoring RFC calls
l Controls technology and GUI communication
l Communication between systems and RFC configuration
l Exercise: Monitoring RFC Load
Objectives
At the end of this unit, you will be able to:
l Understand the basics of the SAP RFC interface
l Monitor RFCs that are used to build up Enjoy screens as of R/3 4.6
l Identify and optimize performance of RFCs that are incoming from a
partner system
Interface Monitoring

© SAP AG 1999
Processing Modes
l Business documents in an SAP System can be processed
in the following ways:
n By users working online in the system (= user interface)
n By background jobs
n Driven by interfaces to other systems (SAP or external)
w Batch input interface (transfer by file)
w RFC interface
n Online processing: Users logged on to R/3 create or process documents in dialog mode, for example,
at a call center, where calls from customers are entered as orders in R/3.
n An example of background processing is delivery due list processing. During the night, customer
orders are automatically analyzed in bulk and converted into deliveries. Typically, in background
processing a program reads and creates documents using data already present in the system.
n Example of Batch Input processing: The data to be converted into R/3 documents often already
exists in electronic form, for example, as a file. Rather than have users manually enter this data, R/3
enables you to transfer file data into R/3 using programs that run in background processing via an
interface. This is a special form of background processing that is often used as a communication
interface between R/3 and other systems. One example is accessing customer orders on non-local
servers. One strategy is that the non-local servers send their data to a central server from which it is
transferred to R/3 using Batch Input.
n RFC interface processing: R/3 can communicate with other data processing systems not just
through files, but also directly, using remote function calls (RFCs). RFCs exchanges can be between
R/3 Systems or between R/3 and external systems. Using RFC, an external system can transfer data
to, and trigger programs in, R/3 – and R/3 can do the same in an external system. For example, R/3
creates transport requests for stock movements and sends them via RFC to an external warehousing
system. After executing the goods movements, the warehouse system triggers the necessary IDocs
and ALE movements in R/3 to confirm delivery.

© SAP AG 1999
mySAP.com Interfaces
SAP R/3
SAP GUI for
Windows or
Java
SAP GUI for
Windows or
Java
CRM
Server
Server
Mobile
Clients
Mobile
Clients
mySAP.com Workplace
Work-
place
Server
RFC
DIAG
or RFC
SAP GUI
for HTML
SAP GUI
for HTML Web
Server
HTTP
SAP BW
SAP APO
Legacy System
SAP R/3
SAP R/3
Warehouse
System
File Interface
(Batch input,
Fast input)
Printer
Interface
PrinterPrinter
RFC, ALE
User Interfaces System Interfaces
n Occasional users (for example users that log on through Internet or intranet) work with the SAP
GUI for HTML. No installation of a GUI is necessary on the desktop computer (except a Web
browser). A Web server and the SAP Internet Transaction Server handles the communication
between the Web browser and the SAP System. Details on the performance monitoring of the SAP
GUI for HTML can be found in SAP training course BC350.
n Specialists and power users normally work with a SAP GUI for Windows or Java.

© SAP AG 1999
Remote Function Calls (RFCs)
l Remote function calls (RFCs) are used for
n Communication between SAP application layer and SAP GUIs
n Communication between two SAP Systems, or between an SAP
System and an external system
n Starting processes in parallel within one SAP System
l There are 3 types of RFCs:
n Synchronous RFCs
w For communication between systems
w For communication between SAP application layer and SAP GUIs
n Asynchronous RFCs
w For communication between systems
w For parallel processing
n Transactional RFCs
w For "safe" communication between systems

© SAP AG 1999
Presentation
Server
Application
Server
Database
Server
'Simple’ Transaction Step
Roll in time
Load time
Processing time (1)
Wait time
Database time (1)
Processing time (2)
Processing time (3)
Database time (2)
Response
time
User starts transaction
Dispatcher receives request
Roll out time
Rollout from work process
GUI displays result
NetworkNetwork
NetworkNetwork

© SAP AG 1999
Presentation
Server
Application
Server
Database
Server
Transaction Step with Synchronous RFC
Processing time (1)
Wait, Roll in & Load time
Processing time (2)
Response
time
External
System
Roll out time
Roll in time
Roll wait time
RFC start
Presentation
Server
Application
Server
Database
Server
NetworkNetwork
NetworkNetwork
RFC + CPIC
time
RFC end
Program rolls out
after RFC is started
CPI/C Communication
= Program not in
work process
n For dialog steps with synchronous RFC, RFC+CPIC time is the runtime of the RFCs plus the time
for setting up the connections. During a synchronous RFC, the ABAP program is rolled out from the
work process. This time can be observed as roll wait time
n For dialog steps with asynchronous RFC, RFC+CPIC time is the runtime for setting up the
connections to the external system. No rollout occurs. The program continues the work after starting
the asynchronous RFC.
n See also SAP Note 8963 in SAPNet.

© SAP AG 1999
Example:
Statistical record
with RFC
processing; See
multiple roll
processes,
RFC+CPIC time
and roll wait time
RFC Monitoring : Statistical Records
n Statistical Records (transaction STAT until 4.5 or STAD as of 4.6):
n RFC+CPIC time can be found under time details in the single records. For dialog steps with
synchronous RFC, RFC+CPIC time is the runtime of the RFCs plus the time for setting up the
connections.
n There is one record per dialog/batch step. For RFC calls an additional record is written at the end of
the dialog/batch step where they occur if the RFC connection is closed. In case of registered external
programs the RFC connection may remain open beyond the end of the dialog/batch step. Then the
RFC record is written after the connection is closed.
n Trouble-shooting:
Ÿ RFC+CPIC time >> Roll wait time (as shown in this slide) indicates a problem during the
communication between the systems. Check whether the reason is due to:
- A slow network connection
- No work process available in the receiver system
Ÿ If RFC+CPIC time ≈ Roll wait time, this indicates that the communication between the systems is
fast. You may need to perform further performance analysis of the RFC function module in the
receiver system.
n To see the RFC subrecords (as shown on the next slide), use the “RFC” button or scroll down.

© SAP AG 1999
RFC Monitoring : Statistical Sub-Records (1)
l The RFC sub-record shows, for example:
n The target destination
n The user, the program that calls the RFC, and the function
module called
n The transferred data, as well as the calling and execution time
n A separate RFC statistical record is created for every dialog step (or batch step) where remote
function calls occur. In this record, all outgoing and all incoming RFC calls are collected (outgoing
calls are client subrecords and incoming are server subrecords).
n The instance profile parameter stat/rfcrec gives the max number of individual RFC sub records
shown. The program name RFC is artificial. You cannot map one single report to this statistic record,
because every RFC call could be located in a different program.
n In the RFC stat record details, you can see the individually called function modules and their report
names. The task type R is also artificial, since RFC calls could be made from any other task type.
n Under Client destination subrecords, you get the summary of all calls per destination (for up to the
stat/rfcrec number of destinations).
n Under Server destination subrecords, you get the summary of all incoming calls per destination (for
up to the stat/rfcrec number of destinations). In the summary, you see the total number of calls for
the destination, not only those which have detail entries in the record. If there are calls for more than
stat/rfcrec destinations, you do not see the number of calls for destinations with no summary entry.

© SAP AG 1999
RFC Monitoring : Statistical Sub-Records (2)
l Response time = sum(calling times)
l Calling time = Rem exec time + wait for gateway time
l RFC+CPIC time = time spent for RFC/CPIC handling (including roll wait time)
l Roll wait time = time spent in roll context waiting for RFCs
l CPU time = sum(CPU usage) (on the server where the record is found)
l Calling time (client) = Rem exec time + (wait for) gateway time + network time
l Calling time (server) = Rem exec time + (wait for) gateway time
l Response time = Time spent in the executing work process + wait time
n Response time is the sum of response times of all collected RFC calls for the related dialog/batch
step. For synchronous RFC, the single RFC response time is the total time from when the call was
started until the result is returned. For asynchronous RFCs, the response time ends as soon as the
receiver confirms reception of the data.
n The CPU and DB times are collected for all locally used CPU and DB times of the RFC calls. The
wait time is the time until a free dialog work process could be allocated to process the calls.
n The remote CPU, DB, and wait times are not known by the sender, so you might see a significant
gap between response time and the sum of the others in the case of synchronous RFCs.
n On the receiver side, an incoming RFC request is put in the dispatcher queue as soon as the RFC call
data is transferred. From there on, the wait time is measured as usual by the dispatcher until the
request is dispatched to a dialog work process.
n The calling time of the client (sender side) is measured in the client gateway and is computed as
receiving time for the RFC request until it returns the result (for synchronous calls). The remote
execution time is measured on the server side (receiver), and transferred back to the client to be
stored in the client subrecord. A delay in the communication between both gateways would be seen
as a time difference here.
n Calling time for the server record is measured at the server side gateway in the same way (that is, the
difference to the remote execution time in the server record is the time spent in the server gateway
and is usually 0 or very small).

© SAP AG 1999
RFC Monitoring: RFC Destinations
Transaction SM59
n RFC destinations are maintained with transaction SM59 or choosing Tools → Administration
→ Administration → Network → RFC destinations. A double-click on a destination takes you to a
detailed screen.
n Button "Test Connection" leads to response times or error message (should be the first topic to check
in case of trouble).
n Sample connection types (use F4 to get complete list):
Ÿ I: Connection to application server with same database
Ÿ 3: Connection to R/3 System
Ÿ T: Start an external program via TCP/IP
n Depending on the connection type, you get different options, for example:
Ÿ R/3 System: Target host and System number
Ÿ External program via TCP/IP: Start or Registration
Ÿ External program via TCP/IP: Program (external program name), host
n Trouble-Shooting: Test response times by using button "Test connection".
n Recommendation for configuration: Use setting "Load distribution" instead of a single target host!

© SAP AG 1999
RFC Monitoring: Performance Trace
n To start the performance trace, enter transaction code ST05.
n The slide shows the SQL and RFC part of a performance trace of a transaction-SM66 dialog step.
(Before creating the trace, choose button "settings", deactivate the option "Display only abbreviated
information”, and activate the option "Display connection and status".)
n In the upper part of the screen, you see the RFC trace record: “pawdf085_CTP_24 p48212 Client
SAPGUI_PROGRESS_INDICATOR”. This provides us with the following information:
Ÿ Sender: pawdf085_CTP_24 (local R/3 instance)
Ÿ Receiver: p48212 (in this example my local PC)
Ÿ Function module: SAPGUI_PROGRESS_INDICATOR (sets the status message "Connection to
<instance>")
n In the lower part of the screen, you see the SQL trace records (for example accesses to table
SWWHRINDEX): “SELECT WHERE MANDT = ‚001‘ AND OBJID ...”

© SAP AG 1999
Contents
l User interfaces and system interfaces
l Monitoring RFC calls
l Controls technology and GUI communication
l Communication between systems and RFC configuration
l Exercise: Monitoring RFC Load
Next Topic in Unit

© SAP AG 1999
R/3 Release 4.6: Enjoy SAP
l In the Enjoy SAP initiative, SAP
demonstrated its commitment to
producing easy-to-learn, easy-to-
use software. The innovativeness
of the 4.6 Release is based on:
n A new design for user interaction
n A new visual design
n New personalization features
l These architectural changes have
implications for performance and
sizing

© SAP AG 1999
Interaction Model: Controls Technology
Tree Control
Text-Edit
Control
List Box
l Controls technology
provides application
programmers with a
means of
incorporating more
complex screen
elements called
controls.
l The new elements are
software components
with their own
independent
functions on the GUI.
l For example,
scrolling, navigating,
or searching no
longer need to
connect to the
application server.
n The new Enjoy R/3 Release elements are not screen elements in the classic SAP sense, but software
components with their own independent functions acting on the GUI. GUI screens can now consist
of one or more controls. Typical controls are
Ÿ APAP list viewer control (ALV control)
Ÿ Tree control (like in SAP Easy Access Menu)
Ÿ Text edit control (texts in the GUI)
Ÿ HTML control (display of HTML documents in the GUI)
n For examples, from the R/3initial screen, choose: Tools >> ABAP Workbench >> Development >>
ABAP Editor >> Environment >> Controls Examples (or use transaction DWDM)
n Literature (http://sapnet.sap.com/performance >> Media Center >> Literature):
Ÿ Performant Programming With Controls
Ÿ Poster: Performant Programming with Controls
Ÿ Using Controls With WAN Logons
n Transactions that were redesigned with the Enjoy R/3 Release are usually indicated by a "N" after the
former transaction code, for example, ME21N, VL01N, ST03N. (But not necessarily: VA01 is also
an "Enjoy transaction”.)

© SAP AG 1999
Interaction Model: Implications for Performance
l Old interaction model
n Each ‘click’ in the GUI (for example a scroll in a
list) requires its own dialog step
l New interaction model
n Functions scrolling, navigating, or searching no
longer need to connect to the application server
l Advantage
n Fewer dialog steps
l Disadvantage
n High initial GUI load (network and CPU)
n What do the new controls imply for the network?
Ÿ The network load per dialog step will increase considerably as more information is pushed to the
SAP GUI in one step. On the other hand, the user can navigate in the screen without connecting to
the application server.
Ÿ Example: When you scroll in a "normal" list, you do a dialog step each time. If you use a new "list
viewer" control, all information in the list are pushed to the GUI in larger portions. Therefore, the
SAP GUI does not connect each time to the application server when scrolling but is able to handle
many requests locally. This is a clear advantage if you scroll up and down the list often. However,
it is a disadvantage if you enter the list once and leave it again immediately.
Ÿ Consequence: The network load per dialog step will increase. Depending on the user behavior, the
number of dialog steps will decrease, thus compensating for part of the increased network load.
However, in total, we expect an increase in network load.
n For details, see SAP Note 164102 and the related white paper under http://sapnet.sap.com/sizing.

© SAP AG 1999
Presentation
Server
Application
Server
Database
Server
Transaction Step with Roundtrip
Processing time (1)
Wait, Roll in & Load time
Processing time (3)
Response
time
Presentation
Server
Application
Server
Database
Server
NetworkNetwork
NetworkNetwork
Database time
Processing time (2)
GUI
time
Time spent for
network transfer
Roundtrip to GUI starts
Time spent for building
up the screen in the GUI
Roll
wait
time
Program rolls out after
RFC to GUI is started
n Roundtrips, Roll wait time, GUI time: During a roundtrip to the SAP GUI, the ABAP program is
usually rolled out of the work process. Therefore, you may observe a high roll wait time due to SAP
GUI communication. This time is measured as GUI time.
n If the dialog step includes no RFC communication with an external system (only RFC
communication to GUI), then the GUI time ≈ roll wait time.
n If the dialog step includes RFC communication with an external system, the GUI time may be less
than the roll wait time, since roll wait time covers roll wait situations due to all RFCs, GUI time only
covers the roll wait situations due to SAP GUI communication.
n See also SAP Note 8963.

© SAP AG 1999
Example (II): STAD - Statistical Record
Frontend data are
shown in transaction
STAD only
(not shown in STAT)
n Monitoring:
Ÿ as of R/3 Release 4.6B, statistics about roundtrips and GUI time are available in transaction
STAD. (In R/3 Release 4.6, you should no longer use transaction STAT.)
Ÿ You can also activate a performance display. To do this, choose System → Utilities
→ Performance display.

© SAP AG 1999
RFC Monitoring: Performance Trace
Function module "OLE_FLUSH_CALL"
indicates a roundtrip to GUI to build up the
tree control
Function module to set GUI process indicator in
status bar (messages such as "Loading data")
Can be deactivated, if GUI connection is slow
RFC trace record
n Activate the Performance Trace (ST05) including SQL trace + Enqueue Trace + RFC trace.
n SAPGUI_PROGRESS_INDICATOR: As of 3.0F, application progress indicators can be switched
off by setting the SPA/GPA value SIN to 0 in the user master record (see SAP Note 51373).
n OLE_FLUSH_CALL indicates a roundtrip to GUI to build up the screen
Ÿ Ideal case:1 call of OLE_FLUSH_CALL per dialog step.
n GUICORE_BLOB_DIAG_PARSER:
Ÿ With one roundtrip, a maximum of 32 kByte of data can be transferred. If more than 32 Kbyte has
to be transferred, function module GUICORE_BLOB_DIAG_PARSER is executed.

© SAP AG 1999
Trouble Shooting : High GUI Time
First case: GUI time versus network transfer ("Terminal Out"message")
n Guidelines:
w on average, 100 ms for 1 KB
w in the worst case, 1 sec for 1 KB
n Possible reasons for a high GUI time:
w Time spent for network transfer- see Network bottleneck
w Time spent for building up the screen in the GUI -
see CPU / memory bottleneck on the desktop computer
n Unfortunately there is way to distinguish between time for network transfer
and time spent in the GUI, so:
w Try to identify network problems with function LAN Check by Ping in
transaction ST06
n What do the new controls imply for the network?
The network load per dialog step will increase considerably as more information is pushed to the
SAP GUI in one step. On the other hand, the user can navigate in the screen without connecting to
the application server. Depending on the user behavior, the number of dialog steps will decrease thus
compensating a part of the increased network load. However, in total we expect an increase in
network load. See SAP Note 161053.
n What is the impact of the new controls imply for the resource consumption of the desktop
computers?
As of 4.6, the SAP GUI comes with a new "New Visual Design". CPU consumption on the desktop
is reduced significantly when you switch from "New Visual Design" to "Classic Design" according
to Note 173028.

© SAP AG 1999
Guidelines (4KB ping)
• No losses
• Response times:
§LAN < 50ms
§WAN < 150ms
§56K Modem< 500ms
Example (III): ST06 - Network Check by Ping
n To perform the LAN Check by ping, run transaction ST06, the choose Detail Analysis Menu → LAN
check by ping.
n To choose the size of the package that is transferred by each ping, choose Edit → Block size.
n For a package size of 4KB, the average response time should be less than 50 ms in a LAN.
n The response times seen above in the screenshot indicate severe network problems.

© SAP AG 1999
Trouble Shooting : High GUI Time (2)
Second case: High network transfer; High number of roundtrips
n Guidelines:
w 2 or less roundtrips for a normal screen;
w 10 roundtrips as upper limit, even for complex screens
w Average network transfer 5 to 8 Kbytes
w Network transfer should always be less than 80 Kbytes, even for
complex screens
n Possible reason for a high number of roundtrips :
w Program or program usage error (send a message to the
developers)
n In the new Enjoy architecture, GUI and network performance must be considered. In particular, you
should look at:
a) Number of roundtrips
The number of roundtrips is determined by the application program. Roundtrips are processed in
an sequential order. If the number is too high, the GUI time will increase considerably. For a
normal screen, the number of roundtrips should be 2 or less. An upper limit, even for complex
screens (long lists or tree structures), should be 10.
b) Network transfer
When you scroll or click to a tab strip in a "classical" R/3 screen, you perform a dialog step with
each scroll. If you use the new controls (tree, textedit, or HTML), a large amount of information is
pushed to the GUI in the first dialog step (if necessary, with multiple roundtrips). Therefore, the
SAP GUI does not connect to the application server when scrolling, but is able to handle many
requests locally. This is a clear advantage if you navigate in the screen many times. However, this
is a disadvantage if you enter the screen only once and leave it immediately.
c) Use of the drop-down list box.
This is a further critical issue for network transfer. The content of the list box is transferred to the
GUI in advance. This may be a performance improvement, because no connection to the
application server is necessary when the user clicks the list box. However, it will be a performance
problem if the list box contains many entries (100 or more).

© SAP AG 1999
Trouble Shooting: New Visual Design
SAP Visual Settings.lnk
Use SAP Visual Settings icon
on your desktop to switch
on/off new design.
There are no functional
changes when changing to
the old design.
n If there is a CPU bottleneck on the frontend, see the following SAP Notes:
Ÿ SAP Note 161053: CPU consumption on the frontend is reduced significantly when you switch
from "New Visual Design" to "Classic Design". The corresponding program is stored in
"SAPpcsapgui". It is particular useful when you use older graphic boards.
Ÿ SAP Note 196238: Deactivate "New Visual Design" for all users
Ÿ SAP Note 203924: Collective performance note for Release 4.6.

© SAP AG 1999
Trouble Shooting: LOW Speed Connection
l For WAN Connection set the flag "LOW Speed Connection"
in SAPLOGON.
n Menus are only transferred on request
n Quantity of the transferred data is reduced for tree and ALV
controls.
n No images are transferred
n The network load is reduced significantly.
l You can find this setting option under:
SAPLOGON → PROPERTIES → ADVANCED
l No functional changes
when changing to low
speed connection
n If there are long response times due to performance problems in the network (in particular when
using SAPGUI in WAN), you should use configuration "LOW Speed Connection” in SAPLOGON.
As a result, menus are only transferred on request, and the quantity of the transferred data is
accordingly reduced. This reduces the network load significantly.
n You can find this setting option under: SSAPLOGON → PROPERTIES → ADVANCED.

© SAP AG 1999
Trouble Shooting: SAP Easy Access Menu
SAP Easy Assess Menu
n Transaction Code
SESSION_MANAGER
n Avoid big pictures
n Avoid large user menus
(not more that 1000 entries)
n As of R/3 Release 4.6, SAP provides the "SAP Easy Access Menu" for navigation to transactions
and report. (Technically, this is transaction SESSION_MANAGER.)
n Instead of having the menu in the header area of the screen, you now see the menu in the left area of
the screen in form of a tree. All users belong to one role (or activity group). The user sees only the
transactions that belong to their own role.
n If you use the SAP Easy Access Menu:
Ÿ The menu should not contain more than 1000 entries. (For comparison: The complete SAP menu
contains 70,000 entries.)
Ÿ The tree is loaded to the user context. A high number of menu entries leads to high memory
consumption on the application server and to long response times for the menu.
Ÿ If you cannot restrict the menu to less than 1000 entries, use the global SAP menu instead.
n For details, see SAP Note 203617.
n To find out the number of nodes in the menu tree, use transaction SE37 (function builder) and
choose Test; enter function module BX_READ_USER_MENU.

© SAP AG 1999
Remote Function Calls (RFC and aRFC)
l Synchronous RFC
n Sender program sends
RFC waits for response
(rolled out) and proceeds
with processing after
RFC returns
l Asynchronous RFC
(aRFC)
n Sender program sends
multiple RFCs in parallel
without waiting for
response.
n See example programs in your training system : "ZSBOX_START_RFC"
n Synchronous RFC:
Ÿ ABAP coding: "CALL FUNCTION … DESTINATION …"
Ÿ Only one RFC can be started in parallel
Ÿ “RFC+CPIC time” should always be greater than “roll wait time”.
n Asynchronous RFC (aRFC):
Ÿ ABAP coding: "CALL FUNCTION … STARTING NEW TASK … DESTINATION …"
Ÿ For asynchronous RFC calls, the sending work process is free as soon as all function input data is
transmitted and this transmission is confirmed by the receiver. For asynchronous RFC, the
RFC+CPIC time only shows the time for setting up the connection to the receiver and starting the
RFCs, not the runtime of the RFCs. The statistical record shows RFC+CPIC time but no roll wait
time.

© SAP AG 1999
Troubleshooting: Incoming RFC Load (Problem)
SAP R/3
SAP GUISAP GUI
SAP GUISAP GUI
SAP GUISAP GUI
SAP GUISAP GUI
SAP R/3
Online
requests
RFC
requests
Online requests
may be blocked if
RFC requests are
not limited
Sender (client) Receiver (server)
n Online requests may be blocked if asynchronous RFC requests are not limited. This may result in
bad response times for online users. Therefore, it is necessary to control the incoming aRFC load on
the receiver side
n On the receiver side for aRFC with an RFC server group specified, performance also depends on the
available resources and the setting of the RFC resource parameters depending on whether the call is
performed synchronously or asynchronously (see SAP Note 74141).

© SAP AG 1999
Troubleshooting: Incoming RFC Load (Monitoring)
l Work process monitor (SM50)
n Running reports SAPLARFC and SAPLERFC (aRFC and tRFC only)
n Accesses to tables ARFC (tRFC only)
n Work processes in status "stopped", reason "CPIC"
l User Overview (SM04)
n Type: "RFC"
n Up to release 4.0: Terminal name "APPC-TM"
l Workload Monitor (ST03N): RFC Profile
l Statistical Records (STAD)
n Records with task type "R"
l TRFC Monitor (SM58)
n (tRFC only)

© SAP AG 1999
l Create a R/3 instance dedicated for RFC requests
n if the number of incoming RFC calls is very high
l Use RFC resource management parameters
n RFC server groups
n Set R/3 parameters that limit the number of work processes
used for RFC processing
n The R/3 instance profile parameters for configuring aRFC
resource management are the same as for tRFC:
rdisp/rfc_... Description Default value =
...use_quotas Activate/deactivate resource determination(0..1) 1 = on
...min_wait_dia_wp Number of dialog wp to be kept free 1
(1..#dialog wp), #dialog wp = rdisp/wp_no_dia
...max_own_used_wp Max. allowed quota of dia WPs used by this user 75 (0..100)
See detailed description for parameters in SAP Note 74141.
Troubleshooting: Incoming RFC Load (Solution)
n If you expect a high incoming RFC/ALE load (as a rule of thumb > 10000 requests per hour), you
should configure an R/3 instance dedicated to RFC processing. Limit the number of work processes
on the instance so that the CPU is not overloaded. If you expect a low volume of RFC load, use the
R/3 instance profile parameters to control the incoming RFC/ALE load.
n See example programs in training system: "ZSBOX_START_ARFC":
Ÿ Starting the aRFCs with "DESTINATION dest" leads to a blocking situation (no resource
management)
Ÿ Starting the aRFCs with "DESTINATION IN GROUP" enables the resource management (no
blocking situation).
n Preconditions for using RFC resource management parameters are:
Ÿ RFC server groups defined and used
Ÿ If used together with ALE: Inbound dispatch mode = scheduled; Inbound processing mode =
parallel
Ÿ Kernel patches as prescribed in SAP Note 74141
n To dynamically set RFC resource management parameters, use SAP program RSARFCD.

© SAP AG 1999
Troubleshooting: Outgoing RFC Load (Monitoring)
l Work Process Monitor (SM50)
n Running reports SAPLARFC and SAPLERFC
(aRFC and tRFC only)
n Accesses to tables ARFC (tRFC only)
n Work processes in status "stopped", reason "CPIC"
l Workload Monitor (ST03N): RFC Profile
l Statistical Records (STAD)
n Records with high Roll wait time
l TRFC Monitor (SM58)
n tRFC only

© SAP AG 1999
Troubleshooting: High RFC Load
n To call the Workload Monitor, use transaction code ST03 and choose Performance Database → ...
→ Goto → Profiles → RFC Profile.
Ÿ Choose "Clients" for monitoring the outgoing load, "Servers" for monitoring the incoming load
Ÿ Under "Function modules", find performance data for specific RFC modules
Ÿ Under "Remote destination", find for example the incoming requests by destination
n To perform troubleshooting, identify the sender program of the RFC load:
Ÿ To identify critical function modules and the sender system, use the RFC profile (ST03) or the
Statistical Records Monitor (STAD/STAT).
Hint: Function modules "ARFC_DEST_CONFIRM", "ARFC_DEST_SHIP",
"ARFC_RUN_NOWAIT" and "RFC_PING" build the framework for tRFC processing. You need
not analyze them in detail.
Ÿ To find the sender program, use Function builder (SE37) and the where-used list.

© SAP AG 1999
Remote Function Calls: tRFCs
l Transactional RFCs (tRFCs) allow safe communication
between systems
l Use transaction SM58 for error analysis
R/3 System 1 R/3 System 2
tRFC
Reports
SAPLARFC
SAPLERFC
Reports
SAPLARFC
SAPLERFC
Tables
ARFCSSTATE
ARFCSDATA
Status tracking
Tables
ARFCRSTATE
ARFCRDATA
Status tracking
n Transactional RFCs (tRFC): ABAP coding: "CALL FUNCTION … DESTINATION … IN
BACKGROUND TASK. Don't get confused by the key words 'IN BACKGROUND TASK’: the
tRFC is started in a dialog work process.
n tRFC are not executed immediately. Instead, they are stored in an internal table and processed
together after the next COMMIT WORK.
n All the calls are stored in the tables ARFCSSTATE and ARFCSDATA. Each LUW is identified by a
unique ID. When a COMMIT WORK occurs, the calls attached to this ID are executed in the
relevant target system. If an LUW runs successfully in the target system, the function module
ARFC_DEST_CONFIRM is called and confirms the successful execution in the target system.
Finally, the entries in ARFCSSTATE and ARFCSDATA are deleted.
n tRFC errors can be displayed in transaction SM58 (which provides a view on tables ARFC*).
n If the target system cannot be reached, for example, because the connection is not active, the report
RSARFCSE with the ID as a parameter is scheduled as a background job and called at regular
intervals. To display the standard values for this, in Transaction SM58, choose Info >> System
setting. If you want a separate setting for each destination, specify this with the tRFC options in
Transaction SM59.
n See example programs in the TCC system “TCD”: "ZSBOX_START_TRFC”.

© SAP AG 1999
l Analyze a workload problem related to the RFC calls
Activities:
l After your trainer starts the workload simulation:
l Use the workload monitors to identify the problem
n To find the user and the program that is blocking the work processes, use the Work Process
Overview (Transaction SM50).
n To find the RFC user, use the User Overview (Transaction SM04).
Ÿ RFC users are indicated by “RFC” in column “Type”
Ÿ For R/3 Releases up to 4.5: Terminal "APPC-TM" indicates that a user is logged on through RFC.
n To identify the following data, use the Workload Monitor (Transaction ST03), selecting This
application server, Last minute load; then choose Goto → Profiles → RFC Profiles → Servers:
Ÿ RFC client. This is the destination that sends the data.
Ÿ Name of the critical RFC module. Tip: Function modules "ARFC_DEST_CONFIRM",
"ARFC_DEST_SHIP", "ARFC_RUN_NOWAIT" and "RFC_PING" build the framework for
tRFC processing.

© SAP AG 1999
Exercise: Work Process Monitor
n In the Work Process Monitor (SM50) you see:
Ÿ Running reports SAPLARFC and SAPLERFC (aRFC and tRFC only)
Ÿ Accesses to tables ARFC (tRFC only)
Ÿ Work processes in status "stopped", reason "CPIC"

© SAP AG 1999
Exercise: User Overview
n To find the RFC user, use the User Overview (Transaction SM04).
Ÿ RFC users are indicated by “RFC” in column “Type”
Ÿ For R/3 Releases up to 4.5: Terminal "APPC-TM" indicates that a user is logged on through RFC.

© SAP AG 1999
Exercise: Workload Monitor (RFC Profile)
n Call the Workload Monitor (Transaction ST03) and choose Performance Database → ... → Goto
→ Profiles → RFC Profile.
Or during the exercise, call the Workload Monitor (Transaction ST03), selecting This Application
Server and Last minute load; then choose Goto → Profiles → RFC Profile.
Ÿ To monitor the incoming load, choose "Clients"; to monitor the outgoing load, choose "Servers"
Ÿ To find performance data for specific RFC modules, choose "Function modules"
Ÿ To find, for example, the incoming requests by destination, choose "Remote destination"
n To perform troubleshooting, identify the sender program of the RFC load:
Ÿ To identify critical function modules and the sender system, use the RFC profile (ST03) or the
Statistical Records Monitor (STAD/STAT).
Hint: Function modules "ARFC_DEST_CONFIRM", "ARFC_DEST_SHIP",
"ARFC_RUN_NOWAIT" and "RFC_PING" build the framework for tRFC processing. You need
not analyze them in detail
Ÿ To find the sender program, use Function builder (SE37) and the where-use-list.

© SAP AG 1999
Exercise: Transactional RFC Monitor
n Transactional RFCs (tRFC): All tRFC calls are stored in the tables ARFCSSTATE and
ARFCSDATA. Each LUW is identified by a unique ID. When a COMMIT WORK occurs, the calls
attached to this ID are executed in the relevant target system. If an LUW runs successfully in the
target system, the function module ARFC_DEST_CONFIRM is called and confirms the successful
execution in the target system. Finally, the entries in ARFCSSTATE and ARFCSDATA are deleted.
n tRFC errors can be displayed in transaction SM58 (which provides a view on tables ARFC*).
n It is necessary to monitor SM58 regularly.

© SAP AG 1999
Conclusion | Appendix
1. Introduction to
Workload Analysis
Monitors
3. R/3 Memory
Management
Verification
5. Expensive SQL
Statements

© SAP AG 1999
l Analyze the workload distribution
in an R/3 System
l Find critical performance bottlenecks
l Tune R/3 Basis and database components
l Find poorly written ABAP programs
that cause performance problems
Conclusion

© SAP AG 1999
Further Documentation
l Knowledge Product CD:System Monitoring
l R/3 Online Documentation
l SAP Notes:
n In application area BC-CCM-MON-TUN
n In application area XX-SER-TCC
l SAPNet in the Internet:
n In the SAP TechNet area
System Monitoring
l Literature:
n German: SAP R/3 Performanceoptimierung, Thomas
Schneider, 1999 Addison-Wesley-Longman
n English: SAP R/3 Performance Optimization, Thomas
Schneider, 1999 Sybex

© SAP AG 1999
Workload Monitor (transaction ST03N) for all task types dialog, and update
Programs with lengthy database time: > 40% (response time - wait time)
Choose Transaction Profile and sort by Response time total
?
Analyze table buffering using Table Call Statistics (transaction ST10)
Detailed analysis with ABAP trace (transaction SE30)
For programs with a lengthy database time, in ST03N, choose Statistics records
? Programs with large CPU time: > 40% (response time - wait time)
? Do the statistics records indicate changes to buffered tables (with Note:
Tables were saved in the table buffer)?
Analyze SQL statements using an SQL trace (transaction ST05)
n This roadmap shows you how to leads you to find problems with table buffering problems:
1) Display the Workload Monitor (transaction ST03N) for task types dialog and update
2) For both respective task types, choose Transaction profile and sort according to response time
3) For the programs or transactions that have a large response time, look at the adjacent columns to
find out whether they have a lengthy CPU time or a lengthy database time.
4) For transactions with database time > 40% (response time - wait time):
Analyze single records by viewing statistical records using transaction STAT.
5) To analyze statistical records with a lengthy database time, double-click the appropriate line.
6) To find out whether a buffer reload occurred in the corresponding dialog step, choose DB and
check for the note Tables were saved in the tablebuffer.
7) If this note occurs for many statistical records, it indicates frequent buffer reloads.
The table buffer should be analyzed using the Table Call Statistics monitor (transaction ST10).

© SAP AG 1999
Overview (1)
Work Process Overview (transaction SM50 / SM66)
Work processes in status “running”?
Action: “Dir. Read”, “Seq. Read”, “Insert”, “Update”, “Delete”, “Commit”
Action: “Load report”?
Action: “Roll In” / “Roll Out”?
Work processes in status “stopped”?
Reason: “PRIV”?
Reason: “CPIC”?
Problems with CPIC connections such as "All work processes blocked in
destination system"?
Detailed analysis of R/3 memory configuration (program buffer too small?)
?
?
?
?
?
?
?
?
n The diagram shows the procedures for analyzing the current workload using the Work Process
Overview (transaction SM50).

© SAP AG 1999
Overview (2)
Work Process Overview (transaction SM50 or transaction SM66)
Work process in status running
Action/reason: “Dir. Read”, “Seq. Read”, “Insert”, “Update”, “Delete” , “Commit”
Database Lock Monitor (transaction DB01)
Wait situations due to database locks (“Exclusive lock waits”)?
Analyse lock holder
Database process monitor (transaction ST04: ORACLE Session)
Detailed analysis: SQL statement
SQL Trace (transaction ST05)
Identify and analyse the SQL statement in detail
?
?
?
n This detection roadmap shows the procedure for using the Work Process Overview.

© SAP AG 1999
Analysis Roadmap: Using the Operating System
Monitor (1)
High CPU utilization (< 35% CPU idle)?
Is there CPU capacity on other servers that is idle?
Operating System Monitor (transaction ST06): Top CPU Processes
R/3 work processes with high CPU utilization?
Work Process Overview (transaction SM50) or Systemwide Work Process
Overview (transaction SM66)
Database process monitor (transaction ST04; for example ORACLE session)
Database processes with high CPU utilization?
External processes with high CPU utilization?
Stop or redistribute
?
?
?
?
?
?
n This roadmap guides you in analyzing your hardware capacity. First, call the Operating System
Monitor (transaction ST06).
Ÿ In an optimal case there should be at least 35% idle CPU.
Ÿ If the idle CPU is indicated as being less than 20% , there is a CPU bottleneck.
n If there is a CPU bottleneck:
2. To find out which processes are using the most CPU, in the Operating System Monitor choose
Detail analysis menu → Top CPU processes. If the processes have high CPU utilization, proceed
as follows:
- For R/3 work processes ("disp+work"): Using the process ID indicated in Top CPU processes,
identify the corresponding program name and user name in the Work Process Overview
(transaction SM50).
- For database processes (for example, ”ORACLE8.0”): Identify corresponding long running
SQL statements in the Database Process Monitor. To access this monitor, call transaction ST04
(Database Overview), and choose Detail analysis menu. Then choose, for example, Oracle
Session.
- For external processes, find out whether the process can be stopped or redistributed.

© SAP AG 1999
Analysis Roadmap: Using the Operating System
Monitor (2)
Memory capacity free on other servers?
File system cache > 10 % of RAM?
Reduce file system cache
Setups/Tune Buffers monitor (transaction ST02): Mode List
Programs / transactions with high memory consumption
High CPU utilization?
...
?
?
?
?
?
n In the Operating System Monitor (transaction ST06), note the amount of memory indicated beside
Physical memory available. Compare this figure with the paging rate. To obtain the paging rate,
double-click Pages in/s. The paging rates for the last 24 hours are displayed in the columns Paged in
[Kb/h] and Paged out [Kb/h]. If 20% of the total amount of physical memory is greater than the
amounts indicated in these columns, you can normally be sure there is no memory bottleneck.
n If there is a memory bottleneck:
2. Check the size of the file system cache – See SAP Note 78498 in the Online Service System
(OSS). If necessary, reduce file system cache to < 10% of the total physical memory.
3. To identify users and their programs with a high memory consumption, call the Mode List for the
extended memory. To do this, in the Setups/Tune Buffers monitor (transaction ST02), choose
Detail analysis menu → SAP memory → Mode List.

© SAP AG 1999
Analysis Roadmap: R/3 Memory Configuration
Check R/3 memory configuration in the Setups/Tune Buffers monitor (transaction ST02)
Many R/3 buffer swaps
If enough physical main memory is available, increase R/3 buffer size
R/3 extended memory is full if Max. used > 80%In memory
ST02: Detailed analysis of SAP memory using the Mode List
Single users with very high extended memory consumption
Identify and analyze respective reports/transactions
If enough physical main memory is available, increase R/3 extended memory
ztta/roll_first > 1024?
ztta/roll_first = 1
Roll buffer is full if for Roll memory, Max. used > 80%In memory
If enough physical main memory is available,
increase roll buffer (rdisp/ROLL_SHM)
?
?
?
?
?

© SAP AG 1999
Analysis Roadmap: Using Table Call Statistics
Call the monitor Table Call Statistics (transaction ST10)
Are there buffered tables with a high number of invalidations?
Are there buffered tables with a large buffer size?
Are there buffered tables with a high number of “Rows affected” in the database?
Unbuffered tables with many “Total ABAP Processor requests”?
Consider the buffering rules – should tables be buffered?
?
?
?
?
n This roadmap helps you to decide which tables should be buffered.
1) Call transaction ST10. Select all tables, since startup, and this server. Then choose Show
statistics. The screen Performance analysis: Table call statistics is displayed, and contains a list of
tables and the related statistics. To sort the list by the figures in a particular column, place the
cursor anywhere in the column and choose Sort.
2) Sort the list by Invalidations.
3) Choose Next view and sort the list by Buffer size [bytes].
4) Sort the list by column Rows affected under DB activity.
5) Sort the list by column Total under ABAP Processor requests.
For the unbuffered tables at the top of the list, consider the buffering rules and decide whether
these tables should be buffered.

© SAP AG 1999
Technical Optimization
of ALE Processing
Technical Background
of ALE
Analysis Tools and
Optimization Methods
Analysis Flow Chart
Section: Technical Optimization of ALE Processing

© SAP AG 1999
1.
2.
Goals
Understand how ALE technically works
Learn how to optimize the performance
of the ALE functionality in order to achieve:
Maximum throughput
Minimum impact on dialog users
Maximum speed (for real-time usage)
n Maximum throughput
the number of logical objects (e.g. Material masters / Sales Orders) transferred from one system to
another system in a given time span should be maximized. E.g. 50,000 material masters need to be
transferred within 2 hours.
n Minimum impact on dialog users
transfer of a huge number of objects in a small time span can occupy most or all of the dialog work
processes on an instance, and thus affect the dialog response times of normal dialog users working
on the same instance. Further problems may result from the high hardware resource consumption on
the server where ALE processing occurs or from object locks during ALE update processing.
n Maximum speed (for real-time usage)
transfer of a single object must not exceed a given time span (e.g. goods issue slip from R/3 to an
external warehouse management system within 10 seconds).

© SAP AG 1999
R/3
R/2
R/3
external
Intent of ALE
n ALE (Application Linking Enabling) is available as of R/3 Release 3.0.
n ALE can be used to link:
Ÿ R/3 Systems that are independent of each other
Ÿ External systems to R/3 or
Ÿ R/3 with R/2 systems.
n ALE is basically an interface service which provides high level function modules for exchanging
data between two or more systems. ALE has its own data storage tables and manages its own data
conversion, low level communications, address determinations and error handling. ALE receives
data from the application programs and deals with it from then on independently.
n Application interfaces are provided for predefined business scenarios.

© SAP AG 1999
Customizing Data
Master Data
Transactional Data
# 00012321/2” screw10g 5c
plant 1
plant 2
Company Code
System A
plant 3
Company Code
System B
plant 1
plant 4
Company Code
System C
Logical System
Logical SystemLogical System
Material Number
Material Number
5 blue shirts $150.00
5 ties 100.00
250.00
10% rebate -25.00
Purchase OrdersPurchase Orders
Distributing Data
n What kind of data can be distributed by ALE
Ÿ Master Data (e.g. Material / Customer / Vendor Masters)
Ÿ Transactional Data (document type data like Contracts / Call Off's)
Ÿ Control Data (Customising data which needs to be synchronised)
n The distribution of ALE customizing / control data and master data of the various applications is
normally not critical in terms of performance. Therefore the emphasis is put on transactional data.

© SAP AG 1999
R/3R/3
Distributed Purchasing Contracts
External storage
management
system
Central
Purchasing
(Holland)
De-central
Purchasing
(Italy)
R/3
De-central
Purchasing
(UK)
System 1System 1
System 2System 2
Business Scenario
n Business Scenario
Ÿ Definition of business processes across independent R/3 systems. E.g. a central R/3 system in
Holland is processing central purchasing contracts for a company's European subsidiaries. The
central purchasing contracts would then be transferred via ALE to the de-central systems.
Ÿ Upon arrival they would be used ‘independently' by purchasing in the U.K. to do their call off's.
The call off's would then be reported back to the central system via ALE using statistic records.
Ÿ It is important to understand that at any point in time the central or de-central systems can work
independently or even be turned off without affecting the other systems.
Ÿ It is therefore a logical link across independent systems rather than a physically distributed data
base approach.
The predefined business scenarios already include the definitions of the necessary ALE object
types to be transferred between the participating systems.

© SAP AG 1999
R/3
Local De-central SystemLocal De-central System
(UK)(UK)
R/3
- Material Master Maintenance- Material Master Maintenance
- Central Purchasing Contracts- Central Purchasing Contracts
R/3
Central SystemCentral System
(Holland)(Holland)
Local De-central SystemLocal De-central System
(Italy)(Italy)
Distributionof
Distributionof
POContracts
POContracts
Warehouse ManagementWarehouse Management
SystemSystem
GoodsIssues(Receipts)
Goods Issues (Receipts)
CallOffStatistics
CallOffStatistics
byPO
byPO Distribution ofDistribution of
PO ContractsPO ContractsCallCall
OffOff
PO
Details
PO
Details
(Note: PO = Purchase Order)(Note: PO = Purchase Order)
Typical Scenario
n The above sample chart describes the information flow from the Materials Management area within
an existing ALE business scenario.
n More detailed information on distributed business scenarios can be found in the R/3 Library.
R/3 Main Menu → Help → R/3 Library → Cross Application Components → Business
Framework Architecture ALE → ALE Business Process Library
n In order to distribute contracts (transactional data), it may be necessary to distribute additional
related data first. If the central contract contains new suppliers and materials, those master data
should be distributed to the de-central system beforehand.

© SAP AG 1999
Sender
Application
IDOC
DB
The application
creates an
IDOC
IDOCIDOC
DBDB
Receiver
ApplicationApplication
Network
How ALE Works - Step 1
n In ALE processing we always distinguish 3 main steps: Step 1 is the sender side processing, Step 2 is
the transfer of data from the sender to a receiver, Step 3 is the receiver side processing.
n IDOC stands for Intermediate DOCument. This document contains exactly one business object. (e.g.
1 material master or 1 sales order including all sales items etc.) More detailed information is given
below.
n For creating an IDOC from application data ALE calls an interface function module from the
respective application area (like MM / SD etc.). This must be provided by the application.
n The application provides master or transactional data in a specific format. ALE function modules are
used to store the data in the IDOC data base at the sender end.
n The IDOC data base is an important feature since it enables both off-line and asynchronous interface
processing to other systems, regardless whether they are available at that specific point in time. It is a
permanent storage for data to be transferred at any time. It allows error handling and repetitive
sending of business objects.
n IDOC data is stored in a machine independent character based ASCII format.
n The application first creates in memory a so called master IDOC which contains the maximum data
needed for the logical object to be transferred. From this master IDOC a communication IDOC is
created for each receiver defined in the ALE customizing and stored in the physical IDOC DB. There
may be filter options specifically defined for each receiver (e.g. one receiver might only get
purchasing relevant data from material masters while another one gets production relevant data.

© SAP AG 1999
SenderSender
IDOCIDOC
DBDB
The IDOC is
sent via the
network
IDOC IDOCIDOC
DBDB
ReceiverReceiver
NetworkNetwork
n In the second step, ALE determines which receiver to contact to by extracting the relevant
information from the communication IDOC stored in the IDOC DB.
n Each sender IDOC is sent to exactly one receiver. If there are multiple receivers for one logical
object there are multiple IDOCs created on the sender IDOC DB.
n Subsequently the receiver specific communication IDOC is sent over the network to the respective
receiver using standard TCP/IP and CPI-C communication methods.

© SAP AG 1999
IDOC
Receiver
IDOC
DB
Application data
is then created
from the IDOCs Application
SenderSender
IDOCIDOC
DBDB
NetworkNetwork
n The receiver of ALE messages has its own IDOC data base. A transferred IDOC is always stored
here before any further processing can happen.
n After the IDOC is stored on the receiver side an application module can be called to begin update
processing.
n The logical transfer is finished after the application data is successfully posted on the receiver side.
n The storage of the IDOC at the receiving end signals successful transfer. This means that from the
senders point of view its work is finished. However, logical or other errors might occur at the
receiving end during posting of the IDOC by the application modules. This is a separate, independent
issue which will be discussed in the error handling and customizing sections of this course.
It is possible to explicitly transfer information about the receiver side IDOC processing status back
using the ALE auditing message type.
n Problems which could occur at the receiver end are, for example, an ISO code or a purchasing group
which is not known there.

© SAP AG 1999
Application
IDOC
DB
The application createsThe application creates
IDOCIDOC’s’s directlydirectly
2.
The applicationThe application
creates change pointerscreates change pointers
for deferred processingfor deferred processing
1.
The applicationThe application
creates a message entrycreates a message entry
for deferred processingfor deferred processing
3.
Sender Details - Three Ways to an IDOC
n 1. Is only used for master data handling like material, customer masters etc.
n 2., 3. Are used for transaction data such as purchasing contracts and goods movements. (The reasons
for this are historical.)
n Which method will be used´depends on the message type to be sent. The function module which is to
be called for the master IDOC creation for a given message type is stored in the table TBDME. For
material master data, e.g., the message type is MATMAS and the function is
MASTERIDOC_CREATE_SMD_MATMAS.
n The ALE layer uses the destinations and their filters defined in the customizing setup for creating the
communication IDOCs from the master IDOC. It also stores the created communication IDOCs in
the IDOC DB.

© SAP AG 1999
Application
IDOCIDOC
DBDB
BDCPBDCP
RBDMIDOCRBDMIDOC
1.
Change pointersChange pointers
for Master Datafor Master Data
written directlywritten directly
to tableto table
App DataApp Data
Sender Details - First Way to an IDOC
n Only Master data uses this technique.
The application program does not create the IDOC directly but defers this task to a later time. The
IDOC's creation could be resource intensive thus affecting the performance of the original
transaction. Moreover, multiple subsequent changes will result in only one IDOC created.
n The change pointer table BDCP contains the key of the changed application data and the type of
change operation (insert, update, delete).
n If change pointers are activated RBDMIDOC reads table BDCP and creates the IDOCs using the raw
application data previously written by the application. It can run either via batch scheduler or
manually. (TCODE= BD21).
n To activate the creation of change pointers you have to setup the ALE customizing as follows :
SALE → Distribution (ALE) → Master data distribution → Activate change pointer (first general
flag has to be set. And then go to) → Activate change pointer for message types → e.g. material
master. (Message type = MATMAS and active = yes.) This will cause the basis interface to write
change pointers, but not IDOCS at this point in time.
n The programs involved for change pointer handling are:
RBDCPCLR Clear Change Pointers
RBDMIDOC Generate Intermediate Document Type From Change Pointers
RBDTBD22 Mapping between change document and IDOC
Tables BDCP Change pointers
BDCPS Change pointer Status.
View BDCPV View on table BDCP and BDCPS
n There is one other method to transfer master data via ALE called direct send (BALE->Master data-
><master data type>->Send). The master data to be transferred is given via a selection screen. This
method is especially useful for initial data transfer and it will directly create one IDOC for each
selected master data with change pointer handling being involved. This method also allows parallel
IDOC creation while the change pointer evaluation via RBDMIDOC always uses one work process
only.

© SAP AG 1999
Application
IDOC
DB
ApplAppl. data. data
is written directlyis written directly
to IDOCto IDOC
2.
Sender Details - Second Way to an IDOC
n This is the current mainstream technique for transactional data.
n This method is also used for direct sending of master data. Usually only newly created objects or
changes to existing objects are transferred via ALE. The direct sending of master data is an
exception. You can select a set of master data objects and transform them into IDOCs which will
then be sent.
n The application modules therefore provide special function modules which are automatically called
during the application update processing.
n Although this results in minimal performance overhead because no further step is involved but it
slows down the update processing on the sender side. Moreover, object enqueue locks will therefore
be held for a longer time span.

© SAP AG 1999
Application
IDOC
DB
NAST
Control DataControl Data
written directlywritten directly
to table NASTto table NAST
NAST
RSNAST00RSNAST00
3.
App DataApp Data
ImmediateImmediate
??
NoNo
YesYes
Sender Details - Third Way to an IDOC
n RSNAST00 may either be scheduled as a batch job or run manually.
n If immediate IDOC processing is turned on, the IDOC is created directly using routines of
RSNAST00. The processing mode for NAST records can be customized in the message condition
record for this record type.
n Only transactional data for special message types are handled in this way. (e.g. distributed
purchasing contracts.)
n In the case of distributed purchasing contracts, an entry will be found in table NAST. See
Transaction SE16 with key : KAPPL = EV, KSCHL= VNEU, NACHA = A .
n Note: in the case of scheduled processing always check whether program RSNAST00 is scheduled,
if you believe that no IDOCs are being created.
n The immediate NAST processing avoids the need of RSNAST00 scheduling for IDOC creation.
Non-immediate processing allows the IDOC creation to be separate from the update part which may
be useful if the update part is critical. Also, enqueue locks on the corresponding application objects
are held for a smaller time span.

© SAP AG 1999
l TRFC - Transactional Remote Function Call
l FTP - File transport protocol
Communication Methods
n TRFC - Transactional Remote Function Calls are part of the SAP functionality. They are called
transactional because a number of function modules are allowed to be bundled into a single LUW
(Logical Unit of Work). Thus transactional integrity can be ensured when executing on the de-central
system. ALE, in general, is always using TRFC for communication between sender and receiver.
n The TRFC interface is also available to connect to external systems. SAP therefore provides a TRFC
library with the necessary functions.
n FTP - File Transport Protocol is of sequential nature and done on operating system level. This type
of processing is normally used by EDI systems.

© SAP AG 1999
Sender
IDOC
DB
TRFC QueueTRFC Queue
Receiver
IDOC
DB
IDOC
NetworkNetwork
TRFC Details 1
n The TRFC queue consists of the tables ARFCSSTATE and ARFCSDATA on the sender side and
ARFCRSTATE and ARFCRDATA on the receiver side. The STATE tables contain status
information of the TRFC call on the sender resp. receiver sides while the DATA tables contain the
list of function modules to be called together with their parameter values.
n After an IDOC is put onto the sender side TRFC queue its status is set to ‘data passed to port OK' in
the IDOC database. The report RBDMOIND may be used to synchronize the sender IDOC status
with the sender TRFC queue. It changes the status ‘data passed to port OK' to ‘DATA SENT' if the
IDOC is not found in the TRFC queue or to ‘COMMUNICATION ERROR' if it is marked with an
error status in the TRFC queue.
n Transaction SM58 can be used to monitor the TRFC queue.

© SAP AG 1999
Sender
IDOC
DB
TapeTape
Receiver
IDOC
DB
INBOUND_IDOC_PROCESSINBOUND_IDOC_PROCESS
1. CopyCopy
TRFC callTRFC call
5.
3. StoreStore
AcknowledgeAcknowledge
2.
6. DeleteDelete
4. DeleteDelete
TRFC Details 2
n Prerequisites : From Release 3.0 onwards, data can be transferred between two R/3 Systems reliably
and safely via transactional RFC (TRFC). Both, sender and receiver must not operate under lower
release levels.
n Format : Transactional RFCs use the suffix IN BACKGROUND TASK in the ABAP statement
CALL FUNCTION.
n Step 1: The RFC function to be called (INBOUND_IDOC_PROCESS) together with its parameter
values (the IDOC) is copied into the TRFC queue (ARFC tables). This is triggered by the COMMIT
statement in the sender LUW.
n Step 2: The data is transferred by the internal function ARFC_SHIP which is executed in another
dialog work process on the sender instance. On the receiver side the data are at first stored in the
TRFC queue.
n Step 3: The function INBOUND_IDOC_PROCESS is called which stores the transferred IDOC(s)
into the receiver IDOC DB (with a receiver IDOC number). This function is executed in a dialog
work process on the receiver side.
n Step 4: The COMMIT statement in the receiver LUW triggers the deletion of the corresponding
TRFC queue entries.
n Step 5: The receiver issues an acknowledge message via the internal function
ARFC_DEST_CONFIRM.
n Step 6: After the acknowledgment of the transfer is returned the sender deletes the TRFC entry in the
sender queue. The LUW for the transfer is then finished on the sender side, too, and the dialog work
process used for the transfer is free.

© SAP AG 1999
Sender
IDOC
DB
Application
Set statusSet status
errorerror
ScheduleSchedule
batch jobbatch job
for retryfor retry
CommunicationCommunication
errorerror
TRFC CallTRFC Call
IDOC
DB
YY
NN
Done,Done,
IDOC will remainIDOC will remain
unsentunsent
SchedSched..
jobjob
TRFC Communication Error Handling
ReceiRecei
n From an IDOC layer point of view at this stage everything looks to ALE as if it was processed
alright (the IDOC status is set to ”Data passed to port OK”). Therefore it is necessary to schedule a
program which runs against the IDOC tables and the TRFC queues in order to change the status of
the IDOCs. The ABAP program doing this conversion is RBDMOIND. The menu path is:Tools-
>ALE-> ALE Administration->Services->Communication->Transactional RFC ->Convert IDOC
status (TCODE=BD75). After the conversion the status of already transferred IDOCs has been
changed from ”Data passed to port OK” to ”Dispatch OK”.
n With transaction SM58 you can view the TRFC queue. Entries you find here have either not yet been
sent or got an error message while trying to be sent. If batch jobs were scheduled for failed TRFC
calls those jobs can also be viewed here (select an entry and then call ”Information->Displ. Backgrnd
jobs” from the menu).
n The names for the automatically scheduled batch jobs are built in the form ‘ARFC:<transaction ID>'.
You can configure the behavior of the automatic batch job scheduling via the RFC destination in
SM59 (select a destination, then call ”Destination->TRFC options” from the menu).
You can suppress the batch job creation altogether, set the max. number of attempts and the time
between 2 attempts. Defaults are: create batch jobs, up to 30 retries, 15 minutes delay between two
retries.
n If you suppress the batch job creation you should regularly schedule the program RSARFCEX which
retries the execution of outstanding TRFC. This report executes all outstanding TRFCs
synchronously one after the other while the batch job always executes only the TRFC that failed.

© SAP AG 1999
Sender ReceiRecei
IDOCIDOC
DBDB
RSEOUT00RSEOUT00
SequentialSequential
FileFile
IDOC
DB
NetworkNetwork
FileFile
Communication Details - Sender FTP
n A common problem occurs during the parallel sending of many IDOCs from R/3 to an external
system which turns out to be too slow and cannot run multiple times concurrently. Parallel calls to
the same external program would occur from multiple dialog work processes at the same time. The
timeout for the communication with a registered external program is set to 60 seconds by default
(R/3 profile parameter gw/req_timeout) so that communication errors due to timeouts would result.
Many batch jobs would be scheduled in a short time frame and be executed 15 minutes later leading
again for most of them to timeouts and so on. For these special bottlenecks there is the possibility to
turn off the asynchronous TRFC execution for a given RFC destination via a program change
according to note 103487 and to execute them via report RSARFCEX synchronously instead.
n In order to send information sequentially to another system a port of type `file‘ has to be defined. By
doing this a file is created on the operating system level of the server where the processing occurs.
n Be sure to maintain the logical destination using SM59 as well.
n The customizing path is : SALE > Modelling and Implementing Business Processes >
Partner Profiles and Time of Processing > Maintain partner profiles Manually
Then define a port on a file (TCODE=WE20)

© SAP AG 1999
Receiver
RSEINB00RSEINB00
FileFile
IDOC
DB
SenderSender
IDOCIDOC
DBDB
NetworkNetwork
FileFile
Communication Details - Receiver FTP
n The sequential file created on the sender side now has to be transported by a file transfer program.
Usually FTP is used.
n The above method is normally used by EDI. The receiver would be an EDI subsystem. In order to
use this outbound file for EDI the inbound one has to convert the file into an inbound file. This can
be done by using transaction WE12.

© SAP AG 1999
Sender
IDOC
DB
Receiver
External systemR/3 system
ExternalExternal
programprogram
RegisteredRegistered
SAP GatewaySAP Gateway
processprocess
NoNo
YesYes
Send DataSend Data
Start ProgramStart Program
External programExternal program
R/3 Communications to Ext. Programs
n Registration of the external program with the R/3 Gateway results in improved performance.
Transferring data to a non-registered program requires the program to be started for each transfer.
n In the non-registered case the program start can be performed via a gateway only. The option ‘Front-
end workstation' in the RFC destination in transaction SM59 will not work for TRFCs because the
TRFC is executed in a work processes with no SAP-GUI associated. If the program to be started
resides on a different host than the gateway a remote shell call resp. a remote exec call will be made.
This works for Unix destinations (remote shell daemon) but on NT there is no remote shell service
by default. It is possible to use the RSH service from the NT Resource Kit with security restrictions
(running as System account). You can also install a standalone gateway on the NT host.
n To register a program use transaction SM59 → TCP/IP connections → click on a destination →
press button Registration. Programs can also be registered during gateway server startup using
parameter saprfc.ini. See also OSS note 63930.
n Multiple Registration of Programs
The same external program can be registered with a R/3 Gateway under the same ID more than once.
This allows parallel processing of IDOCS between the sender and the receiver.
This implies that the called external program is capable of multitasking with regard to record
locking. This also results in loss of serialization of transferred IDOCs. From a throughput
perspective this only makes sense if the receiving system has more than one processor available.
n R/3 <-> R/3 connections cannot be registered meaning that a new logon is made for each TRFC. Up
to release 3.1G the user logon could take several seconds (depending on the size of the authorization
profiles). From release 3.1G onwards this logon effect can be neglected (see OSS note 63415). For
releases <= 31G you should minimize the authorization profile for the user which is used for the
TRFC and specified in the SM59 destination. If you do not set immediate processing at the receiver
side this user only needs the authorization for the object B_ALE_RECV. For immediate processing
the necessary permissions for the update processing of the related application objects have to be
given.

© SAP AG 1999
ExternalExternal
programprogram
Sender
Receiver
External system R/3 system
SAP GatewaySAP Gateway
processprocess
LogonLogon
to R/3to R/3
R/3 Communications
n In the reverse direction i.e. from an external program to R/3 there is no registration concept. The
external program performs a log on, then transfers the data. If the data transfers are rather common it
makes sense to start the external program once, log on once and then maintain the connection and
transfer data whenever a new packet has to be transferred. The SAP gateway will automatically ping
to the external program from time to time and if it is still reachable the connection will be kept open.
n The network traffic can also be reduced if the external program collects IDOCs on its side sends
packets.

© SAP AG 1999
Application
IDOC
DB
1. 2.
Call TransactionCall Transaction
using...using...
update modulesupdate modules
App DataApp Data
Receiver Details - Unwrapping an IDOC
n On the receiver side there are two possibilities of how to transfer the IDOC data into the application:
1. The inbound processing may directly call the update modules of the corresponding application.
This method is fast but there are fewer consistency checks made than with the second method.
With this method a so-called mass update is possible for some message types, i.e. the update
module is able to handle multiple IDOCs in one call speeding up the inbound processing if the
inbound packaging is used properly. Whether a mass update is possible for a specific message
type is stored in the INPUTTYP of the inbound function that is used for the given message type.
To get this information you first need to find the name of the inbound function used for a message
type via transaction SALE then Extensions->Inbound->Allocate function module to logical
message type and check for the ‘FM name' for the given message type. Then you check for the
‘Input t.' field for this function module via SALE, Extensions->Inbound->Define settings for input
modules.
The input types have the following meaning:
0: the function module supports mass processing
1,2: the function module does not support mass processing
If the function module does not allow mass processing but IDOC packets are built on the receiver
side the IDOCs within a packet will be processed sequentially within one work process.
2. The inbound processing may be done by creating batch input data and calling ‘call transaction
using…’ for the transaction to create the application data. This method is slower but has the
advantage that all checks during input are performed.
n The updates are performed within the work process which executes the inbound processing (by the
ABAP keyword ‘SET UPDATE TASK LOCAL'), i.e. no update work process is used for it. For R/3
ABAP release <=3.0F you need to apply note 63710 to achieve this behavior.

© SAP AG 1999
Single IDOCs Packets
Parallel
Scheduled
Parallel
Single IDOCs
Immediate
ProcessingProcessing
ModeMode
DispatchDispatch
ControlControl
UnitUnit
TransferTransfer
TypeType
SenderSender
IDOC Processing Options
n IDOC Dispatch Control
Ÿ IDOCS are collected and sent later on:
In this case the IDOCs are only written to the IDOC layer and are sent later by scheduling report
RSEOUT00. No TRFCs are automatically generated right after an IDOCs is created.
Advantage: Packets of a number of IDOCs can be created for performance improvement (see also
Unit Transfer Type).
The separation of creation and sending of IDOCs also allows to distribute the work load over time.
Ÿ IDOCS are sent immediately to the receiving system(s):
No packets can be created. Throughput losses are the consequence. However, it might be
necessary from a business process point of view to have the IDOC sent immediately.
n Processing Mode
Independent of immediate or scheduled processing the single IDOCs or IDOC packets will result in
asynchronously processed TRFCs. This means that many IDOCs/IDOC packets may be concurrently
in process. It is a completely asynchronous process from an ALE point of view and the only way to
reduce the degree of parallelism is to use TRFC resource management as described earlier. A source
code modification is available if there is a need to avoid parallel processing (see OSS note 0103487).
n Unit Transfer Type
You have the possibility to build packets and send a whole packet in one TRFC only if IDOCs are
collected (see dispatch control mode). The advantage of sending packets is that a logon in the
receiving system has to be carried out only once for all IDOCs in the packet and that the programs
processing the IDOCS have to be loaded into memory only once. Packets always consist of IDOCs
of the same type. The report RSEOUT00 for sending the IDOCs will group them by message type
and build packets of the configured size. The remaining IDOCs will be sent in a smaller packet, i.e.
RSEOUT00 does not leave any IDOC unsent because of the packaging.

© SAP AG 1999
Sender
IDOC
DB
Send IDOC packetsSend IDOC packets
UnitUnit
transfertransfer
typetype
DispatchDispatch
modemode
Send single IDOCsSend single IDOCs
NetworkNetwork
RSEOUT00RSEOUT00
ImmediateImmediate
ScheduledScheduled
TRFCTRFC
Sender Details
n The Dispatch Mode is controlled by the ALE customizing in the partner profile and can be specified
for each message type and receiver combination.
n The program RSEOUT00 works sequentially, i.e. an IDOC resp. IDOC packet is handled after the
last one is processed (no ARFC calls are used). The transfer itself is done via TRFC calls and this
means that a new dialog process is used for processing the TRFC. The program RSEOUT00 begins
processing the next IDOC resp. IDOC packet immediately after the TRFC is taken over by another
dialog work process. Therefore if the TRFC transfer is slower than prepaation of the next IDOC resp.
IDOC packet the result are parallel TRFC executions on the sender side. This may be limited by the
RFC resource parameters explained later.
n The duration of a TRFC depends on the amount of data transferred which itself depends on the size
and number of IDOCs in a packet. Usually the throughput increases when the packet size is
increased. Very large packets though will increase the memory usage needed for the corresponding
modes possibly causing problems for very large sizes. A packet size of 30 is a good start. You should
not go beyond 1000 IDOCs per packet.

© SAP AG 1999
ModeMode
DispatchDispatch
ControlControl
UnitUnit
TypeType
ReceiverReceiver
Single
IDOCs
Single
IDOCs
determined
by Sender
IDOC
Packets
IDOC
Packets
Scheduled Immediate
Parallel ParallelSequential
IDOC Processing Options
n IDOC Dispatch Control
Ÿ IDOCs are collected and processed later on:
In this case incoming IDOCs are only written to the IDOC layer and are processed later by
scheduling report RBDAPP01. No ARFCs for inbound processing are automatically generated
right after an IDOC or IDOC packet is received.
Advantage: The separation of receiving and processing of IDOCs allows for distribution of the
work load over time. Also, less dialog work processes will be in use for inbound processing while
new IDOCs are still transferred which may otherwise lead to a blocking of the sender when all free
dialog work process resources are in use. You also have the possibility to specify a packet size for
inbound processing different from the sender side packet size. The packets may then be processed
in parallel and it is possible to specify an RFC server group which allows dialog work processes of
multiple or different R/3 instances to work on the inbound processing in parallel. Note that the
RFC server group option exists only as of R/3 ABAP release 3.1G.
Ÿ IDOCs are processed immediately after receiving:
In this case the INBOUND_IDOC_PROCESS function triggers the inbound processing right after
the IDOC resp. IDOC packet is stored in the IDOC database and the TRFC is committed. It uses
an ARFC call to hand over the IDOC resp. IDOC packet to another work process for performing
the inbound processing.
n Processing Mode In case of scheduled inbound processing the report RBDAPP01 offers the choice
of sequential or parallel processing. In sequential processing no ARFC calls but synchronous RFC
calls will be used by RBDAPP01 i.e. all IDOCs resp. IDOC packets are processed sequentially. No
other dialog work process will be used.
The parallel processing mode will use an ARFC call for each IDOC resp. IDOC packet which is
processed asynchronously in a new dialog work process. This may increase the throughput but also
use up all dialog work processes (if not controlled through RFC resource parameter settings as
explained later).
In case of immediate inbound processing always an ARFC call is made for the incoming IDOC resp.

IDOC packet which will be processed asynchronously in a separate dialog work process. This means
that many incoming packets may be in process concurrently (parallel).
n Unit Processing Type In case of scheduled processing (see dispatch control) you have the choice of
processing single IDOCs or building packets of IDOCs. Packets are always handed over as whole
packets to processing modules that allow mass processing. For other modules they will be split into
single IDOCs but still all IDOCs within a packet are processed sequentially (see processing mode).
Single IDOCs are just a special case where the packet size is one.
The packets build by RBDAPP01 always contain only IDOCs of the same type and all IDOCs to be
processed will be processed (i.e. the last packet may be smaller than the defined packet size).
In case of immediate processing the incoming objects will be processed as they arrive, i.e. the packet
size is determined by the sender. The previous comments on mass processing are also valid in this
case.

© SAP AG 1999
Receiver
IDOC
DB
ScheduledScheduled
UnitUnit
TypeType
modemode
DispatchDispatch
ControlControl
ImmediateImmediate
UpdateUpdate
UpdateUpdate
UpdateUpdate
ParallelParallel
updatesupdates
RBDAPP01RBDAPP01
NetNet
Single IDOCsSingle IDOCs
IDOCIDOC
packetpacket
UpdateUpdate
ARFCsARFCs
(RFC server(RFC server
group)group) ......
ARFCARFC
Update Details
n The incoming TRFC call is always processed in a dialog work process and writes all IDOCs of the
received packet separately into the IDOC database. It depends on the dispatch control customized for
the incoming message type what happens next:
n Message type customized as ‘Processing immediate'.
The ALE inbound function module INBOUND_IDOC_PROCESS, which is processing the IDOCs
in the receiving system, always starts an asynchronous RFC (ARFC) on the same R/3 instance that
processes the IDOC. The asynchronous RFC requires a free dialog process resp. free RFC resources
in accordance with the RFC resource parameter settings (explained later). If no RFC resources are
free the ARFC call will be processed synchronously in the calling dialog process. All IDOCs in the
incoming IDOC packet will be processed in the dialog work process executing the ARFC call
sequentially (i.e. for each incoming packet only one dialog work process for ARFC is needed in
addition to the one processing the TRFC). The TRFC will be finished as soon as the IDOCs are
written to the IDOC DB. Therefore the sender is not blocked by the inbound processing on the
receiver side even in the immediate processing mode.
n Message type customized as ‘Processing in Background' ( = scheduled).
The incoming IDOCs can be manually processed by calling program RBDAPP01. The usual way is
to schedule the report RBDAPP01 in background.
n RBDAPP01 called with ‘Packet size' set
In the report RBDAPP01 you can specify a packet size for each message type. Each built packet will
be processed in one logical step. IDOCs within one packet are handed over as a whole packet to the
inbound processing module if it is able to perform mass processing - otherwise the module is called
in a loop for each IDOC although this still happens in one logical step (see also processing mode). If
this option is not used each logical step handles a single IDOC which is equivalent to packet size = 1.
n RBDAPP01 called with option ‘Parallel processing' set.
The parallel processing option causes each logical step (see above) to be processed in a separate
dialog work process by issuing an ARFC call. Otherwise the logical steps will be processed
sequentially one after the other within the calling work process.
When parallel processing is used you have the option to specify an RFC server group for load
balancing (precondition is R/3 release >=3.1G). The technical background of RFC server groups will
be explained later.

© SAP AG 1999
Remote Function Processing
RFC - Remote Function Call - Call function in remote
system and wait for response
ARFC - Asynchronous RFC - Do not wait for a response
and return immediately
TRFC - Transactional RFC - with repeat on
communication error functionality (Optional)
1
Basic Functions used by ALE 1
n RFC's (Remote Function Calls) are of synchronous nature and only used by ALE for customizing
integrity checks. The advantage is that the calling program knows the result of the remotely called
function. The sender waits for confirmation of the processing result from the receiver.
n ARFC's (Asynchronous Remote Function Calls) (ABAP statement: call function .... starting new
task) are used by the sender for parallel direct sending of master data and by the receiving system for
parallel inbound processing. The sender does not wait for results from the receiver. For the
communication between sender and receiver only TRFC calls are used (see below).
n With TRFC (Transactional Remote Function Calls) the sender sends a group of RFC's to the receiver
as a Logical Unit of Work (LUW). This group of function calls is handled like a database
transaction. If merely one function call in the LUW fails, the whole group of RFCs is rolled back.
For ALE TRFC is used to transfer the IDOCs (resp. IDOC packets) and only one function
(INBOUND_IDOC_PROCESS) is called on the receiver side. The execution of the functions is
triggered by the commit. The sending part is performed in a second dialog work process
concurrently. On the receiver side a free dialog work process is needed to execute the remotely
called functions.
n The load balancing mechanism use by ARFC and TRFC as well as its configuration are described in
OSS notes 74141 and 99284.

© SAP AG 1999
PROGRAM RS01.
...
CALL FUNCTION '...'
DESTINATION IN GROUP 'A’
STARTING NEW TASK ‘ABC’
R/3-System
Instance 1 Instance 2 Instance 3 Instance 4
Group A Group B
ARFC: usage of RFC groups
n A more detailed explanation of the statement syntax can be found in the ABAP online help of the
‘call function ... destination in group … starting new task' statement.
n As of release 3.0F resources of a server are determined and made available to the caller of the
parallel RFC (language element ... STARTING NEW TASK TASKNAME DESTINATION IN
GROUP <group>). Note that an overloading of instances may be achieved by using R/3 instance
profile parameters as mentioned in OSS note 74141. Unfortunately ALE uses this new language
element only since 3.1G.
n As a rough load balancing method in releases <3.1G you may use the logon load balancing which
can be switched on in SM59 for each RFC destination. However, this method is only a bad
replacement for RFC server groups as the load data is collected by the message server only every 5
minutes (rdisp/autoabaptime) by default. Usually a high number of ARFCs arise in a short time
frame and therefore will be sent to the same instance (see also note 103523).
n The RFC groups ( instances ) can be defined with transaction SM59, menu RFC->RFC groups or via
transaction RZ12. All instances which you assign to the same group will form one RFC server group.
n In case of ARFC calls overload on the receiver side can only be safely avoided by using an RFC
server group. If no RFC server group is used, only work processes on the given destination instance
will be used and all work processes on that instance may potentially be used concurrently for ARFC
processing. If all dialog work processes are used by ARFCs there is a risk of a deadlock: if each
work process needs to get a number from the number range mechanism which leads to a number
range buffer load that needs another free dialog work process they will wait forever.
Therefore it is always recommended to use RFC server groups.
n You should also define an RFC group for a central system with only one R/3 instance. Then you can
use the resource management explained above.

© SAP AG 1999
CALL FUNCTION ...
DESTINATION IN GROUP ...
STARTING NEW TASK 'ABC'
Group A
WP1
WP3
WP2
...
Message-Server
Instance 1 ?
Dispatcher-Queue
WP1
WP3
WP2
...
Instance 2
Dispatcher-Queue
1) Dispatcher queue:
usage rdisp /rfc_max_queue %
and
2) At least rdisp/rfc_max_own_used_wp
free dialog work processes
and
3) At most rdisp/rfc_max_login % of
allowed logins
and
UseUse
quotas?quotas?
yesyes
..
.
ARFC: Resource determination
n For load balancing the message server asks the dispatcher of each instance belonging to the
addressed RFC server group whether there are enough resources available to start an ARFC on that
instance.
n The same resource check is also used on the sender side for TRFCs before the RFC is started within
another dialog work process. If no resources for the call are available it will be performed
synchronously within the initiating work process.
n The R/3 instance profile parameter for configuring the resource determination are:
rdisp/rfc_use_quotas activate/deactivate resource determination(0..1) default = 1=on
rdisp/rfc_max_queue max. allowed dispatcher queue usage % (0..100) default = 5
max. size of dispatcher queue = rdisp/elem_per_queue
rdisp/rfc_max_login max. allowed logon quota usage % (0..100) default = 90
max. number of logins = rdisp/tm_max_no
rdisp/rfc_max_own_login max. allowed logon quota usage % for own default = 25
logins (0..100)
rdisp/rfc_max_comm_entries max. allowed communication entries used % default = 90
(0..100), max. comm. entries = rdisp/max_comm_entries
rdisp/rfc_min_wait_dia_wp number of dialog wp to be kept free default = 1
(1..#dialog wp), #dialog wp = rdisp/wp_no_dia
rdisp/rfc_ max_own_used_wp max. allowed quota of dia wps used by this user default = 75
(0..100)

© SAP AG 1999
The IDOC database consists of three
separate entities
2
NASTEDIDC NASTEDID2 NASTEDIDS
Control Data IDOC Data Status DataControl Data IDOC Data Status Data
(In cluster EDI30C)(In cluster EDI30C)
Contains currentContains current
status link to thestatus link to the
datadata
Contains oneContains one
status record perstatus record per
status changestatus change
Basic Functions used by ALE 2
n A single IDOC can have one or more status records which can be used as a history log.
A successfully sent IDOC always has to have at least 3 status entries as shown below (occurring
from bottom to top):
Ÿ Status records
03 Data passed to port OK
30 IDoc ready for dispatch (ALE service)
01 IDoc created
A successfully processed IDOC at the receiver side (including the successful inbound processing)
has at least the following status sequence:
Ÿ Status records
53 Application document posted
64 IDOC ready to be passed to application
62 IDOC passed to application
50 IDOC added
n The IDOC data is stored in a cluster table and is therefore automatically compressed. Some
databases do not allow to make EDID2 transparent because of a long field (1000 char).

© SAP AG 1999
IDOC IDOC data structure (example)
HEADERHEADER
MM 11
ITEMITEM
MM 99999999
SUBITEMSUBITEM
OO 9999
ACCUMACCUM
MM 11
TEXTTEXT
OO 99999999
Sender Receiver MsgType IDOC-type StatusSender Receiver MsgType IDOC-type Status
HEADERHEADER xxxxxxxxxxxxxxxx
ITEMITEM
SUBITEMSUBITEM
SUBITEMSUBITEM
TEXTTEXT
ITEMITEM
SUBITEMSUBITEM
SUBITEMSUBITEM
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx
xxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxx
xxxxxxxx
ACCUMACCUM xxxxxxxxxxxxxxxx
"Ready for processing" 16:22:34"Ready for processing" 16:22:34
"Successfully processed" 16:22:42"Successfully processed" 16:22:42
Control record
Data
records
Status records
EDIDC
EDID2
EDIDS
Structure of an IDOC
n The physical IDOC structure consists of a 50 byte unique key and 1000 bytes of data.
n With transaction BALE you may view the contents of the IDOC database tables for each single
IDOC.
n An IDOC consists of a control record, a sequence of data segments that belong together and a set of
status records.
The IDOC has a control record in which, amongst other things, the contents and structure of the
IDOC, as well as the sender and receiver of the IDOC are defined, along with its current status. Each
data segment has a "standard header text" (sequential number of the segment, segment type) and a
1000-byte long string field, containing the actual data of the segment.
The status records give a history of processing steps applied to the IDOC.
n The data structure of an IDOC is stored in the SAP System. The structure definition covers the
segment sequence and the fields contained in a segment
n The above example has a header segment, which must be the first segment in the message. After that
at least one item must be present. Each item can be followed by subitems (optional). There may be at
most 99 subitems per header item.
After the header item's subitem segments, one to 9999 text segments may appear (optional).

© SAP AG 1999
ALE Customizing
Distribution Model
Partner Profile
Communication Control (SM59)
Logon User-ID definition
RFC server groups
TRFC scheduling on Communication errors
1
2
Customizing
n The distribution model defines the message flow between so called ‘logical systems'. The ‘logical
system' either represents an external system or a client within an R/3 system. The list of defined
logical systems with a short text are shown using SALE: Sending and Receiving Systems-> Logical
systems ->Define logical system.
n The main ALE customizing transaction is SALE. To get an overview of the systems where messages
are received from or sent to you can check the complete view of message flow via transaction
SALE: Modelling and Implementing Business Processes->Maintain Distribution Model and
Distribute Views. This shows you the message flows that are possible but not how intensively they
are really used.
n A Logical System is an application system within which the applications are coordinated to work in
one database. In the SAP sense of the word, a logical system corresponds to a client. To view the
mapping of clients to logical systems in the local system use SALE: Sending and Receiving
Systems-> Logical systems ->Assign client to logical system and double click on a client (this leads
to the client maintenance screen). If no logical system is displayed there, this client is not used for
ALE communication.
n The Partner Profile defines the message types that are sent to or received from another logical system
to/from the logical system you are in. Use SALE: Modelling and Implementing Business Processes-
>
Partner Profiles and Time of Processing -> Generate partner profiles and enter the remote logical
system. In the inbound section the message types that come from the selected logical system into the
local logical system are shown. The outbound section shows the message types sent to the selected
logical system. A double click on a message type then gives you the communication settings for this
specific message type and direction. Via the Port the used RFC destination resp. EDI file are
mapped.

© SAP AG 1999
SummarySummary
RSEOUT00 ALE outbound processing
RBDAPP01 ALE inbound processing
RSNAST00 IDOC creation via message determination
RBDMIDOC Creation of IDOCs from change pointers
RSARFCEX (Re)Processing of failed/not executed
TRFCs
RBDMANIN Reprocessing of failed inbound IDOCs
RBDMOIND IDOC status update from TRFC queue
RBDCPCLR Reorganization of change pointer table
RSARFC01 Reorganization of the TRFC queue
RBDAUD02 Reorganization of the ALE audit database
Batch Administration
n The above listed programs have to be scheduled either time based or event triggered.
n A common problem is that the selection screen of some of the listed reports have a date field but you
want to schedule the report periodically with a constant variant. This means you need to transform a
relative time frame to an absolute date and time value. This can be done via date variables in the
variant creation.
n Events can be raised in user exits of ALE. Use transaction SMOD and enhancement ALE00001.
User exits are EXIT_RBDPROSE_001, EXIT_SAPLBD11_001 and EXIT_SAPLBDMO_001.
There you could raise an event using function module BP_EVENT_RAISE. You can create an event
using transaction SM62 (e.g. test_event). Then create an event based job using transaction SM36.
n RBDCPCLR should be scheduled on a daily basis if master data is transferred.
n The program RBDMOIND is not necessary for correct functionality but only to have an easier way
to see the real IDOC status on the sender side. You can get the same information also by checking
the TRFC queue via SM58 and comparing with IDOCs states. This report should not be run too often
(maybe once a night).
n For performance reasons it is important to restrict the amount of scanned IDOCs by reasonable input
parameters for the reports RBDMOIND and RBDMANIN. They are also negatively affected if
IDOCs are not regularly archived (see later).
n RBDAUD02 is only necessary if ALE auditing is used. Note that ALE auditing has a negative
impact on performance especially if ALEAUD messages are sent frequently.

© SAP AG 1999
ArchivingArchivingSender
Application
IDOC
DB
ArchiverArchiver
TapeTape
WorkflowWorkflow
itemsitems
Receiver
IDOC
DB
Application
WorkflowWorkflow
itemsitems
Administration
n Archiving has to be set up for all participating logical systems.
Transaction SARA with object IDOC is used for archiving of tables :
EDI30C Intermediate document cluster (data records) from 3.0C
EDIDC Control record (EDI Intermediate Document)
EDIDOC EDIDOC EDI intermediate document cluster
EDIDS Status record (EDI IDoc)
The actual archive program which is called is named RSEXARCA. Program RSEXARCR can
also read the archived IDOCs from the files again.
n As ALE also writes workitem entries even without explicit usage of workflow you have to archive or
reorganize the workitems, too. The archiving object is WORKITEM. As there is no direct link to
IDOCs in the archiving program for WORKITEMs you can only go by the same time frame. If you
are sure that you do not need the workitems any more you can delete them from the database with
the reports RSWWWIDE and RSWWHIDE (see note 49545). Especially if workflow is also used
you should reorganize workflow tables and indices on the database level from time to time
(depending on the used DB system!) - see note 72873.
n Change pointers in table BDCP have to be reorganized separately by program RBDCPCLR.
n The TRFC queue should be reorganized from time to time as well using program RSARFC01.
n There is another option called ALE Audit which sends a confirmation IDOC (message type
'ALEAUD‘) back from the receiver to inform the sender about the status of IDOCs at the receiver
side. As there is a lot of IDOC status information packed in one ALEAUD message these messages
can get very large. ALE audit costs performance and should not be used too frequently or during
high load times. If ALE audit is used you should regularly reorganize the audit database via report
RBDAUD02.

© SAP AG 1999
IDOC Lists Overview
n Tools → ALE → ALE Administration → Monitoring → Display IDOC list, Select Data and enter.
(TCODE=WE05)
n Here you get information on which message types produce the highest workload and which ones
create the most problems (failures).

© SAP AG 1999
Time Distribution of IDOC Creation
n (WE05, from previous screen) → Time Distribution (highlight TOTAL)
n This gives a rough feeling of the peak amount of transferred IDOCs.

© SAP AG 1999
If min and max transferIf min and max transfer
times vary widely, looktimes vary widely, look
at single IDOCat single IDOC
IDOC Trace
n Tools → ALE → ALE Administration → Monitoring → IDOC tracing (TCODE=BDM2)
n Be aware that the above stated transfer times are only useful with message types that are processed
immediately at the receiver end. If there is a time gap between sending and processing - which is the
case for scheduled processing - the figures will become unusable.
n The above statistics are created by evaluating the time stamps of the status records and work flow
tables.

© SAP AG 1999
TESTUSER INBOUND_IDOC_PROCESS REMOTE 06.04.1998 11:26:08TESTUSER INBOUND_IDOC_PROCESS REMOTE 06.04.1998 11:26:08
You are not allowed to logon to the target system 9B38C83F259035289FAD00059B38C83F259035289FAD0005
hs5094 bd21 RBDMIDOC 810 0000hs5094 bd21 RBDMIDOC 810 0000
Host TCTN ProgramHost TCTN Program ClientClient Repeats Transaction IDRepeats Transaction ID
TRFC Monitor
n Tools → ALE → ALE Administration → Services → Communication → Transactional RFC →
Display incorrect calls (TCODE=SM58)
n The transaction ID is a unique identifier for each TRFC call world wide. It is linked to the
corresponding IDOC (in the case of an ALE related TRFC). In the IDOC monitor you can see the
associated transaction ID by double clicking on a selected IDOC and by checking the message in the
status record ‘03' on the sender side.
n As workflow also uses TRFCs you might see entries belonging to workflow also here, too.

© SAP AG 1999
( R/3 Process Monitor - SM50
- gather information on the
workprocess being utilized
( Batch Scheduling - SM37
- check both completed and
scheduled batch jobs
R
Monitoring Transactions
n In SM50 you can see the currently used work processes together with the report executed and the
user executing it. A TRFC call can be detected as executing report SAPLERFC (on the sender as
well as on the receiver side). The ARFC calls produced on the receiver side are executing
SAPLARFC. If they are performing the inbound processing via call transaction you'll see the reports
used for those transactions.
n If scheduled processing is used you should watch out in the batch work processes on the sender side
for RSEOUT00 and on the receiver side for RBDAPP01.
n Usually the TRFC on the receiver side is processed by a special user (defined in the RFC destination
on the sender side) so that you can watch out for this specific user. This is also useful if you want to
trace the receiver via ST05.
n In SM37 you see batch jobs through job names. You can select by user names if you know which
user scheduled the jobs. If you don't know the job and user name you can check for the execution of
specific reports with the help of the report SAPBTCJO. This report gives you all batch jobs that
execute a given report. Alternatively you can use the table TBTCP which contains the steps of batch
jobs.

© SAP AG 1999
Job List of ALE User on Sender Side
n Transaction SM37
n If the automatic batch job creation for failed TRFC calls is set in SM59 (which is the default setting)
you will get an ARFC:… called job for each failed TRFC. In a communication problem situation this
may dramatically make the situation even worse as the batch system is flooded and many jobs will
probably reappear at the same time and maybe fail again and in turn produce new jobs.

© SAP AG 1999
Dialog Work is Disturbed at Receiver
n In this case the inbound processing is needed to refill the number range buffer (report SAPLSNR3).
This operation needs a free dialog work process but there was none free. If all dialog work processes
try to do this at the same time they will wait forever (process deadlock).
n This situation was produced on an instance where RFC resource parameters where used and thus all
dialog work processes where allowed to be used by ARFC calls doing inbound processing. This was
disturbing the dialog work on this machine significantly as you can see from the long work process
hold times.

© SAP AG 1999
Transfer unit sizeTransfer unit size
Dispatch controlDispatch control
Outbound Processing Options
n Outbound processing options can be set
Ÿ During the Definition of the ALE Model (Generation of Partner Profiles)
SALE → Modelling and Implementing Business Processes → Partner Profiles and Time of
Processing → Generate Partner profiles
TCODE=BD82→ outbound parameters
Ÿ When Partner profiles are already existing
Processing → Maintain Partner Profiles Manually
TCODE=WE20→ outbound parameters
n The packet size is ignored if ‘Transfer Idoc immed.' is selected.

© SAP AG 1999
Dispatch control
Inbound Processing Options (1)
n Inbound processing options can be set
Ÿ During the Definition of the ALE Model (Generation of Partner Profiles)
Processing → Generate Partner profiles
TCODE=BD82→ inbound parameters
Ÿ When Partner profiles are already existing
Processing → Maintain Partner Profiles Manually
TCODE=WE20→ inbound parameters
n The option ‘override possible' means that even if a message type is specified not to be processed
immediately after it's received this can be overwritten by a so-called express flag in the IDOC. In
such a case it would be processed immediately anyway.

© SAP AG 1999
Processing ModeProcessing Mode
Transfer limit sizeTransfer limit size
RFC loadRFC load
distributiondistribution
Inbound Processing Options (2)
n Tools → ALE → ALE Administration → Monitoring → Process IDOCs manually
TCODE=BD87 → highlight posting) → (Execute)
n Note that this display was derived from an R/3 of release 3.1G. You will not have the server group
option for <3.1G.

© SAP AG 1999
Avoids flooding ofAvoids flooding of
retried batch jobsretried batch jobs
RFC Customization
n SM59, R/3 connections→ remote(double-click) → destination→ TRFC options
n By default this option is not set. If communication errors occur during high load times this may flood
the batch system with ARFC:.. jobs and also increase workload if all those jobs retry at the same
time and reschedule over and over again.
Therefore we recommend to set this option ‘X' and schedule the RSARFCEX which retries all failed
TRFCs sequentially on a regular basis (e.g. once per hour).

© SAP AG 1999
Avoid processing mode immediately
whenever possible (sender and receiver)
Build packets for sending and updating
(up to 1000-2000 IDOC segments/packet)
Switch off automatic batch retry for TRFC
communication errors and schedule RSARFCEX instead
Schedule mass transfer/updates when there is low
dialog activity (sender and receiver). Spread out
evenly over this defined time window.
1
2
3
4
The 10 Golden ALE Rules (1)

© SAP AG 1999
Archive IDOCS and work items on a regular basis
and reorganize change pointers, TRFC queue and
audit database if used
Use registration for receiving external programs
and keep logged on for external sender programs
Use multiple registration for external receivers
if possible (and useful)
5
6
7

© SAP AG 1999
Use RFC server groups for parallel update
and actually use the parallel update
Adjust the number of dialog work processes
on the sender side as well as on the receiver side
Use RFC resource parameters to avoid that all
resources are used up by TRFC or ARFC
8
9
10

© SAP AG 1999
Technical Background of ALE
Analysis Flow Chart
of ALE Processing
of ALE
Analysis Tools and
Analysis Flow Chart

© SAP AG 1999
Performance
Problems
with ALE
PerformancePerformance
ProblemsProblems
with ALEwith ALE
Application Data
does not arrive
Application DataApplication Data
does not arrivedoes not arrive
Application Data
arrive too slow
(throughput problem)
arrive too slowarrive too slow
(throughput problem)(throughput problem)
Dialog work
is disturbed
Dialog workDialog work
is disturbedis disturbed
111
222
Application Data
arrive too late
(realtime problem)
arrive too latearrive too late
((realtimerealtime problem)problem)
444
333
Possible Performance Problems
n It seems that case 1 (application data does not arrive) does not fit into the performance problem area.
In fact it may be the reason for a performance problem e.g. if the system constantly retries aborted
transfers.

© SAP AG 1999
SALE / BALE
Info
Is ALE used?
Kind of
problem
Do not tune
ALE
Yes
App.data
does not
arrive
No
Ask suffering
people
Use
subchart
1
Use
subchart
2
App.data
arrives
too slow
App.data
arrives
too late
Use
subchart
3
Use
subchart
4
Dialog work
is disturbed
Analysis and Tuning Flowchart (1)
n To check whether ALE is used you can tap into several information sources:
1. Ask the customer (this is sometimes not as easy as it looks because usually not every contact
person knows enough about the R/3 system usage).
2. Check the ALE customizing. The potential ALE message flow is shown via SALE: Modelling
and Implementing Business Processes->Maintain Distribution Model and Distribute Views.
3. Check the IDOC overview (transaction WE05) to see which messages were really transferred
during the last days. In the selection screen of WE05, you should enter ‘LS' as ‘Partner type' to see
only ALE relevant IDOCs.

© SAP AG 1999
Sender
IDOC
created?
no
Use
subchart
1.1
yes
BALE:
IDOC overview
Master data
msg. Type?
no
yes
Check change
pointer activation
+ RBDAPP01 run
Messaging
used?
no
Immediate
NAST processing
or RSNAST00
ran?
yes
Check for DB error
on IDOC creation
(e.g. tablespace full,
max extents reached)
yes
Change messaging
option or schedule
RSNAST00no
Msg.type =
BLAORD,
BLAOCH,...
Customizing
for messaging
condition rec.
Msg.type =
MATMAS,…
(*MAS)
Application Data Does not Arrive (Subchart 1)
n Another rare but possible error is that the IDOC could not be created due to a DB error (e.g.
tablespace full, max extents reached,…).

© SAP AG 1999
SM59
IDOC status?
Use
subchart
1.2
BALE:
IDOC overview
+ SM58 (TRFC)
sent
error
Receiver is
ext. program?
yes
Check RFC address
+
login info
Receiver temp.
unreachable? yes
Start receiver
and retry
Ext. program
registered?
Check if ext. prog.
Can be started,
Check gateway
Check if ext.prog
running or busyyes
no
SM59
test conn.
no
no
Application Data Does not Arrive (Subchart 1.1)
n The status of an IDOC can be updated from the TRFC queue to the IDOC via report RBDMOIND.
Otherwise you have to check manually via SM58 if there are aborted TRFC calls.
n The receiver is an external program if the SM59 RFC destination used for it is a TCP/IP connection.

© SAP AG 1999
ALE
customizing
Receiver IDOC
status?
BALE
IDOC overview
ALE
error
received
Immediate
processing?
yes
Check RBDAPP01
scheduling
RBDAPP01 ran?
Check
SM13, SM21
Check customizing
due to error msg.
SM37
no
no
yesor update err
Application Data Does not Arrive (Subchart 1.2)
n The receiver status of an IDOC can always be checked on the receiver system. If you use ALE
auditing you can automatically update the status information of the corresponding sender IDOC and
thus see the receiver status also on the sender side. However ALE auditing sends additional
messages and costs performance.
n To check which batch job is executing report RBDAPP01 you can use SE16 and search for entries in
the table TBTCP with PROGNAME = ‘RBDAPP01'.
n In SM13 you can check for aborted updates in the application modules and SM21 shows the R/3
system log where other principal system problems are logged.

© SAP AG 1999
Master data
msg. type?
ALE
customizing
Use
subchart
2.1
no
yes
RBDMIDOC
period too
long?
no
Messaging
used?
Msg.type =
BLAORD,
BLAOCH,...
Reduce period or
use event (user exit),
check batch resources
yes
SM37
yes Immediate msg
or RSNAST00
schedule ok?
ALE
customizing,
SM37
no
Immediate send
or RSEOUT00
schedule ok?
ALE
customizing,
SM37
no
yes
yes
no Set
immediate
send
Set
immediate
msg.
processing
Application Data Arrive too Late (Subchart 2)
n For batch jobs also check whether enough batch resources are available
n For event-triggered batch jobs (e.g. RBDMIDOC in master data create user exit) be aware that event
scheduled jobs are translated to time triggered (one minute in the future) if the batch scheduler runs
on an instance that is different from the one where the event is raised.
n The processing mode for NAST entries is set up in the condition record customizing of the
corresponding application.

© SAP AG 1999
SM50,
ST03
no
Logon too slow?
Receiver WP
bottleneck?
no
no
SM59
RFC dest.
Sender WP
bottleneck?
Network
connection
slow?
Receiver is
ext. prog?
yes
Use
subchart
2.2
yes
SM50,
ST03
no
SM59,
ping
SM59,
test
Increase Sender
DIA WPs / check
RFC resource params
yes
yes
Upgrade to
R/3 > 30F,
reduce user
profiles
yes
Increase
Receiver
DIA WPs
Use
subchart
2.3 or 4.2
***
no
Check
hardware
Application Data Arrive too Late (Subchart 2.1)
n Automatically created batch jobs for TRFCs for automatic retry following communication errors
(turned on in SM59->TRFC options by default) are named ARFC:<transaction ID>.
n In ST03→ Detail analysis→ Statistical records you can see if all work processes were used by
CPIC/RFC. You can select by the user which is used for sending at the sender side and the ALE user
at the receiver side. WE05 gives the time frame to investigate.
n The RFC resource parameter settings may prevent the TRFC from using all available resources.
n *** If you are coming from subchart 3 goto subchart 4.2 instead of 2.3 here.

© SAP AG 1999
no
Network
connection
slow?
Ext. program
registered?
SM59
Register ext.
program
to avoid startup
yes
Ext. program
running multiply?
yes
Increase
parallelismno
SM59,
SMGW
Ext. program
can run in
parallel?
Check
hardware
OS
Process
list
no
yes
Optimize
ext. program
no
Register
ext. program
multiple times
yesAsk vendor
or developer
n If the external program needs to run in parallel it has to synchronize concurrent access to shared
resources (e.g. an output file or a robot) - this is usually easy if the resource is a database system
which provide synchronization mechanisms.
n To check where the time is spent you can monitor time stamps. Each IDOC status change produces a
time stamp. If an SAP gateway is involved you can also use the gateway trace (trace level 2) to get a
time stamp each time the gateway enters a work loop. It is also a good idea to write time stamps from
the external program right before it makes a TRFC call and after this call returns.
n If you have time stamps from different machines you must take into account that they may run
within different time zones and are usually out of sync with the correct time. You need to get a
reasonably precise measurement of the delay between every two involved systems. The easiest way
is to use one base system to refer to and remotely logon to each other system from there (e.g. via
telnet). Then call the OS command to get the time on the local and one remote machine and execute
it within the same second (should be manually possible). You can do this several times also by
switching the order of both calls and compute a mean value of the measured time delays. Usually
this method is accurate enough. If you have radio controlled clocks on all machines you only need to
calculate the time zone difference.

© SAP AG 1999
yes
Immediate
processing used?
Switch to
immediate
update
no
RBDAPP01
period ok? yes
ALE
customizing SM37
no
Reduce
period
Check RFC
resource params,
Analyze receiver
application
RBDAPP01
params ok?
Packet size,
RFC server group,
parallel execution
yes
Correct
parameters
no
n Usually we recommend to use scheduled inbound processing via RBDAPP01 but for some cases it
may be necessary to use immediate processing (especially if the number of IDOCs is reasonably
small).
n The RFC resource parameters may particularly affect the immediate processing as in addition to the
TRFC receiving process another dialog work process for ARFC inbound processing is needed. If the
resource parameters prohibit the use of all available resources it may switch to synchronous
processing and wait.
n If the packet size of RBDAPP01 is too large it may take too long until the last IDOC of the packet is
processed as all IDOCs within a packet are processed sequentially.
Using RFC server groups also allows to utilise resources from other R/3 instances. When parallel
execution is not used the maximum possible throughput of RBDAPP01 may also not be achieved.

© SAP AG 1999
Immediate send?
no
Packet size
< 100 ?
yesyes
build packets
+
schedule
RSEOUT00
Increase
packet size
no
Sender is
ext. program?
no
yes
Logon once
and stay
connected
Use
subchart
2.1
ALE
customizing
ask
Application Data Arrive too Slow (Subchart 3)
n You can reuse subchart 2.1 from ‘application data arrive too slow' here.
n If the sender program is external, time stamps from this program as well as the gateway monitor may
help you to find out where exactly the bulk of time is lost. Cases are known where on an NT machine
a large file was scanned before each TCP/IP transfer which caused a sender delay.
n Logging on and staying connected is logically equivalent to registration when the external program
is the receiver.

© SAP AG 1999
Problem at
which side?
Sender Receiver
Ask suffering
people
Use
subchart
4.1
Use
subchart
4.2
Dialog Work is Disturbed (Subchart 4)
n If you want to monitor the situation life you may face the problem that the monitoring within R/3
itself is practically impossible as it also needs a dialog work process. Even a logon to the system
might not be possible. In that case you can also use the SAP executable ‘dpmon' which talks directly
to the message server to get SM50 like information and does not need a work process.

© SAP AG 1999
Immediate
Send ?
ALE
Customizing
Packet size
< 100 ?
Increase
packet size
build packets
+ schedule
RSEOUT00 at
non-peak time
From
subchart
4
Add DIA WPs,
setup dedicated
ALE sender
instance / server,
use RFC server group
yesyes
no no
RFC resource
params set?
yes
no
Check RFC
resource params
RFC
Customizing
Dialog Work is Disturbed at Sender (Subchart 4.1)
n The optimal packet size depends strongly on the size of the IDOCs, the underlying hardware and the
most useful degree of parallelism (each packet will produce a new TRFC call in a separate work
process, as long as free RFC resources are detected).
n The RFC resource parameters can prevent that too many R/3 resources are given to the TRFC calls
and thus reserve more available resources for dialog users.
n With a dedicated ALE instance the RFC resource parameters can be set less restrictively.

© SAP AG 1999
ALE
Customizing
Increase
packet size
From
subchart
4
RFC
Customizing
Packet size
< 30 ?
Immediate
Update ?
RFC resource
params set?
build packets
+ schedule
RBDAPP01 at
non-peak time
yes
Add DIA WPs
or setup
dedicated
ALE sender
instance / server
no no no
yes yes
Check RFC
resource
params
Dialog Work is Disturbed at Receiver (Subchart 4.2)
n The RFC resource parameters on the receiver side are used whenever an ARFC call is issued. If no
RFC resources are returned the call will be handled synchronously and thus not use another dialog
work process.
n The RFC resource parameter setting on the sender side also directly affects the workload produced
on the receiver side during peak times. You may also need to slow down the sender via setting the
RFC parameters on the sender side properly.

Exercises - Technical Optimization of ALE Processing
1. Check ALE message flow (customizing)
Check in the two training systems which message flows are defined (potentially possible).
Fill out the form on this page according to the ALE customizing. Only write down the
message flow between the training systems from or to client 100 and eventually between
the training systems and external programs.
Sender
Logical
system
Sender
hostname,
Instance,
Client
Message
type
RFC
destination
Receiver
Logical
system
Receiver
hostname,
Instance,
Client
Outbound
Dispatch
control
(immediate /
scheduled)
Outbound
Packet size
Inbound
Dispatch
control
(immediate /
scheduled)
2. Check ALE message flow (communication statistics)
Check how many ALE messages were sent between the logical systems identified in
exercise 1 during the last 7 days and fill out the following table. Determine the time
difference between the clocks of the two systems. How would different time zones affect
the time stamps written on sender and receiver side? For the message with the longest
transfer duration write down all IDOC status change time stamps.
Sender
Logical
system
Sender
SAP
system id
Message
type
Receiver
Logical
system
Receiver
SAP
system id
#IDOCs
sent
#IDOCs
posted
#IDOCs
in error
status
Minimum
transfer
duration
Maximum
transfer
duration
Average
transfer
duration

Time delay at REMOTE against CENTRAL:
3. Create 20 new material masters and transfer them from system CENTRAL to REMOTE
For this exercise you should first create you own R/3 user as a copy of TESTUSER system
CENTRAL – use transaction SU01 to do this (otherwise it is not easy to distinguish your
activity from other groups).
Use report ZCREMAT to create material masters with
MATPFIX = EXERCISE3_<groupnr>_ FROMNO = 1, TONO = 20.
Transfer the new materials via analyzing the change pointers – how many work processes
are used for the transfer on the sender side?
What happens if another group also transfers materials using the same method?
Transfer these 20 materials once more without changing them – how can you do this?
First do not specify an RFC server group – how many work processes are used on the
sender side for creating the IDOCs and how many for transferring them?
Then transfer the 20 materials once more but this time specify an RFC server group.
Therefore create an RFC server group with the name ‚RFC_group_<nr>‘ with <nr> as your
group number. Specify 5 IDOCs per process. What is the difference in work process usage
this time?
4. Dialog users are disturbed
100 material masters are sent from CENTRAL to REMOTE. During this operation users
on REMOTE complain about bad performance.
The trainer will send the material masters and you observe the systems. You can use your
results from exercise 1 to discuss performance improvement possibilities. How can you
check what happens on REMOTE if your R/3 screen display seems to be frozen or you
even cannot log on?
Write down possible steps to improve performance. Afterwards the trainer will implement
the reasonable suggestions and retry.
5. Archiving on system CENTRAL
How old is the oldest IDOC in the system CENTRAL?
What percentage of IDOCs is older 1 month?
What is the transaction to perform archiving and which archiving objects should be used
for ALE?
How do many entries are in the change pointer table? How can you reorganize it?
How many failed entries are in the TRFC queue? How can you get rid of them?

Solutions - Technical Optimization for ALE Processing
1. Check ALE message flow (customizing)
First find out the logical system name of client 100 and 200 in both systems. Use the client
maintenance transaction.
Tools → Administration, Administration→Client admin→Client maintenance, double click
on client 100 and 200
You will find the logical system names CENTRAL for client 100 and REMOTE for client
200.
To see the message flow defined for these logical systems use:
SALE, Modelling and Implementing Business Processes→Maintain Distribution Model
and Distribute Views
For each message type perform a configuration check via:
SALE, Modelling and Implementing Business Processes → Partner Profiles and Time of
Processing →Maintain partner profiles Manually
Enter partner logical system and check for outbound respectively inbound settings on both
systems.
For outbound options you can go via double clicks for each message type and the port
number to the associated logical RFC destination. This can then be checked in SM59 in
R/3 connections for R/3 to R/3 communication or in TCP/IP connections to an external
system.
Each resulting line in the table contains collected information from the sender and the
receiver side.
Example:
Sender
Logical
system
Sender
hostname,
instance,
client
Message
type
RFC
destination
Receiver
Logical
system
Receiver
hostname,
instance,
client
Outbound
Dispatch
control
(immediate /
scheduled)
Outbound
Packet size
Inbound
Dispatch
control
(immediate /
scheduled)
CENTRAL twdf3f01/00/100 BLAORD REMOTE REMOTE twdf3f02/00/200 immediate 1 immediate
CENTRAL twdf3f01/00/100 MATMAS REMOTE REMOTE twdf3f02/00/200 immediate 1 immediate
REMOTE twdf3f02/00/200 BLAREL CENTRAL CENTRAL twdf3f01/00/100 immediate 1 Immediate
2. Check ALE message flow (communication statistics)
The following results table is only an example and the IDOC list in your case may look
different according to a different communication history. To get the numbers of sent and
received IDOCs you logon to both systems and use transaction
Tools→ALE→ALE Administration→Monitoring→Display IDOC list.
Enter selected start date 7 days ago, partner type of sender and receiver = LS (this filters

out potential EDI related IDOCs).
The duration information can be read via the IDOC trace from the sender side (CENTRAL)
giving the logical system name of the partner and the message type of interest.
Tools→ALE→ALE Administration→Monitoring →IDOC tracing
To get the duration list for all IDOCs you can double click on the summary. As there is no
sort function you can search via the find function for the occurrence of the maximum delay
shown in the first screen (if the number of IDOCs is large). For this IDOC you go to the
IDOC overview on sender and receiver sides with the IDOC number to get the status
history. In our example we got for the 4 min 22 sec MATMAS IDOC:
01 IDOC created 22.07.2000, 12:26:08
30 IDOC ready for dispatch (ALE service) 22.07.2000, 12:26:08
03 Data passed to port OK, 22.07.2000, 12:26:08
12 Dispatch OK 22.07.2000, 12:27:47
50 IDOC added 22.07.2000, 12:30:30
64 IDOC ready to be passed to application 22.07.2000, 12:30:30
62 IDOC passed to application 22.07.2000, 12:30:30
53 Application document posted 22.07.2000, 12:30:30
Example:
Sender
Logical
system
Sender
SAP
system id
Message
type
Receiver
Logical
system
Receiver
SAP
system id
#IDOCs
sent
#IDOCs
posted
#IDOCs
in error
status
Minimum
transfer
duration
Maximum
transfer
duration
Average
transfer
duration
CENTRAL TCC/100 BLAOCH REMOTE TCC/200 0 0 0 - - -
CENTRAL TCC/100 BLAORD REMOTE TCC/200 5 5 0 0 sec 3 sec 1 sec
CENTRAL TCC/100 MATMAS REMOTE TCC/200 19 18 2 0 sec 22 sec 4 m. 22 s.
CENTRAL TCC/100 BLAREL REMOTE TCC/200 10 10 0 0 sec 4 sec 1 sec
3. Create 20 new material masters and transfer them from system CENTRAL to REMOTE
Part 1:
Execute report ZCREMAT with given parameters. This produces change pointers. To
create IDOCs from change pointers call:
Tools→ALE→Adminitration→Services→Change Pointers→Process (BD21)
Then enter Message type ‚MATMAS‘. Note that you cannot specify object ranges to be
processed – you always process all master data of a given message type. If another group
was faster your change pointer analysis might not find any more work to do.
During the transfer all free dialog work processes are used on the sender side.
Part 2:
Use the direct send of master data this time:
Tools→ALE→Master Data Distribution→Cross-Application→Material→Send (BD10)
and enter the range of materials you created in Part 1. During the IDOC creation only one
work process is used but for the transfer again all free dialog work processes are used.
Part 3:

Define an RFC server group via:
SM59, RFC→RFC groups
Then create Entry, Server group = RFC_group_<nr>, Instance = central instance name.
Then resend directly the same materials again and specify the new created RFC server
group and specify 5 IDOCs per process.
This time 4 (=20/5) dialog work processes are used for IDOC creation and all available
dialog work processes for the transfer.
4. Dialog users are disturbed
100 material masters are sent from CENTRAL to REMOTE. During this operation users
on REMOTE complain about bad performance.
Problems:
IDOCs are sent immediately (i.e. one by one, 100 send transfer operations).
IDOCs are updated immediately (i.e. additional DIAs used for ARFC updates + DIAs at
receiver longer in use during transfer operation).
Therefore all dialog work processes on the receiver side are used up quickly by ALE. To
check this you can use transaction SM50 on the receiver side during the transfer.
(You can also use the operating system level tool dpmon from the R/3 executable directory.
You must specify the R/3 profile which has the connect informations for the system.
Example:
dpmon pf=/sapmnt/TCC/profile/TCC_DVEBMGS00-<hostname>
With the menu m->p you get an SM50 like display which refreshes automatically every
few seconds. This method does not occupy a work process but directly asks the dispatcher
for information.)
The IDOC trace for the 100 IDOCs showed minimum transfer time 8 sec, max 1 min 48
sec and average 34 sec.
Solutions:
Change update immediately to collect IDOCs and update via RBDAPP01 (optional with
parallel booking and packet size 30).
Change sender mode to collect IDOCs and send via RSEOUT00 using packets (e.g. 50
IDOCs in size).
Another solution would be to use RFC resource parameters on the sender side to reduce the
number of concurrently used work processes. You need to ensure that the preconditions of
note 74141 are set.
5. Archiving on system CENTRAL
The IDOC creation time stamps are stored in the table EDIDC. Table contents can be
viewed via SE16. If the table is very large it does not make sense to display everything
(may even cause a short dump). Therefore use binary search to see which is the smallest
IDOC number that exists. For this IDOC read the creation time stamp. For estimating how
many IDOCs are older than one month also binary search can be used to find via existing
IDOC numbers the highest number which belongs to an older IDOC. If there are no gaps in
the numbers (which will be the case in our systems) the estimation is quite good.

The change pointers are stored in BDCP. The number of entries could be found also with
SE16 or estimated via binary search. Also the database monitors help to get the table sizes.
It can be reorganized via:
Tools→ALE→Adminitration→Services→Change Pointers→Reorganize (BD22)
The TRFC queue can be monitored via SM58 for eachuser. It can be reorganized form
there via:
SM58→Execute, Log File→Reorganize
The user DDIC can also delete any entries.

Basis week5

More Related Content

Similar to Basis week5 (20)

More from nanda nanda (14)

Recently uploaded (20)

Basis week5