Concurrency Datenkonsistenz & Datensicherheit

Problemstellung

Überweisung von Konto1 auf Konto2.

Die Daten werden in einer Tabelle gespeichert:

Kontonummer	Saldo
1	100
2	200

update Konto set Saldo = Saldo - 50 where KtoNr = 1; update Konto set Saldo = Saldo + 50 where KtoNr = 2;

Was ist das Problem, wenn der Rechner während der Verarbeitung „abstürzt“?

Lösung:

begin transaction; 
   update Konto set Saldo = Saldo - 50 where KtoNr = 1; 
   update Konto set Saldo = Saldo + 50 where KtoNr = 2; 
commit; 

Überweisung von Konto1 auf Konto2. Das soll aber nur dann möglich sein, wenn für eine entsprechende Kontodeckung gesorgt ist.

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; 
}
update Konto set Saldo = Saldo - 10 where KtoNr = 1;

Was ist das Problem, wenn zwischendurch eine andere Überweisung von Konto1 stattfindet?

Lösung:

begin 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;

isolation level serializable bedeutet, dass das selbe Ergebnis erzielt wird, wenn die beiden Transaktionen hintereinander ausgeführt geworden wären.

Concurrency

In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors.

Multiversion concurrency control (MCC, MVCC, multi-generational concurrency control) ist ein Verfahren aus der Datenbanktechnik, das dazu dient, konkurrierende Zugriffe auf eine Datenbank möglichst effizient auszuführen, ohne zu blockieren oder die Konsistenz der Datenbank zu gefährden.

(Wikipedia – 26. 10. 2015)

Konsistenz und Transaktion

Ein konsistenter Zustand der Datenbank bedeutet die Korrektheit der in der DB gespeicherten Daten.

Es muss sichergestellt werden, dass ein konsistenter DB-Zustand durch eine Benutzermanipulation in einen wiederum konsistenten Zustand übergeführt wird. Zwischen den beiden konsistenten Zuständen befindet sich die DB in einem inkonsistenten Zustand.    Die Concurrency Control sichert die korrekte Ausführung nebenläufiger Transaktionen.

Philosophenproblem

Das Dining-Philosophers-Problem bringt die Concurrency Problematik auf den Punkt. Es geht um den konkurrierenden zugriff auf Betriebsmittel, der zu einem Deadlock führen kann.

Wenn ein Philosoph hungrig ist, greift er zur linken Gabel, dann zu rechten Gabel und beginnt zu essen. Wenn er satt ist, legt er die Gabeln weg und beginnt wieder zu denken.

Kein Problem, wenn nur einzelne Philosophen speisen wollen. Wenn aber alle Philosophen gleichzeitig essen wollen, greifen alle Philosophen zur linken Gabel (das funktioniert noch), scheitern aber, wenn sie zur rechten Gabel greifen wollen (deadlock). => Synchronisierungsproblematik

Nebenläufigkeit

Zwei Prozesse A und B heißen nebenläufig, wenn sie voneinander unabhängig bearbeitet werden können. Dabei ist es egal, ob zuerst der Vorgang A und dann B ausgeführt wird, oder ob sie in umgekehrter Reihenfolge abgearbeitet werden oder ob sie gleichzeitig erledigt werden.

Beispiel

Gegeben sind 2 Prozesse A und B

A bestehe aus den Schritten 1 und 2
B bestehe aus den Schritten 1 und 2 und 3

Nebenläufigkeit (allgemeiner als Parallelität), bedeutet die Ausführung der beiden Prozesse in verschiedenen Ausprägungsformen: 

Die Ausführung parallel auf verschiedenen Rechnern:

• A1 A2
• B1 B2 B3

  Die sequentielle Ausführung auf 1 Rechner:

• A1 A2 B1 B2 B3

oder

• B1 B2 B3 A1 A2

  Die verzahnte Ausführung auf 1 Rechner:

• A1 B1 A2 B2 B3

Parallele Prozesse

Nebenläufige Prozesse heißen parallel, wenn sie aufeinander keinen Einfluss ausüben – also unabhängig sind.   Zwei Prozesse können auf 1 CPU nebenläufig, aber nicht parallel ablaufen.

2 Rechner, die nicht miteinander verbunden sind, arbeiten vollständig parallel.

Zusammenfassung

• 2 Prozesse heißen nebenläufig, wenn sie voneinander unabhängig bearbeitet werden können.

• Für 2 nebenläufige Vorgänge ist es irrelevant, wie sie ‚zeitlich zueinander liegen‘.

• Nebenläufigkeit ist damit ein allgemeinerer Begriff als Parallelität.

Konsistenz

• Ein konsistenter Zustand der Datenbank bedeutet die Korrektheit der in der Datenbank gespeicherten Daten („innere Widerspruchsfreiheit“)
• Es muss sichergestellt werden, dass ein konsistenter Zustand einer Datenbank durch eine Benutzermanipulation in einen wiederum konsistenten Zustand übergeführt wird. Zwischen den beiden konsistenten Zuständen befindet sich die Datenbank in einem inkonsistenten Zustand.
• Durch Recovery- Funktionalitäten wird sichergestellt, dass Soft- und Hardwarefehler die Konsistenz von Daten nicht beeinträchtigen.

Grundstruktur einer Transaktion

Das Wort Transaktion leitet sich vom lat. trans (hinüber) und Agere (handeln, führen) also Überführen her.

Das Prinzip ist, die Überführung von einem konsistenten Zustand zum nächsten.

Begin of transaction    -- BOT
	Read x
	Write y
End of transaction      -- EOT

Das ausführende System muss sicherstellen, dass immer entweder beide Aktionen ausgeführt werden oder keine der Aktionen ausgeführt wird.

Eine Transaktion wird auch als LUW (logical unit of work) bezeichnet.

Die Reihenfolge der Operationen innerhalb einer Transaktion kann nicht geändert werden.

Darstellung als gerichteter Graph:

r[x] => w[x] => r[y] => c
           r[z]

r[x] => w[x] und r[z] können gleichzeitig ausgeführt werden.

ACID

