Transcription

DatenbanksystemeTransaktionenBurkhardt RenzFachbereich MNITechnische Hochschule MittelhessenSommersemester 2021

nRecoveryUrsachen für RecoveryLogging und BackupVorgehen bei el

Beispiel 1Wir wollen eine Überweisung durchführen von Konto 1 auf Konto2.Die Daten der Konten werden in der Tabelle Konto aufgezeichnet:KtoNr12Saldo100100update Konto set Saldo Saldo - 50 where KtoNr 1;update Konto set Saldo Saldo 50 where KtoNr 2;Was passiert, wenn der Rechner mittendrin abstürzt?

Beispiel 1 – mit TransaktionWir wollen eine Überweisung durchführen von Konto 1 auf Konto2.Die Daten der Konten werden in der Tabelle Konto aufgezeichnet:KtoNr12Saldo100100begin transaction;update Konto set Saldo Saldo - 50 where KtoNr 1;update Konto set Saldo Saldo 50 where KtoNr 2;commit;Was passiert, wenn der Rechner mittendrin abstürzt?

Beispiel 2Wir wollen eine Überweisung durchführen von Konto 1 auf Konto2. Sie soll nur möglich sein, wenn das Konto nicht überzogen wird.Die Daten der Konten werden in der Tabelle Konto aufgezeichnet:KtoNr12Saldo100100select Saldo from Konto where KtoNr 1;if (Saldo 60) {update Konto set Saldo Saldo - 60 where KtoNr 1;update Konto set Saldo Saldo 60 where KtoNr 2;}Was passiert, wenn zwischendrin eine andere Überweisung von Kto1 stattfindet?

Beispiel 2 – mit TransaktionWir wollen eine Überweisung durchführen von Konto 1 auf Konto2. Sie soll nur möglich sein, wenn das Konto nicht überzogen wird.Die Daten der Konten werden in der Tabelle Konto aufgezeichnet:KtoNr12Saldo100100begin transaction isolation level serializable;select Saldo from Konto where KtoNr 1;if (Saldo 60) {update Konto set Saldo Saldo - 60 where KtoNr 1;update Konto set Saldo Saldo 60 where KtoNr 2;}commit;Was passiert, wenn zwischendrin eine andere Überweisung von Kto1 stattfindet?

TransaktionDefinitionEine Transaktion ist eine logische Verarbeitungseinheit auf einerDatenbank, die eine oder mehrere Datenbankoperationen(Einfügen, Löschen, Ändern und/oder Suchen) umfasst.Eine Transaktion wird mit dem Befehl commit als gültig erklärtoder mit dem Befehl rollback rückgängig gemacht.

Eigenschaften von TransaktionenACIDAtomarität (atomicity)Konsistenz (consistency)Isolation (isolation)Dauerhaftigkeit (durability)

AtomaritätDefinition (Atomarität)Die Teilschritte einer Transaktion werden vom DBMS als eineunteilbare, atomare Einheit durchgeführt, d.h. alle oder gar keiner.Merke: „Alles oder nichts“

KonsistenzDefinition (Konsistenz)Die Datenbank hat vor und nach einer Transaktion stets einenkonsistenten Zustand, d.h. alle Integritätsbedingungen desDatenbankschemas sind erfüllt.Merke: „Daten bleiben konsistent“

IsolationDefinition (Isolation)Eine Transaktion läuft isoliert gegenüber dem Einfluss andererTransaktionen ab, so als ob sie exklusiven Zugriff auf die Datenhätte.Eventuell wird die Transaktion vom DBMS abgebrochen, weilandernfalls ein unerlaubter Einfluss anderer Transaktionen erfolgtwäre.Merke: „Eine Transaktion hat die Daten quasi allein“

DauerhaftigkeitDefinition (Dauerhaftigkeit)Die Ergebnisse einer bestätigten Transaktion (nach dem Commit)sind dauerhaft gesichert, d.h. das DBMS garantiert, dass bei einemFehler der bestätigte Zustand wiederhergestellt werden kann.Merke: „Nichts geht verloren“

nRecoveryUrsachen für RecoveryLogging und BackupVorgehen bei el

Worum geht es beim Recovery?Atomarität verlangt, dass eine Transaktion vollständig oder garnicht ausgeführt wird.Konsistenz verlangt, dass eine Datenbank auch nach einem Fehlerin einem konsistenten Zustand ist.Dauerhaftigkeit verlangt, dass einmal bestätigte Änderungendauerhaft erhalten bleiben.DefinitionMit Recovery bezeichnet man die Mechanismen eines DBMS umauch nach einem Fehler oder dem Fehlschlagen einer Transaktioneinen ordnungsgemäßen Betrieb in einem konsistenten Zustand zugarantieren.

