Commit ?

[HEBORA]

Hallo,

wir haben hier neue Handscanner in der Verladung im Einsatz.
Nun kommt es vor, das ganze Touren nach dem Scannen wieder aus einen Teil der Datentabellen verschwunden sind.
Auf den Scannern wird mit einem Telnetprogramm gearbeitet.
In dem SQLRPGLE-Programm gibt es 3 SQL-Statements die lediglich einen Parameter setzen. z.B.:
EXEC SQL SET :PARM1 =
(select sum(t01.mng5)
from DATEI1 t01 join DATEI2 t02
on t01.mdt = t02.mdt
and t01.artnr = t02.artnr
where t01.mdt = :MDT
and t01.palcodih = :T_BARCODID
and t01.s2stat = ' ');
Ich kann mir nicht vorstellen, das das Problem an den Scannern liegt aber auch nicht an den Programm, denn läuft nun schon 6 Monate. Wird allerdings bei Datenbankumstellungen immer mal wieder umgewandelt.
Zur Umwandlung: gibt es eigentlich sowas wie eine optimale Einstellung der Umwandlunsparameter? -- Besonders im Bereich COMMIT, CLOSQLCSR , ALWBLK ... also alles, was mit SQL zusammenhängt

Und gibt es eine gute Dokumentation in Deutsch und nicht Neudeutsch (das kann ich nämlich nicht)

Gruß Heinfried

[BenderD]

... die gültigen Umwandlungsoptionen für SQLRPGLE *PGM Objekte bekommt man mit PRTSQLINF.
Ansonsten empfiehlt sich die zu schreibenden Tabellen zu journalisieren, dann sieht man ganz genau, was da abgeht.

D*B

[HEBORA]

Die Tabellen sind journalisiert. Doch leider sind aus Platzgründen z.Z. nur ca. 2 Stunden auf der Maschine. Das bedeutet, das es kaum eine Chance gibt dort etwas zu finden, da die Jungs in der Verladung erst Stunden oder gar ein bis 2 Tage später den Fehler bemwerken.

Gibt es bestimmte Regeln bei embedded SQL, die einzuhalten sind, damit die Daten sicher gelöscht, geändert oder geschrieben werden?
Reicht ein einfaches "COMMIT" nach jeder SQL-Anweisung?

Standarteinstellungen für CRTSQLRPGI sind zur Zeit:
COMMIT(*CS)
OPTION(*SYS *NOEXTIND *COMMA )
TGTRLS(V7R1M0)
ALWCPYDTA(*OPTIMIZE)
CLOSQLCSR(*ENDMOD)
RDB(*LOCAL)
DATFMT(*DMY)
DATSEP('.')
TIMFMT(*HMS)
TIMSEP(':')
DFTRDBCOL(*NONE)
DYNDFTCOL(*NO)
MONITOR(*USER)
SQLCURRULE(*DB2)
ALWBLK(*READ)
DLYPRP(*NO)
DYNUSRPRF(*OWNER)
USRPRF(*NAMING)
SRTSEQ(*HEX)
LANGID(DEU)
RDBCNNMTH(*DUW)
SQLPATH(*LIBL)
DECRESULT(31 31 0)
DECFLTRND(*HALFEVEN)
CONACC(*DFT)
STATEMENT TEXT CCSID(65535)


Gruß Heinfried

[BenderD]

... bei COMMIT(*CS) (alles außer *NONE) kommt beim end activation group automatisch ein Rollback - und fort ist...
Außerdem hält das Programm alle Satzsperren der geänderten/eingefügten Sätze, beides klassische Kunstfehler.
Commit klammert Transkationen und nach jeder kompletten Transaktion wird selbige mit commit oder rollback geschlossen.

D*B

PS: ein paar Platten vom Broker sind billiger als 2 Tage Fehlersuche!

[dabeda]

Also nach jedem Statement ein Commit zu machen, ist sinnfrei.
Da braucht ihr dann gar kein Commitmentcontrol.

Wenn ein Set abgearbeitet ist, z.B.
setzen Variable
-> Fehlerprüfung -> Fehler = Rollback
-> kein Fehler = update auf Tabelle
-> Fehlerprüfung -> Fehler = Rollback
kein Fehler = insert
usw.
wenn immer noch kein Fehler -> COMMIT