• Atomic: alle oder keine Operationen einer Transaktion
• Consistency preserving: vollständige Transaktionsausführung einer Transaktion bewahrt die Konsistenz der Daten (event. über inkonsistente Zwischenzustände)
• Isolated: gewährleisten Schutz vor parallelen Datenbankzugriffen anderer Transaktionen (virtueller Einbenutzerbetrieb)
• Durable: alle Transaktionsergebnisse sind nach Transaktionsende dauerhaft.

Transaktion

Eingabe: anr_alt, anr_neu ...

EXEC SQL WHENEVER SQLERROR GOTO undo;
EXEC SQL UPDATE artikelstamm
         SET anr = :anr_neu
         WHERE anr = :anr_alt;
EXEC SQL UPDATE bestellungen
         SET anr = :anr_neu
         WHERE anr = :anr_alt;
EXEC SQL COMMIT WORK;
undo:
EXEC SQL ROLLBACK WORK;

die Datenbank durchwandert während einer solchen LUW inkonsistente Zwischenzustände

Commit / Rollback

Auswirkungen von COMMIT:

• eine Transaktion wird erfolgreich beendet
• von der Transaktion geänderten Daten werden in die DB übernommen
• andere Prozesse sehen ab diesem Zeitpunkt die geänderten Daten
• alle von der Transaktion gesperrten Ressourcen werden freigegeben

Oracle führt nach jedem DDL Statement ein implizites COMMIT aus.

Auswirkungen von ROLLBACK:

• eine Transaktion wird erfolglos beendet
• alle von dieser Transaktion geänderten Daten werden auf den ursprünglichen Wert zurückgesetzt, wobei die ursprünglichen Werte aus dem Rollback Segment gewonnen werden
• alle von der Transaktion gesperrten Ressourcen werden freigegeben

Die Daten werden aber zum COMMIT Zeitpunkt nicht zwangsweise physisch geschrieben, sondern es wird nur ein kurzer, die Transaktion beschreibender Eintrag in den REDO Log File geschrieben.

Beispiel Commit

CREATE TABLE accounts (account_id NUMBER(6), balance NUMBER (10,2));
INSERT INTO accounts VALUES (7715, 6350.00); 
INSERT INTO accounts VALUES (7720, 5100.50); 
DECLARE
  transfer NUMBER(8,2) := 250;
BEGIN
  UPDATE accounts SET balance = balance - transfer WHERE account_id = 7715;
  UPDATE accounts SET balance = balance + transfer WHERE account_id = 7720;
  COMMIT COMMENT 'Transfer From 7715 to 7720' WRITE IMMEDIATE NOWAIT;
END;
/

Beispiel Rollback

CREATE TABLE emp_name AS SELECT employee_id, last_name FROM emp;
CREATE UNIQUE INDEX empname_ix ON emp_name (employee_id);
CREATE TABLE emp_sal AS SELECT employee_id, salary FROM emp;
CREATE UNIQUE INDEX empsal_ix ON emp_sal (employee_id);
CREATE TABLE emp_job AS SELECT employee_id, job_id FROM emp;
CREATE UNIQUE INDEX empjobid_ix ON emp_job (employee_id);

2-Phasen Commit

Verteilte Transaktion

Es gibt 2 Arten von verteilten Transaktionen. Flache Transaktionen besitzen eine Hierachieebene, verschachtelte Transaktionen besitzen mehrere Hierachieebenen.

Read Only Transaktion

Werden verwendet, wenn in einer Transaktion mehrfache Abfragen auf eine andere Transaktion „treffen“, die dieselben Tabellen ändert. In dieser Situation wird durch read only transactions die Performance verbessert.   Nach der Festlegung einer Transaktion als read only transaction sehen alle nachfolgenden Queries nur diejenigen Änderungen die vor dem Start der Transaktion commited worden sind. Read Only hat keine Auswirkung auf andere Transaktionen.

Transaktion 1 read only	Transaktion 2
Start Report
Query Table 1	Update Table 1
Query Table 2	Update Table 2
End Report

COMMIT;

SET TRANSACTION READ ONLY;

SELECT product_id, quantity_on_hand FROM inventories

  WHERE warehouse_id = 5
  ORDER BY product_id; 

COMMIT; -- Ende “read only”

DECLARE

  daily_order_total   NUMBER(12,2);
  weekly_order_total  NUMBER(12,2); 
  monthly_order_total NUMBER(12,2);

BEGIN

  COMMIT; -- ends previous transaction
  SET TRANSACTION READ ONLY NAME 'Calculate Order Totals';
  SELECT SUM (order_total) INTO daily_order_total FROM orders
    WHERE … Bestelldatum Heute;
  SELECT SUM (order_total) INTO weekly_order_total FROM orders
    WHERE … Bestelldatum in der letzten Woche inkl. Heute;
  SELECT SUM (order_total) INTO monthly_order_total FROM orders
    WHERE … Bestelldatum im letzten Monat inkl. Heute;
  COMMIT; -- ends read-only transaction

END; /

Autonome Transaktion

• Eine autonome Transaktion ist eine unabhängige Transaktion, die durch eine andere Transaktion gestartet wird. Es werden keine Sperren weitergegeben.

• Haupttransaktion
  • führt auf bestimmte Tabellen Änderungen durch. Wenn ein Fehler aufgetreten ist, soll ein Rollback durchgeführt werden.

 

• Untergeordnete Transaktion
  • hier werden die in der Haupttransaktion aufgetretenen Fehler / Ausnahmebedingungen protokolliert in der Form, dass ein Eintrag in einer Fehlertabelle durchgeführt wird.

Unter diesen Umständen würde ein Rollback der Haupttransaktion auch die in der Protokolltabelle eingetragenen Fehlermeldungen zurückrollen.   AT laufen in einem eigenen Kontext - sie erlauben es, dass der Fehlereintrag durchgeführt und commited wird, ohne das Ergebnis der Haupttransaktion festzuschreiben.

Geschachtelte Transaktion

Commit Regel

Das (lokale) Commit einer Sub-Transaktion macht ihre Ergebnisse nur der Vater-Transaktion zugänglich. Das endgültige Commit der Sub-Transaktion erfolgt dann und nur dann, wenn für alle Vorfahren bis zur TopLevel-Transaktion das endgültige Commit erfolgreich verläuft.

Rücksetzregel

