Transaction Control

ROLLBACK und COMMIT

Ziel einer Datenbank ist es, die Datenbank von einem konsistenten Zustand in den nächsten konsistenten Zustand zu überführen.

Stellen Sie sich vor, Sie erhöhen den Preis von 1000000 Produkten um 3 %. Nachdem 700000 Produkte aktualisiert wurden, gibt es einen Fehler. Die Datenbank befindet sich nicht mehr in einem konsistenten Zustand. Der erste konsistente Zustand sind die Produkte vor der Erhöhung und der nächste konsistente Zustand wäre der Zustand nach der Änderung aller 1000000 Produkte.

Führen Sie unter Oracle Einfüge-, Änderungs- oder Löschaktionen aus, so werden die beteiligten Datensätze noch nicht festgeschrieben. Erst durch ein COMMIT werden die geänderten Datensätze wirklich festgeschrieben. Analog zum Festschreiben per Commit gibt es auch die Möglichkeit, die durchgeführten Änderungen rückgängig zu machen. Die Anweisung hierfür lautet ROLLBACK. Wir wollen nun die beiden Anweisungen COMMIT und ROLLBACK in einem kleinen Beispiel etwas genauer betrachten:

insert into dept (deptno,dname) values (50,'MARKETING');
insert into dept (deptno,dname) values (60,'MERCHAND');
commit;

In die Tabelle Abteilung dept werden zwei neue Datensätze hinzugefügt. Diese Datensätze werden mit COMMIT festgeschrieben.

insert into dept (deptno,dname) values (70,'DEP1');
insert into dept (deptno,dname) values (80,'DEP2');
rollback;

In die Tabelle Abteilung dept werden zwei neue Datensätze hinzugefügt. Diese Datensätze zum Abschluss wieder zurückgerollt. Das bedeutet, die beiden Datensätze sind nicht eingefügt worden.

Automatisches COMMIT

Bei einigen Befehlen ist ein automatisches COMMIT eingebaut. Das bedeutet, wenn Sie Ihre Datenbank geändert, aber die Änderungen noch nicht mit COMMIT permanent gemacht haben und dann einen dieser Befehle ausführen, werden die Änderungen automatisch dauerhaft gespeichert. Die gebräuchlichsten Befehle mit einem automatischen COMMIT sind:
ALTER, CREATE, DROP und RENAME.

SAVEPOINT

Das setzen von Savepoints erlaubt interime Labels innerhalb einer Transaktion zu setzen und diese explizit bei einem ROLLBACK anzusprechen. Auch wenn SAVEPOINTS gesetzt sind ist immer ein Gesamt ROLLBACK möglich. Das explizite ROLLBACK zu einem SAVEPOINT macht alle Datenmanipulationen bis zurück zum angegebenen SAVEPOINT rückgängig. LOCKS, welche nach dem SAVEPOINT gesetzt wurden, werden freigegeben. Änderungen vor dem SAVEPOINT können nach einem ROLLBACK TO SAVEPOINT mit COMMIT festgeschrieben bzw. mit ROLLBACK rückgängig gemacht werden.

SAVEPOINTS sind Befehls- und nicht Transaktions-orientiert. Sie werden in Error-Handlers verwendet, um geleistete Arbeit zu schützen. Oracle setzt vor jedem Befehl einen impliziten SAVEPOINT. Dieser ist allerdings nicht explizit (vom User) ansprechbar.

Beispiel: SAVEPOINT / ROLLBACK TO

INSERT INTO personal (name,ort) values ('Meier','Luzern');
SAVEPOINT meier;
INSERT INTO personal (name,ort) values ('Huber','Luzern');
SAVEPOINT huber;
INSERT INTO personal (name,ort) values ('Weber','Luzern');
SAVEPOINT weber;
ROLLBACK TO meier; 
-- Macht eine ROLLBACK bis zum SAVEPOINT meier, der erste INSERT bleibt also erhalten.
COMMIT; 
--Schreibt das erste INSERT fest.

Lesekonsistenz

Nehmen wir einmal an, dass Scott die Tabelle Mitarbeiter (emp) ändert. Er fügt zwei neue Datensätze hinzu.

insert into emp(empno,ename,job) values(21,'Kluge','SALESMAN');
Insert into emp(empno,ename,job) values(22,'Hinze','SALESMAN');

select empno,ename,job from emp where empno between 21 and 22;
EMPNO  ENAME       JOB
 ----------  ----------  --------------------
         21  Kluge       SALESMAN
         22  Hinze       SALESMAN

Die eingefügten Datensätze sind für Scott in seiner Sitzung bereits zu sehen. Und zwar noch bevor er ein COMMIT durchgeführt hat. Ein anderer Benutzer ist ebenfalls am Oracle-Server angemeldet. Auch dieser Benutzer fragt die Tabelle Mitarbeiter (emp) ab:

select empno,ename,job from scott.emp where empno between 21 and 22;

Es wurden keine Zeilen ausgewählt. Die von Scott geänderten Daten sind noch nicht verfügbar. Auch in einer zweiten Session von Scott wären die geänderten Daten noch nicht verfügbar. Erst, nachdem Scott seine Änderungen mit einem Commit bestätigt, sind diese Daten auch für alle anderen am Oracle-Server angemeldeten Benutzer zu sehen. Diese Vorgehensweise wird als Lesekonsistenz bezeichnet. Datenänderungen sind nur in der Sitzung zu sehen, in der die Änderungen durchgeführt wurden.

Übungen 07

Übungen siehe Seite .