Wichtig ist nach jedem Statement den SQLSTATE oder SQLCODE zu prüfen und darauf zu reagieren.

Kann es sein, dass die Telnetverbindung zur Maschine zwischenzeitlich abbricht?

[Fuerchau]

Journalisierung und Commit hat nichts damit zu tun, ob die Daten sicher auf der Platte sind.
Die AS/400 puffert hier alles (im Normalfall) und schreibt das irgendwann auf die Platte.
Das ist auch der Grund, dass die Maschine massiv langsamer wird, wenn die Cachebatterie leer ist, da hie immer sofort physisch geschrieben werden muss.

In einer PF kann man sicherlich mit FRCRATIO(1) das physische Schreiben zu lasten der Performance erzwingen.
Dies sollte man unterlassen und genug Saft bei Stromausfall zu haben, der alle Puffer schreibt und die Maschine dann runterfährt.

Mit Journalisierung und Commit werden beim plötzlichen Runterfahren und neuem IPL die Commitgrenzen ermittelt und die Daten konsistent wiederhergestellt.
Das enthebt niemanden davon festzustellen, was denn gerade so gemacht wurde um "fehlende" Transaktionen (die also vom System zurückgedreht wurden) nachzuarbeiten.
Allerdings ist das während meinem Arbeitsleben mit der AS/400 noch nie vorgekommen.

Ansonsten ist eben alles, was zu einer "Transaktion" gehört mit einem Commit abzuschließen.
Über den Begriff Transaktion lässt sich wieder herrlich streiten.
Wichtig ist hier allerdings, dass eine Transaktion nicht durch einen Benutzereingriff (also warten am Bildschirm) unterbrochen werden darf.
Z.B.
Auftragerfassung - Positionsteil
- Position schreiben
- Auftragsbestand schreiben
- Lagerbestand prüfen, bei Sofortlieferung (Kasse) gleich buchen
- sonstige Aktivitäten in diesem Context
- Commit

Tritt nun z.B. beim Lagerbestand ein Problem auf kann ich einen Rollback machen und alle vorherigen Aktivitäten bis zum letzten Commit/Rollback werden rückgängig gemacht.

Was also eine Transaktion genau ist liegt in der Funktion der Anwendung.

[hel400]

Bitte nicht böse sein, aber bei 2 Dingen muss ich hier widersprechen:

FRCRATIO(1) hat nichts mit Cache oder Cachebatterien zu tun, sondern betrifft ausschließlich die Blockweise Satzausgabe bei Output-Dateien.

Weiters ist es so, dass auch bei FRCRATIO(1) der Satz NICHT zwangsweise sofort physisch auf die Platte geschrieben wird, das bestimmt ausschließlich der Plattencontroller. Es wird damit nur gesagt, dass dieser Satz sofort an den Controller "übergeben" wird, ohne auf weitere Sätze zu warten.
(einen diesbezüglichen Hinweis dazu gibt's übrigens auch in der Umwandlungsliste).

Wäre die Pufferung tatsächlich von der Cachebatterie abhängig, dann gäbe es bei gespiegelten Platten nur sofortige (synchrone) Plattenausgaben, weil es beim Mirroring ja gar keine Cachebatterien gibt ...

[KingofKning]

Wäre die Pufferung tatsächlich von der Cachebatterie abhängig, dann gäbe es bei gespiegelten Platten nur sofortige (synchrone) Plattenausgaben, weil es beim Mirroring ja gar keine Cachebatterien gibt ...

Wieso gibt es da keine Cachebatterie? Kann mir nicht vorstellen das bei modernen Raid-Controllern kein Cache vorhanden ist unabhängig wie der jetzt die Platten beackern soll.

Vielleicht meinst Du ja was anderes?

GG

[hel400]

Nein :-) ich meine nichts anderes.
Ich denke, dass hier Einiges verwechselt bzw. vermischt wird - kann man auch an Deiner Antwort sehen.
Bei gespiegelten Platten gibt's keine Cachebatterie. Das heißt aber NICHT, dass es keine "Pufferfunktion" (wie auch immer man die nennen will) gibt, allerdings hat das nichts mit dem Raid5-/Rai6-Cache zu tun.

