SQL UPDATE und COMMIT im SQLRPGLE

[harkne]

Wird der SET OPTION COMMIT=*CHG bzw. SET OPTION COMMIT=*NONE bei der Umwandlung umgesetzt?
Ich wollte das jetzt parameterabhängig machen, da der Compiler diese Anweisungen aussternt kann das ja nicht funktionieren.
Habe ich eine andere Möglichkeit?

[BenderD]

... gibt es irgendeinen vernünftigen Grund updates per SQL ohne commit zu machen? Ich kenne keinen und etliche, dass SQL update ohne commit ein übler Kunstfehler ist.

D*B

[harkne]

Naja jetzt komm aber. Ich mach doch einen COMMIT nur dann wenn ich sicher gehen will dass alles gemeinsam upgedated ist. Ich muss doch nicht für 10 Mio Sätze alles offen halten wenn es nicht wichtig ist ob er zwischendurch abbricht oder nicht.

In dem Programm hier werden 1-x SQLs aufgerufen. Der der das Programm aufruft entscheidet ob er den COMMIT braucht oder nicht. Die SQLs die ausgeführt werden sind ohne Variablen und liegen in einer Tabelle. Da dieses dann von verschiedenen Programmen aufgerufen wird, wird dort entschieden ob es notwendig ist, das alle unter COMMIT laufen oder nicht.

Ich persönlich verwende fast nie einen COMMIT, es sei denn ich brauche ihn wirklich wenn Abhängigkeiten vorhanden sind.

Ich wollte jetzt eigentlich nur wissen ob es eine andere Möglichkeit gibt dies variabel zu gestalten.

[Fuerchau]

Nun ja, 10 Mio Locks gehen aber ganz schön auf die Performance.
Das wird wohl kein Tagesjob sein sonderen eher am arbeitsberuhigtem WE.

Übrigens: Transaktionen sind Konzepte die i.d.R. keine Millionen von Updates/Insert/Deletes umfassen.

[BenderD]

... commit ist nicht gedacht für Bulk updates von 10 Mio. Sätzen, über commit werden Satzsperren gesteuert, um Transaktionen abzusichern. Bedenken muss man, dass lesen und geändert fortschreiben auch schon eine Transaktion ist!
Für Bulk updates ist es effektiver sich wiederaufsetzpunkte zu setzen, etwa per Timestamp oder Änderungssignaturen.

D*B

[harkne]

Alles gut soweit. Gibt es eine Möglichkeit per Parameter im Programm zu sagen, die UPDATES laufen unter Commit-Steuerung oder sie laufen nicht unter Commit-Steuerung? Oder muss ich jetzt tatsächlich 2 verschiedene Programme aufrufen?

[Fuerchau]

Ob die Updates unter Commit laufen, wird auf Modulebene per Compile-Option bestimmt.
Wenn nicht *NONE angegebene ist, muss ein STRCMTCTL (macht RPG eigentlich automatsch) aufgesetzt werden.
Wird *NONE definiert, wird jeder SQL implizit mit "with nc" ausgeführt, da du ja entschieden hast, an der Transaktion vorbei zu arbeiten.

Da du SQL's je inzwischen auch per CLLE mit RUNSQL ausführen kannst, wäre dies auf dieser Ebene angebbar, da die Commitsteuerung dem Befehl mitgegeben wird.

[harkne]

Ich habe gerade was von Birgitta gelesen

[COLOR=rgba(0, 0, 0, 0.87)]If you compile your program by specifying COMMIT *CHG all files that[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]are changed by SQL UPDATE, INSERT or DELETE statements must be[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]journaled.[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]If you have to manipulate data with SQL, but don't want or can[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]register the file in the journal, you can add WITH NC to the UPDATE,[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]INSERT or DELETE statement. If a ROLLBACK is performed these[/COLOR]
[COLOR=rgba(0, 0, 0, 0.87)]statements are not rolled back.[/COLOR]

Wenn ich das mit deinem (Fuerchau) vergleiche, dann könnte ich das lösen wenn ich *CHG angebe und WITH NC an die SQLs dran hänge wenn es ohne COMMIT laufen soll. Stimmt das so?

[BenderD]

Alles gut soweit. Gibt es eine Möglichkeit per Parameter im Programm zu sagen, die UPDATES laufen unter Commit-Steuerung oder sie laufen nicht unter Commit-Steuerung? Oder muss ich jetzt tatsächlich 2 verschiedene Programme aufrufen?

... das kann man im laufenden Programm mit set transaction isolation einstellen (zurücksetzen nicht vergessen). Als DB2 Erweiterung kann man bei jedem Statement eine isolation clause angeben. Die erste Variante ist näher am Standard. Gewandelt wird dann in jedem Fall mit commit, was ohnehin der Unterlassungswert ist und an dem man tunlichst nicht rumschrauben soll (was irgendwelche Dilettanten per chgcmddft gerne tun).

D*Bl

[harkne]

@Bender Das mit set transaction isolation habe ich gefunden aber nicht verstanden. Heißt das ich mache dann abhängig von meinem Parameter entweder einen SET TRANSACTION ISOLATION LEVEL NO COMMIT den anderen brauche ich ja nicht da ja das automatisch so ist wenn es richtig umgewandelt ist und nachdem meine SQLs durch sind mache ich einen SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ?

[BenderD]

... dabei muss man sicher sein, das man an einer commit Grenze ist. Aber für deinen Bulk update (wenn es denn einer ist) ist das kein gutes Design.

D*B

[harkne]

Was verstehst Du unter BULK-update. Mehrer Sätze? mehrere 1000 Sätze, mehrere Millionen Sätze. Grundsätzlich ist das egal, denn jeder der das Programm verwendet muss wissen was er macht. Deshalb kann er ja sagen mit oder ohne COMMIT. Und was ihr mit Eurer Commit-Grenze meint bin ich mir auch nicht sicher. Was soll das sein? Das ich keinen ENDCMTCTL mache wenn ich noch offene COMMITs habe? oder das ich erst einen COMMIT ausführe wenn ich den Soll und den Haben-Satz geschrieben habe. An dieser Stelle geht es einfach darum, dass wir UPDATES in einer Tabelle ablegen können die nacheinander ausgeführt werden. Die Tabelle hat einen Schlüssel Wenn jetzt jemand das Programm aufruft mit Schlüssel KEY1, werden alle SQLs ausgeführt die unter dem Schlüssel KEY1 augeführt sind. z.B. KEY1 UPDATE DATEI SET STATUS = 'X' WHERE PARTGROUP = 'Y' und dann noch KEY1 UPDATE DATEI SET STATUS = 'V' WHERE PARTGROUP = 'A'. Jetzt entscheidet der der das Programm aufruft ob es ein Problem ist wenn SQL1 ausgeführt wird und SQL2 abbricht. Wenn das kein Problem ist, braucht er meiner Ansicht nach auch keine Commit-Steuerung. Das kann aber nicht ich entscheiden, sondern muss der entscheiden der die SQLs in der Tabelle anlegt und aus seinem Programm aus dann das Programm hier aufruft mit Schlüsselwert um die SQLs auszuführen. Wie gesagt, ich versuche die COMMIT-Steuerung schon immer zu vermeiden wenn ich sie nicht brauche. Und da unterscheide ich nicht zwischen BULK oder gutem Stil oder sonst was. Brauche ich die COMMIT-Steuerung Ja oder Nein. Und es gibt oft die Antwort NEIN.