Presentation . . . presen tation serv ers: con trol GUI LAN - PDF document

Arc hitecture and Database In terfaces Donald Kossmann Outline 1. SAP's Clien t-serv er Arc hitecture 2. Ov erview of the SAP Sc hema 3. T ransaction Pro cessing 4. Benc hmarks and Results 2 SAP's Three-Tier Clien t-Serv er Arc hitecture Presentation . . . presen tation serv ers: con trol GUI LAN or WAN carry out ABAP application serv ers: programs and DynPros appl. appl. . . . server server stores all the data (including RDBMS: LAN ABAP programs, DynPros, data dic- tionary , etc.) RDBMS 3

Adv an tages of Three-Tier Arc hitectures 1. Scalabilit y . Add mac hines in middle tier to supp ort more users 2. It is p ossible to use di�eren t platforms at all lev els. P ortabilit y . 3. In terop erabilit y and op enness. Middlew are serv es as platform to in tegrate and in teract with third-part y pro ducts. 4. Nice GUIs. Presen tation serv ers can in teract with Microsoft W ord, Excel, etc. 4 Services Transaction Server Internet Server server Web appl. WWW Internet RDBMS LAN LAN . . . Internet tegrating clients local clients server appl. In 5

SAP R/3 Con�gurations tin y: 1 user all three la y ers on one mac hine � one of the SAP founder's golf club is run b y R/3 on a laptop � ab out 10 users small: PCs for presen tation � application and database serv er on one (mid-range) mac hine � Ethernet � 6 Serious SAP R/3 Con�gurations ab out 100 users medium: PCs, noteb o oks, other w orkstations for presen tation � a couple of mac hines for application serv ers; � one (fairly big) database serv er mac hine; � Ethernet for lo cal PCs; � more than 1000 users big: PCs, noteb o oks, other w orkstations for presen tation; � sev eral mac hines for application serv ers; � a mainframe/m ulti-pro cessor mac hine for the database � FDDI � 7