Wenn eine (Sub-) Transaktion auf irgendeiner Schachtelungsebene zurückgesetzt wird, werden alle ihre Sub-Transaktionen, unabhängig von ihrem lokalen Commit-Status ebenso zurückgesetzt. Diese Regel wird rekursiv angewendet.

Sichtbarkeits-Regel

Änderungen einer Sub-Transaktion werden bei ihrem Commit für die Vater-Transaktion sichtbar. Objekte, die eine Vater-Transaktion hält, können Sub-Transaktionen zugänglich gemacht werden.

Problemfelder

• ACID ist auf kurze Transaktionen zugeschnitten.
• Lange Batchvorgänge können zu einem hohen Arbeitsverlust führen => Rücksetzen der gesamten Aktivität möglicherweise nicht akzeptabel.
• Lange Sperrdauer kann zu einem extrem schlechten Durchsatz führen.
• Sperren vieler Objekte führt zu einer hohen Blockierungsrate.

Probleme mit langlaufenden Transaktionen

„Druck der Dokumente“ für eine Urlaubsreservierung umfasst:

• Flugstatus zeigen
• Flugreservierung durchführen
• Hotelinfo anzeigen
• Hotelreservierung durchführen
• Leihauto reservieren
• Dokumente Drucken

Mehrere ‚Transaktionen‘ werden hintereinander ausgeführt. Wenn bei der vorletzten Aktivität (Leihauto reservieren) ein Problem auftritt, muss die gesamte Transaktion zurückgesetzt werden.

Genau genommen spricht man hier nicht mehr von Transaktionen, sondern von Prozessen, die einer anderen Fehler- / Ausnahmebedingungsstrategie bedürfen.

Die Basis dieser Prozesse oder Prozessketten bilden einzelne Transaktionen. Dort ist die lokale ACID Eigenschaft sichergestellt.

Spezielle Rollbacks (Kompensation)

• Wenn ein zustandsorientiertes Undo – Recovery nicht möglich ist, wird eine logische Kompensation notwendig (Stornierung, Terminabsage)
• Problembereiche dabei:
  • Korrektheit des Kompensationsprogramms
  • Kompensationsprogramm darf nicht scheitern
  • Nicht alle Operationen sind kompensierbar (z.B. Ausgabe eines Betrags beim Bankomat, …). Nicht kompensierbare Operationen sollten an das Ende einer Verarbeitungsfolge gestellt werden.

SAVEPOINT

• Dadurch können längere Transaktionen unterteilt werden verbunden mit der Möglichkeit des partiellen Zurückrollens.

 

• Vor jedem INSERT, UPDATE oder DELETE wird ein impliziter Savepoint gesetzt. Wenn das Statement scheitert, wird auf diesen Savepoint zurückgerollt.

  Anwendungsfall: Aus einer Transaktion heraus werden mehrere Funktionen aufgerufen. Vor jedem Aufruf wird ein SAVEPOINT gesetzt – damit ist es problemlos möglich auf den Zustand vor Start der Funktion zurückzurollen, wenn die Funktionsausführung scheitert.

COMMIT
UPDATE PERS SET GEHALT = GEHALT * 1.5
SAVEPOINT VOR_INSERT
INSERT INTO PROJEKT VALUES ...
SAVEPOINT VOR_DELETE
DELETE FROM PROJEKT WHERE PROJ_NR = 4711
CASE ERROR IS
	WHEN 0		THEN COMMIT
	WHEN 1		THEN ROLLBACK TO VOR_DELETE
	WHEN 2		THEN ROLLBACK TO VOR_INSERT
	WHEN OTHERS 	THEN ROLLBACK;

Beispiel

CREATE TABLE emp_name AS SELECT employee_id, last_name, salary FROM employees; 
CREATE UNIQUE INDEX empname_ix ON emp_name (employee_id); 

DECLARE emp_id employees.employee_id%TYPE; 
        emp_lastname employees.last_name%TYPE; 
        emp_salary employees.salary%TYPE; 
BEGIN 
SELECT employee_id, last_name, salary 
   INTO emp_id, emp_lastname, emp_salary 
   FROM employees 
   WHERE employee_id = 120; 
UPDATE emp_name SET salary = salary * 1.1 WHERE employee_id = emp_id; 
DELETE FROM emp_name WHERE employee_id = 130; 
SAVEPOINT do_insert; 
INSERT INTO emp_name VALUES (emp_id, emp_lastname, emp_salary); 

EXCEPTION WHEN DUP_VAL_ON_INDEX THEN ROLLBACK TO do_insert; 
DBMS_OUTPUT.PUT_LINE('Insert has been rolled back'); 
END; 
/ 

Transaktion und Integrität

Integritätskontrolle erfolgt durch das DBMS: Für welche Operationen welche Überprüfungen durchzuführen sind Wann die Überprüfung durchgeführt werden soll (direkt bei der Änderungsoperation oder verzögert bei Transaktionsende)

CREATE TABLE games (scores NUMBER, CONSTRAINT unq_num UNIQUE (scores) INITIALLY DEFERRED DEFERRABLE); 

Hier wird die Constraint prinzipiell als deferrable (widerruflich) definiert. Initially deferred verzögert die Prüfung bis zum commit

• Durch deferrable kann die Integritätsprüfung bis zum Transaktionsende ausgeschaltet werden – während der Transaktion kann sich die Datenbank ja in einem inkonsistenten Zustand befinden.

• Bei Massenverarbeitung kann die zeitaufwändige Integritätskontrolle an das Transaktionsende verlegt werden – damit wird verhindert, dass jeder einzelne Satz (z.B. bei Insert) geprüft wird.

Transaction Log File

Logging ist das Protokollieren von Änderungen in der Datenbank sowie von Zustandsänderungen der Transaktionen in einer Log – Datei zum Zweck des Recovery.

Recovery durch Log File

Eine Wiederherstellung (recovery) der Datenbank nach einem Fehlerfall erfordert eine Protokollierung (logging) aller Änderungen an der Datenbank um ein UNDO oder ein REDO auszuführen. Ausgangspunkt ist eine Sicherung (backup) der Datenbank.

• Roll Forward Recovery
  • angenommen, ein File wurde zerstört und kann nicht mehr gelesen werden. In diesem Fall wird die letzte Sicherungskopie des Files geladen. Danach werden alle Log Files bearbeitet und alle aufgezeichneten Änderungen des zerstörten Files nachvollzogen.
