Transaktionen ?

[MilloZ]

Hallo Leute,

ja ich bins schon mal wieder. Grund für meine evtl. etwas sinnlosen Frage ist dass in den kommenden Tagen eine wichtige Prüfung in Datenbanken ansteht. Deshalb lese ich zur Zeit sehr viel bezüglich des Themas "Transaktionen" um eine möglichst gute Vorbereitung zu haben. Allerdings stellt sich bei mir folgende Frage:

Gegegeben ist folgende Tabelle einer alten Klausur:

Student (MatrikelNr, Name, Adresse, Telefon, Immatr, Exmatr)
Dozent (DozKn, Name, FB, Raum Telefon)
Vorlesung (Vnr, Name)
Voraussetzungen (Vnr , VorVnr )
Vorlesungsangebot (Vnr , Semester, DozKn , Raum, Zeit)
Pruefung (MatrikelNr , Vnr , Semester , Datum , Note)

Die Frage dazu:

Welcher Eigenschaften muss eine Transaktion besitzen? Bilden Sie Beispiele fur Ihre Aussagen anhand des obigen Datenmodells mit den FH-ublichen Operationen darauf. Wie werden Transaktionen typischerweise unterst¨utzt? Wann werden innerhalb einer Transaktion Integritätsprufungen vorgenommen werden.

Bisher haben wir herausgefunden, dass der Zeitpunkt einer Integritätsprüfung imediate oder dereffered sein kann.
Die Eigenschaften von Transaktionen richten sich nach dem ACID-Prinzip (Atomar etc. )

Meine Frage ist jetzt eher die, wie sich Transaktionen explizit auf obige Tabelle auswirken? Weil irgendwie habe ich das Gefühl habe, dass meine Antworten eher zu allgemein sind aber nicht korrekt die Frage beantworten, könnt ihr mir vielleicht helfen?

[dimitri]

Meine Frage ist jetzt eher die, wie sich Transaktionen explizit auf obige Tabelle auswirken?

Also bei jeder Transaktion erhält die Tabelle einen sog. Share Lock. D.h. die Tabelle ist gegen Änderungen per DDL (Alter table) gesperrt.

Des weiteren werden bei Änderungen ein Bevor Image des Tabellenblocks und ggf. vorhandener Indexblöcke im Undo Tablespace abgelegt und in der Transaktionstabelle auf dem betreffenden Block hinterlegt, wo sich dieses Image genau befindet.
Bei einem Insert wird in der Tabelle kein weiterer Lock angelegt (der Satz ist ja neu) allerdings wird ein evtl. vorhandener Index schon upgedatet und dort der neue Datensatz gelockt.
Bei Update/Deletes ist der Datensatz in der Tabelle und im Index geändert/gelöscht und der entsprechende Satz für Änderungen aussehalb der Session geblockt.

Alle Änderungen sind nur innerhalb der Transaktion sichtbar. Andere Sessions haben keine Möglichkeit diese zu sehen. In Oracle gibt es auch keinen Dirty Read wie z.B. in DB2, MSSQL oder MySql.
Des weiteren blockiert in Oracle eine schreibende Session niemals eine lesende Session und umgekehrt.

Dim

[MilloZ]

poah Danke für die ausführliche Antwort! Aber ich merk schon dass du deutlich mehr Erfahrungen hast als ich ^^ Dein Niveau in der Erklärung ist richtig heftig (im positiven Sinne)

Meinst du kannst diese Sätze auch irgendwie für einen etwas ahnunglosen Studenten erklären ?

Also meinst du kannst mir anhand der Tabelle irgendwie nen verständliches Beispiel schreiben damit wir das irgendwie verstehen?

Wie gesagt Transaktionen usw, der Begriff ist halbwegs klar, aber diesen Begriff so auf die Tabelle anzuwenden erscheint immer noch schwierig und wenn ich ehrlich bin überfordert uns deine ausführliche Erklärung (wofür ich mich nochmals rechtherzlich bedanke) nicht unbedingt weiter um das Problem zu klären :S

[dimitri]

Ok, dann betrachten wir einfach mal die drei DML Typen:

INSERT: Der neue Datensatz wird eingefügt, Indices aktualisiert und diese Daten dort für andere geblockt. Damit wird z.B. auch die Uniqueness sichergestellt, da eine andere Session versuchen würde den gleichen Platz im Index zu schreiben (ein Index ist ja immer sortiert).

UPDATE: Der Datensatz wird in der Tabelle und dem Index geändert, die Werte aber, so wie sie vorher waren, im UNDO hinterlegt. In der Tabelle und im Index werden Verweise angelegt, wo im UNDO die alten Werte stehen. Die entsprechenden Sätze sind geblockt, so dass eine andere Session sie zwar selektieren kann (über dem Umweg UNDO sieht sie den alten Stand) sie aber nicht per Update oder Delete verändern kann solange die Transktion nicht per Commit oder Rollback abgeschlossen ist.

