View Full Version : SQL-Transaktionen auf AS400?
Souljumper
06-08-09, 12:46
hallo
ich kenne von oracle datenbanken das Transaktionsprinzip und das abschließen bzw. zurückrollen mit commit/rollback.
In wie fern igibts sowas auf der as400? die maschine die ich hier hab, macht nach jedem befehl wohl ein auto-commit.
wie kann man das abschalten?
kann mir wer dazu was sagen?
... bei konsequentem Einsatz von SQL stehen alle default Einstellungen richtig, es muss also für den Einsatz von Transaktionssteuerung nichts anderes getan werden als Transaktionen mit commit/rollback abzuschließen; der default level ist dabei uncommited read. Wenn sich das bei euch anders verhält, dann hat da jemand gestümpert. BTW: diverse Stümpereien sind weit verbreitet (siehe auch so manches, was als Empfehlung ausgegeben wird in diesem Forum) und führen zu unkontrollierbarem Verhalten bei updates per SQL.
D*B
hallo
ich kenne von oracle datenbanken das Transaktionsprinzip und das abschließen bzw. zurückrollen mit commit/rollback.
In wie fern igibts sowas auf der as400? die maschine die ich hier hab, macht nach jedem befehl wohl ein auto-commit.
wie kann man das abschalten?
kann mir wer dazu was sagen?
Souljumper
06-08-09, 14:04
wo finde ich den die einstellungen von sql ? bzw. die sql steuerung?
dann schau ich da mal rein.
... das sind Compileangaben, die bei den Compilebefehlen gemacht werden können, oder mit set option in der Quelle erfolgen; erste Info findet man, wenn man ein PRTSQLINF für das Programm/Serviceprogramm macht.
Wichtig ist noch, dass die Dateien journalisiert werden (was man aus oft aus Unvernunftsgründen unterlässt), das wiederum zeigt ein DSPFD auf.
D*B
wo finde ich den die einstellungen von sql ? bzw. die sql steuerung?
dann schau ich da mal rein.
Souljumper
06-08-09, 14:39
wie ich das so lese wird kein commit gemacht, wie du schon sagtest, read uncommited.
Wenn ich in der "sql-shell" (strsql) einen commit eingebe sagt er mir, das dieses ungültig sei.
"commit oder rollback ungültig"
wo hat das seinen ursprung, das muss man doch auch irgendwo umstellen können?
@ read uncommited: das ist eine der Commit level, die ANSI SQL definiert, verwendet man diese, ist Transaktionssteuerung aktiv und man muss Änderungen mit commit persistent machen. Ohne Commit geht das nur mit auto commit (was die DB2/400 nicht kennt) und ohne Transaktions Steuerung (commit level *none)
@STRSQL: beim STRSQL (prompten mit F4) kann man die Sperrstufe angeben, was auch noch später einstellbar ist, wenn man in der "sql-shell" F13 betätigt.
wobei hier nochmals drauf hingewiesen sei, dass jedes andere commit level als *none journalisierung der Dateien erfordert, was sich allerdings in jedem Fall empfiehlt.
D*B
wie ich das so lese wird kein commit gemacht, wie du schon sagtest, read uncommited.
Wenn ich in der "sql-shell" (strsql) einen commit eingebe sagt er mir, das dieses ungültig sei.
"commit oder rollback ungültig"
wo hat das seinen ursprung, das muss man doch auch irgendwo umstellen können?
Beachte noch Dieters Hinweis der Aufzeichnung im Journal (DSPFD).
Fehlt diese, ist Commit/Rollback unmöglich.
Bei STRSQL musst du vorher einen STRCMTCTL absetzen sonst gehts da auch nicht.
Dateien, die nicht aufgezeichnet werden, können beim Rollback auch nicht zurückgedreht werden.
Eine Änderung mit/ohne Commit von außen führt meist zu gewaltigen Problemen in der Anwendung, wenn diese nichts davon weiß.
Nur die Journalisierung läßt sich durchführen, was allerdings manchmal zu gewaltigen Journalempfängern führen kann (manche Alt-RPG's machen immer einen Chain/Update bzw. READ/UPDATE um Sperren wieder aufzuheben, was zu unnötigen Journaleinträgen führt und im Commit-Fall zu massiven Deadlocks führen wird).
Zunächst mal: Ich würde keinem, der nach COMMITMENT verlangt, Angst machen ...
Einfach und gut (für Anfänger) finde ich den Ansatz, die Datenbibliothek selber nicht mit dem AS400 Befehl CRTLIB sondern im SQL (nach STRSQL) mit dem Befehl CREATE COLLECTION zu erstellen. Dann wird automatisch ein Journal QSQJRN und der erste Journalreceiver erstellt und alle Dateien, die Du danach mit CREATE TABLE erstellst, werden automatisch journalisiert. Damit ist die o.g. Voraussetzung erfüllt.
Im interaktiven SQL (nach STRSQL) kannst Du Deine Session-Attribute mal mit F13 ändern, und zwar den Commitment-Level auf *ALL oder so setzen. Danach kannst Du sofort ROLLBACK und COMMIT ausprobieren. Anschließend bitte mal mit den Alternativen zu *ALL beschäftigen, denn *ALL blockiert geänderte Sätze, bis der aktuelle COMMIT-Zyklus beendet wird (ROLLBACK oder COMMIT).
Bitte nicht vergessen, bei kritischen Updates immer vorher mit F13 nachzusehen, ob das COMMITMENT aktiv ist. Programme machen das z.B. mit dem Befehl StartCommitmentControl (STRCMTCTL) zu Beginn der Anwendung.
Ja, und auf Dauer solltest Du immer mal nachschauen, wieviel Daten sich im Journal-Receiver ansammeln. Evtl. einen Plan machen, wann er aufgeräumt werden soll (z.B. monatlich), oder die Option wählen, daß die AS400 das automatisch macht.
Bei STRSQL musst du vorher einen STRCMTCTL absetzen sonst gehts da auch nicht.
Das stimmt nicht! SQL (interaktives oder auch embedded SQL) führen den STRCMTCTL (mit Unterlassungswerten aus), sofern mit Commitment Control gearbeitet wird und der STRCMTCTL in dem Job noch nicht ausgeführt wurde!
Dateien, die nicht aufgezeichnet werden, können beim Rollback auch nicht zurückgedreht werden.
Wird mit SQL und Commitment Control gearbeitet und wird die Datei nicht aufgezeichnet, führt SQL den Insert, Update oder Delete nicht durch, sondern bringt die Fehlermeldung:
MyTable in MyLib für Operation ungültig.
Wenn man nur eine Transaktionssicherheit gewährleisten will, kann man die Journal-Receiver so definieren, dass sie sobald sie abgehängt werden gelöscht werden. Ein Journal-Receiver bleibt solange geöffnet, bis die letzte angefangene Transaktion beendet wird.
Im interaktiven SQL (nach STRSQL) kannst Du Deine Session-Attribute mal mit F13 ändern, und zwar den Commitment-Level auf *ALL oder so setzen. Danach kannst Du sofort ROLLBACK und COMMIT ausprobieren. Anschließend bitte mal mit den Alternativen zu *ALL beschäftigen, denn *ALL blockiert geänderte Sätze, bis der aktuelle COMMIT-Zyklus beendet wird (ROLLBACK oder COMMIT).
Ich würde nicht gerade mit dem höchsten Commitment-Level *ALL anfangen, bei dem ich mir alles dicht mache, sondern mit dem niedersten UR (uncommitted read) oder *CHG. Ein unter Commit gesperrter Satz kann nur durch den nächsten Commit oder Rollback im gleichen Job wieder freigegeben werden, z.B. der RPG-Befehl UNLOCK oder die Erweiterung (N) ziehen nicht!
... "Schmalspur"-Journaling mit Gewährleistung der Transaktionssicherheit sollte man auf alle Fälle fahren.
Birgitta
... Commit Level *ALL ist keineswegs die höchste Sperrstufe, sondern entspricht in ANSI Sprache dem repeatable read; diese Sperrrstufe ist in Programmen bequem für updates ohne Verwendung eines Cursors, Vorsicht ist angebracht bei Konstrukten wie select max(KundeId), das könnte die ganze Tabelle sperren.
Für interaktives SQL kommen in erster Linie in Betracht:
*CHG (entspricht read uncommited) zur Absicherung von Bulk updates
*CS (entspricht read commited) hiermit lassen sich konsistente Sichten während der Verarbeitung sicherstellen (allerdings nur, wenn die Anwendungen Commit verwenden, tut sie das nicht geht sowas nur im Batch)
BTW: der SQL Standard fordert serializable als default, was im DB2/400 so lausig implementiert ist, dass das mit RLA garnicht verwendbar ist!
D*B
Ich würde nicht gerade mit dem höchsten Commitment-Level *ALL anfangen, bei dem ich mir alles dicht mache, sondern mit dem niedersten UR (uncommitted read) oder *CHG. Ein unter Commit gesperrter Satz kann nur durch den nächsten Commit oder Rollback im gleichen Job wieder freigegeben werden, z.B. der RPG-Befehl UNLOCK oder die Erweiterung (N) ziehen nicht!
... "Schmalspur"-Journaling mit Gewährleistung der Transaktionssicherheit sollte man auf alle Fälle fahren.
Birgitta