• Roll Back Recovery
  • angenommen, ein Programm stürzt ab. In dieser Situation wird der Log File 'rückwärts' gelesen und alle aufgezeichneten Änderungen werden mit umgekehrten Vorzeichen wiederholt.

Struktur der Log-Einträge

• Eindeutige Nummer (Log Sequence Number - LSN) zur Identifizierung. Damit wird auch die zeitliche Ordnung bestimmt.
• Eine Transaktionskennung
• Ein Feld Previous LSN über das die Einträge rückwärts miteinander verknüpft sind.
• Einträge, die Beginn, Ende oder Abbruch einer Transaktion kennzeichnen.
• Nur für Änderungsoperationen:
  • Redo – Information: gibt an, wie die Änderung nachvollzogen werden kann
  • Undo – Information: gibt an, wie die Änderung rückgängig gemacht werden kann

Tipps im Umgang mit Log Files

• Oracle Log Miner: zur Analyse von Log Files

• Dadurch kann der Log File betrachtet werden SELECT * FROM v$log;

• • V$LOGMNR_DICTIONARY - The dictionary file in use.
  • V$LOGMNR_PARAMETERS - Current parameter settings for LogMiner.
  • V$LOGMNR_LOGS - Which redo log files are being analyzed.
  • V$LOGMNR_CONTENTS - The contents of the redo log files being analyzed.

Transaction Log

Im folgenden Beispiel werden folgende Einträge durchgeführt: (LSN, TransactionID, PageID, Redo, Undo, PrevLSN)

• LSN (log sequence number) - eindeutige Kennung des Log Eintrags.
• TransactionID - Transaktion, die die Änderung durchgeführt hat
• PageID - Kennung der Seite, die geändert wurde
• Redo - gibt an, wie die Änderung nachvollzogen werden kann
• Undo - gibt an, wie die Änderung rückgängig gemacht werden kann
• PrevLSN - Pointer auf vorhergehenden Log Eintrag der gegenständlichen Transaktion

Beispiel Log File

Logfile Aufbau Schematisch

Log File Speicherhierachie

Log Ringpuffer

Concurrency Control

DBMSe sind Multiuser-Systeme, was bedeutet, dass es erlaubt ist, dass mehrere Transaktionen zur selben Zeit in der gleichen Datenbank ablaufen.In solchen Systemen wird ein Concurrency-Kontrollmechanismus benötigt, damit sich zeitlich nebenläufige Transaktionen gegenseitig nicht beeinträchtigen. Ohne einen solchen Mechanismus können verschiedene Probleme auftreten…

DB Probleme

http://www.internetoekonomie.com/lernmaterialdemosite/module/transaktionen/html/a30.html

Lost Update Problem

Lost Update Beispiel

Das w(x) soll in diesem Fall bedeuten: x = x + 1

Dirty Read (uncommited dependency problem)

Das Phantom Problem

Eine Transaktion liest Daten, welche sie vorher schon gelesen hat, erneut und stellt fest, dass die Daten von einer anderen Transaktion (die seit dem ersten Lesen abgeschlossen wurde) verändert (oder gelöscht oder eingefügt) worden sind.

Das Problem wird aber nicht immer als wirkliches Problem angesehen: es wird eine Entscheidung zu treffen sein, ob mit „consistenten oder current“ Daten gearbeitet werden soll.

Unrepeatable-Read Problem

Locking

• Grundidee:
  • Wenn eine Transaktion A ein Objekt (Tabelle, Datensatz) benötigt und sichergestellt werden soll, dass eine andere Transaktion B keine Veränderung an diesem Objekt vornimmt, dann wird von der Transaktion A ein Lock für dieses Objekt angemeldet.
  • Damit können andere Transaktionen solange keine Veränderungen an diesem Objekt vornehmen, bis das Objekt wieder frei verfügbar ist (z.B. bei Ende von Transaktion A).

Sperrgranularität

Konsequenzen der Sperrgranularität

• Bei zu kleiner Granularität werden Transaktionen mit hohem Datenzugriff ‚gebremst‘, da viele Sperren angefordert werden müssen.
• Bei hoher Granularität werden unnötig viele Objekte gesperrt, was die Parallelität der Verarbeitung negativ beeinträchtigt.

Exclusive Locks (X Locks)

Falls die Transaktion A den Datensatz R durch einen X Lock sperrt, wird eine Anfrage von Transaktion B für den gleichen Datensatz R abgelehnt, egal, ob die Anfrage nach einem X Lock oder S Lock getätigt wurde. Transaktion B wird in einen Wartezustand versetzt und sie wartet, bis der Datensatz R wieder frei ist.

Shared Locks (S Locks)

Falls eine Transaktion A einen S Lock für den Datensatz R aufrechterhält, muss eine X Lock anfordernde Transaktion B warten, bis A den Lock zurücknimmt. Falls die Transaktion B nur einen S Lock anfordert, so wird dieser gewährt. Damit hat nun auch B einen S Lock am Datensatz R.

Kompatibilitätsmatrix

Lockebenen

• Row Lock
  • ist eine Sperre auf einen einzelnen Datensatz. Ein solcher Lock wird angemeldet durch INSERT, UPDATE, DELETE, MERGE und SELECT … FOR UPDATE. Diese Lockart existiert bis zum nächsten Commit oder Rollback.
• Table Lock
  • durch INSERT, UPDATE, DELETE, MERGE und SELECT … FOR UPDATE wird nicht nur ein Row Lock, sondern auch ein Table Lock angemeldet. Mit dem LOCK TABLE Statement kann explizit ein Table Lock angefordert werden.

DML Sperren

Jede DML Operation fordert 2 Sperren an:

• Sperre im ROW EXCLUSIVE Mode für die zu aktualisierende Zeile – unabhängig von der Anzahl der zu sperrenden Zeilen.
• Sperre im SHARE Modus auf Tabellenebene für die zu aktualisierende Tabelle. Damit kann eine andere Transaktion nicht die ganze Tabelle sperren (z.B. durch DELETE, DROP).

DML und DDL

Locking in Oracle