Auf der AS/400 haben wir ja bekannterweise das sogenannte "Einspeicherkonzept".
Das bedeutet nicht nur, dass alle Platten als EINE Einheit gesehen werden (das kann ja jeder Raidcontroller), sondern für den Programmablauf werden Platten und Hauptspeicher als EINES gesehen.
Sobald ein Datensatz zB mit WRITE ausgegeben wird, befindet er sich also entweder im HSP oder auf Platte - das regelt aber der jeweilige Controller.
Selbst wenn der Satz noch nicht auf Platte sondern "nur" im HSP steht, so steht er trotzdem allen anderen zur Verfügung (READ, CHAIN ..).

Was nun das oben erwähnte FRCRATIO(1) betrifft: Bei WRITE-Operationen ist es ja so, dass das System nicht jeden Satz sofort schreibt, sondern wartet, bis mehrere Sätze ("Puffer") zusammengekommen sind, dann werden diese als Block ausgegeben (einen diesbezüglichen Hinweis dazu gibt's übrigens in jeder RPG Umwandlungsliste, soferne eine Outputdatei definiert ist).
Gibt man nun FRCRATIO(1) an (oder verwendet die RPG-Anweisung FEOD!), so wird der Satz sofort ausgegeben, ohne auf einen ganzen Block zu warten.

Natürlich wird hier gepuffert oder gecached, was das Zeug hält, egal ob Raid5/6 oder 1 (Spiegelung).
Da bei Raid5+6 aber noch zusätzliche Rechnereien gemacht werden müssen, gibt's hier einen weiteren Schreibcache - dieser wird mit Batterie gepuffert, Batterie daher nur bei Raid5+6 Platten.

Das ist jetzt mal die salopp aufgezählte Einfachvariante. Natürlich gibt's da im Detail noch Einiges mehr, nicht zu vergessen den "Expertcache" für die Lesezugriffe u. die weiteren Optimize-Values.

[B.Hauser]

Reicht ein einfaches "COMMIT" nach jeder SQL-Anweisung?

Standarteinstellungen für CRTSQLRPGI sind zur Zeit:
COMMIT(*CS)
OPTION(*SYS *NOEXTIND *COMMA )
TGTRLS(V7R1M0)
ALWCPYDTA(*OPTIMIZE)
CLOSQLCSR(*ENDMOD)

Wo wird der Commit überhaupt gesetzt? Innerhalb des Moduls? Irgendwann nach der Ausführung des/der SQL-Statements oder nicht innerhalb des Moduls?
Erfolgt kein Commit innerhalb des Moduls, könnte die Option CLOSQLCSR=*ENDMOD den Rollback verursachen. Beim Beenden des Moduls werden die ODPs gelöscht (was im Allgemeinen sowieso keine allzu gute Idee ist). Da die Updates vor dem Schließen der ODPs nicht commitet werden, könnte es sein, dass die nicht festgeschriebenen Änderungen zurückgesetzt werden.

Birgitta

[Fuerchau]

Cursor (sind nur zum Lesen) haben mit ODP's nicht viel zu tun.
Cursor werden geschlossen, wobei die ODP's zur Optimierung aufbleiben können.
Da ein Cursor keine Daten ändern kann (for-update-Cursor benötigen einen Update) wüsste ich nicht, wie das Schließen einen Rollback auslösen kann.

[Fuerchau]

FRCRATIO(1) ist nicht zu verwechseln mit SEQONLY(*YES/*NO).
FRCRATIO(1) hat direkte Auswirkung auf die Performance.
In simpler CPYF wird u.U. um Faktor 1000 langsamer bei eingeschaltetem FRCRATIO(1), was halt mit der Kontrolle zu tun hat, ob der Satz auf der Platte ist oder nicht.

Was die RPG-Pufferung angeht, so trifft diese nur bei I und O-Dateien zu.
Hier wird erst mal nur durch die Runtime "gepuffert" bevor die Daten an das OS abgegeben werden.
Wobei durch FRCRATIO(1) dieses wieder ausgeschaltet wird (ominöse Log-Meldung "Zugriff wurde in SEQONLY(*NO) geändert").

Ich habe in einer Altanwendung allein durch abschalten des FRCRATIO Laufzeiten von Stunden in Minuten gekürzt.