Transaktionssysteme

1.552 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.552
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Transaktionssysteme

  1. 1. Transaktionssysteme Arno SchmidhauserLetzte Änderung: 13. März 2012Email: arno.schmidhauser@bfh.chWebseite: http://www.sws.bfh.ch/db
  2. 2. I - Übersicht• Transaktionsmodell – ACID Regel• Wichtige Komponenten – Recovery System – Concurrency Control – Zugriffsoptimierung
  3. 3. IITransaktionsmodell
  4. 4. Was ist eine Transaktion• Aus logischer Sicht ist eine Transaktion ein Arbeitspaket, das einen geschäftlichen Nutzen erzeugt. – So klein wie möglich. – so gross wie nötig, um alle Integritätsbedingungen einhalten zu können.• Aus technischer Sicht ist eine Transaktion eine Folge von Lese- und Änderungsoperationen in der Datenbank, mit einem definierten Beginn und einem definierten Abschluss.• Die Transaktionsverwaltung ist eine der Kernaufgaben eines Datenbanksystems.
  5. 5. ACID-Regel• Das Datenbanksystem garantiert für eine Transaktion folgende Eigenschaften: A Atomarität C Konsistenz I Isolation D Dauerhaftigkeit Diese Eigenschaften werden als ACID Regel bezeichnet.
  6. 6. Arbeiten mit Transaktionen• Jeder lesende oder schreibende Zugriff auf die Datenbank kann nur innerhalb einer Transaktion stattfinden.• Eine Transaktion beginnt explizit mit einem "begin transaction" Befehl oder implizit mit dem ersten SQL-Befehl.• Eine Transaktion wird nur mit dem "commit"-Befehl korrekt abgeschlossen. Andernfalls gilt sie noch nicht als korrekt beendet.• Eine Transaktion kann explizit mit "rollback" oder implizit durch ein äusseres Ereignis abgebrochen werden.
  7. 7. ACID, Systemkomponenten• Es folgt die Betrachtung einiger Systemkomponenten, die sowohl für die Erfüllung der ACID-Regel wichtig sind, wie auch gleichzeitig die Performance der Datenbank entscheidend beeinflussen. Zeitverhalten eines Datenbanksystems• Recovery System• Concurrency Control• Zugriffsoptimierung
  8. 8. IIIDas Recovery-System• Zweck• Logfile• Fehlerbehebung
  9. 9. Zweck des Recovery-Systems Das Recovery-System eines DBMS enthält alle Hilfsmittel zum Wiederherstellen eines korrekten Datenbank-Zustandes nach Transaktionsfehlern (Rollback) Systemfehlern (Crash des Serverprozesses) Das Recovery-System garantiert die Atomarität und Dauerhaftigkeit einer Transaktion (ACID Regel).• Das Recovery-Systems basiert auf dem Führen eines Logfiles, in welchem Änderungen protokolliert werden.• Abschätzen und Überwachen der Grösse und Festlegen des Speicherortes für das Logfile sind zwei wichtige Aufgaben der Datenbank-Administration
  10. 10. Fehlerarten• Transaktionsfehler – Rollback-Befehl durch Applikation – Verletzung von Integritätsbedingungen – Verletzung von Zugriffsrechten – Deadlock – Verbindungsunterbruch oder Client-Crash• Systemfehler – Stromausfall, Hardware- oder Memory-Fehler
  11. 11. Ablauf von ModifikationsbefehlenSQL-Befehl eines Clients 2. Neue Datenwerte 1. Alte und neue Workspace Datenwerte Checkpoint (Gelegentlich) Logfile DB-Storage
  12. 12. Zeit Systemfehler M42 M42 RBK T3 M32 M32Logging, Beispiel CMT T2 M22 M22 Checkpoint E_CKPT (T2,T3,T4) B_CKPT (T2,T3,T4) M41 M41 M31 BOT T4 M31 M21 BOT T3 M21 BOT T2 CMT T1 M11 M11 BOT T1 Logfile T1 T2 T3 T4
  13. 13. Behebung von Transaktionsfehlern• Bei einem Transaktionsfehler (Rollback) werden aus den rückwärts verketteten Transaktionseinträgen im Logfile die alten Daten (Before Images) in den Workspace übertragen.• Das Datenbanksystem führt hierzu für jede laufende Transaktion einen Verweis auf den letzten Log- Eintrag mit. Der Transaktionsabbruch wird im Logfile ebenfalls protokolliert.• Beispiel: Für Transaktion T3 müssen die Before-Images von M31 und M32 zurückgeladen werden.
  14. 14. Behebung von Systemfehlern• Gewinner- und Verlierer-Transaktionen ermitteln• Verlierer-Transaktionen mit Hilfe der Before-Images zurücksetzen• Gewinner-Transaktionen mit Hilfe der After-Images noch einmal durchführen• Checkpoint durchführen• Beispiel – Gewinner: T2 -> M22 nachspielen. – Verlierer: T3 und T4 -> M31, M41 zurücksetzen.
  15. 15. Zusammenfassung Recovery-System• Logfile = Performance-kritisches Element einer Datenbank• Grössenabschätzung vornehmen• Alternative Speichermöglichkeiten prüfen (SSD Disks mittl. Zugriffszeit ~10x schneller, 0.4ms statt 4ms)• Für Bulk-Load Operationen kann und darf man Logging oft ausschalten• Logfile wird bei fast allen Datenbanken heute neben dem Recovery für die Datenreplikation verwendet.
  16. 16. IVConcurrency Control• Zweck• Serialisierbarkeit• Neue Methoden
  17. 17. Ziel des Concurrency Control• Einerseits: Isolation (I-Bedingung der ACID Regel) – Änderungen am Datenbestand dürfen erst bei Transaktionsabschluss für andere sichtbar sein. – Die parallele Ausführung von Transaktionen muss bezüglich Datenzustand und bezüglich Resultatausgabe identisch mit der seriellen Ausführung von Transaktionen sein (Serialisierbarkeit).• Andererseits: Parallelität – Eine Datenbank muss mehrere Benutzer(-prozesse) gleichzeitig bedienen können und es sollen möglichst wenig Wartesituationen entstehen.
  18. 18. Serialisierbarkeit, BeispielDie folgenden zwei Transaktionen müssen so gesteuert werden,dass der Schritt 1.3 nicht zwischen 2.1 und 2.2 zu liegen kommen.Transaktion 1 Transaktion 21.1 select * from Kunde 2.1 select * from Kunde where name = "Muster" where name = "Muster"1.2 delete from Kunde 2.2 select * from Bestellung where kunr = :kunr where kunr = :kunr commit1.3 delete from Bestellung where kunr = :kunr commit
  19. 19. Serialisierbarkeit ffUnter der Annahme, dass die Datenbank keine Synchro-nisationsmittel einsetzt und jedes SQL-Statement einatomarer Schritt ist, sind verschiedene zeitliche Abläufeder beiden Transaktionen denkbar: 1. 1.1 2.1 1.2 2.2 1.3 (k) 2. 1.1 2.1 1.2 1.3 2.2 (f) 3. 1.1 2.1 2.2 1.2 1.3 (k) 4. 1.1 1.2 2.1 1.3 2.2 (k) 5. 1.1 1.2 2.1 2.2 1.3 (f) 6. 1.1 1.2 1.3 2.1 2.2 (s) 7. 2.1 1.1 1.2 2.2 1.3 (k) 8. 2.1 1.1 2.2 1.2 1.3 (k) 9. 2.1 1.1 1.2 1.3 2.2 (f) 10. 2.1 2.2 1.1 1.2 1.3 (s)
  20. 20. Locking• Locking ist die häufigste Technik zur Gewährleistung der Serialisierbarkeit. – Für das Lesen eines Datensatzes wird ein S-Lock gesetzt – Für das Ändern, Löschen, Einfügen wird ein X-Lock gesetzt. – Für das Einfügen wird zusätzlich ein S-Lock auf der Tabelle gesetzt.• Die gesetzten Locks sind gemäss einer Verträglichkeitstabelle untereinander kompatibel oder nicht: S X Angeforderte Sperre S + - X - - Angeforderte Sperre wird gewährt (+) oder nicht gewährt (-) Bestehende Sperre
  21. 21. Deadlocks• Beim Sperren von Daten können Deadlocks auftreten. Der Deadlock ist nicht ein logischer Fehler, sondern bedeutet: – Es gibt keinen Weg mehr, die anstehenden Transaktionen so zu steuern, dass ein serialisierbarer Ablauf entstehen wird. – Eine der beteiligten Transaktionen wird daher zurückgesetzt, so dass für die übrigen wieder die Chance besteht, gemäss Serialisierbarkeitsprinzip abzulaufen.2004.ppt#121. Serialisierbarkeit
  22. 22. Isolationsgrade• Eine unter allen Umständen garantierte Serialisierbarkeit kann die Parallelität empfindlich einschränken. Ist zum Vornherein bekannt, dass gewisse Inkonsistenzen aufgrund der Business-Logik gar nicht auftreten können, oder allenfalls in Kauf genommen werden sollen, können die Locking-Massnahmen des DBMS gelockert werden.• SQL definiert deshalb vier Isolationsgrade beim Lesen von Daten: Isolationsgrad Inkonsistenzen 3 SERIALIZABLE - Isolatio n 2 REPEATABLE READ Phantom-Problem 1 READ COMMITTED Lost-Update, Reporting Problem Paralleli 0 READ UNCOMMITTED Lesen unbestätigter Daten ät
  23. 23. Bei REPEATABLE READ Phantom-ProblemT1 T2select *from Personwhere name = Muster insert Person ( name ) values ( Muster) commitselect * Hier tauch neuer Datensatz auffrom Personwhere name = Mustercommit
  24. 24. Bei READ COMMITTED Lost-UpdateT1 T2select saldofrom Kontowhere idKonto = 3 select saldo from Konto where idKonto = 3 neuerSaldo = saldo + 100 update Konto set saldo = neuerSaldo where idKonto = 3 commitneuerSaldo = saldo + 100update Kontoset saldo = neuerSaldo Änderungen von T2 gehen beimwhere idKonto = 3 Update von T1 verloren !commit
  25. 25. Bei READ COMMITTED Reporting-ProblemT1 T2select *from Bestellungorder by zahlDatum update Bestellung set zahlDatum = now() where idBestellung = 4711 commit-- …-- Abfrage läuft hier weiter Derselbe Datensatz kann hier wieder-- … auftauchencommit
  26. 26. DemoAuswirkung des Isolationsgrades auf Transaktions-Durchsatz• Die Einstellung des Isolationsgrades hat bei intensiven genutzten Systemen grosse Auswirkungen auf den Transaktionsdurchsatz, die Deadlockhäufigkeit und das Auftreten von Inkonsistenzen. Transaktionssimulator
  27. 27. Neue Methoden• Range Locks: Entschärft ganz entscheidend die Phantomproblematik und erlaubt in den meisten Fällen von OLTP das Arbeiten im Modus SERIALIZABLE.• Datensatz-Versionierung: Erlaubt ein vollständiges stabiles Lesen von Daten und Vermeidung des Phantom-Problems, ohne Anwendung von Locks.
  28. 28. Range Locks (1)• Range Locks werden für die Realisierung des Isolation Levels SERIALIZABLE verwendet.• Mit Range Locks werden Datensätze nach einer logischen Bedingung und nicht nur rein physisch gesperrt.• Mit Range Locks kann das Phantom Problem elegant gelöst werden.• Voraussetzung: Die Abfragebedingung enthält einen oder mehrere Teile, welche über einen Index evaluiert werden können. Beispiel: select * from Reservation where resDatum > 1.1.2008 and resDatum < 31.12.2008
  29. 29. Range Locks (2)Range Locks werden auf Index-Einträge gesetzt, nicht aufDatensätze, wie gewöhnliche Locks. Datensatz mit resDatum 1.6.2009select * from Reservationwhere resDatum < 31.12.2008 Datensatz mit resDatum 1.6.2008and resDatum > 1.1.2008 Datensatz mit resDatum 1.6.2007 Datensätze mit Datensatz mit resDatum 1.6.2006 gesetztem Range Lock Wirkungsbereich des Range Locks
  30. 30. Concurrency Control mit Versionen• Von einem Datensatz werden zeitweilig mehrere Versionen geführt, mit folgenden Zielen: – Eine Transaktion sieht einen committeten Datenbankzustand bezogen auf den Zeitpunkt des Starts. Dieser Zustand bleibt über die ganze Transaktionsdauer eingefroren. – Schreibbefehle werden durch Lesebefehle nicht behindert und umgekehrt. – Schreibbefehle beziehen sich immer auf die neueste Version eines Datensatz in der Datenbank.
  31. 31. Versionen, Leser gegen Schreiber 6 Lesende Transaktion/Befehl, TNC = 6 4 Lesende Transaktion/Befehl, TNC = 52Schreibende Transaktion/Befehl, TNC = 4 1 Lesende Transaktion/Befehl, TNC = 33 Kopie des Datensatz 5 commit Datensatz X, TNC = 2 Datensatz X, TNC = 4 Datensatz X, TNC = 2 7 Kann gelöscht werden Datensatz X, TNC = 1
  32. 32. Versionen, Schreiber gegen Schreiber 2 Schreibende Transaktion, TNC = 41Schreibende Transaktion, TNC = 3 4 Änderungsbefehl Datensatz X, TNC = 2 73 commit: abort, weil TNC 2 max Datensatz X, TNC = 2 TNC im Pool 5 commit: ok, weil TNC 2 = max TNC 6 im Pool Datensatz X, TNC = 3 Kopie Datensatz Kopie Datensatz Datensatz X, TNC = 2 Datensatz X, TNC = 1
  33. 33. DemoIsolationsverbesserung mit Versionenverfahrenin SQL Server 2005/2008• Zusätzlicher Isolation Level SNAPSHOT : Ergibt serialisierbare Transaktionen ohne Verwendung von Lesesperren. Änderungskonflikte mit anderen Transaktionen werden beim Commit festgestellt.• Isolation Level READ COMMITTED mit Versionenverfahren realisiert. Es wird immer ein committeter Zustand gesehen, es sind aber Lost Updates möglich.
  34. 34. VZugriffsoptimierung• Zielsetzung• Indexierung von Daten• SQL Ausführungsplan• Optimierungshinweise
  35. 35. Zielsetzung• Ein zentrales Ziel der Abfrageoptimierung ist die Minimierung des Zugriffs auf I/O-Pages.• Eine I/O-Page ist ein Datenblock fester Grösse, der am Stück von einem Speichermedium gelesen oder darauf geschrieben wird.• Ein Query Optimizer erzeugt einen Query Execution Plan (QEP), der den Ablauf einer Abfrage festlegt.• Die Hilfsinformation für die Planung einer Abfrage sind verschiedenste Statistiken.• Das primäre Hilfsmittel für die Durchführung einer Abfrage ist ein Index.
  36. 36. Indexierung von Daten• Ein Index ist eine Hilfsstruktur zum schnelleren Auffinden von Datensätzen.• Indices werden immer für ein, allenfalls mehrere Attribute einer Tabelle erzeugt.• Für Primär- und Fremdschlüssel erzeugt das DMBS meist selbstständig einen Index.• Für Attribute, die in Suchbedingungen oder Sortierklauseln vorkommen, werden zusätzliche Indices erstellt mit: create index ixname on table (attr1 [,attrn]...)• Indices haben meist die Struktur eines verzweigten, ausgeglichenen Baumes (B*).
  37. 37. B*-Index Z0 W1 Z1 W2 Z2 freier Platz Knoten (I/O-Page) Z0 W1 Z1 W2 Z2 freier Platz Z0 W1 Z1 W2 Z2 freier Platz P S1 D1 S 2 D2 freier Platz N P S1 D1 S2 D2 freier Platz NIndexDaten R1 R2 R3 R4 R5 R6 R7 R1 R2 R3 R4 R5 R6 R7
  38. 38. B*-Index, BeispielIndex E N A D G K P T C D E E G G K L N O P R T X a a d m a ü u o i t et o h e r n g i b nt r r c h e l o n m i ar l i h t e o m r f m o e el r n l a a n z a r sDaten Xeno Emil Müller Huber Waldstr. 8 Schlossweg1
  39. 39. Anwendungsmöglichkeiten B*• Auffinden einzelner Datensätzen eines bestimmten Schlüsselwertes. Beispiel: where name = Meyer• Auffinden von Datensätzen in einem bestimmten Schlüsselbereich.Beispiel: where gebdatum between 1.1.2000 and 1.1.2001• Sortierte Ausgabe von Daten. Beispiel: order by name• Auffinden von Datensätzen wenn nur der Anfang des Schlüssels bekannt ist. Beispiel: where name like M%
  40. 40. Join-Bildung • Joins sind ein zentrales Konstrukt in SQL. Häufige Algorithmen für die Join-Bildung sind: – Nested Loop Join • Doppelte Schlaufe zur Abarbeitung der Tabellen. Für ganz kleine Tabellen geeignet und als theoretischer Fallback, der immer möglich ist. • Aufwand: M/k1 + M * N/k2 – Lookup Join • Äussere Tabelle sequentiell durchlaufen. Jeden Vergleichswert (Schlüsselwert) via Indexzugriff in der inneren Tabelle suchen. • Aufwand: M/k1 + M * (k2log(N/k2)+2) Zugriff Root-Page + Zugriff Datenpage Gesamtzugriffe für IO-Pages innere TabelleAnzahl IO-Pages äussere Tabelle Anzahl Datensätze aussen = Anzahl Aufrufe in den inneren Index
  41. 41. Join-Bildung, Merge Join• Es müssen zwei bereits sortierte Tabellen vorliegen. Alle Datensätze der linken und rechten Tabelle werden abwechslungsweise über ein Vergleichsfenster geschoben und die Schlüsselwerte verglichen.• Aufwand: M/k1+N/k2 2 3 7 7 Vergleichsfenster 1 2 2 3 3 4 Sortierte 5 7 7 7 10 12 T1 T2
  42. 42. Join-Bildung, Hash Join• Buckets mit Datensätzen beider Tabellen, die den gleichen Hashwert für das Join-Attribut haben. Verknüpfung der Datensätze pro Bucket für die Ausgabe.• Aufwand: M/k1+N/k2 Join Resultat Bucket 1 Bucket 2 Originale Datensätze Originale Datensätze
  43. 43. Sortieren• Sortieren ist in Datenbanken eine unverzichtbare Operation: – für die sortierte Ausgaben mit order by – für die Durchführung von group by – als Vorbereitung für Merge Join – für den Datenabgleich in redundanten Systemen• Sortieren ist für die Präsentation und Analyse von grossen Datenmengen in Data Warehouses eine viel gebrauchte, aber auch zeitkritische Operation, da enorme Datenmengen pro Abfrage verarbeitet werden.• Für die reine Transaktionsverarbeitung (OLTP) weniger kritisch, da meist nur wenig Daten betroffen.
  44. 44. Merge Sort, Prinzip• Prinzip: Tabellen zerlegen und Bottom Up sortiert neu aufbauen• Aufwand: N/k * blog( N/k) * 2 Anzahl IO-Pages Anzahl Verabeitungsstufen Lese- und für die ganze Liste für die ganze Liste Schreiboperation
  45. 45. Merge Sort, Mischen von Listen• Zwei Startlisten L1 und L2 L1 1 3 5 1 2 3 4 5 6 LR L2 2 4 6 Mischbuffer Listenkopf• Drei und mehr Startlisten L1, L2, L3,… L1 1 3 5 5 L2 2 4 6 7 1 1 2 3 4 5 6 7 LR 6 L3 1 3 7 (Proz Cache) Mischbuffer Listenkopf SortHeap
  46. 46. Merge Sort, Zahlenbeispiele• Rechenbeispiele Anzahl Tabellen- Anzahl Totale Zeit Totale Zeit Totale Zeit Datensätze grösse IOs Disk-basiert Flash-basiert RAM-basiert (GB) (Pages) (sec) (sec) (sec) OLTP 1.00E+02 0.00 0.00E+00 0.000 0.000 0.000 1.00E+03 0.00 2.00E+01 0.002 0.000 0.000 1.00E+04 0.00 4.00E+02 0.032 0.006 0.000 1.00E+05 0.01 6.00E+03 0.480 0.096 0.005 OLAP 1.00E+06 0.08 8.00E+04 6.400 1.280 0.064 1.00E+07 0.80 1.00E+06 80.000 16.000 0.800 1.00E+08 8.00 1.20E+07 960.000 192.000 9.600 1.00E+09 80.00 1.40E+08 11200.000 2240.000 112.000 1.00E+10 800.00 1.60E+09 128000.000 25600.000 1280.000 1.00E+11 8000.00 1.80E+10 1440000.000 288000.000 14400.000 Demo
  47. 47. Ausführungsplan• Eine Ausführungsplan (QEP) bestimmt, mit welchen Indexzugriffen, mit welchen Join-Methoden usw. eine Abfrage durchgeführt wird.• Der Ausführungsplan ist eine Baum-Struktur, deren Blätter Tabellen oder Indices sind. Die Wurzel des Baumes ist das Resultat der Abfrage. Geschätzter Zeitbedarf. Abgleichen mit Testmessung!
  48. 48. OptimierungshinweiseIdentifikation von kritischen Teilen des Ausführungsplanes! Auf Primär- und Fremdschlüsselattributen einen Index erstellen. Für Attribute, die häufig in der order by Klausel auftreten, einen Index erstellen. Indices beschleunigen Abfragen, aber verlangsamen Änderungen. Der Boolsche Operator NOT und der Vergleichsoperator <> sind nicht optimierbar. Ausdrücke mit dem Vergleichsoperator LIKE sind nur optimierbar, wenn allfällige Wildcards nicht am Anfang des Suchmusters stehen. Ausdrücke mit einem Funktionsaufruf über einem Attribut sind nicht optimierbar.  Berechnete Hilfsattribute, welche indexiert werden, z.B. create table Messung ( messwert numeric(6,2), grenzwert numeric(6,2), messwertRelativ as messwert / grenzwert persisted ) create index ix_messwertRel on Messung( messwertRelativ )
  49. 49. Spezielle Indexe• Pro Tabelle ist ein Clustered Index möglich. Der Clustered Index enthält in den Blattknoten direkt die Datensätze.• Ein Index heisst covering, wenn er alle Attribute enthält, die in der Abfrage gebraucht werden (insbesondere im Select-Teil). Für breite Tabellen kann ein Covering Index aus häufig benützten Attributen sinnvoll sein.• Bitmap Indexe sind extrem schnell für Attribute mit wenig Werten (z.B. Geschlecht, Zivilstand, Farbe). Nur einige DMBS unterstützen Bitmap Indexe, z.B. Oracle.
  50. 50. Demo Query-Optimizer SQL Server 2008• Table Scan• Verwendung eines Index – Abfrage selektiv – Abfrage zuwenig selektiv• Lookup Join – mit Index auf einer Tabelle – mit Index auf beiden Tabellen• Merge Join• Sortierung

×