8 Supp orted Platforms � � � Presen tation La y er sensors) ISDN, standb usually Windo ws 3.1, Windo ws 95, Windo ws NT � y D , Ja v a � installations are A database TEX-P OSF/Motif also � Additional v OS/2 , � ery serv and ha Macin tosh common er � sp v e mac ecial separate in the long run, only Windo ws and Ja v a � hine are going to b e supp orted links Gimmic is mac to recommended Op erating Systems for Application tec hines Serv ers hnical ks for AIX, Digital Unix, HP-UX, SINIX, � subsystems tests SOLARIS Windo ws NT � OS/100 (for IBM AS/400) � (e.g., 9

AS/400, for old HP for for Digital, NT mainframes) ort DB2 cols ws supp Windo er, SUN, Proto Serv only Systems IBM OS/390 platforms Online SNI, er for Common unication Serv D: installations) AS/400 y S/390 (for man IBM, ABAS Informix SQL TCP/IP for are 6.2 Database Oracle UNIX , y Bull, DB2 DB2 IBM IBM (AD man Hardw Comm MS LU � � � � � � � � � � � 10 Ov erview of the SAP Sc hema R/3 has more than 10,000 pre-de�ned tables (V ersion 3.x) � { tables for data suc h as customers, orders, etc. { tables for statistics (monitoring the system) tables for authorization { ... { comprehensiv e, generic sc hema for an y kind of conceiv able { business rather than greatest common denominator fully normalized, (almost) no redundancy � go o d for OL TP { bad for OLAP (as w e will see) { users can also de�ne their o wn tables � 11

( ) three di�eren t kinds of SAP tables � transparen t: mapp ed 1:1 to RDBMS tables mapp ed n:1 to RDBMS tables p o ol: motiv ation: in the 80s, some RDBMS pro ducts limited the total n um b er of tables mapp ed n:1 to RDBMS tables so that related tuples of cluster: sev eral cluster tables are stored in one ro w of the RDBMS table motiv ation: sometimes go o d during transaction pro cessing T rend: mak e all tables transparen t 12 Examples 1. All c omments and descriptions need to b e stored in separate tables in order to k eep information in di�eren t languages: part(id , . . . ) , . . . , commen t) part(id ) commen t(partid, language , commen t) Actually , SAP tables come with names suc h as K ONV, STXL, N.B.: VBAP, VBEP, etc. Keys span sev eral attributes (including business unit , etc.) 13

2. Generic w a y of dealing with pricing terms (customizable): lineitem(id , . . . , pricing term id ) lineitem(id , . . . , tax, discoun t) ) pricing terms(id, condition , amoun t) tax and discoun t are stored in t w o di�eren t tuples � (additional pricing terms stored in additional tuples) to allo w quic k access, pricing term tuples that b elong to the � same lineitem are clustered together (i.e., pricing terms is a cluster table) 14 Sc hema: Observ ations SAP databases tend to b e v ery large (due to genericit y) � Sc hema is the heart of SAP , but still under constan t revision � a couple of thousand new tables with ev ery new ma jor release { { a great deal of reorganization w ork with ev ery upgrade 15

g SAP's T ransaction Concept SAP uses the term L o gic al Unit of Work (LUW) for transaction. � Basically , an SAP LUW has the same A CID prop erties as SQL � and an y (SQL) database system: an SAP LUW can span sev eral dialog steps { { an SAP LUW is either executed completely or not at all (i.e., atomicit y) { ... nested transactions are also p ossible { 16 Ov erview of Implemen tation SAP LUWs are NOT mapp ed 1:1 to database transactions � SAP implemen ted its o wn lo c king � (cen tralized enqueue servic e ) basically , SAP also implemen ted its o wn TP monitor � ( message hand ler and queues in ev ery application serv er) online transactions and batc h (o v ernigh t) queries p ossible � (for comparison: P eopleSoft uses third-part y TP monitors suc h � as T uxedo) 17

Pro cessing Dialog Steps 1. when a user logs in, a message handler Application Serv er �nds the application serv er with the smallest load (load balancing) 2. this application serv er handles all of the requests of that user session Dispatcher 3. a user session consists of sev eral transactions, and ev ery transaction consists Queue of sev eral dialog steps 4. ev ery application serv er has one dispatc her Work Work . . . Process Process pro cess and sev eral w ork pro cesses 5. the dispatc her queues requests un til a w ork private private pro cess is a v ailable buffers buffers 6. a w ork pro cess carries out a dialog step; rolls in relev an t data and in terprets Shared Memory Buffers DynPro and ABAP programs 7. so, ev ery user session is handled b y a single application serv er, but ev ery dialog step is handled b y di�eren t w ork pro cesses 8. exception: transactions that in v olv e large ob jects ha v e exclusiv e w ork pro cesses to a v oid cost of rolling data in and out 19 18

g lock requests lock release P1 P2 P3 P4 posting steps D1 D2 D3 dialog steps online phase posting phase log records for up dates are generated as part of ev ery dialog step � log records are propagated to RDBMS in p osting phase � lo c ks are requested during online phase and released after the � p osting phase is complete (2-phase lo c king) lik e dialog steps, p osting steps are handled b y di�eren t w ork � pro cesses (p oten tially in parallel) 20 Wh y do esn't SAP directly use the RDBMS? T ypical RDBMSs do not allo w transactions that cross pro cess � b oundaries. (This is necessary in SAP b ecause the dialog steps of an LUW can b e handled b y di�eren t w ork pro cesses) ab orts are quite frequen t (e.g., out of sto c k) and only carried out � b efore p osting; as a result, no roll-bac k at the RDBMS, the b ottlenec k, is required for ab orts SAP carries out lo c king in the gran ularit y of \business ob jects" � whic h are de�ned in the ABAP dictionary 21