5.6 Mehrstufige Transaktionsverwaltung im Prinzip und in SAP

5.6 Mehrstufige Transaktionsverwaltung im
Prinzip und in SAP
SAP (allgemein C/S/M -Architektur) unterscheidet
C
AS
SS
zwei wesentliche Abstraktionseben:
Anwendungsserver (AS) und
Speicherserver (SS). Der Speicherserver ist ein
DBMS.
Wir nehmen im folgenden an, dass wir auf der ASEbene A-SQL-Objekte anlegen und manipulieren
und auf der SS-Ebene S-SQL-Objekte. Die Abbildung
zwischen A-SQL und S-SQL ist festgelegt. Wir
können daher auch A-SQL-Transaktionen und SSQL-Transaktionen unterscheiden. Neben einer
trivialen Abbildung, wo jede A-SQL-Transaktion auf
eine S-SQL-Transaktion abgebildet wird, können wir
unter Anwendung der Theorie zusammengesetzter
Transaktionen (s. IS-K) jede A-SQL-Aktion als eine SSQL-Transaktion verarbeiten
OHO
Kap5-6 1
Zweistufige Transaktionen
OHO
Die Vorteile sind (s. IS-K):
Höhere Parallelität
Unterstützung langer Transaktionen über Prozessgrenzen
Ausnützen von Semantik auf der AS-Ebene
Ziel ist es, ein einfaches mehrstufiges Transaktionsprotokoll zu
entwicklen, ausgehend von der Theorie aus IS-K. Dabei soll ein
einfaches striktes 2PL auf A-SQL-Objektmengen verwendet
werden. Dieses Protokoll wird dann dem in SAP implementierten
gegenübergestellt.
Aus IS-K: Scheduler verwendet Konfliktrelation und ordnet
Konfliktpaare. Bei Anwendung eines Sperrprotokolls wird ein
Konflikt in unverträgliche Sperranforderungen übersetzt. Damit
werden Konfliktpaare stark geordnet.
Kap5-6 2
1
Insert
Delete
Update
Select
Sperrverträglichkeit für A-SQL-Aktionen
Select
In allen Fällen, ausser
Select, muss geprüft
werden, ob die Tupelmengen aller Sperrenbesitzer disjunkt sind zur
Tupelmenge, die der
Sperranforderer möchte.
Unterscheidung von S und
X-Sperren, wie im einfachen
Read/Write-Modell: bei
Select S, sonst X.
Update
Delete
Anwendung von „groben“
Prädikaten für effizientes
Testen, „Signatursperren“
(Schek83)
Insert
OHO
Kap5-6 3
Zweistufiges Recovery
Jede Aktion einer A-SQL-Transaktion wird als S-SQL-Transaktion
mit Commit beendet.
Daher muss im Sinne eines WAL (Write-Ahead-Log) vor der
Ausführung einer A-SQL-Aktion ein Logsatz zur Ausführung einer
Kompensations-Aktion (Inverse) auf der Ebene A-SQL geschrieben
werden.
Inverse werden automatisch generiert:
Select:
Update:
Insert:
Delete:
OHO
nil
Update rückgängig
Delete
Insert
Kap5-6 4
2
Einfaches Beispiel (aus IS-K)
t1 = <select * from R where A < 0,
delete from S where B = 0> ...kurz t1=<p1,q1>
t2 = <select * from S where B = 0,
delete from R where A > 0> ... kurz t2=<p2,q2>
OHO
Kap5-6 5
Arbeitsweise des S2PL-A-SQL-Schedulers
Konflikte bestehen zwischen
(p1, p2) : kein Konflikt: Leser
(p1, q2) : kein Konflikt, weil Tupelmengen disjunkt
(q1, p2) : Konflikt (gleiche Tupelmenge)
(q1, q2) : kein Konflikt, weil Tupelmengen disjunkt)
Daher Arbeitsweise des dynamischen S2PL- A-SQL -Schedulers
Angenommene Eingabe:
p2, p1, q1, q2
p1 <<1 q1
p2 <<2 q2
Erzeugte Ausgabeordnungen:
<< :
p1 << q1 , p2 << q2
p2 << q1 ,
q2 << q1
wegen Intra-Transaktionsordnung
weil Konfliktpaar
wegen S2PL
erzeugter Schedule ist korrekt, weil S2PL korrekte Schedules erzeugt. (der
serielle Schedule t2 ⇒ t1 enthält diese Ordnungen)
OHO
Kap5-6 6
3
Pseudo-Code des A-SQL-Schedulers am Beispiel
Siehe Vorl.
OHO
Kap5-6 7
Transaktionen in SAP/R3 (aus IS-K)
Transaktionen heissen in SAP/R3 Logical Unit of Work (LUW). Eine LUW
besteht aus zwei Teilen:
der SAP-Transaktion: Zusammenfassung der vorbereitenden
Dialogschritte Di und der
SAP-Verbuchung: eigentliche Ausführung der vorbereiteten Schritte.
Sperrdauer für SAP- Objekte
SAP-LUW
SAP-Objekte
DB-Objekte
SAP-Transaktion
SAP-Verbuchung
D1
D2
D3
D4
t1
t2
t3
t4
t5
DB-Transaktionen
OHO
Kap5-6 8
4
Transaktionen in SAP/R3 - 2 Dialogschritte und Verbuchung werden jeweils als DBTransaktionen ausgeführt. Die Ausführung der Dialogschritte
entspricht einem Enqueue der Aufträge und die Verbuchung ist
die Durchführung als eine DB-Transaktion.
SAP-Objekte werden für die Dauer der SAP-LUW gesperrt, DBObjekte nur während der DB-Transaktion, also kurz.
Die SAP Transaktionsverwaltung kann daher als ein ZweiScheduler-Stapel aufgefasst werden.
SAP- Scheduler
Sperrverwaltung für
SAP-Objekte
DB- Scheduler
Sperrverwaltung für
DB-Objekte
OHO
Kap5-6 9
SAP-Transaktionen = Zweistufige
Transaktionsverwaltung?
Vorige Gegenüberstellung sieht eigentlich so aus,
aber (siehe anschliessender Workshop)
Umgehung des SAP-Transkationsmangers durch native SQL
möglich (klar, man müsste födererierte Transaktionsverwaltung einsetzen, wenn man native SQL zulässt),
Programmierer müssen explizit Sperren setzen! (Dies ist,
verglichen mit dem Stand der Technik, ein grosser Rückschritt,
mindestens optional sollten automatisch Sperren gesetzt
werden)
Es können (private, für andere Nutzer nicht sichtbare
Versionen) verwendet werden
OHO
Kap5-6 10
5