• ein lesender Zugriff braucht keine Sperren
• alle DML Operationen sperren auf Satzebene
• während aller DML Operationen können weitere Prozesse diese Tabellen auch lesen
• Automatisches Locking
  • eine Transaktion führt alle notwendigen Locks durch.
• Explizites Locking
  • in bestimmten Ausnahmesituationen kann es möglich sein, dass ein manuell ausgeführter Lock der aktuellen Situation besser angepasst ist als ein automatischer Lock.
  • Beispielsweise könnte es in dem Fall, dass sehr viele Datensätze einer Tabelle geändert werden, besser sein, die gesamte Tabelle explizit zu sperren, als dass für jeden einzelnen Satz ein automatischer Lock durchgeführt wird. In diesem Fall würde also ein explizites Locking einen Performancegewinn mit sich bringen.

lock table Tabelle in exclusive mode;

Oracle Locktypen

• Exclusive Mode (X)
  • Tabelle ist exklusiv vom Prozess gesperrt
• Share Mode (S)
  • Tabelle ist im read-only Modus gesperrt. Andere Prozesse können die Tabelle ebenfalls im S Mode sperren und die Tabelle lesen, jedoch können von keinem Prozeß DML Operationen durchgeführt werden
• Row Exclusive (RX)
  • Standard Lock Typ innerhalb von Oracle, der weiteren Prozessen RX Locks gestattet. Das Sperren der Tabelle im X oder S Mode durch andere Prozesse ist nicht gestattet.
• Row Share (RS) und Share Update (R)
  • gestattet weiteren Prozessen, RS Locks zu setzen. Andere Prozesse können die Tabelle lesen, aber nicht im X Mode sperren. Andere Prozesse können die Tabelle im S Mode sperren.
• Share Row Exclusive (SRX)
  • andere Prozesse können die Tabelle lesen. Andere Prozesse können die Tabelle nur im RS Mode sperren. Andere Prozesse können die Tabelle weder im X Mode noch im S Mode sperren.

SQL Locks

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE; 
LOCK TABLE table IN EXCLUSIVE MODE; 
LOCK TABLE table IN ROW EXCLUSIVE MODE;

Lock Escalation

Kann in manchen Datenbanken (nicht in Oralce) vorkommen, wenn eine größere Anzahl von Locks auf einer Granularitätsebene (z.B. Zeilenebene) gehalten werden. Das DBMS eskaliert die Locks auf eine höhere Ebene (z.B. Tabellenebene).

Durch Lock Escalation steigt die Deadlockwahrscheinlichkeit.

Szenario:

Durch vielfache Sperre von Zeilen durch Transaktion T1 möchte T1 zu einem table-lock eskalieren – kann das aber nicht, da T2 einen Lock hält. Es kommt zu einem Deadlock, wenn T2 auch eine Lock – Esacalation anfordert.

Lösung Lost Update

Lösung Dirty Read

Lösung Phantom Read

Deadlock

Die vorangegangenen Probleme wurden zwar gelöst, jedoch trat ein neues Problem auf, nämlich ein Deadlock. Das Deadlock-Problem wird verursacht, wenn 2 Transaktionen sich gegenseitig sperren.

Behandlung von Deadocks

• Vermeidung von Deadlocks (Preclaiming):
  • Transaktionen werden erst begonnen, wenn alle ihre Sperranforderungen zu Transaktionsbeginn erfüllt werden können. Problem: die Transaktion ‚weiß‘ zu Beginn (üblicherweise) nicht, welche Datenobjekte auf Grund des Kontrollflusses tatsächlich benötigt werden.
• Zulassung von Deadlocks, Erkennung (Detection) und Behandlung – wie in Oracle

Übung

Versuchen Sie einen Deadlock zu erzeugen und stellen Sie fest, wie Oracle reagiert!

Wartegraph

• Ist eine Detection – Methode
• Ein gerichteter Graph mit den Prozessen als Knoten und den Wartebeziehungen als Kanten wird als Wartegraph bezeichnet.
• Die Knoten entsprechen den Kennungen der derzeit im System aktiven Transaktionen. Wann immer eine Transaktion T2 auf die Freigabe einer Sperre durch eine Transaktion T1 wartet, wird die Kante T2 -> T1 eingeführt.

• Deadlock: Wartegraph weist einen Zyklus auf.

Beispiel Wartegraph

• Die Auflösung eines Deadlocks erfolgt durch Rücksetzen einer an der Verklemmung beteiligten Transaktion.

• T2 wartet darauf, dass T3 die Sperre auf Objekt O1 freigibt. T2 wartet aber auch darauf, dass T5 die Sperre auf Objekt O2 freigibt. In diesem Fall werden beide Deadlocks durch Zurücksetzung von Transaktion T2 aufgelöst.

Deadlock Prevention - Preclaiming

• Durch ein Preclaiming – Sperrverfahren. Dabei fordert eine Transaktion alle benötigten Sperren beim Beginn der Transaktion an. Die Ausführung der Transaktion startet erst dann, wenn auch alle Sperren erworben werden konnten.
• Bei diesen Verfahren werden keine Deadlocks auftreten – allerdings sind Wartezeiten zu erwarten, bis die Transaktion gestartet werden kann, da sie ja auf den Erwerb aller Sperren warten muss.
•  Problem: Zu Transaktionsbeginn ist nicht unbedingt bekannt, welches Objekt (welcher Datensatz) gesperrt werden muss – in der Regel nur die Obermenge (welche Tabelle). Damit würde die Sperrgranularität auf eine unakzeptabel hohe Ebene gehoben werden.

Transaktion 1 Transaktion 2 (Anf. X Lock auf R1) (Anf. X Lock auf R2) (Anf. X Lock auf R2) (Anf. X Lock auf R1)

Beim Preclaiming fordert T1 die Sperren auf R1 und R2. Wenn jetzt die Sperranforderung von T1 an R1 zuerst bearbeitet wird, dann darf T1 ohne Behinderung auch alle weiteren Sperren anfordern (in diesem Fall für R2). Wenn eine Transaktion alle Sperren hält, dann darf sie starten. T2 würde bei der Sperranforderung an R2 in einen Sperrkonflikt eintreten und muss daher warten, bis T1 endet. Der Deadlock wird dadurch umgangen.

Deadlock: Transaction Scheduling