Abbruch einer TransaktionEine Transaktion kann abgebrochen werden durchBenutzerabbruch – wenn er während einer Transaktioninteraktiv Zugriff hatAusnahmebedingungen – Prüfungen innerhalb derTransaktion, die zu einem Abbruch führenNebenläufigkeitskontrolle – etwa wenn das DBMS eineVerklemmung oder eine Verletzung der SerialisierbarkeitentdecktSystemfehler – etwa bei einer Division durch Null in einerTransaktion

Schwere FehlerDas DBMS kann abstürzen durchSystemabsturz – etwa wegen Stromausfall, Netzausfall,Softwarefehler in der Software des DBMS, DatenfehlerHardware-Ausfall – etwa Plattenfehler, dies betrifft dann nichtnur laufende Transaktionen, sondern auch ältere Daten

Grundlegendes KonzeptUm verlorene Daten durch ein Recovery wieder herstellen zukönnen, braucht man Redundanz.Zwei wichtige Formen:Logging – Der Ablauf von Transaktionen wird laufendmitprotokolliertBackup – Der Zustand der Datenbank wird dauerhaft aufeinem besonderen Medium gesichert

Write-Ahead LogDefinitionEin Systemlog, kurz Log ist eine Folge von Einträgen, die denAblauf und den Inhalt von Transaktionen protokollieren.DefinitionEin Write-Ahead Log ist eine Technik des Protokolls vonTransaktionen, bei der immer zunächst das Log geschrieben wirdund erst dann Änderungen an den Nutzdaten vorgenommenwerden.

Arten der Einträge im LogDaten werden in die Datenbasis immer blockweise geschrieben – inSpeicherblöcken zu z.B. 8 KiloByte.DefinitionEin before image ist der Zustand des von einer Transaktionveränderten Blocks vor der Änderung.Möchte man Änderungen rückgängig machen (undo), benötigtman das before image.DefinitionEin after image ist der Zustand des von einer Transaktionveränderten Blocks nach der Änderung.Möchte man Änderungen wiederholen (redo), benötigt man dasafter image.

Einträge im LogrTn , begins – Beginn der Transaktion mit der Nummer nrTn , update, before-image, after-images – Eintrag überÄnderung eines Blocks innerhalb der Transaktion mit derNummer nrTn , commits – Ende der Transaktion mit commitrTn , aborts – Ende der Transaktion mit Rollbackrcheckpoint, Ti , Tj , Tn s – Checkpoint mit Nummern dernoch aktiven Transaktionen.

Vorgehen beim RollbackBeispiel einer Situation im Log beim Rollback – Die TransaktionT2 wird abgebrochen.Log zum Zeitpunkt des Rollbacks:1: rT2 , begins2: rT3 , begins3: rT3 , update, before-images4: rT2 , update, before-images5: rT3 , update, before-images

Vorgehen beim Systemcrash.10:rT2 , begins11:rT3 , begins12:rT2 , update, before-image,13:rT1 , begins14:rT2 , commits15:rT5 , begins16:rT3 , update, before-image,17:rT5 , update, before-image,18:rT5 , aborts19:rcheckpointT1 , T3 , T4 s20:rT1 , update, before-image,21:rT4 , update, before-image,22:rT6 , begins23:rT4 , commits24:rT6 , update, before-image,25:rT1 , update, fter-imagesafter-imagesafter-imagesafter-images

BackupHardwareTrennung von Log-Dateien und Nutzdaten auf verschiedenePlattenGeeignete Plattensysteme, z.B. RAIDDatensicherungenOffline-BackupOnline-Backup – im laufenden Betrieb, Daten Logs

Beispiel OracleBackupumfasst alle Datenfiles und das Controlfile für eine OracleDatenbankRedologLog mit allen Änderungen an den Datenfiles, gespeichert auf einemMedium getrennt von den DatenfilesRollback SegmentsSpeichert die Undo-Logs für laufende Transaktionen

Beispiel Oracleproving Recovery PerformanceFigure 32–1 Basic Recovery Steps: Rolling Forward and Rolling BackRedoLogRedoLogDatabaseDatabaseRedo LogsappliedBackup ofDatabasethat needsrecoveryDatabaseRollback SegmentsappliedDatabase withcommitted anduncommittedtransactionsDatabase withjust committedtransactionsCommittedUncommittedOracle can roll back multiple transactions simultaneously as needed. Alltransactions system-wide that were active at the time of failure are marked asDEAD. Instead of waiting for SMON to roll back dead transactions, newtransactions can recover blocking transactions themselves to get the row locks theyneed.

