Basis week5

SAP AG 1999

TABC30 Technical Consultant Training Week 5:Performance Analysis & TuningTechnical Consultant Training:Performance Analysis & TuningTechnical Consultant Training:Performance Analysis & Tuning

TABC30 R/3 Release 4.6C 50039594

TABC30 R/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 maybe copied or reproduced in any form or by any means,or translated into another language, without the priorconsent of SAP AG. The information contained in thisdocument is subject to change and supplement without priornotice.

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 Next Topic in Unit ........................................................................................................................................................83 Allocation Sequence for Dialog WPs (1)..................................................................................................................84 Allocation Sequence for Dialog WPs (2)..................................................................................................................85 Allocation Sequence for Dialog WPs (3)..................................................................................................................86 Allocation Sequence for Dialog WPs (4)..................................................................................................................87 Allocation Sequence for Dialog WPs (5)..................................................................................................................88 Allocation Sequence for Dialog WPs (6)..................................................................................................................89 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 Next Topic in Unit ........................................................................................................................................................94 Allocation Sequence for Non-Dialog WPs ...............................................................................................................95 Next Topic in Unit ........................................................................................................................................................96 Freeing Heap Memory (1) ...........................................................................................................................................97 Freeing Heap Memory (2) ...........................................................................................................................................98 Freeing Heap Memory (3) ...........................................................................................................................................99 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 Next Topic in Unit ..................................................................................................................................................... 126 Hardware Analysis Roadmap (1) ............................................................................................................................ 127

Hardware Analysis Roadmap (2) ............................................................................................................................ 128 Response Time Components .................................................................................................................................... 129 Hardware Analysis Roadmap (3) ............................................................................................................................ 130 Workload Analysis Exercise.................................................................................................................................... 131 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 Checking Tuning Results (2) ................................................................................................................................... 139 Checking Tuning Results (3) ................................................................................................................................... 140 Next Topic in Unit ..................................................................................................................................................... 141 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 Summary of this Unit ................................................................................................................................................ 147 Appendix: 32 Bit Configuration Example (1) ....................................................................................................... 148 Appendix: 32 Bit Configuration Example (2) ....................................................................................................... 149 Appendix: Quick Sizing (1) ..................................................................................................................................... 150 Appendix: Quick Sizing (2) ..................................................................................................................................... 151 Appendix: Quick Sizing (3) ..................................................................................................................................... 152 Appendix: Quick Sizing (4) ..................................................................................................................................... 153

Expensive SQL Statements........................................................................................................................................... 154 Expensive SQL Statements ...................................................................................................................................... 155 Expensive SQL Statements ...................................................................................................................................... 156 Topics Covered Elsewhere ....................................................................................................................................... 157 First Topic in Unit ...................................................................................................................................................... 158 What is an Expensive SQL Statement?.................................................................................................................. 159 Consequences of Expensive SQL Statements....................................................................................................... 160 Next Topic in Unit ..................................................................................................................................................... 161 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 Detection Roadmap (2) ............................................................................................................................................. 170 Monitoring Buffer Gets / Disk Reads (1)............................................................................................................... 171 Monitoring Buffer Gets / Disk Reads (2)............................................................................................................... 172 Monitoring Buffer Gets / Disk Reads (3)............................................................................................................... 173 Detection Using the SQL Trace (1) ........................................................................................................................ 174 Detection Using the SQL Trace (2) ........................................................................................................................ 175 Detection Using the Where-Used List.................................................................................................................... 176 Detection Roadmap (3) ............................................................................................................................................. 177 SQL Statement Exercise (1) ..................................................................................................................................... 178 SQL Statement Exercise (2) ..................................................................................................................................... 179 Exercise Solution for 1st SQL Statement............................................................................................................... 180 Exercise Solution for 2nd SQL Statement............................................................................................................. 181 Next Topic in Unit ..................................................................................................................................................... 182 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 Index Use in SQL Statements (2) ............................................................................................................................ 187 Index Use in SQL Statements (3) ............................................................................................................................ 188 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 Detection Roadmap (3) ............................................................................................................................................. 198 Tuning Roadmap ........................................................................................................................................................ 199 Workload Analysis Exercise.................................................................................................................................... 200 Workload Analysis Exercise: Detection ................................................................................................................ 201 Workload Analysis Exercise: Solution................................................................................................................... 202 Before -and-After Comparison................................................................................................................................. 203 Summary of this Unit ................................................................................................................................................ 204 Appendix1: Optimizing ABAP Database Programming..................................................................................... 205 ABAP Database Programming ................................................................................................................................ 206 Creating Efficient SQL Statements......................................................................................................................... 207 Tuning Checklist for ABAP Coding (1) ................................................................................................................ 208 Tuning Checklist for ABAP Coding (2) ................................................................................................................ 209 Tuning Checklist for ABAP Coding (3) ................................................................................................................ 210 Appendix 2: Database Locks and R/3 Enqueues.................................................................................................. 211 Exclusive Lock Waits (1) ......................................................................................................................................... 212 Exclusive Lock Waits (2) ......................................................................................................................................... 213 Exclusive Lock Waits (3) ......................................................................................................................................... 214 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 First Topic in Unit ...................................................................................................................................................... 223 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 Buffer Synchronization (2) ....................................................................................................................................... 229 Buffer Synchronization (3) ....................................................................................................................................... 230 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 Solution (2) ..................................................................................................................... 237 SQL/Buffering Exercise Solution (3) ..................................................................................................................... 238 SQL/Buffering Exercise Solution (4) ..................................................................................................................... 239 SQL/Buffering Exercise Solution (5) ..................................................................................................................... 240 SQL/Buffering Exercise Solution (6) ..................................................................................................................... 241 SQL/Buffering Exercise Solution (7) ..................................................................................................................... 242 SQL/Buffering Exercise: 2nd Run of ZZBUFFER............................................................................................. 243 Next Topic in Unit ..................................................................................................................................................... 244 Buffering Strategy: Technical Criteria ................................................................................................................... 245 Buffering Strategy: Application Criteria ................................................................................................................ 246 Buffering Strategy: Condition Tables..................................................................................................................... 247 Buffering Optimization ............................................................................................................................................. 248 Next Topic in Unit ..................................................................................................................................................... 249 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 Next Topic in Unit ..................................................................................................................................................... 289 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 Next Topic in Unit ..................................................................................................................................................... 303 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 Next Topic in Unit ..................................................................................................................................................... 311 Workload Analysis Exercise.................................................................................................................................... 312 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 How ALE Works - Step 2......................................................................................................................................... 337 How ALE Works - Step 3......................................................................................................................................... 338 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 The 10 Golden ALE Rules (2)................................................................................................................................. 378 The 10 Golden ALE Rules (3)................................................................................................................................. 379

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 Late (Subchart 2.2) ................................................................................................. 388