DELETE: Analog zu UPDATE nur, dass die Daten aus der Tabelle und dem Index gelöscht werden. Es verbleibt ein Verweis wo im UNDO die alten Werte stehen. Eine andere Session kann die Daten noch lesen aber nicht mehr ändern bis die Transaktion beendet ist.

UNDO ist ein oraclespezifischer Begriff. Andere Datenbanken verwenden hier z.B. das Wort Transaktionslog o.ä. In jedem Fall wird aber dort der Stand abgespeichert wie er vor der Änderung war. Ich weiß aber nicht, ob das für die Aufgabe relevant ist, da es so scheint, als ob der Fragensteller auch eher rein akademisches Wissen darüber hat - ansonsten hätte er die Aufgabe nicht so seltsam formuliert

Gleiches gilt für den Begriff Share Lock. Auch das kommt aus der Oracle Welt. Der Share Lock verhindert nur, dass die Tabelle nicht per DDL geändert wird, während eine offene DML Transaktion darauf zugreift. Auch hier bin ich mir nicht sicher, ob der Fragensteller das hören möchte.

Dim

[MilloZ]

Hey danke für deine Antwort Hilft schon mal ein ganzes stück weiter ! Vielen Dank, dass du dir nochmal die Mühe gemacht hast es mir etwas ausführlicher zu erklären DANKE!

[javakh]

Heir sind die wischtigsten Eigenschaften der Transaction:

• DML-Anweisungen, die eine konsistente Änderung der Daten bewirken
• Einer DDL-Anweisung
• Einer Anweisung der Datenkontrollsprache (DCL)
• Transaktion beginnt, wenn die erste DML-SQL-Anweisung ausgeführt wird.
• Eine Transaktion endet bei einem der folgenden Ereignisse:
– Eine COMMIT- oder ROLLBACK-Anweisung wird abgesetzt.
– Eine DDL- oder DCL-Anweisung wird ausgeführt (und automatisch
festgeschrieben).
– Das System stürzt ab.

vielen Erfolg, SQL-Expert

[Xpisto]

Transaktionen

Hallo Leute, ich habe auch eine Frage zu Transaktionen.

Zuerst einmal möchte ich euch sagen, wass ich zu Transaktionen bisher weiss, und dann schilder ich euch mein "Problem".

Transaktionen besitzen die Eigenschaften des ACID, das istsoweit klar, ich denke dass muss ich auch nicht weiter erläutern.
EIne Transaktion ist eine in sich geschlossene "Einheit" die Anweisungen durchführt und sie dann in der Datenbank festschreibt mittels commit und zurücksetzt mittels rollback, je nachdem ob die Integritäten eingehaten wurden (commit daraufhin) oder ob diese verletzt wurden (rollback).

Nun meine Frage, ich verstehe den Sinn der Transaktion nicht, wenn man das commit bzw. rollback selber hinter den DML Anweisungen schreiben muss.

Heisst also, ich schreibe ein insert und dahinter schreibe ich commit, daraufhin wurden die Daten festgeschrieben in der Datenbank und die Transaktion ist beendet.

Nun schreibe ich ein rollback hinter dem insert, dass setzt dann alles wieder auf den Ursprung bis zum letzten commit zurück. Welchen Sinn hat dass, wenn ich selber ein Rollback dahinschreibe, dass würde doch heissen dass ich von vornherein weiss, dass meine inserts irgendeine Integritätsverletzung begangen haben....

Ich würde dass alles verstehen wenn diese commits und rollbacks automatisch ausgeführt werden, also wenn ich ein insert schriebe und nachdem alles super lief wird ein commit automatsich gesetzt.
Wenn nun was in meinem Insert schief läuft würde das rollback zum einsatz kommen, dass ist alles verständlich, aber was bringt es mir wenn ich ein commit selber hinter dml anweisungen schriebe oder rollbacks???


Desweiteren hätte ich ein Beispiel und würde mich freuen wenn mir das jemand so bestätigen würde:

Ein Student wird neu angelegt in der Tabelle Student. Die Matrikelnr. wurde auf 111 gesetzt, leider aber war dies ein fehler und diese Matrikelnummer ist schon vergeben (Matrikelnr Primärschlüssel) also ist eine Integritsverletzung vorhanden und es wird ein rollback ausgeführt.

Ist das so richtig?

Und nun den Sinn dahinter wenn ich das rollback manuell hinter diesem insert schreibe? Wenn man doch ein rollback dahinter schriebt, wird doch auf jedenfall dieser ausgeführt oder nicht? ALso wäre der insert der von mir geschrieben wurde für die Katz sehe ich das richtiG?

Würde mich echt freuen wenn mir jemand bei meinem Problem helfen würde, es geht ledglich um einfache Beispiele wie ich es oben z.b. aufgeführt habe.

DANKE schonmal

[dimitri]

Transaktionen besitzen die Eigenschaften des ACID

In Oracle ja, aber es gibt diverse Datenbanken, mit denen man per Dirty Read in eine offene Transaktion hineinsehen kann.