• Dieses Verfahren lässt die parallele Durchführung nur in eingeschränkter Weise zu. Nur solche Transaktionen dürfen sich zeitlich überlappen, die keine gemeinsamen Datenobjekte behandeln. Damit behindern sich die Transaktionen gegenseitig niemals. Dieses Verfahren setzt aber voraus, dass bereits vor dem Ausführen der Operationen feststeht, auf welche Datenobjekte zugegriffen wird. Da man dies i.a. nie ganz genau sagen kann, sind solche Verfahren unnötigerweise pessimistisch.
• Als Konsequenz ergibt sich z.B. statt einem einfachen Lock auf Datensatzebene oft ein Lock der gesamten Tabelle, da eben nicht genau bekannt ist, welcher Datensatz verändert werden wird.

Timeout Verfahren

• Eine Transaktion wird zurückgesetzt, wenn ihre Wartezeit auf ein Objekt auf Grund einer Sperre eine bestimmte Zeitschranke überschreitet. (timeout).
• Schwierigkeit: Wahl der richtigen Zeitschranke.
  • Ein hoher Wert bedeutet, dass die ein Deadlock erst nach langer Zeit aufgelöst wird - Transaktionen sind unnötig lange blockiert. Ein niedriger Wert kann zu einer hohen Anzahl unnötiger Rücksetzungen führen – ohne dass auch tatsächlich ein Deadlock vorliegt.

Serialisierbarkeit

• Eine Menge von parallel ablaufenden Transaktionen ist serialisierbar, falls dabei ein Datenbankzustand DBZ erzielt wird, der auch resultieren würde, falls eine beliebige Form der Hintereinanderausführung der erwähnten Transaktionen erfolgt wäre. (Ausgehend von einem gewissen DB-Zustand DBZ_1 wird sowohl durch die überlappende als auch durch irgendeine serielle Transaktionsausführung derselbe DB-Zustand DBZ_2 erreicht.)

• In serialisierbaren Transaktionen kann kein Deadlock auftreten

Beispiel

Ergebnis der seriellen Ausführung von Transaktion A und B: a wird um 10 erhöht b bleibt gleich c wird um 10 vermindert

2 Schedules

Ablauf 1 ist serialisierbar, da derselbe Zustand wie bei Hintereinanderausführung erreicht wird. Ablauf 2 ist nicht serialisierbar, da folgendes Ergebnis erreicht wird: a = a + 10 b = b - 10 c = c - 10

Abhängigkeit von Transaktionen

• Bei der Betrachtung der Serialisierbarkeit ist festzustellen, ob zwischen Transaktionen eine Abhängigkeit besteht. Eine Abhängigkeit zwischen zwei Transaktionen Ti und Tj liegt vor, wenn Ti vor Tj auf dasselbe Objekt zugegriffen hat und die Operationen der beiden Transaktionen nicht reihenfolgeunabhängig sind.
• Eine Abhängigkeit liegt also dann vor, wenn eine der beiden Operationen auf dasselbe Datenobjekt eine Schreiboperation ist.

Schedule und Wartegraph

• T2 und T3 sind in keinem Abhängigkeitsverhältnis, da sie auf verschiedene Datenobjekte zugreifen. Zwischen T1 und T3 besteht wegen x eine Abhängigkeit, ebenso zwischen T2 und T1 wegen y.
• Der Schedule ist genau dann serialisierbar, wenn der Abhängigkeitsgraph azyklisch ist.
• Serialisierungsreihenfolge: T3 < T1 < T2
• Bewertung dieser Methode: üblicherweise kann erst nachträglich die Serialisierbarkeit von Schedules geprüft werden.

Zwei Phasen Sperrprotokoll

• Phase 1 jede Transaktion setzt die Sperren, die sie setzen kann und beginnt die von ihr gesperrten Datenobjekte zu bearbeiten.
• Phase 2 sobald eine Transaktion ihre erste Sperre löst, darf sie keine neuen Sperren mehr setzen. Lediglich die bereits gesperrten Objekte werden weiter verarbeitet und die gesetzten Sperren nach und nach gelöst.

Gehorchen alle Transaktionen eines DBMS dem2-Phasen-Sperrprotokoll, so ist jede Ausführung jeder Menge parallel arbeitender Transaktionen serialisierbar.

Serialisierbarkeit bedeutet die Lösung des Isolationsproblems der ACID Forderung.

2PL

• Konservatives 2-Phasen-Sperrprotokoll (Preclaiming) �bei welchem zu Beginn der Transaktion alle benötigten Sperren auf einmal gesetzt werden. Dies verhindert in jedem Fall Deadlocks, führt aber auch zu einem hohen Verlust an Parallelität, da eine Transaktion ihre erste Operation erst dann ausführen kann, wenn sie alle Sperren erhalten hat. Weiterhin muss im Voraus bekannt sein, welche Sperren von der Transaktion benötigt werden. Aus diesem Grund wird diese Variante in der Praxis kaum eingesetzt. Es kann bei dieser Variante bereits vor Ende der Transaktion mit der Freigabe gesperrter Objekte begonnen werden.
• Striktes 2-Phasen-Sperrprotokoll, �bei welchem alle gesetzten Sperren erst am Ende der Transaktion (nach der letzten Operation) freigegeben werden. Dieses Vorgehen verhindert den Schneeballeffekt, also das kaskadierende Zurücksetzen von sich gegenseitig beeinflussenden Transaktionen. Der Nachteil ist, dass Sperren häufig viel länger gehalten werden als nötig und sich somit die Wartezeit von blockierten Transaktionen verlängert

Kaskadierendes Zurücksetzen

• Das strikte 2-Phasensperrprotokoll verhindert das kaskadierende Zurücksetzen.
• Durch das Rollback von T1 muss, da A in T2 gelesen wird, auch die Transaktion T2 zurückgenommen werden. Da T3 von T2 und alle folgenden Transaktionen von der jeweilig vorhergehenden Transaktion abhängig sind, müssen alle zurückgerollt werden.
• Übung: simulieren Sie den oben angeführten Schedule in Oracle

Zulassen von Deadlocks

