The SAP Transaction Model: Know Your Applications

Transcription

1 The SAP Transaction Model: Know Your Applications SYSTEMATIC THOUGHT LEADERSHIP FOR INNOVATIVE BUSINESS Shel Finkelstein, Rainer Brendle, Dean Jacobs, Manfred Hirsch and Ulrich Marquard SAP Labs

2 Outline SAP Applications and Data Examples, Requirements, Properties SAP Data Management Architecture Application Architecture Database Execution Model SAP Scalability and Performance Application Scalability Benchmarks SAP ACM SIGMOD Conference, June,

3 SAP Applications and Data SAP ACM SIGMOD Conference, June,

4 SAP Customer Application Requirements SAP ERP - HCM Payroll calculation for 500,000 employees and retirees in 4 hours SAP NetWeaver Portal 100,000 concurrent users SAP for Utilities 25 million business partners 85 million service and sales orders per year SAP ERP On a laptop SAP NetWeaver BI Currently productive: 10 TB database (planned 60 TB) SAP for Retail 1.3+ million sales order items per day SAP SCM 4.5 million characteristic combinations & 256 GB memory in live cache SAP for Consumer Products concurrently active users SAP ACM SIGMOD Conference, June,

5 Solution Areas and Data Access Order Processing Enter order with line items; schedule delivery; handle changes Read mostly; most updates are inserts; most updates don t conflict Supply Chain Management (SCM) Planning for procurement, sales and demand, production, distribution; control and management Read mostly, most updates are inserts; most updates don t conflict Business processes handle impacts of updates Integrated Product and Process Engineering (IPPE) Master data that provide high integration of engineering processes and manufacturing processes Read mostly; most updates don t conflict Collaboration, but changes usually involve independent subtrees SAP ACM SIGMOD Conference, June,

6 Data Access Patterns for Applications Applications may be conversational, with multiple conversational user interaction steps in a transaction Most business data is read-only Update operations are insert-mostly Most database transactions are short For all updates, conflicts are rare in practice Potential hotspots (e.g., inventory stock; sequence numbers that must be consecutive for legal reasons) must be addressed SAP ACM SIGMOD Conference, June,

7 Data Management Principles Technical: Maintain integrity of Business Data across apps Multiple solution areas use the same Business Objects Legal: Handle most updates as inserts of new data Support for Governance, Risk and Compliance (GRC) and auditing Operational: Run on multiple DBMS products Don t depend on special properties of any DBMS DB must not be a bottleneck Programming Model: Message-based consistency Like normalization and serializability, transactions should only be used where appropriate Use transactions within a deployment unit; avoid distributed commit across deployment units SAP ACM SIGMOD Conference, June,

8 SAP Data Management Architecture SAP ACM SIGMOD Conference, June,

9 Basic Application Server Architecture User User User User User User Application Server Gateway Shared Memory and Buffers Dialog Handler Dialog Handler Dispatcher Dialog Handler Dialog Handler Database SAP ACM SIGMOD Conference, June,

10 Two-Stage Execution Model Dialog Stage COMMIT WORK Update Stage Screen Screen Screen Read from database Acquire locks Queue descriptors of update operations No writes Rollback possible Perform update operations in deadlockfree order Single message database transaction No rollbacks Release locks upon completion Rediscovered in H-Store, where it is used to eliminate the undo log SAP ACM SIGMOD Conference, June,

11 Lock Manager The Problem Many applications have multiple screens with long user think times Maintaining open database connections would hurt performance Implicit Pessimistic and Optimistic Concurrency Control have disadvantages E.g., scalability; rollback after user completes work The Solution A business-level logical lock manager (Enqueue Manager) outside the database Business-level locking is very flexible approach No danger of lock escalation or index locking in the database Locks are explicitly requested; a contract between applications, using framework Lock types: shared, intention, exclusive Rather than getting blocked, applications get errors that they can handle Can request that individual locks be held after commit SAP ACM SIGMOD Conference, June,

12 Steps in Two-Stage Execution User User User Application Server 1 Dialog Handler Dispatcher 2 Dialog Handler 5 3 Gateway Shared Memory 4 1 Message Server 6 Dialog Handler Dispatcher Lock Manager Lock Table Application Server 2 Database SAP ACM SIGMOD Conference, June,

13 Asynchronous Updates The packaging of rollback-free queued updates into a bundle allows them to be executed after the transaction completes (write behind) Doing so allows the user to continue on to other work sooner The locks are released after the updates have been performed so subsequent write operations never get stale data Appropriate when subsequent operations go on to other work, so they never read stale data The updates are performed by an Update Handler, which reduces the number of handlers that do writes The updates from several transactions may be delayed indefinitely until a coordinator picks them up and performs them all together Example: A background process that updates statistical data SAP ACM SIGMOD Conference, June,

14 Three-Stage Execution Model SAVE COMMIT WORK DB COMMIT Dialog Stage Update Stage Write Stage Screen Screen Screen Screen Read from database Acquire logical locks No writes Rollback possible Write descriptors of update operations to the database No rollbacks Read update operations from database and perform them in deadlock-free order Single message database transaction No rollbacks Release locks upon completion SAP ACM SIGMOD Conference, June,