Application Data Arrive too Late (Subchart 2.3) ................................................................................................. 389 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/IPnetwork administration.

l Practical experience with these issues is essential forpassing the SAP R/3 Certified Technical Consultant exam.

SAP AG 1999

Course Goals

l Course participants receive comprehensive expert leveltraining in R/3 System management

l The course prepares participants for the “SAP R/3 CertifiedTechnical 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 OperationManagement




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 CapacityVerification

5. Expensive SQL Statements

SAP AG 1999

Introduction to Workload Analysis








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 approachinga performance problem

Introduction to Workload Analysis

SAP AG 1999

Introduction: Performance Bottlenecks

System bottlenecks

l Hardware (CPU, RAM, I/O,network)

l Configuration(memory/bufferconfiguration,process configuration)

Long-running programs

l Unnecessary functionality

l Non-optimal implementation

n Technical implementation (e.g.database indexes, tablebuffering, ABAP coding)

n Logical implementation (non-optimal use of SAP standardfunctionality

Long-runningprograms may cause

system bottlenecks

System bottlenecks maycause long-runningprograms

SAP AG 1999

Basis Tuning

l Goal:

n Distribute the given workload

optimally to avoid performancebottlenecks

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 andoptimal 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 / WANPresentation

Application

Database

CreateProduction

Orders

Release

ProductionOrders

ScheduleProduction

Accept Customer

Order

ConfirmDelivery

BuildProducts

Explode

Bill-of-Material

ReserveMaterial

CustomerService

Rep

PlantPersonnel

ProductionOrder

CustomerOrder

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

DatabaseLayer

Network

ApplicationLayer

PresentationLayer

Network

Wait queue (memory)

. . .

Work process

DispatcherWait 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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Dispatcher

Roll buffer

Roll fileRoll file

Roll memory

. . .

Work process

Extended Extended 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

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Roll buffer

Roll fileRoll file

Roll memory

Dispatcher


DatabaseLayer

Databasebuffers

. . .

Work process

Databaseprocess

Databaseinterface

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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Databasebuffers

Roll buffer

Roll fileRoll file

Dispatcher

Databaseprocess

Extended memoryExtended memoryDatabaseinterface

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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Databasebuffers

Roll buffer

Roll fileRoll file

Databaseinterface

Roll memory

. . .

Work process

Dispatcher

SAP shared pool buffers

Databaseprocess


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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Databasebuffers

Dispatcher


Databaseprocess

Roll buffer

Roll fileRoll file

Databaseinterface

Roll memory

. . .

Work process


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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Databasebuffers

Roll buffer

Roll fileRoll file

Databaseinterface

Roll memory

. . .

Work process

Dispatcher


Databaseprocess


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

DatabaseLayer

Network

NetworkApplication

Layer

PresentationLayer

Wait queue (memory)

Databasebuffers

Roll buffer

Roll fileRoll file

Databaseinterface

Roll memory

ABAP processing. . .

Work process

Dispatcher


Databaseprocess

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

PresentationServer

Roll in

Loadtime

Processing timeWaittime

Database time

Response time

Application Server Database Server

Net

wor

kN

etw

ork

Net

wor

kN

etw

ork

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

AllAlltransactionstransactions

affected?affected?

Program analysis

No

Yes

(Cont.)

Performance problem?

Check:

Workload Workload on all serverson all servers

Problem symptoms:

Large load timeLarge load time

Processing timeProcessing timemuch larger thanmuch larger thanCPU timeCPU time

Large databaseLarge databaserequest 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 timemuch larger thanmuch larger thanCPU timeCPU time

CPU/memory bottleneck on database server, network problems, expensive SQL statements, database locks,missing indexes, missing statistics, small buffers

Large databaseLarge databaserequest 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 systemLarge 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 buffertoo 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

DatabaseMonitor

SetupsBuffers

Operating SystemMonitor

Work ProcessOverview

Workload Monitor

… Details in the following units

TransactionST04

TransactionST02

TransactionST06

TransactionSM50 / SM66

TransactionST03 orST03N

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

Statisticalrecords

SQL trace ApplicationMonitors

ABAP trace

Workload MonitorTransactionST03N

… Details in the following units

TransactionsST07 / ST14

TransactionSE30

TransactionST05

TransactionSTAT / 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.6B 4.0B 5.0

STADFirstavailability

Fullfunctionality

4.6C/D

STATGeneralavailability

Last functionalenlargement

Planned lastavailability

Generalavailability ST03

ST03NFirst

availability Planned fullfunctionality

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 approachinga performance problem

SAP AG 1999








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 SystemMonitor

Work ProcessOverview

Workload Monitor

TransactionST04

TransactionST02

TransactionST06

TransactionSM50 / SM66

TransactionST03N

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 ProcessOverview

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 extendedmemory or roll buffer)

Work processes in status “stopped”?

Reason: “PRIV”?


Reason: “CPIC”?

Problems with CPIC connections such as "All work processes blocked indestination 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 andoperating 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 systemconfiguration 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 CodeProgram buffer

PERFORM Costing.ENDIF.SELECT * FROM MARA

PERFORM Costing.ENDIF.SELECT * FROM MARA

SELECT * FROM.VBAK.CALL FUNCTIONENDSELECT


. . .. . .


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

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 fromP

rese

nta

tio

nP

rese

ntat

ion

Ap

plic

atio

n s

erve

rA

pp

licat

ion

ser

ver

Dat

abas

eD

atab

ase

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

Pre

sent

atio

nP

rese

nta

tio

nA

pplic

atio

n se

rver

Ap

plic

atio

n s

erve

r

Work process

Work process

Work process

Work process

Memory

Code

Program buffer

Dat

abas

eD

atab

ase

Code CodeCode

. . .. . .

PERFORM Costing.ENDIF.SELECT * FROM MARA . . .. . .

SELECT * FROM.VBAK.CALL FUNCTIONENDSELECT . . .. . .


. . .. . .

PERFORM Costing.ENDIF.SELECT * FROM MARA . . .. . .

SELECT * FROM.VBAK.CALL FUNCTIONENDSELECT. . .. . .

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

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

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








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 memorymanagement

l Explain how these types of memory work together

l Use R/3 memory management monitors

l Configure parameters as part of R/3 memorymanagement


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 twokinds 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

Physicalmemory

Maximum virtual memory ≤physical memory +

operating system swap space * Do not confuse with R/3 paging !

Operating systempaging file* =operating systemswap 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

Workprocess

Workprocess

Workprocess...

Localmemory

Localmemory

Localmemory...

1 : 1Local work process memory is for:l Executablesl Data, stackl Buffer for database transferl Local roll areal Local paging area