• Manche Situationen treten in der Realität nur sehr selten auf – beispielsweise ein Deadlock. Wie groß ist der vertretbare Aufwand das Problem vorab zu lösen. Sollte nicht vielmehr in dieser Situation das Problem zugelassen werden und dann eine Problemlösung angestrebt werden?

Rücksetzen von Transaktionen - Zeitmarkenverfahren

• Die Grundidee dabei ist, dass jede Transaktion einen Zeitstempel (timestamp) zur eindeutigen Identifikation erhält. Diese Zeitmarke ist als Transaktions-Startzeitpunkt zu betrachten.
• Konflikte werden durch einen Neustart einer im Konflikt befindlichen Transaktion gelöst.
• Ein Konflikt tritt auf, falls eine 'ältere' Transaktion eine Leseanforderung auf ein Datenobjekt absetzt, das bereits von einer 'jüngeren' Transaktion verändert wurde oder falls eine 'ältere' Transaktion eine Updateanforderung auf ein Datenobjekt absetzt, das bereits von einer 'jüngeren' Transaktion gelesen oder verändert wurde.
• Es wird die 'jüngere' Transaktion zurückgenommen und zu einem späteren Zeitpunkt neu angesetzt. Dazu ist es erforderlich, dass jede Transaktion eine eindeutige Zeitmarke erhält. Diese Zeitmarke wird auch bei einem späteren Versuch wieder verwendet. Jede Transaktion bekommt also nur einmal eine Zeitmarke.

Transaction retry

• Fordert eine Transaktion eine Sperre an, die von einer jüngeren gehalten wird, so wartet die ältere bis die Sperre von der jüngeren freigegeben wird.
• Fordert eine Transaktion eine Sperre an, die von einer älteren gehalten wird, so bricht sie sich selber ab (genauer: sie startet neu, allerdings behält sie ihren alten Zeitstempel bei, um so „älter“ zu wirken und ihre Chancen zu erhöhen, diesmal komplett durchlaufen zu können)
• Fordert eine Transaktion eine Sperre an, die von einer jüngeren gehalten wird, so wird die jüngere abgebrochen (genauer: neu gestartet) und die ältere bekommt die Sperre zugewiesen.
• Fordert eine Transaktion eine Sperre an, die von einer älteren gehalten wird, so wartet sie, bis die Sperre von der älteren wieder freigegeben wird.

Wait-Die Beispiel

Read Consistency in Oracle

Garantiert, dass alle Daten, die durch ein einzelnes Query geliefert werden von 1 bestimmten Zeitpunkt stammen – dem Zeitpunkt, zu dem die Query gestartet wurde. In Oracle wird das Problem gelöst, indem zum Lesen die Rollbacksegmente verwendet werden, in denen der frühere Zustand aller veränderten Daten gespeichert ist. Dabei wird eine SCN (system change number) verwendet. Für einen Lesevorgang wird die aktuelle SCN festgestellt. Nur Blocks mit dieser Nummer werden direkt gelesen. Blocks mit einer jüngeren SCN werden aus dem Rollback Segment gelesen.

Isolation

• Die nebenläufige Ausführung von Transaktionen kann zu Problemen führen, die aus der gegenseitigen Beeinflussung resultiert.
• Isolation ist die Trennung von Transaktionen in der Art, dass eine gerade laufende Transaktion nicht von einer parallel laufenden Transaktion in einen undefinierten Zustand gebracht werden kann („Stärke“ des Isolationsgrades von ACID)
• ANSI – SQL – 99 unterscheidet 4 Isolationsebenen:

Isolation Level I

• Read Uncommitted
  • Änderungen aus anderen Transaktionen sind sofort sichtbar, auch wenn diese noch nicht committed sind.
• Read Committed
  • Änderungen einer parallel ablaufenden Transaktion sind erst nach einem commit sichtbar – d.h. ,dass Transaktionen vor Daten geschützt sind, die am Ende einer anderen Transaktion nicht übernommen werden. Default - Einstellung vieler DBMS.

Isolation Level II

• Repeatable Read
  • garantiert, dass wiederholte Leseoperationen mit den gleichen Parametern auch die selben Ergebnisse haben. Üblicherweise wird dies sichergestellt, indem eine Transaktion nur Daten sieht, die vor ihrem Startzeitpunkt vorhanden waren. Eine parallele Änderung führt somit auch nach commit nicht zu Inkonsistenzen während einer Transaktion.
• Serializable
  • garantiert, dass die Wirkung parallel ablaufender Transaktionen exakt die selbe ist wie sie die entsprechenden Transaktionen zeigen würden, liefen sie nacheinander in Folge ab.

Isolation Level III

„Einstellung“ von weniger anspruchsvollen Isolationsstufen dient zur Erhöhung des Grades der Parallelität, gefährdet aber bei fehlerhafter Verwendung die physische Konsistenz der Transaktionen möglicherweise erheblich.