Ich würde dass alles verstehen wenn diese commits und rollbacks automatisch ausgeführt werden, also wenn ich ein insert schriebe und nachdem alles super lief wird ein commit automatsich gesetzt.

Bei nur einem Satz mag das theoretisch stimmen, es gibt aber Transaktionen (und das dürften die Mehrzahl sein) die aus 2, 10 oder tausenden Änderungen bestehen, die allsamt nur dann festgeschrieben werden dürfen, wenn alle korrekt durchgelaufen sind.
Da darf nicht nach jeden DML ein Commit erfolgen (mal davon abgesehen, dass die Performance extrem darunter leiden würde und es in Oracle auch kein serverseitiges Autocommit gibt).

Des weiteren gibt es auch noch Savepoints, mit denen man innerhalb einer Transaktion auf einen bestimmten Stand zurückrollen kann, also einen teilweisen Rollback.

Ein Student wird neu angelegt in der Tabelle Student. Die Matrikelnr. wurde auf 111 gesetzt, leider aber war dies ein fehler und diese Matrikelnummer ist schon vergeben (Matrikelnr Primärschlüssel) also ist eine Integritsverletzung vorhanden und es wird ein rollback ausgeführt.

Nicht ganz. In Oracle wird vor jedem DML implizit ein Savepoint gesetzt. Schlägt die Anweisung fehl, wird auf diesen savepoint zurückgerollt. Beispiel:

insert into tabelle x values(1);
insert into tabelle x values(2);
insert into tabelle x values(1); <-- Fehler

Oracle würde jetzt die letzte Änderung zurückrollen und zwar auf den Savepoint, den es vor dem dritten Insert gesetzt hat. Die ersten beiden Inserts sind also nach wie vor da, und die Transaktion offen.

Und nun den Sinn dahinter wenn ich das rollback manuell hinter diesem insert schreibe? Wenn man doch ein rollback dahinter schriebt, wird doch auf jedenfall dieser ausgeführt oder nicht? ALso wäre der insert der von mir geschrieben wurde für die Katz sehe ich das richtiG?

Mit einem echten Rollback wird die Transaktion auch beendet und die Änderung ist weg (ebenso alle anderen Änderungen die Du in dieser Transaktion gemacht hast).
Der Regelfall wird das aber sicherlich nicht sein, denn, wie Du schon richtig festgestellt hast, sind die Änderungen danach wieder weg.

Dim

[Xpisto]

Ok das war sehr verständlich, nur dieses rollback macht mir einfach irgendwie ein strich durch die rechnung, weil ich den total sinnlos finde.

Ich mache mehrere inserts und schriebe dahinter rollback bin ich denn bekloppt? :P Naja war jetzt bisschen blöd formuliert, aber es ist doch eher sinnvoller wie du schon gesagt hast macht es mehr sinn oracle alles automatsich durchführen zu lassen.

Nehmen wir mal dieses Beispiel für manuelle commits und rollbacks.

drei Studenten sind immatrikuliert

insert into stud values (1);
insert into stud values (2);
insert into stud values (3);

nun mach ich ein commit;

jetzt schreibt sich noch einen studenten ein

insert into stud values(4);

der Student sagt nun ne sry ich will doch nicht an euere uni also mach ich nun ein rollback

Nun sind nur noch die ersten drei studenten eingeschrieben und der letzte ist raus.
So da wäre jetzt ein rollback sinnvoll würde ich sagen.

Dein Beispiel mit den savepoints sind super, das gefällt mir da macht das rollback auch einen sinn, also wenn alles atomatisch gemacht wird ist es ja super und logisch, aber ein echtes ollback hinzuschrieben macht wie gesgat für mich irgendwie wenig sinn, bis auf das Beispiel was ich da eben geschrieben habe. Wäre klasse wenn du mir as bestätigen könntest Grüße

[dimitri]

aber ein echtes ollback hinzuschrieben macht wie gesgat für mich irgendwie wenig sinn, bis auf das Beispiel was ich da eben geschrieben habe. Wäre klasse wenn du mir as bestätigen könntest

Richtig. Meistens ist es so.
Man kann aber z.B. auch DML Statements auf einer Entwicklungsdatenbank testen aber diese dann nicht festschreiben wollen.

Dann läßt man die Statements loslaufen, setzt zuvor einen Rollback dahinter und hat so einen Test, dass alles ok ist.
Anschließend gibt man die Statements (ohne den Rollback) ans Datenbankteam, damit diese dass dann in der produktiven Umgebung einspielen.
Möglich wäre auch, dass man mit einem Programm im Test Änderungen machen möchte, diese aber wiederholt ausführen will. Auch hier würde man den Commit temporär durch einen Rollback ersetzen.

Das wären sinnvolle Anwendungen dieses Falls, die ich öfters verwende.
Ansonsten ergiebt ein Insert, direkt gefolgt von einem Rollback nur wenig Sinn.

Dim

[Xpisto]

Ich bedanke mich für deine ausführliche und verständliche Hilfe, hat mir alles sehr geholfen!