Local memory

is associated withindividual work

processes

SAP AG 1999

R/3 Memory II: R/3 Buffers

Server

Virtual memory


Workprocess

Workprocess

Workprocess...

1 : n

R/3 buffers contain global objects for allusers and work processes, such asprograms, and Customizing tables

Shared memory isassociated with

all the processes ofone instance

R/3 buffers

SAP AG 1999

R/3 Memory III: Extended Memory

Server

Virtual memory


Workprocess

Workprocess

Workprocess...

1 : nExtended memory containsuser contexts – that is, objectsassociated with individualusers, such as variables, lists,and internal tables

Extended memory

SAP AG 1999

R/3 Memory IV: Heap Memory

Server

Virtual memory


Workprocess

Workprocess

Workprocess...

Localmemory

Localmemory

Localmemory

...

Heap memory(temporary)

1 : 1Heap memory:l Contains user contexts, for example, when extended memory is fulll 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

ServerVirtual memory


Workprocess

Workprocess

Workprocess...

1 : n

R/3 roll file

Roll memory contains theinitial part of user contexts

Roll buffer

SAP AG 1999

R/3 Memory VI: Paging Memory

Server

Virtual memory


Workprocess

Workprocess

Workprocess...

1 : n

R/3 paging file

R/3 paging memory contains:l ABAP objects such as extractsl Context-independent objects such as exports

R/3 paging buffer

SAP AG 1999

R/3 Memory - System Point of View

Server

Virtual memory


Workprocess

Workprocess

Workprocess...

Localmemory

Localmemory

Localmemory

...

Heap memory(temporary)

1 : n 1 : 1

R/3 rollfile 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 memoryNot 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

Datafor user 1

Datafor user 3

Dialogwork

process 1

Dialogwork

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

Datafor user 1

Datafor user 3

Dialogwork

process 1

Dialogwork

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

Datafor user 1

Datafor user 3

Dialogwork

process 1

Dialogwork

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

Datafor user 3

Datafor user 1

Dialogwork

process 1

Dialogwork

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

Rollarea

Pagingarea

Memory for specificABAP commands

Dialogwork

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

Dialogwork

process 1

Dialogwork

process 2

Paging file

Paging buffer

Roll file

Roll bufferRollarea

Pagingarea

Rollarea

Pagingarea

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

Mappin

g


111 222 333

R/3 user

444

Swap

Extendedmemory(shared)

Dialogwork

process 1

Dialogwork

process 2Rollarea

Pagingarea

Rollarea

Pagingarea

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 datafor successive frontend users

l The roll data and paging data is copied to the roll buffer andpaging buffer and the corresponding files when a userleaves the work process.

Allocation Concepts - Summary (1)

SAP AG 1999

Allocation Concepts - Summary (2)

l R/3 extended memory uses mapping instead of copyingand 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

Next Topic in Unit

l R/3 memory areas


n Concepts





è

SAP AG 1999


111 222 333

R/3 user

444

Rollarea

Pagingarea

ExtendedExtendedmemorymemory(shared)(shared)

Dialogwork

process 2

A defined initial portion ofthe roll area is used

1st :11st st ::

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

Rollarea

Pagingarea


Dialogwork

process2Extended memory is used

until ...2nd :22nd nd ::

Mappin

g


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


Dialogwork

process2

Rollarea

Pagingarea

... the extended memory is full or ...


SAP AG 1999


111 222 333

R/3 user

444


Dialogwork

process 2... until the user quota is reached

Pagingarea

Rollarea


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

Rollarea

Pagingarea


Dialogwork

process 23rd: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

Rollarea


Dialogwork

process 2

Heapmemory

The system is forcedto 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

Rollarea


Dialogwork

process 2Rollarea

Pagingarea

Dialogwork

process 1

Heapmemory

Pagingarea

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

Rollarea


Dialogwork

process 2

Dialogwork

process 1

Heapmemory(local)

PRIV mode

Rollarea

Pagingarea

Pagingarea

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

Sharedmemory

Localmemory

Roll memoryup to

ztta/roll_first

Extended memoryup to

ztta/roll_extension or EM exhausted

Roll memory:remainder ofztta/roll_area

Heap memoryup to

abap/heap_area_diaor 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 processesaims to prevent work processes from allocating R/3 heapmemory and thus entering PRIV mode.

l When a work process enters PRIV mode, it remainsconnected to the user until the user ends the transaction.

Allocation Sequence for Dialog WPs - Summary

SAP AG 1999

Next Topic in Unit

l R/3 memory areas


n Concepts





è

SAP AG 1999

Allocation Sequence for Non-Dialog WPs

Roll memoryup to

ztta/roll_first



Roll memory:Remainder ofztta/roll_area

Heap memoryup to

abap/heap_area_diaor HM exhausted

� � � �

Time

Roll memoryup to

ztta/roll_area



Heap memoryup to

abap/heap_area_nondiaor HM exhausted

� � �

Sharedmemory

Localmemory

Allocationsequence fornon-dialog WPson NT and fordialog WPs onall platforms

Allocationsequence fornon-dialogWPs on allplatformsexcept 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

Next Topic in Unit

l R/3 memory areas


n Concepts





è

SAP AG 1999

Heap memory isreleased after use


111 222 333

R/3 user

444

Swap


Workprocess 2

Rollarea

Pagingarea

Workprocess 1

Rollarea