set transaction
   [read only]
   [isolation level
      Stufe 1, 2, 3 oder 4

Anomalien

Folgende Anomalien werden unterschieden:

• Lost Update
• Dirty Read
• Non – Repeatable – Read
• Phantom Read

Non Repeatable Read

• Transaktionsanfang
  • Selektiere alle Benutzernamen mit weniger als fünf erfassten Artikeln (Aktion 1a)
  • Gib die Liste der faulen Benutzer aus
  • Selektiere alle Benutzerdatensätze mit weniger als fünf erfassten Artikeln (Aktion 1b)
  • Gib für diese Benutzer eine genauere Aufschlüsselung aus (Alter des Kontos, genaue Anzahl der Artikel usw.)
• Transaktionsende

Gleichzeitig könnte die folgende Transaktion Bestandteil der bei Erfassung eines neuen Artikels ablaufenden Operationen sein:

• Transaktionsanfang
  • Füge neuen Artikel ein (Aktion 2a)
  • Erhöhe Anzahl der erfassten Artikel des erfassenden Benutzers (Aktion 2b)
• Transaktionsende

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
BEGIN TRANSACTION
 	IF EXISTS(
		SELECT 1
		FROM Theatre.AvailableSeats
		WHERE seat = 'B23')
	BEGIN
 		-- imagine a concurrent transaction
		-- sells seat B23 here and removes the record
		-- from table Theatre.AvailableSeats
 		-- then no rows are returned here:
		SELECT price
		FROM Theatre.AvailableSeats
		WHERE seat = 'B23‘
 		-- and zero rows are affected here:
		DELETE FROM Theatre.AvailableSeats
		WHERE seat = 'B23'
 END
COMMIT

Phantom Read

Isolation Level - Synchronisationsproblem

Dirty Read in Oracle

• set transaction isolation level
  • { read committed | serializable | read only };

Dieses Kommando hat nur für die unmittelbar folgende Transaktion Gültigkeit.

• alter session set isolation_level
  • { read commited | serializable | read only };

Serializable Transactions

Beispiel

Für den Beschäftigten mit empno = 6789 gilt sal = 1234

Recovery

• Bezeichnet alle Maßnahmen zur Wiederherstellung verlorengegangener Datenbestände. Es umfasst insbesondere die Datensicherung zur Vorbeugung sowie das Wiederherstellen eines konsistenten DB-Zustandes im Fehlerfall.

• Mit Hilfe von Recovery-Methoden kann eine DB, die durch einen Fehler in einen inkonsistenten Zustand geraten ist, wieder in einen konsistenten Zustand gebracht werden. (Transaktion entspricht „Unit of Recovery“)

Fehlerarten

• Systemfehler:
  • betreffen alle aktiven Transaktionen, zerstören aber die Datenbank nicht physisch (z.B. Stromausfall).
• Mediumfehler:
  • DB ist teilweise physisch zerstört (z.B. Head Crash)
• Transaktionsfehler:
  • Fehler im Benutzerprogramm, Deadlock, Integritätsverletzung. Ein Recovery ist durch Rücksetzen einer oder mehrerer Transaktionen möglich.

Basisoperationen der Wiederherstellung

• UNDO
  • macht alle bereits ausgeführten Änderungen einer Transaktion rückgängig und stellt damit den konsistenten Zustand wieder her.
• REDO
  • dient zum Wiederholen der Operationen einer bereits abgeschlossenen Transaktion und führt damit zum neuen, wiederum konsistenten Zustand der Datenbank.

= Behandlungsmöglichkeiten

• Transaktions – UNDO
  • nach einem Transaktionsfehler wird diese Transaktion isoliert zurückgesetzt.

• Partielles REDO
  • nach einem Systemfehler werden die noch nicht in die DB eingebrachten Änderungen erfolgreich abgeschlossener Transaktionen wiederholt.

• Globales UNDO
  • nach einem Systemfehler werden die Änderungen der zum Fehlerzeitpunkt noch aktiven Transaktionen rückgängig gemacht.

• Globales REDO
  • nach einem Mediumfehler muss das Backup eingespielt werden und es müssen alle Transaktionen, die seit dem Zeitpunkt der Backup – Erstellung erfolgreich abgeschlossen worden sind, nachvollzogen werden.

Behandlung von Systemfehlern

• Bei den Systemfehlern geht der Inhalt des Hauptspeichers verloren und damit auch alle DB-Puffer. Eine Transaktion, die zu diesem Zeitpunkt aktiv war und noch nicht 'commited' worden ist, kann daher nicht erfolgreich beendet werden und muss beim Neustart des Systems rückgängig gemacht werden. Es kann auch sein, dass Transaktionen, die schon 'commited' worden sind, wiederholt werden müssen, da deren Werte physikalisch noch nicht auf die Datenbank übertragen wurden.
• Frage: Wie weiß das System zum Zeitpunkt des Neustarts, welche Transaktionen rückgängig gemacht werden müssen und welche Transaktionen wiederholt werden müssen?

Checkpoint

• In bestimmten Zeitintervallen erstellt das System automatisch einen Checkpoint

• Bei einem Checkpoint wird der Inhalt aller Datenbankpuffer physikalisch auf die Datenbank geschrieben. Ein spezieller Checkpoint-Datensatz wird in den physikalischen Logfile geschrieben. Er beinhaltet eine Liste all jener Transaktionen, welche zur Zeit des Checkpoints aktiv waren.

Beispiel

• Tf .. Fehlerzeitpunkt
• Tc .. Checkpoint - Zeitpunkt

Bei einem Neustart führt das System folgende Recovery-Prozedur durch:

• 1. Starte mit 2 Transaktionslisten, der UNDO-Liste und der REDO-Liste. Setze die UNDO-Liste gleich der Liste aller Transaktionen aus dem letzten Checkpoint Datensatz, d.h. alle Transaktionen, die zum letzten Checkpoint Zeitpunkt aktiv waren (T2,T3). Setze die REDO-Liste gleich der leeren Liste.

• 2. Suche im Log-File nach vorwärts, beginnend beim Checkpoint Datensatz.

• 3. Falls ein 'BEGIN TRANSACTION' Eintrag im Log-File für eine Transaktion T gefunden wird, dann füge diese Transaktion T in der UNDO-Liste an (T4,T5).

• 4. Falls ein 'COMMIT' Eintrag im Log-File für die Transaktion T gefunden wird, übertrage die Transaktion T von der UNDO-Liste auch in die REDO-Liste (T2,T4).

• 5. Wenn das Ende des Log-Files erreicht wurde, dann beinhaltet die UNDO-Liste die Transaktionen T2,T3,T4,T5 und die REDO-Liste die Transaktionen T2 und T4.

• 6. Nun arbeitet das System den Log-File in rückwärtiger Richtung durch, wobei die Transaktionen in der UNDO-Liste rückgängig gemacht werden und die Transaktionen in der REDO-Liste werden im nächsten Vorwärtsdurchgang wiederholt.

Behandlung von Mediumfehlern

• Ein Mediumfehlern verursacht eine physikalische Zerstörung eines bestimmten Teils der Datenbank.

• Recovery von einem solchen Fehler basiert auf dem Zurücksichern (Reloading) der Datenbank von einer Backup Copy. Anschließend wird der Log-File (Archivteil und aktiver Teil) verwendet, um alle Transaktionen zu wiederholen, welche seit dem letzten Backup fertiggestellt wurden. Es ist nicht nötig, Transaktionen rückgängig zu machen, weil mit dem Rücksichern alle Transaktionen danach verlorengegangen sind.

• Um einen Mediumfehler zu korrigieren, sind also Utilities notwendig, um ein Backup der Datenbank durchführen zu können.