Der Transaktionssimulator
Werbung
Der Transaktionssimulator Dr. Arno Schmidhauser Letzte Revision: Oktober 2004 Email: [email protected] Webseite: http://www.sws.bfh.ch/~schmd/db Transaktionssimulator 2 Inhalt 1 2 3 4 5 6 7 8 9 10 11 12 13 Zweck ................................................................................... 3 Transaktionsmuster ................................................................. 3 Isolationsgrade ....................................................................... 4 Ablauf eines Simulationsthreads ................................................ 5 Thread-Modelle ....................................................................... 7 Datentabelle für die Simulation ................................................. 8 Property-File für die Simulation ................................................. 9 Start der Simulation ................................................................ 9 Vordefinierte Thread-Modelle ...................................................10 Simulationsresultate in der Datenbank ......................................11 Aufgaben ..............................................................................12 Einige Simulationsresultate......................................................12 Anwendungsbeispiel Bank-Konto ..............................................19 Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 1 3 Zweck Der Transaktionssimulator soll die Performance und das Auftreten möglicher Inkonsistenzen simulieren, wenn viele Transaktionen gleichzeitig auf eine Datenbank zugreifen. Der Simulator startet für eine bestimmte Zeit mehrere Threads, von denen jeder nach bestimmten Vorgaben Transaktionen durchführt. Ein Simulations-Thread könnten beispielsweise ein Session Bean in einer J2EE Umgebung entsprechen, oder auch einer alleinstehenden Client-Applikation. Ein Thread folgt einem Transaktionmuster (Lesen, LesenSchreiben, Einfügen usw.), einem bestimmten Isolationsgrad und einem bestimmten zeitlichen Ablauf (Wartezeiten zwischen den DatenbankZugriffen). Folgende Resultate werden nach der Simulation global angezeigt: Anzahl durchgeführte Transaktionen aller Threads Durchschnittlicher Zeitbedarf für eine Transaktion aller Threads Anzahl produzierter Lost Updates in der Datenbank Folgende Resultate werden nach der Simulation pro Thread angezeigt: 2 Anzahl durchgeführte Transaktionen Durchschnittlicher Zeitbedarf für eine Transaktion Anzahl aufgetretener Deadlocks Durchschnittliche Zeit von Transaktionsbeginn bis zum Rollback des Deadlocks Anzahl gelesene Phantomzeilen Anzahl Rollbacks beim optimistischen Zeitstempelverfahren Transaktionsmuster Jeder Thread führt seine Transaktionen nach einem bestimmten Muster durch. Folgende Muster können für einen Thread gewählt werden: R Reine Lesetransaktion. Ein bestimmter Prozentsatz der Datensätze wird gelesen, anschliessend ein Commit abgesetzt. RR Reine Lesetransaktion. Ein bestimmter Prozentsatz der Datensätze wird gelesen, danach eine kurze Zeit gewartet. Die Wartezeit simuliert eine applikationsspezifsche Berechnung oder Business Logic. Anschliessend werden diesselben Daten nochmals gelesen, damit Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator RU I D 4 nochmals eine (-andere-) applikationsspezifsche Berechnung simuliert werden kann. Lese- und Änderungstransaktion. Ein bestimmter Prozentsatz der Datensätze wird zuerst gelesen, anschliessend wird eine kurze Zeit gewartet, um bestimmte Berechnungen/Auswertungen zu simulieren. Danach wird ein Teil der gelesenen Daten geändert und in die Datenbank zurückgeschrieben. Einfügetransaktion. Pro Transaktion wird eine bestimmte Anzahl neuer Datensätze eingefügt. Löschtransaktion. Pro Transaktion wird ein bestimmter Prozentsatz der Datensätze gelöscht. Jeder Thread folgt einem bestimmten Transaktionsmuster. Zusätzlich zum Muster wird für die Transaktionen eines Threads ein bestimmter Isolationsgrad eingestellt. 3 Isolationsgrade Für jedes Transaktionsmuster können folgende Isolationsgrade (Isolation Levels) eingestellt werden. Die Isolationsgrade 0, 1, 2 und 3 sind Teil des SQL Standards. Die Isolationsgrade 4, 5, und 6 wurden speziell für diesen Simulator definiert. Viele Datenbanksysteme besitzen entsprechende SQLBefehle. 0 1 2 3 4 5 6 READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE SHARED TABLE LOCK EXCLUSIVE TABLE LOCK OPTIMISTIC LOCKING Der vorliegende Simulator wurde gegen eine Sybase SQL Anywhere 9.0 Datenbank geprüft. Die Isolationsgrade sind wie folgt implementiert: 0 1 Dirty Read auf den aktuellen Daten. Änderungen einer anderen Transaktion (insbesondere unbestätigte und noch gesperrte) können sofort und ohne Behinderung gelesen werden. Kurze Lesesperrre auf den zu lesenden Daten. Für die zu lesenden Daten wird eine Lesesperre angefordert. Damit wird verhindert, dass Änderungen einer anderen Transaktion, die noch nicht committet hat, Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 2 3 4 5 6 5 gelesen werden können. Die Lesesperre wird aber sofort nach dem Lesen wieder freigegeben. Setzen einer Leseperre auf alle gelesenen Datensätze. Datensätze, die gelesen werden, um die Auswahlbedingung zu prüfen, werden mit einer Lesesperre belegt. Lesesperren auf Datensätzen, die der Auswahlbedingung nicht genügen, werden sofort wieder zurückgegeben. Es wird mit Shared Range Locks gearbeitet. Es werden also alle Datensätze gesperrt, welche in den von der Auswahlbedingung definierten Wertebereich fallen. Range Locks sind so implementiert, dass das Einfügen neuer Datensätze in den gesperrten Wertebereich nicht möglich ist. Die Tabelle als Ganzes wird mit einer Lesesperre versehen. Damit sind keinerlei Einfügungen, Löschungen oder Änderungen innerhalb der Tabelle mehr möglich. Jedoch kann die Tabelle von anderen Transaktionen ohne Einschränkungen gelesen werden. Die Tabelle als Ganzes wird mit einer exklusiven Sperre versehen. Damit ist jeder anderen Transaktion ein Zugriff irgendwelcher Art verwehrt. Aufgrund der Implementation von Sybase sind nicht einmal mehr Dirty Reads möglich. Pro Datensatz wird ein fortlaufender Zähler geführt. Bei jeder Änderung wird dieser Zähler inkrementiert (z.B. durch einen Trigger oder die Applikation selbst). Beim Lesen eines Datensatzes (mit READ UNCOMMITTED) wird auch der aktuelle Zählerwert gelesen. Da keine Lesesperre gesetzt wird, ist der Datensatz sofort frei für andere Transaktionen. Beim Zurückschreiben eines Datensatzes wird geprüft, ob der gelesene Zählerwert noch mit demjenigen des Datensatzes in der Datenbank übereinstimmt. Wenn nicht, führt die Applikation ein Rollback durch. Das Zurückschreiben der Daten unter gleichzeitiger Prüfung des Zählerwertes ist in SQL ganz einfach: update dataTable set data = wert, ... where zaehlerAttribut = zaehlerAppl and ... 4 Ablauf eines Simulationsthreads Die Simulation besteht aus mehreren, parallel laufenden Threads. Jeder Thread führt anhand seines Transaktionsmusters, laufend Transaktionen gegen die Datenbank durch. Jeder Thread hat neben dem Transaktionsmuster zusätzlich Vorgaben für den Isolationsgrad, die Anzahl zu lesender oder schreibender Datensätze, die Wartezeiten usw. Alle Angaben für einen Thread bilden zusammen ein Thread-Modell. Jedes Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 6 Oktober 2004 Commit Warten Commit Warten Warten Daten lesen Commit Warten Commit Warten Warten Warten Warten Commit Daten Lesen Warten Warten I D Warten Daten lesen RU Gelesene Daten ändern Warten Daten lesen RR Daten Einfügen Setzen Isolationsgrad Setzen Isolationsgrad Setzen Isolationsgrad Setzen Isolationsgrad Setzen Isolationsgrad Start Start Start Start Start Thread-Modell ist durch Angaben in einem Property File definiert. Einige vordefinierte Thread-Modelle sind in Kapitel 5 beschrieben. Der zeitliche Ablauf der verschiedenen Thread-Modelle, bezogen auf das Transaktionsmuster (R, RR, RU, I, D), ist wie folgt gestaltet: R Arno Schmidhauser SWS Transaktionssimulator 7 Die mittleren Werte für die Wartezeiten werden im Thread-Modell vorgegeben. Bei jedem Wartevorgang wird die mittlere Wartezeit aber mit einem zufälligen Faktor von 0 bis 2 multipliziert. Damit ist ein gutes statistisches Verhalten gewährleistet. 5 Thread-Modelle Jedes Thread-Modell ist in einem Property-File definiert, das den Namen Modell.props trägt. Bei Start der Simulation können die Namen mehrerer Modelle angegeben werden. Es werden dann soviele Threads gestartet, wie Modelle angegeben sind. Dasselbe Modell kann mehrmals angegeben werden. Einige vordefinierte Thread-Modell sind im letzten Kapitel beschrieben. Der Name des Modells besteht in diesen Beispielen aus dem Transaktionsmuster und dem Isolationsgrad. Folgende Parameter können angegeben werden: Name Werte Beschreibung THR_NAME TRA_TYPE ISO_LEVEL deskriptive Beschreibung des Modells . Transaktionsmodell Kurzform für die Isolationsgrade 0, 1, 2, 3, 4, 5 oder 6. SEL_PRCNT String R RU RR D I UNC COM REP SER T_S T_X TST Zahl [0..100] UPD_PRCNT Zahl [0..100] DEL_PRCNT Zahl [0..100] INS_NUMBER Zahl > 0 RR_DELAY Zahl > 0 RU_DELAY Zahl > 0 CMT_DELAY Zahl > 0 LOP_DELAY Zahl > 0 Oktober 2004 Anteil der Datensätze in %, die aus der Tabelle gelesen werden sollen. Anteil der gelesenen Datensätze in %, die modifiziert werden sollen. Anteil der Datensätze in %, die gelöscht werden sollen. Anzahl Datensätze, die pro Transaktion eingefügt werden sollen. Mittlere Wartezeit zwischen den zwei select-Befehlen (msec). Mittlere Wartezeit zwischen dem select- und dem ersten update-Befehl (msec). Mittlere Wartezeit vor dem CommitBefehl (msec). Mittlere Wartezeit nach dem Commit und vor dem Eintritt in den nächsten Schlaufendurchgang (msec). Arno Schmidhauser Verwendung in Transaktionsmuster Alle Alle R, RR, RU RU D I RR RU Alle Alle SWS Transaktionssimulator 6 8 Datentabelle für die Simulation Die Testtabelle TrxTable, auf der alle Transaktionen operieren, hat folgende Attribute: name pkey searchKey typ numeric(10,0) autoincrement double data int tranCount int Beschreibung Primärschlüssel. Wir in der Applikation für den Update benötigt. Nach diesem Attribut wird beim Lesen gesucht. Die Werte sind zufällig zwischen 0 und 100 verteilt. Auf diesem Feld besteht ein Index. Dieses Feld wird gelesen und in nachfolgenden Update-Befehlen jeweils um 1 inkrementiert. Dieses Attribut wird unmittelbar bei jedem Update-Befehl um 1 inkrementiert. Bemerkungen Sollen beispielsweise 10% der Datensätze gelesen werden, sucht die Simulation einen zufälligen Startwert für searchkey zwischen 0 und 90. Ausgehend von diesem Startwert werden die nächsten 10% gelesen. Die Differenz zwischen data und tranCount entspricht der Anzahl LostUpdates auf diesem Datensatz. Die Simulation nimmt nur eine einzige Art Änderung auf dem Wert von data vor: Der Wert wird in der Applikation um 1 erhöht und anschliessend zurückgeschrieben. Der Wert von tranCount wird im Update-Befehl um 1 erhöht (wenn der Datensatz also bereits mit einer exklusiven Sperre belegt ist). Der Wert von tranCount kann bei Isolationgrad 6 benützt werden, um festzustellen, ob ein Datensatz zwischen dem Lesen im select-Befehl und den Schreiben im Update-Befehl geändert wurde. Der Wert von tranCount wird durch die Simulation im update-Befehl jeweils beim Zurückschreiben um 1 erhöht. Standardmässig wird die Testtabelle mit 100 Datensätze initialisiert. Wesentlich mehr oder weniger Datensätze erhöhen oder erniedrigen die Wahrscheinlichkeit für Deadlocks, Phantoms, Lost Updates, Optimistic Rollbacks in nicht-linearer Weise: Um didaktisch anschauliche Resultate zu demonstrieren, müssen entsprechende Tests gefahren werden. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 7 9 Property-File für die Simulation Die Simulation als Ganzes benötigt verschiedene Parameter. Diese sind im Property File Simulation.props festgelegt. Proprietäre Datenbank-Befehle, welche für die Isolationsgrade 4 und 5 benötigt werden, sowie die JDBCTreiberklasse sind ebenfalls in diesem Property File definiert. Name Wertbeispiel Beschreibung DB_CONURL DB_USER DB_PASSWD DB_RECONNECT jdbc:sybase:Tds:localhost:2638 ?ServiceName=asademo dba sql 0 DB_NUMRECORDS OUT_CLRSTATS 100 1 OUT_INTERVAL PROD_DRIVERCLASS PROD_LOCKTABLE_S 10000 com.sybase.jdbc2.jdbc.SybDriver LOCK TABLE TrxTable IN SHARE MODE LOCK TABLE TrxTable IN EXCLUSIVE MODE URL für den JDBC Verbindungsaufbau Datenbankbenutzer Passwort 0=Verbindungsaufbau einmal pro Thread, vor dessen Start. 1=Verbindungsaufbau vor jeder Transaktion Initiale Anzahl Datensätze Statistik nach jeder Simulation löschen (1) oder Beibehalten (0) Laufzeit der Simulation (msec) JDBC-Treiberklasse Lesesperre auf Tabelle PROD_LOCKTABLE_X 8 Exklusive Tabellensperre Start der Simulation Der CLASSPATH muss auf die Datei jconn2.jar von Sybase jConnect zeigen. Starten der Simulation mit: java Simulation Simulation.props Anschliessend kann eine Anzahl Thread-Modelle eingegeben werden, zum Beispiel: Enter Thread Modells > RR2 RU1 RU1 Die Simulation läuft während der vordefinierten Zeit gemäss Simulation.props . Anschliessend können neue Thread-Modelle eingegen werden. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 9 10 Vordefinierte Thread-Modelle Folgende Property-Files enthalten vordefinierte Thread-Modelle R0.props R1.props RU0.props R01.props RU2.props RU3.props RU4.props RU5.props RU6.props RR0.props RR1.props RR2.props RR3.props RR4.props RR5.props I0.props I3.props I5.props D0.props D3.props D5.props Der Filename setzt sich aus dem Transaktionstyp und dem verwendeten Isolationsgrad des Thread-Modelles zusammen. Beispiel RR2.props THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY = = = = = = = RR 2 RR REP 20 100 0 20 Beispiel RU1.props THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY Oktober 2004 = = = = = = = = RU 1 RU COM 10 40 100 0 20 Arno Schmidhauser SWS Transaktionssimulator 11 10 Simulationsresultate in der Datenbank Das Simulationsprogramm schreibt neben der Ausgabe auf Konsole alle Resultate zurück in die Datenbank, in die Tabellen Simulation und Run. Ausserdem existiert eine View SimulationRuns über diesen beiden Tabellen. Von diesen Tabellen können die Resultate beispielsweise in ein Grafik- oder Tabellenkalkulationsprogramm übernommen werden. Bei Sybase Adaptive Server SQL kann aus Excel heraus direkt eine Datenquelle angezapft werden. Die Tabelle Simulation enthält Angaben über die Simulation als Ganzes, wie Zeitstempel und Lost Updates. Die Taballe Run enthält Angaben zu den einzelnen Threads einer Simulation. Die View SimulationRuns ist ein natural join über beide Tabellen. Beispielinhalt von SimulationRuns Im Excelsheet SimulationsResultate.xls werden die Resultate grafisch dargestellt. Die Datenquelle bezieht sich auf die installierte Demodatenbank von Sybase ASA, kann aber leicht neu definiert werden für andere Einstellungen oder Datenbanksysteme. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 11 12 Aufgaben 1. Bei welchem minimalen Isolationsgrad kann das Transaktionsmuster RU in mehreren Threads nebeneinander ohne Deadlocks ablaufen? 2. Welcher Isolationsgrad ist notwendig, damit das Transaktionsmuster RU in mehreren Threads nebeneinander ohne Lost Updates ablaufen kann? 3. Bei welchem Isolationsgrad kann das Transaktionsmuster RR in mehreren Threads nebeneinander ablaufen, ohne dass Phantome entstehen? 4. Für welchen Isolationsgrad (3 oder 5) ergeben sich Performance-Vorteile, wenn zwei Threads mit Transaktionsmuster RR und ein Thread mit dem Transaktionsmuster I gestartet wird? 5. Mit welchen Isolationsgraden können Deadlocks in RU Transaktionen vermieden werden? 6. Mit welchen Isolationsgraden können Lost Updates in RU Transaktionen vermieden werden? 7. Welche Isolationsgrade verhindern Phantome in RR Transaktionen? 8. Welche Vorteile hat der Isolationsgrad 6? 9. Wie ist das Verhalten bezüglich gesamtem Durchsatz an Transaktionen für die verschiedenen Thread-Modelle. Starten Sie beispielsweise 1 bis 10 Threads RU1 parallel, oder 1 bis 10 Threads RU5 parallel. 12 Einige Simulationsresultate Im Folgenden werden einige Simulationsresultate vorgestellt. Die ThreadNamen setzen sich aus dem Transaktionstyp (RR, RU, I, D) und dem Isolationsgrad (0-6 entsprechend READ_UNCOMMITTED, READ_COMMITTED, REPEATABLE_READ, SERIALIZABLE, SHARED TABLE LOCK, EXCLUSIVE TABLE LOCK, OPTIMISTIC) zusammen. Die Simulationsdauer für alle Threads ist 10 Sekunden. Die Y-Achse für das Diagramm 'Einzelne Threads' ist 'Anzahl'. Die Y-Achse für das Diagramm 'AlleTransaktionen' ist einerseits 'Anzahl', andererseits 'Millisekunden'. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 13 Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 0 RU 0 RU 0 RU 0 RU 0 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU0 ist nur akzeptabel, wenn Lost Updates aus applikatorischer Sicht keine Probleme bieten. Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 1 RU 1 RU 1 RU 1 RU 1 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU1 ist nur akzeptabel, wenn Lost Updates aus applikatorischer Sicht keine Probleme bieten. Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 2 RU 2 RU 2 RU 2 RU 2 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU2 ist sicher bezüglich Inkonsistenzen in der Datenbank (Lost Updates), produziert aber öfters Deadlocks. Wenn diese automatisch behoben werden können (Retry), vermindern sie lediglich den Gesamtdurchsatz an Transaktionen. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 14 Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 3 RU 3 RU 3 RU 3 RU 3 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU3 unterscheidet sich kaum von RU2. RU3 kann gegenüber RU2 verhindern, dass während dem Lesen und Ändern von Datensätzen eine andere Transaktion Datensätze einfügt, welche die erste Transaktion eigentlich auch gerade hätte ändern wollen. Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 4 RU 4 RU 4 RU 4 RU 4 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates Bei RU4 (Shared Table Lock) führt der Deadlock-Anteil zu einer sehr schwachen Performance. Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 5 RU 5 RU 5 RU 5 RU 5 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU5 ergibt einen sehr schlechten Gesamtdurchsatz. Jede einzelne Transaktion läuft exklusiv ab und blockiert jede andere vollständig. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 15 Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 6 RU 6 RU 6 RU 6 RU 6 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates RU6 ergibt einen guten Durchsatz (Weniger als RU1, aber mehr als RU2 und RU5), bei gleichzeitiger Sicherheit, keine dauerhaften Inkosistenzen (Lost Updates) in der Datenbank zu produzieren. Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 80 60 40 20 0 numOptRlbks numPhn numDlks RU 3 RR 4 RR 4 RR 4 RR 4 numTrx 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates 5 Lesetransaktionen RR4 schliessen die Änderungstransaktionen RU3 sehr effizient vom Zugriff aus (Livelock)! Einzelne Threads 200 180 160 Alle Transaktionen 140 120 numOptRlbks 100 80 numDlks numPhn numTrx RU 3 RR 3 RR 3 RR 3 RR 3 60 40 20 0 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates 5 Lesetransaktionen RR3 lassen die Änderungstransaktionen RU3 noch weitgehend auf die Datenbank zu. Der Gesamtdurchsatz ist sehr hoch (RR3 lesen 10% der Daten). Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 16 Einzelne Threads 200 180 160 Alle Transaktionen 140 120 100 numOptRlbks numPhn numDlks 80 60 numTrx D 0 I 0 RR 3 RR 2 RR 1 RR 0 40 20 0 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates Sobald Einfüge- und Löschtransaktionen ins Spiel kommen, ergeben sich Phantom-Probleme bei RR-Lesetransaktionen. RR0 bis RR2 leiden an Phantomen. Erst bei RR3 verschwinden diese gemäss Theorie ordnungsgemäss. RR0 bis RR2 sind jedoch auch leicht performanter (RR0 – RR3 lesen 20% aller Datensätze). Einzelne Threads 200 180 Alle Transaktionen 160 140 numOptRlbks numPhn 120 100 numDlks numTrx 80 60 40 20 D 0 I 0 RU 2 RR 4 RR 4 RR 4 RR 4 0 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates Die Implementation von SERIALIZABLE mit einem Shared Table Lock (RR4) verdrängt Änderungs-, Einfüge- und Löschtransaktionen. Einzelne Threads 200 180 Alle Transaktionen 160 140 numOptRlbks 120 numPhn numDlks numTrx 100 80 60 40 20 D 0 I 0 RU 2 RR 3 RR 3 RR 3 RR 3 0 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates Die Implementation von SERIALIZABLE mit Range Locks (RR3) bringt wesentliche Vorteile: Änderungs-, Einfüge- und Löschtransaktionen können gleichberechtigt agieren (RR3 lesen 20% der gesamten Daten). Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 17 Einzelne Threads 200 180 Alle Transaktionen 160 140 numOptRlbks numPhn numDlks numTrx 120 100 80 60 40 20 I 0 D 0 RU 6 RU 5 RU 4 RU 3 RU 2 RU 1 RR 5 RU 0 RR 4 RR 3 RR 2 RR 1 RR 0 0 1000 900 800 700 600 500 400 300 200 100 0 SummeTrx avgTrxTime LostUpdates Bunter Mix verschiedenster Transaktionen. RR0 – RR5 lesen 20% der Daten. RU0 bis RU6 lesen 10% der Daten und verändern 40% der gelesenen Daten. Transaktionen, die am meisten Resourcen beanspruchen, werden selbst am meisten von der Datenbank ausgeschlossen (RR4, RR5, RU5). Zu beachten ist noch, dass der Gesamtdurchsatz von Transaktionen mit der Anzahl Threads wächst. Weil gesamthaft 15 Threads laufen, ist der Gesamtdurchsatz höher also bei den anderen Diagrammen weiter oben. Oktober 2004 Arno Schmidhauser SWS Transaktionssimulator 18 Es gelten folgende Parametersätze für die Threadmodelle in den obigen Beispielen (ausser wenn anders beschriftet unter der Grafik) THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY Oktober 2004 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = RU 0 RU UNC 10 40 100 0 20 RU 3 RU SER 10 40 100 0 20 RU 6 RU TST 10 40 100 0 20 RR 2 RR REP 20 100 0 20 RR 5 RR T_X 20 100 0 20 THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY = = = = = = = = = = = = = = = = = = = = = = = RU 1 RU COM 10 40 100 0 20 RU 4 RU T_S 10 40 100 0 20 RR 0 RR UNC 20 100 0 20 THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT UPD_PRCNT RU_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY = = = = = = = = = = = = = = = = = = = = = = = RU 2 RU REP 10 40 100 0 20 RU 5 RU T_X 10 40 100 0 20 RR 1 RR COM 20 100 0 20 THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL INS_NUMBER CMT_DELAY LOP_DELAY = = = = = = = = = = = = = RR 3 RR SER 20 100 0 20 I 0 I UNC 1 100 20 THR_NAME TRA_TYPE ISO_LEVEL SEL_PRCNT RR_DELAY CMT_DELAY LOP_DELAY THR_NAME TRA_TYPE ISO_LEVEL DEL_PRCNT CMT_DELAY LOP_DELAY = = = = = = = = = = = = = RR 4 RR T_S 20 100 0 20 D 0 D UNC 1 100 20 Arno Schmidhauser SWS Transaktionssimulator 19 13 Anwendungsbeispiel Bank-Konto Beispiel RU-Transaktion: Kontonstand lesen und prüfen, dann Betrag abheben oder einzahlen. Isolationsgrad REPEATABLE READ oder OPTIMISTIC LOCKING ist ausreichend. READ COMMITTED ist sicher nicht ausreichend, weil Lost Updates nicht akzeptabel wären. Was soll im Fall eines Deadlocks passieren? Kunde informieren oder Transaktion auf die Gefahr eines inkonsistenten Kontostandes hin trotzdem durchführen? Sollen Deadlocks mit einem EXCLUSIVE TABLE LOCK verhindert werden? Ist die Performance noch akzeptabel? Beispiel einer RR-Transaktion: Erstes Lesen um Kontosaldo zu bilden. Zweites Lesen für Detailauszug, jeder Datensatz einzeln. Beide Abfrage müssen gegenseitig konsistente Resultate ergeben bezüglich Saldo. Kombination von R und I Transaktion: Wenn das Bankkonto nicht als einzelner Datensatz, sonder journalartig geführt wird, das heisst jedes Abheben oder Einzahlen ein Journaleintrag ist, ergeben sich neue Fragen: Reicht REPEATABLE READ noch aus? Ja, wenn das Bankkonto keine Limite für das Überziehen hat. Nein, wenn es eine Limite gibt! Wenn es eine Limite gibt, ist SERIALIZABLE notwendig! Oktober 2004 Arno Schmidhauser SWS