Heapmemory{Paging

area

Freeing Heap Memory (1)

SAP AG 1999

But used swap spaceis not freed by theoperating system


111 222 333

R/3 user

444

Swap


Workprocess 2

Rollarea

Pagingarea

Workprocess 1

Rollarea

Heapmemory

Pagingarea

{


SAP AG 1999


111 222 333

R/3 user

444

Swap


Workprocess

2

Roll

Paging

Workprocess

1

Roll

Paging

When the limit set inabap/heaplimit isreached, the workprocess is flagged forautomatic 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

Mem

ory

/ sw

ap s

pace Restart

of WP 1

Parameter ABAP/HEAPLIMIT

n Operating system swap space is saved through parameter abap/heaplimit.

SAP AG 1999

Extendedmemory(shared)

DIA

em/initial_size_MB

ztta/roll_extension

abap/heap_area_dia

ztta/roll_first Rollarea

ztta/roll_area

Heapmemory

abap/heap_area_total

rdisp/roll_SHM

rdisp/roll_MAXFSRoll 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 reportZBC315_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 isavailable (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

Rollmemory Extended memory Heap memory

Memory used

Sharedmemory

Localmemory

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

Sharedmemory

Localmemory

Rollmemory

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 simplifiesR/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 untilthe 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 managementparameters – such as em/initial_size_MB, andabap/heap_area_total

See alsoR/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/3work

process

Address space (2 to 3.8 GB)

User-independent data User context

Extended memory Heap memoryR/3 buffersLocalWP

Address space restrictiondue to 32 bit architecture

em/initial_size_MB abap/heap_area_(non)dia

Sharedmemory

Localmemory

Rollmemory

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/3work

process

Address space (2 to 3.8 GB)

User-independent data User context


Address space restrictiondue to 32 bit architecture

em/initial_size_MB abap/heap_area_(non)dia

Sharedmemory

Localmemory

Rollmemory

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 backgroundprocessing

n No performance loss due to sub-optimal setup

l Note 146289: Recommendations for 64-Bit R/3 Kernel

SAP AG 1999

R/3 workprocess

Address space (approx.. 1.8 GB)

Sharedmemory

Localmemory


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 amountof extended memory per work process

n Parameter em/initial_size_MB can be very large

Rollmemory

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/3memory 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 memorymanagement

SAP AG 1999

Appendix: Menu Paths for R/3 MemoryManagement

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








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 thewhole 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 hardwarebottlenecks



è

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 (loadaverage)

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




è

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 ProcessOverview (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


Detailed analysis of hardware bottleneck



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 withextended 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

Pre

sen

tati

on

Pre

sent

atio

nA

pp

licat

ion

ser

ver

Ap

plic

atio

n s

erve

r

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

Change cost center

?? é é é é3333

Cost center

Profit from

Change cost center?? éé

éé3333

Costcenter

Profit from

Workprocess

Workprocess

Workprocess

Databaseprocess

Databaseprocess

Databaseprocess

Externalprocess

Externalprocess

Externalprocess

Workprocess

External process

Database process

Change cost center?? éé é é3333

Cost

center

Profit from

Change cost center?? éé é é3333

Costcenter

Profit from

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 creatingan 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

Databaseprocess

Work process

Pre

sen

tati

on

Pre

sent

atio

nA

pp

licat

ion

ser

ver

Ap

plic

atio

n s

erve

r

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

Change cost center

?? é é é é3333

Cost center

Profit from

Change cost center??é é

éé3333

C o s t

cen te r

Profit from

Database process

Databaseprocess

Databaseprocess

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



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 processesn Approx. 12 MB per work process

R/3 extended memoryn 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 spacen 3 x physical memoryn At least 2 GB

Workloadn Number of active usersn 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 bottleneckon 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

CPUusage

perdialog

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 theperformance 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 bottleneckproblems

SAP AG 1999

For the current recommendations, seeSAP 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 pagingin 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, seeSAP 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 SIZINGRegistration

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 andlimitations of the tool.

This application is based on the results of publicly available SAP Standard Application benchmarks and considers the dialog workloadonly. It can, therefore, only reflect the standard components of the SAP® R/3 ™ system. As sizing for an R/3 system depends heavilyon factors such as peak versus average workload, number of users, user behavior, amount of batch processing, user Customizing andreporting, 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 representslikely 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 orfor any purpose without the express permission of SAP AG. The information contained herein may change without prior notice. SAP AGmakes no warranties or representations with respect to the content hereof and specifically disclaims any implied warranties of fitness forany particular purpose.SAP AG assumes no responsibility for any errors that may appear in this program. The information contained in this application is subjectto change without notice. SAP AG reserves the right to make any such changes without obligation to notify any person of such revision orchanges. 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 Personnel Administration and Payroll Accounting

PD Personnel Planning and Development

MM Materials Management

TR Treasury

PM Plant Maintenance 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 SIZINGQuantity - Structure - Dialog

High load PhaseComp- Sub- Name of Object Number of objects creations Name of Sub-Object Average No. of Retention Period Number of Objects Creations Execution Time % of Object % of Objectonent 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 Objectcreations 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: 0000188213Project Name: BERLIN

Request Sizing from... or from...

ll AmdahlAmdahlll BullBullll CompaqCompaqll DigitalDigitalll FujitsuFujitsull Hewlett-PackardHewlett-Packardll IBMIBMll NCRNCRll SiemansSiemans --NixdorfNixdorfll SunSunll TandemTandem

ll Data GeneralData Generalll DellDellll HitachiHitachill IntergraphIntergraphll NECNECll SequentSequentll UnisysUnisys

These partners already provideWEB pages especially customized

0 5 10 15 20 23

2000

4000

6000

8000 SAPS

CPU Requirement

SAP AG 1999




7. Interfaces




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 reduceperformance 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 coursesfor the respective database platform cover:

n General database tuning, such as tuning databasebuffers, 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 coursecovers:

n Avoiding expensive SQL statementsby 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 SQLstatements

l Monitors for detecting and analyzing expensive SQLstatements

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

ApplicationServer

Database instance

ABAP program

Database interface

Databaseprocess

Database

Database buffer

n Database is busy reading manydata 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 fromdatabase buffer

èCache hit rate for other SQLstatements suffers

Expensive SQL statementsreduce performance of theentire 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



l Detailed Analysis and Tuning

è

SAP AG 1999

l What to detect:

n Reports or transactions where the database request time is a largefraction 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

Transactionprofile

SQL traceShared SQLarea

Where-usedlist

8 ST03NTransactionprofile

8 ST05

8 SE12 →Utilities →Where-used list

Learn thereport /transactionname

Learn thetable nameand theindex used

Report / transaction name or user name required

G No informationabout report name

G G Table namerequiredG Sometimes

a table isused in manydifferent places

WorkProcessOverview

8 SM50 or SM66

Learn the tablename, and thereport / trans-action name

G Criticaltransactionmust be run atthe same time

8 ST04 → Detailanalysis menu →SQL request

Learn thetable nameand theindex used

Learn thereport /transactionname

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

DBMSDBMS process

Databasebuffer

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 ofexecutions

3. Number of buffer gets per record

2. Number ofbuffer 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 ofexecutions

3. Number of buffer gets per record

2. Number ofbuffer 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

DBMSDBMS

processDatabasebuffer

Records

Database

SQL tracefile

For each SQL statement, SQL traceaudits:• 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

SharedSQLarea

Work processoverview

SQLtrace

Transactionprofile

EXPLAIN SQLstatement


Index used Index used

Table nametransaction /report name

Transaction code

Wait timeDatabase time

Table nameWHERE clause


ExpensiveSQL statement

Databasemonitor

WHERE clause

Go to TuningRoadmap


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)

ObjectivesIn this exercise, you will learn how to:

l Perform and analyze an SQL trace and an EXPLAIN

ActivitiesAfter your trainer executes report ZBC315_SELECT_ZMARA,

and creates an SQL trace for this report:l Log on to the training system

l Monitor the trace activated by your trainerl 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



l Detailed Analysis and Tuningè

SAP AG 1999

Two Types of Expensive SQL Statements

Appl.-Server

DBMS

ABAP program

Database interface

DBMSprocess

Database

Database buffer

Appl.-Server

DBMS

ABAP program

Database interface

DBMSprocess

Database

Database bufferBuffergets

Diskreads

Recordsprocessed

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 perrecord 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 complexrewrite 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 MARAFull 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 ofthe 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 tochoose 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 tablein 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

Databasetable

SELECT * FROM ADDRSELECT * FROM ADDRWHEREWHERE name =”Schneider” name =”Schneider” AND pnum = ”69126" AND pnum = ”69126" AND city = ”Heidelberg" AND city = ”Heidelberg"

Possible access pathsPossible access paths

Index A

Fulltablescan

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 statisticalinformation. For example, the cost-basedoptimizer needs to know the number ofentries in a table or index.

l Outdated table statistics may lead toincorrect optimizer decisions andinefficient table accesses.

l Schedule the periodic update of tablestatistics using the DBA planningcalendar (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 andIndex Information"screen

SELECT STATEMENT ( Estimated costs = 1)

Execution Plan

Up-to-date statistics?

Check the optimizerexecution 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 PerformanceProblems

SYSTEM

Statisticstables

To refresh the statistics, only use SAP tools

l Statistics are outdated or havethe wrong level of accuracy

l Incorrect assumptions ofcost-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 statistic s 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


SharedSQLarea

Work processoverview

SQLTrace

Transactionprofile



Index used Index used

Table nametransaction /report name

Transaction code

Wait timeDatabase time



ExpensiveSQL statement

DB ProcessMonitor

WHERE clause

Go to TuningRoadmap

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 problemscaused by expensive SQL statements

l Use the Detection Roadmaps and the Tuning Roadmap foranalyzing SQL statements

Activities:



l Use the monitors described in the Detection Roadmaps toidentify expensive SQL statements

l Use Tuning Roadmap to find solutions for the problem

l Determine which recommendationsshould 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 yie ld 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 andtrace 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 reduceperformance 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 General rules:

� 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 DatabaseProgramming

OptimizingABAP DatabaseProgramming

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%'

SELECTclause

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 theamounts 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 CHECKstatements for table fields?þ Replace the CHECK statement with an appropriate WHERE

clause

ý Do SQL statements on fields other than key fields use anappropriate 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 SQLstatements?þ 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 WHEREclauses affecting tables that are growing constantly, such asBSEG, 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: SELECTCARRID 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 theORDER 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 thedatabase perform

ý Does the program change data in dialog mode throughupdate, insert, modify, or delete?ý Ensure that the program contains a COMMIT WORK statement

after one or more Logical Units of Work (LUWs) have beencompleted


SAP AG 1999

Database Locksand 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, PIDsession A

Host, PID waitingsession 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 applicationprograms

l CALL FUNCTION 'ENQUEUE..'

l Released at the end of an R/3LUW

l Stored in main memory(enqueue table)

l Granularity: record, genericarea, may involve more thanone table

Database locks:

l 'Physical' database locks

l Applied automatically by theDBMS

l INSERT, UPDATE, DELETE,SELECT FOR UPDATE

l Released at the end of adatabase 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 useenqueues: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 canserialize 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 recordinserts/updates

w For example, pre-aggregate data to enable one update insteadof many

n For number ranges: fewer requirements cause less serialization

n For available-to-promise quantities (ATP): additional logic can helpto reduce locking times, especially over dialog steps

l For many enqueues, use bundling in a local enqueuecontainer

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








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 thedatabase 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

DatabaseManagementSystem

DBMSProcesses

DatabaseCache

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 DBMSProcesses

DatabaseBuffer

Database

SELECT * FROM T001WHERE ...

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 DBMSProcesses

DatabaseBuffer

Database

SELECT * FROM T001WHERE ...

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 buffering1 key field

Generic buffering2 key fields

Partial buffering(single record)

001001001001002002002002002002003003003003003003003003

001001001001002002002002002002002002003003003003003003003003003003003

001001001001001002002002002002002002002002002003003003003003003003003003003003003003

AA

BB

AABBBC

DC

AAABBCCCDDD

AA

BB

BAAAABBBC

DC

AAABBCCCCDDDD

42

31

513681230

53

2362423581234

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

DatabaseDatabase isup to date

Local buffer isup 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 isNOT up todate

Database isup to date

Local buffer isup 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 isinvalidated

Database isup-to-date

Local buffer isup-to-date

...

DDLOG

R/3 DBIF R/3 DBIF

SELECT DDLOG

Buffer synchronizationoccurs 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 bufferedtables:

l Single-recordbuffered tables:

Any change invalidatesthe buffered table

Changes in work areamode invalidate datawith the same genericfield keys

Changes in work areamode invalidate onebuffered 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 setthe 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): forexample, 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 programZBC315_SELECT_BUFFER:


l Display the SQL trace and the program source code.

l For each SQL statement, determine whether the data is retrieved fromthe database or from the buffer.

l If the data is retrieved from the buffer, determine whether partialbuffering or generic buffering is used.

SQL/Buffering Exercise

SAP AG 1999

l SELECT * FROM RESBWHERE RSNUM = '1234567890'AND RSPOS = '0987654321'AND RSART = 'A'AND BDART = 'XX'.

ENDSELECT.

l SELECT * FROM TITLEWHERE DDLANGUAGE = 'E'AND PROGNAME = 'RSORA000'AND DDNR = '110'.

ENDSELECT.

è Buffering of RESB: Not Buffered

Thus, conclude: Database access

è Buffering of TITLE: Partial BufferedFull primary key specifiedBUT NOT specified as

SELECT SINGLE * FROM ...


SQL/Buffering Exercise Solution (1)

SAP AG 1999

l SELECT SINGLE * FROM TCOLLWHERE RNAME = 'RSHOSTDB'.

l SELECT SINGLE * FROM T001WHERE BUKRS = '0001'.

è Buffering of TCOLL: Buffered

Thus, conclude: Buffer access; generic buffer

è Buffering of T001: Generic (1 Field)

Field MANDT is filled automaticallyThus, conclude: Generic key is specified



SAP AG 1999

l SELECT * FROM ZZBUF_SNGLWHERE FIELD_1 = '1'.

ENDSELECT.

l SELECT * FROM ZZBUF_FULLWHERE FIELD_1 = '2'.

ENDSELECT.

è Buffering of ZZBUF_SNGL: Partial Buffered Full primary key NOT specified and NOT specified as SELECT SINGLE Thus, conclude: Database access

è Buffering of ZZBUF_FULL : Full Thus, conclude: Buffer access; generic buffer


SAP AG 1999

l SELECT * FROM ZZBUF_NONEWHERE FIELD_1 = '3'.

ENDSELECT.

l SELECT * FROM ZZBUF_GEN3WHERE 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 BufferedThus, conclude: Database access

è Buffering of ZZBUF_GEN3 : Generic (3 Fields)Thus, conclude: Generic key is specifiedThus, conclude: Buffer access; generic buffer


SAP AG 1999

l SELECT * FROM ZZBUF_FULLWHERE FIELD_5 = '5'.

ENDSELECT.

l SELECT * FROM ZZBUF_GEN3 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_FULL : Full


è 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.

l SELECT * FROM ZZBUF_GEN3WHERE FIELD_1 = '8'

AND FIELD_2 = '8'AND FIELD_3 = '8'AND FIELD_5 = '8'AND FIELD_6 = '8'.

ENDSELECT.

è Buffering of ZZBUF_FULL : Full



Thus, conclude: Generic key is specified



SAP AG 1999

l SELECT * FROM ZZBUF_GEN3WHERE FIELD_1 = '9'AND FIELD_2 = '9'AND FIELD_3 = '9'AND FIELD_4 = '9'AND FIELD_6 = '9'.

ENDSELECT.

l SELECT * FROM ZZBUF_GEN3 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 applicationserver 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 arelarge 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, salesdocuments 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 intable MARA

n Reason: These tables are normally too large and are oftenaccessed by secondary indexes (not possible through R/3table buffers)

l Customizing data is normally buffered

n Examples: company codes in table T001, exchange rates intable 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, textdetermination, 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 numberranging:

n From 000 to 499; indicates that the table is part of the SAPstandard 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 tableis 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 Customisingtables, 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 Statistic s 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]. For the tables at the top of the list, consider the buffering rules and decide whether these tables should be unbuffered.

n 5) Sort the list by column Rows affected under DB activity. For the tables at the top of the list, consider the buffering rules and decide whether these tables should be unbuffered.

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 TableAccording 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 rowsRequested bytes per row: 58 bytes per rowRequested bytes to be buffered 100%: 4,693,012 bytesCurrent buffering mode: 100% buffering

Distribution between clients: Client 400 80,889 rowsClient 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 perGeneric Key

DistinctValues

1 to10

11 to100

101 to1000

1001 to10000

>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 criticaltransactions

l As a rule, tables can be buffered if the table buffers haveenough free space and if the tables are:

w Small

w Frequently accessed

w Rarely changed

w Not time-critical (inconsistencies between application serverbuffers 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 inthe logistics supply chain (for example, SD, PP, and MM)

l Tables affected:

n Tables read:Table RESB: Material reservations per production order itemTable VBBE: Material requirements per sales document itemOther 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 manychecks are performedsimultaneously

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/3Rel.

Description Advantage

Locking withquantit ies

≥ 2.2 Shorter material locks Less mater ia l b locking àHigh transact ion volume

ATP server ≥ 4.0 Central ATP check forone R/3 System

Reduced load on databasetables RESB and VBBE

APO* server ≥ 4.5 Global ATP check formult ip le R/3 Systemsand legacy systems

Global , company wide ATPinformation

*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/3Release 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 andactivate the flag Block QtRq for each checking group asrequired

l Advantages:

n Short exclusive R/3 enqueues

n Attempts to set R/3 enqueues have less likelihood of beingrejected. This also means less database load and less CPUload.

l Further Information:

n Empowering Workshop: EWC10 Technical Optimization ofAvailability 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 (sumVBBE records) and reservations (sum RESB records) perplant, 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 theenqueue 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 = 20000rsdb/obj/max_objects = 20000

n Two buffer entries are required for each material and plant in theATP 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 bufferentry:

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

DIADIA

Gateway

R/3 instance 2

Dispatcher

DIADIA

1

2

ENQ table

Export /import buffer Gateway

RFC

3

Database

RESBVBBE

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

MaterialPlantRE/VB = RESB/VBBEClient

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 aproblem

Monitoring R/3 Enqueues

Man User Time Shared Table Lock Argument001 WÄCHTLERH 10:07:57 X ATPENQ 001TEST 001000000080830000WPF001 WÄCHTLERH 10:07:57 AUFK 001000000787121001 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" = :A3GROUP 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








SAP AG 1999

Contentsl User interfaces and system interfaces

l Monitoring RFC callsl Controls technology and GUI communication

l Communication between systems and RFC configurationl Exercise: Monitoring RFC Load

ObjectivesAt 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.6l 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 processedin 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 forWindows orJava

SAP GUI forWindows orJava

CRMServerServer

MobileClientsMobileClients

mySAP.com Workplace

Work-place

Server

RFC

DIAGor RFC

SAP GUIfor HTMLSAP GUIfor HTML Web

Server

HTTP

SAP BW

SAP APO

Legacy System

SAP R/3

SAP R/3

WarehouseSystem

File Interface(Batch input,Fast input)

PrinterInterface

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 SAPSystem 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

PresentationServer

ApplicationServer

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 timeRollout from work process

GUI displays result

Net

wor

kN

etw

ork

Net

wor

kN

etw

ork

SAP AG 1999

PresentationServer

ApplicationServer

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

PresentationServer

ApplicationServer

Database Server

Net

wor

kN

etw

ork

Net

wor

kN

etw

ork

RFC + CPICtime

RFC end

Program rolls outafter 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 recordwith RFCprocessing; Seemultiple rollprocesses,RFC+CPIC timeand 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 functionmodule 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




Next Topic in Unit

SAP AG 1999

R/3 Release 4.6: Enjoy SAP

l In the Enjoy SAP initiative, SAPdemonstrated its commitment toproducing easy-to-learn, easy-to-use software. The innovativenessof 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 haveimplications for performance andsizing

SAP AG 1999

Interaction Model: Controls Technology

Tree Control

Text-EditControl

List Box

l Controls technologyprovides applicationprogrammers with ameans ofincorporating morecomplex screenelements calledcontrols.

l The new elements aresoftware componentswith their ownindependentfunctions on the GUI.

l For example,scrolling, navigating,or searching nolonger need toconnect to theapplication 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 alist) requires its own dialog step

l New interaction model

n Functions scrolling, navigating, or searching nolonger 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

PresentationServer

ApplicationServer

Database Server

Transaction Step with Roundtrip

Processing time (1)

Wait, Roll in & Load time

Processing time (3)

Response time

PresentationServer

ApplicationServer

Database Server

Net

wor

kN

etw

ork

Net

wor

kN

etw

ork

Database time

Processing time (2)

GUI time

Time spent fornetwork transfer

Roundtrip to GUI starts

Time spent for buildingup the screen in the GUI

Rollwaittime

Program rolls out afterRFC 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 (I): ST03 - High Roll Wait Time

High roll wait timemay indicate high

GUI times

SAP AG 1999

Example (II): STAD - Statistical Record

Frontend data areshown in transactionSTAD 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 thetree control

Function module to set GUI process indicator instatus 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 transferand time spent in the GUI, so:

w Try to identify network problems with function LAN Check by Ping intransaction 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 forcomplex screens

n Possible reason for a high number of roundtrips :

w Program or program usage error (send a message to thedevelopers)

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 iconon your desktop to switchon/off new design.

There are no functionalchanges when changing tothe 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 "SAPpc\sapgui\". 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 ALVcontrols.

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 changeswhen changing to lowspeed 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 CodeSESSION_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




Next Topic in Unit

SAP AG 1999

Remote Function Calls (RFC and aRFC)

l Synchronous RFC

n Sender program sendsRFC waits for response(rolled out) and proceedswith processing afterRFC returns

l Asynchronous RFC(aRFC)

n Sender program sendsmultiple RFCs in parallelwithout waiting forresponse.

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

Onlinerequests

RFCrequests

Online requestsmay be blocked ifRFC requests arenot 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 processesused for RFC processing

n The R/3 instance profile parameters for configuring aRFCresource 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 communicationbetween systems

l Use transaction SM58 for error analysis

R/3 System 1 R/3 System 2

tRFC

Reports SAPLARFCSAPLERFC

Reports SAPLARFCSAPLERFC

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




Next Topic in Unit

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








SAP AG 1999


l Analyze the workload distributionin an R/3 System

l Find critical performance bottlenecks

l Tune R/3 Basis and database components

l Find poorly written ABAP programsthat 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 areaSystem Monitoring

l Literature:

n German: SAP R/3 Performanceoptimierung, ThomasSchneider, 1999 Addison-Wesley-Longman

n English: SAP R/3 Performance Optimization, ThomasSchneider, 1999 Sybex

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 hardware bottlenecks



Load time > 50 ms

Detailed analysis of R/3 memory configuration (is the program buffertoo 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)

!

?

?

?

?

?




� Hardware bottlenecks, see the unit Hardware Capacity Verification

� Interfaces and GUI problems, see the unit Interface Monitoring

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

Analysis Roadmap: Using the Work ProcessOverview (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 indestination 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

Analysis Roadmap: Using the Work ProcessOverview (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 SystemMonitor (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 ProcessOverview (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 SystemMonitor (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. For the tables at the top of the list, consider the buffering rules and decide whether these tables should be unbuffered.

3) Choose Next view and sort the list by Buffer size [bytes]. For the tables at the top of the list, consider the buffering rules and decide whether these tables should be unbuffered.

4) Sort the list by column Rows affected under DB activity. For the tables at the top of the list, consider the buffering rules and decide whether these tables should be unbuffered.

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 Optimizationof ALE Processing

Technical Backgroundof ALE

Analysis Tools andOptimization Methods

Analysis Flow Chart

Section: Technical Optimization of ALE Processing

SAP AG 1999

Technical Optimization of ALE Processing




Analysis Flow Chart

SAP AG 1999

1.

2.

Goals

Understand how ALE technically works

Learn how to optimize the performanceof the ALE functionality in order to achieve:

Maximum throughputMinimum impact on dialog usersMaximum 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 SystemLogical SystemLogical System

Material Number

Material Number

5 blue shirts $150.005 ties 100.00 250.0010% 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 storagemanagement 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)

Distribution of

Distribution of

PO Contracts

PO Contracts

Warehouse ManagementWarehouse Management System System

Goods Issues

(Receipts)

Goods Issues

(Receipts)Call O

ff Stati

stics

Call Off S

tatistics

by PO

by PO Distribution of Distribution of

PO ContractsPO ContractsCallCallOffOff

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

Technical Background of ALE




Analysis Flow Chart

SAP AG 1999

Sender

Application

IDOCDB

The application creates an

IDOC

IDOCIDOCDBDB

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

IDOCIDOCDBDB

The IDOC issent via the

network

IDOC IDOCIDOCDBDB

ReceiverReceiver

ApplicationApplicationApplicationApplication


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

IDOCDB

Application datais then created from the IDOCs Application

SenderSender

IDOCIDOCDBDB



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

IDOCDB

The application createsThe application createsIDOCIDOC’s’s directly directly

2.

The applicationThe applicationcreates change pointerscreates change pointersfor deferred processingfor deferred processing

1.

The applicationThe applicationcreates a message entrycreates a message entryfor 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

IDOCIDOCDBDB

BDCPBDCP

RBDMIDOCRBDMIDOC

1.Change pointers Change pointers for Master Data for 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

IDOCDB

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

IDOCDB

NAST

Control Data Control Data written directlywritten directlyto 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

IDOCDB

TRFC QueueTRFC Queue

Receiver

IDOCDB


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

IDOCDB

TapeTape

Receiver

IDOCDB


INBOUND_IDOC_PROCESSINBOUND_IDOC_PROCESS1. 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

IDOCDB

ApplicationTRFC QueueTRFC Queue

Set statusSet statuserrorerror

Schedule Schedule batch job batch job for retryfor retry

CommunicationCommunicationerrorerror

TRFC CallTRFC Call

IDOCDB

YY

NN

Done,Done,IDOC will remain IDOC 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

IDOCIDOCDBDB

RSEOUT00RSEOUT00

SequentialSequentialFileFile

IDOCDB


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

SequentialSequentialFileFile IDOC

DB


SenderSender

IDOCIDOCDBDB 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

IDOCDB


Receiver

External systemR/3 system

ExternalExternalprogramprogram

RegisteredRegistered

SAP GatewaySAP Gatewayprocessprocess

NoNo

YesYesSend 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

ExternalExternalprogramprogram

Sender


Receiver

External system R/3 system

SAP GatewaySAP Gatewayprocessprocess

LogonLogonto 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

IDOCDB

1. 2.

Call Transaction Call Transaction using...using...

ApplicationApplicationupdate 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

ProcessingProcessingModeMode

DispatchDispatchControlControl

Unit Unit TransferTransferTypeType

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

IDOCDB

Send IDOC packetsSend IDOC packetsUnitUnittransfertransfer

typetype

DispatchDispatchmodemode

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

ProcessingProcessingModeMode


Unit Unit ProcessingProcessingTypeType

ReceiverReceiver

Single IDOCs

Single IDOCs

determinedby Sender

IDOCPackets

IDOCPackets

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

IDOCDB

ScheduledScheduled

Unit Unit ProcessingProcessing

TypeTypeProcessingProcessing

modemode



ImmediateImmediate

UpdateUpdate

UpdateUpdate

UpdateUpdate

Parallel Parallel updatesupdates

RBDAPP01RBDAPP01

NetNetSingle IDOCsSingle IDOCs

Sequential Sequential ProcessingProcessing

IDOC IDOC 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-Queue1) Dispatcher queue: usage rdisp /rfc_max_queue %and 2) At least rdisp/rfc_max_own_used_wp free dialog work processesand

3) At most rdisp/rfc_max_login % of allowed loginsand