15 Steps in Three-Stage Execution User User User Application Server 1 Dialog Handler Dispatcher Dialog Handler 2 3 Message Server Application data Update Handler Database Manager Dispatcher 5 Update Handler 7 Lock Manager Data to be updated Gateway Lock Table Application Server 2 Database SAP ACM SIGMOD Conference, June,

16 Comparison of the Models Two-Stage Updates always visible immediately after transaction completes Lower database load for single transaction Synchronous execution of updates helps to build process chains Three-Stage User can continue sooner, since return to user as soon as update descriptor is in DB Lower database load when multiple transactions are boxcarred together Shorter locking times and/or log for sequence number assignment and other hotspot operations SAP ACM SIGMOD Conference, June,

17 What Does SAP Use Database For? Store/Retrieve data Transaction commit Internal locks are held very briefly Canonical ordering of locked resources avoids deadlocks Rollbacks for internal DB reasons only (can retry) Operational utilities, including disaster recovery Indexing Internal indexes But external indexes are maintained in main memory, kept consistent by postcommit processing SAP ACM SIGMOD Conference, June,

18 Hot Spots: Sequence Numbers Many ERP and Financial applications require that sequence numbers be assigned to transactions or documents Number allocation requirements depend on legal requirements Weaker requirements permit implementations that scale better Strictest guarantee: chronological assignment with no gaps Number assignment must occur inside the transaction and be rolled back in case of abort Forces serialized access to the next available number, which reduces concurrency Essential to hold the (database) lock for as short a time as possible Two-stage model: lock held during updates and writes Three-stage model: lock held during updates but not writes Weaker guarantee: Gaps must be logged for auditing Three-stage model: pending updates provide a log SAP ACM SIGMOD Conference, June,

19 Hot Spots: Aggregates Applications often must update shared aggregate data, as well as exclusive data Order Processing focuses on a specific Order Processing an Order also affects aggregate data Total expense for Contract associated with that Order Stock remaining for Products sold in that Order Transaction execution strategy is designed for scalability Acquire exclusive logical lock on specific Order After Commit, perform updates on Order After Commit, perform (commutative) delta update on aggregate data SAP also can perform merge update, e.g., for collaborative applications such as Integrated Product and Process Engineering SAP ACM SIGMOD Conference, June,

20 Reviewing SAP Transaction Execution Stages During transaction Logically lock data that needs to be changed Read Business Data into an application context Before commit, perform updates only on the application context After commit Stage 1: Application does logical consistency checks, then queues update descriptor Due to logical locks, there can be no conflicts with concurrent transactions Stage 2: Transaction s queued update descriptor is written to DB in single message transaction (with boxcarring) Return to user after its single message transaction completes Stage 3: Updates to Business Data in DB are performed Updates are executed in canonical order to avoid deadlocks Delta updates to aggregated executed last, with coarsest aggregations executed last of all SAP ACM SIGMOD Conference, June,

21 Scalability and Performance SAP ACM SIGMOD Conference, June,

22 What Exactly Is Good Performance? Performance typically defined by two metrics Response time - speed of task completion (latency) System throughput - amount of work done in a given amount of time ResponseTime t[1] Good performance if metrics match customer needs or Service Level Agreements Most important Key Performance Indicators (KPIs) CPU time consumed Peak memory used Disk space Network load Proven and predictable scalability Precondition for translating business requirements into hardware configurations (sizing) with linear growth Minimize load on central resources (e.g., DB) No system wait times, no bottlenecks Web Server(s) Application Server Application Server(s) Database ResponseTime = t[i] SAP ACM SIGMOD Conference, June, t[2] t[3] t[4] t[5] t[6] t[i]

23 Vertical & Horizontal Scalability (Cross-Tier Scaling and ScaleOut) From one tier (laptop demo) to multi-tier systems Presentation More than 150K very active users (fat transactions) Internet More than tens of thousands of hits /sec 10 servers at one of our largest customers Application and Integration Over 150 app servers connected to DB Database More than 100 CPUs; more than 10 TB DB size Scalability through SMP database server Scalability through parallel partitioned databases SAP ACM SIGMOD Conference, June,

24 Architecture of SAP Solutions User User HTTP HTTP, SOAP SAP Web Dispatcher HTTP Dispatcher HTTP Dispatcher Application Server ABAP ABAP Dispatcher Application Server ABAP ABAP Dispatcher RFC Shared memory & buffers Work process Shared memory & buffers Work process RFC Enqueue Services (Logical Locks) Message Services Central Services DBMS DB WP DB WP I/O sub system SAP 24

25 Simulation of User Interaction Load The Sales and Distribution (SD)benchmark is the most common SAP benchmark Core business process (selling, shipping, delivery) High scalability demands from customers Focuses on CPU utilization Easy to install Easy to use "Well understood and accepted" Highly credible and influential high-end OLTP business application benchmark Certified benchmarks run since 1995 SAP ACM SIGMOD Conference, June,