nRecoveryUrsachen für RecoveryLogging und BackupVorgehen bei el

Serielle und serialisierbare AbläufeDefinition (Serieller Ablauf)Ein Ablauf von Transaktionen mit ihren Teilschritten heißt seriell,wenn alle Teilschritte einer Transaktion vollständig ausgeführtwerden, ehe die der nächsten Transaktion beginnen.Definition (Serialisierbarer Ablauf)Ein Ablauf von Transaktionen mit ihren Teilschritten heißtserialisierbar, wenn er im Effekt äquivalent zu einem seriellenAblauf ist.D.h. die Transaktionen sind zwar mit ihren Teilschrittenverschränkt, kommen aber nicht in Konflikt zueinander.

IsolationDie ACID-Prinzipien schreiben für eine Transaktion Isolationvor, d.h. eine Transaktion darf nicht durch Aktionen andererTransaktionen beeinflußt werden, also Serialisierbarkeit.Manchmal braucht man jedoch nicht eine so strenge Isolation.Der SQL-Standard sieht deshalb Isolationslevel vor – Gradeder Abschirmung von Transaktionen.Der Standard definiert bestimmte Phänomene derBeeinflussung und dann die Isolationslevel dadurch, inwiefernsolche Phänomene vorkommen können.

Lost Update[1]/Dirty WriteT1T2Saldo100update Kontoset Saldo 200where KtoNr 1200update Kontoset Saldo 250where KtoNr 1250200commitcommit250Die Änderung von Transaktion T2 hat die Änderung vonTransaktion T1 überschrieben.

Dirty WriteT1 geht von einem Saldo von 200 ausT1100T2200250Konto 1

Dirty ReadT1T2Saldo für Konto 1100update Kontoset Saldo 200where KtoNr 1200rollback100select Saldofrom Kontowhere KtoNr 1.T1 verwendet den Wert 200100commitTransaktion T1 hat einen Wert verwendet, der niemals gültig war!

Dirty ReadT1 geht von einem Saldo von 200 ausT1100T2200100rollbackKonto 1

Non-repeatable ReadT1T2Saldo für Konto 1100select Saldofrom Kontowhere KtoNr 1T1 liest den Wert 100update Kontoset Saldo 200where KtoNr 1.commit200select Saldofrom Kontowhere KtoNr 1T1 liest den Wert 200Transaktion T1 kann sich nicht darauf verlassen, dass ein gelesenerWert gültig bleibt!

Non-repeatable ReadT1100T2T1 liest 100200T1 liest 200Konto 1

Falsche Ergebnisse bei Non-repeatable ReadT1T2Saldo Konten 1-340, 50, 30Summe: 120T1 liest Saldo von Konto1 und schreibt den Wert insum, also 40.T2 ändertSaldo von Konto 3auf 20und von Konto 1 auf60commitT1 liest Saldo von Konto2 und addiert den Wert zusum, also 90.T1 liest Saldo von Konto3 und addiert den Wert zusum, also 110.60, 50, 20Summe: 130

Phantom RowT1T2Saldo für Konten100, 100select sum(Saldo)from KontoT1 liest den Wert 200insert into Kontovalues (3,50)commit100, 100, 50select sum(Saldo)from KontoT1 liest den Wert 250Transaktion T1 bekommt Datensätze „untergeschoben“!

Phantom RowT1T1 liest 200100T1 liest 250Konto 1100Konto 250T2Konto 3

Definition der Isolationslevel in SQLDirty ReadNon-RepeatableReadPhantom Rowmöglichmöglichmöglichnicht möglichmöglichmöglichnicht möglichnicht möglichmöglichnicht möglichnicht möglichnicht SERIALIZABLE

BeispielWir wollen eine Überweisung durchführen von Konto 1 auf Konto2. Sie soll nur möglich sein, wenn das Konto nicht überzogen wird.Die Daten der Konten werden in der Tabelle Konto aufgezeichnet:KtoNr12Saldo100100-- begin transaction isolation level serializable;-- begin transaction isolation level read committed;select Saldo from Konto where KtoNr 1;-- hier funkt die 2. Transaktion dazwischenif (Saldo 60) {update Konto set Saldo Saldo - 60 where KtoNr 1;update Konto set Saldo Saldo 60 where KtoNr 2;}commit;Was passiert bei den beiden Isolationsleveln?

T1 liest Saldo von Konto 1 und schreibt den Wert in sum, also 40. T2 ändert Saldo von Konto 3 auf 20 und von Konto 1 auf 60 commit 60, 50, 20 Summe: 130 T1 liest Saldo von Konto 2 und addiert den Wert zu su