UseUsequotas?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 current Contains current status link to the status link to the datadata

Contains one Contains one status record perstatus record perstatus 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

Datarecords

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 definit ion 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 ModelPartner Profile

Communication Control (SM59)

Logon User-ID definitionRFC server groupsTRFC 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 processingRBDAPP01 ALE inbound processingRSNAST00 IDOC creation via message determinationRBDMIDOC Creation of IDOCs from change pointersRSARFCEX (Re)Processing of failed/not executed

TRFCsRBDMANIN Reprocessing of failed inbound IDOCsRBDMOIND IDOC status update from TRFC queueRBDCPCLR Reorganization of change pointer tableRSARFC01 Reorganization of the TRFC queueRBDAUD02 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

IDOCDB

ArchiverArchiverTapeTape

WorkflowWorkflowitemsitems

Receiver

IDOCDB

Application

WorkflowWorkflowitemsitems

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

Analysis Tools and Optimization Methods




Analysis Flow Chart

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 transfertimes vary widely, looktimes vary widely, lookat 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 9B38C83F259035289FAD0005 9B38C83F259035289FAD0005 hs5094 bd21 RBDMIDOC 810 0000 hs5094 bd21 RBDMIDOC 810 0000

Host TCTN Program Host TCTN Program ClientClient Repeats Transaction ID Repeats 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 SALE → Modelling and Implementing Business Processes → Partner Profiles and Time of 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) SALE → Modelling and Implementing Business Processes → Partner Profiles and Time of Processing → Generate Partner profiles TCODE=BD82→ inbound parameters