26 User Interaction Steps SAP SD Standard Application Benchmark 0. Logon 10. Choose customer order 1. Main screen 11. Change delivery info for order 2. Create customer order 12. Posts goods issue (schedule delivery) 3. Enter order info 13. List orders 4. Enter details for 5 items 14. Choose set of orders 5. Save 15. Create invoice 6. Create a delivery 16. Save 7. Enter delivery info 17. End 8. Save 18. Confirm logoff 9. Display customer order Steps 2 to 16 are repeated n times; each 15 step run takes at least 150 seconds due to 10 second think time between steps. Business aspect: One run (steps 2 to 16) corresponds to the selling of 5 line items. SAP ACM SIGMOD Conference, June,

27 Proven Scalability Using SD Benchmarks 35,000 30,000 25,000 SD Benchmark, Two-Tier Internet Architecture: Scale with Hardware Number of SD Benchmark users , , ,400 20,000 20,000 21,000 15,000 13,000 10,000 5, ,800 8,000 3,000 1,410 1,708 4, SAP ACM SIGMOD Conference, June,

28 Key Figures for the 168,300 User Three-Tier SD Benchmark (2005) 8,392 DB transactions per second (commits) 323 MB written to disk per second on average 611 GB data written in one hour (~ 170 MB per second on average) 1,157,000 network packets per second on average, with packet size of 512 bytes 469,091 SQL statements per second 2,240 GB database disk space 5,632 SAP (as opposed to DB) transactions / second 14,081 Screen changes / second Database used a 32-processors SMP server R/3 was running on 712 processors 16,896,670 fully business processed order line items per hour ( 4,694 per second ) SAP ACM SIGMOD Conference, June,

29 Conclusion Data and transaction management should be based on applications and their data utilization Traditional DBMS are not ideally suited for this SAP has had its own external data and transaction layer since 1985 This works; DB hasn t been a bottleneck for us Get the programming model right for your apps Explicit locking for applications, based on framework Use distributed commit only within a deployment unit Across deployment units, use message/process-based (loose) consistency Know your applications One size hasn t fit all, for SAP, for other companies, and for our customers SAP ACM SIGMOD Conference, June,

30 Further Information Public References SAP Standard Application Benchmarks SAP Standard Benchmark Certification Rudiger Buck-Emden, The SAP R/3 System: A Client/Server Technology, Addison-Wesley, 1996 Horst Keller, The Official ABAP Reference, SAP Press, 2005 Gerhard Knolmayer, Supply Chain Management Based on SAP Systems: Processes and Architecture, Springer, 2002 Burkhard Neidecker-Lutz, Frying your infrastructure: Are transactions really useful in a distributed realtime enterprise system?, HPTS 2005 [H-Store] Mike Stonebraker, The End of an Architectural Era (It's Time for a Complete Rewrite), VLDB 2007 SAP ACM SIGMOD Conference, June,

31 Further Information SAP Service Marketplace (SAP customers) SAP ACM SIGMOD Conference, June,

32 Copyright 2008 SAP AG All rights reserved No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP, R/3, xapps, xapp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte können Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind. SAP, R/3, xapps, xapp, SAP NetWeaver, Duet, SAP Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwähnte SAP-Produkte und Services sowie die dazugehörigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Ländern weltweit. Alle anderen in diesem Dokument erwähnten Namen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte können länderspezifische Unterschiede aufweisen. Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderen Vereinbarung mit SAP. Dieses Dokument enthält nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP -Produkts und ist für SAP nicht bindend, einen bestimmten Geschäftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP übernimmt keine Verantwortung für Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht die Richtigkeit oder Vollständigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewähr, weder ausdrücklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschließlich, hinsichtlich der Gewährleistung der Marktgängigkeit und der Eignung für einen bestimmten Zweck sowie für die Gewährleistung der Nichtverletzung geltenden Rechts. SAP übernimmt keine Haftung für Schäden jeglicher Art, einschließlich und ohne Einschränkung für direkte, spezielle, indirekte oder Folgeschäden im Zusammenhang mit der Verwendung dieser Unterlagen. Diese Einschränkung gilt nicht bei Vorsatz oder grober Fahrlässigkeit. Die gesetzliche Haftung bei Personenschäden oder die Produkthaftung bleibt unberührt. Die Informationen, auf die Sie möglicherweise über die in diesem Material enthaltenen Hotlinks zugreifen, unterliegen nicht dem Einfluss von SAP, und SAP unterstützt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewährleistungen oder Zusagen über Internetseiten Dritter ab. Alle Rechte vorbehalten. SAP ACM SIGMOD Conference, June,

33 The SAP Transaction Model: Know Your Applications Shel Finkelstein, Rainer Brendle, Dean Jacobs, Manfred Hirsch and Ulrich Marquard SAP Labs SAP ACM SIGMOD Conference, June,

34 SAP ACM SIGMOD Conference, June,