� When Partner profiles are already existing SALE → Modelling and Implementing Business Processes → Partner Profiles and Time of 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 ModeTransfer limit sizeTransfer limit size

RFC load RFC 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 ofretried 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 TRFCcommunication errors and schedule RSARFCEX instead

Schedule mass transfer/updates when there is lowdialog activity (sender and receiver). Spread outevenly 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 ALEAnalysis Flow Chart




Analysis Flow Chart

SAP AG 1999

Performance Problemswith ALE

Performance Performance ProblemsProblemswith ALEwith ALE

Application Data does not arrive

Application Data Application Data does not arrivedoes not arrive

Application Dataarrive too slow

(throughput problem)

Application DataApplication Dataarrive too slowarrive too slow

(throughput problem)(throughput problem)

Dialog workis disturbedDialog workDialog workis disturbedis disturbed

111

222

Application Dataarrive too late

(realtime problem)

Application DataApplication Dataarrive 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 / BALEInfo

Is ALE used?

Kind ofproblem

Do not tuneALE

Yes

App.datadoes notarrive

No

Ask sufferingpeople

Use subchart

1

Use subchart

2

App.dataarrivestoo slow

App.dataarrivestoo late

Use subchart

3

Use subchart

4

Dialog workis 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 datamsg. Type?

no

yes

Check change pointer activation+ RBDAPP01 run

Messagingused?

no

ImmediateNAST processing

or RSNAST00 ran?

yesCheck for DB erroron IDOC creation

(e.g. tablespace full,max extents reached)

yes

Change messagingoption or schedule

RSNAST00no

Msg.type =BLAORD,

BLAOCH,...

Customizingfor messagingcondition 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?

Usesubchart

1.2

BALE:IDOC overview+ SM58 (TRFC)

sent

error Receiver isext. program?

yes

Check RFC address +

login info

Receiver temp.unreachable? yes

Start receiverand retry

Ext. programregistered?

Check if ext. prog.Can be started,Check gateway

Check if ext.progrunning or busyyes

no

SM59test 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

ALEcustomizing

Receiver IDOCstatus?

BALEIDOC overview

ALEerror

received Immediateprocessing?

yes

Check RBDAPP01scheduling

RBDAPP01 ran?

Check SM13, SM21

Check customizingdue 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 datamsg. type?

ALEcustomizing

Use subchart

2.1

no

yes

RBDMIDOCperiod too

long?

no

Messagingused?

Msg.type =BLAORD,

BLAOCH,...

Reduce period or use event (user exit),

check batch resources

yes

SM37

yes Immediate msgor RSNAST00schedule ok?

ALEcustomizing,

SM37

no

Immediate sendor RSEOUT00schedule ok?

ALEcustomizing,

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 WPbottleneck?

no

no

SM59RFC dest.

Sender WPbottleneck?

Networkconnection

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 userprofiles

yes

Increase Receiver DIA WPs

Use subchart2.3 or 4.2

***

no

Checkhardware

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

Networkconnection

slow?

Ext. programregistered?

SM59

Register ext.program

to avoid startup

yesExt. program

running multiply?

yes

Increaseparallelismno

SM59, SMGW

Ext. programcan run inparallel?

Checkhardware

OSProcess

list

no

yes

Optimizeext. programno

Registerext. program

multiple times

yesAsk vendoror 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

Immediateprocessing used?

Switch toimmediate

update

noRBDAPP01period ok? yes

ALEcustomizing SM37

no

Reduce period

Check RFC resource params,Analyze receiver

application

RBDAPP01params ok?

Packet size,RFC server group,parallel execution

yes

Correctparametersno


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+

scheduleRSEOUT00

Increasepacket size

no

Sender isext. program?

no

yes

Logon onceand stay

connected

Use subchart

2.1

ALEcustomizing

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 atwhich side?

Sender Receiver

Ask sufferingpeople

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

ImmediateSend ?

ALECustomizing

Packet size< 100 ?

Increasepacket size

build packets+ schedule

RSEOUT00 atnon-peak time

Fromsubchart

4

Add DIA WPs,setup dedicated

ALE senderinstance / server,

use RFC server group

yesyes

no no RFC resourceparams set?

yes

no

Check RFCresource params

RFCCustomizing

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

ALECustomizing

Increasepacket size

Fromsubchart

4RFC

Customizing

Packet size< 30 ?

ImmediateUpdate ?

RFC resourceparams set?

build packets+ schedule

RBDAPP01 atnon-peak time

yes

Add DIA WPsor setup

dedicatedALE sender

instance / server

no no no

yes yes

Check RFCresource 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 SAP system id

Message type


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 hostname, instance, client

Message type

RFC destination


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 SAP system id

Message type


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 each user. It can be reorganized form there via: SM58→Execute, Log File→Reorganize The user DDIC can also delete any entries.

Education

Basis week5