[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2011
    Beiträge
    93

    Read commit oder uncommit

    Hallo Gemeinde,
    erstmal wünsche ich allen, ein gesundes und erfolgreiches neues Jahr!

    dann hab ich da noch eine Frage zum System:
    In der DB beim Select gibt es ja verschiedene Level:

    Read Uncommited (RU)
    Read Commited (RC)
    Repeatable Read (RR)
    Cursor Serializable (CS)

    zumindestens nach meiner Internet recherche.
    Nun würde mich intressieren, was ist bei der i5 der Standard? (Denke mal RU)
    Wo (wenn möglich) kann man das umstellen? Oder muss ich das bei der Abfrage mitgeben?

    Vielen Dank!

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ...
    fangen wir mal beim einstellen an:
    - das ist ein session (= Connection) Eigenschaft
    - default ist hierfür, dass in einem Job jede ACTGRP einen eigenen connect hat (Banausen ändern das per STRCMTCTL auf JOB)
    - einstellbar beim:
    -- CRTSQLxxx
    -- STRSQL
    -- per exec sql set transaction isolation level...
    -- per isolation clause bei sql statements (DB2 only, kein Standard
    - default ist:
    -- im SQL/400 uncommited read (auch *CHG genannt)
    -- SQL Standard fordert serializable (was RLA Programme wg. Table Lock abstürzen lässt)
    -- Banausen stellen den default per CHGCMDDFT auf *NONE, weil sie glauben commit brauche man nicht.

    Empfehlung:
    - immer commit verwenden (SQL Programme sind ohne Commit zumeist fehlerhaft)
    - alle Dateien journalisieren
    - konsistente Auswertungen erfordern read commited
    - bei hohem Trasnaktionsvolumen (sprich: konkurrierende Updates sind wahrscheinlich) erfordern sauberes Vorgehen.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Der Standard in SQL ist RC. Allerdings findet das Ganze nur dann statt, wenn STRCMTCTL ausgeführt wird und die betroffenen Dateien journalisiert sind.
    Solange dies nicht durchgeführt ist, ist in der DB2 for i der Zugriff RU oder auch im Sinne von SQL "Chaos".
    Sobald du SQL in z.B. (ILE)RPG verwendest, ist der Standard Commit=*chg, der explicit per set Option in *none (Chaos) geändert werden kann.
    Zusätzlich kann ich in (fast) allen SQL's zum Schluss "with nc" definieren, was die Transaktion unterläuft.

    Einen systemweiten Standard in dieser Richtung gibt es nicht, denn dann würden die meisten Nicht-SQL-Programme auf die Nase fallen. Da könnte bereits ein CPYF scheitern.
    Daher ist dies anwendungssprezifisch und muss für jeden Job, jede Aufgabe separat entschieden werden.

    Dies ist im Gegensatz zu anderen Datenbanken historisch gewachsen, da die DB2 zum OS/400 (gibts da auch einen anderen Namen,-)) gehört und eben viele alte Programme immer noch funktionieren.
    Andere Datenbanken sind nicht in das OS integriert und können sich da ganz auf SQL konzentrieren (incl. der Non-SQL-DB's, Non = Not Only), die generell transaktionsorientiert sind (ggf. automatisch/implizit).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Aug 2011
    Beiträge
    93
    Vielen Dank die Herren, das nenn ich doch mal wieder eine Aussage, mit der ich was anfangen kann! :-)

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... zwei Anmerkungen noch zu Baldur:
    - RLA Programme ohne Commit erlauben kein OLTP (deshalb werden Buchungen meist im Batch verarbeitet, wenn keiner mehr auf der Büchse ist).
    - CPYF etc. beißt sich keineswegs mit Journalisierung und Commit.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Das sich CPYF durchaus mit Commit und Journal verträgt habe ich nicht bestritten.
    Allerdings gibt es halt die Fälle, in denen man mal STRCMTCTL im Job gestartet hat und nicht wusste dass da irgendwo CPYF's laufen die mit Transaktionen nicht rechnen.
    Deswegen könnte ein CPYF scheitern, wenn dieser unerwartet in eine Transaktion rennt, ins besonders dann, wenn dann das Locklimit des Jobs erreicht wird.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Vielleicht noch ein paar Anmerkungen:
    1. Auch Programme mit Native I/O können unter Commit verarbeitet werden. Dazu muss in den F-Bestimmungen bei den Update/Output-Dateien das Schlüssel-Wort COMMIT angegeben werden.
    Commit kann auch durch einen Indikator bedingt werden. In diesem Fall muss der Indikator vor dem Öffnen der Datei gesetzt sein. Nur dann wenn entweder das Schlüssel-Wort COMMIT (ohne Indikator) oder wenn der Indikator vor dem Öffnen der Datei auf *ON gesetzt wurde, wird die Datei unter Commitment Control verarbeitet.
    Native I/O und SQL können durchaus unter der gleichen Transaktion Datensätze hinzufügen/ändern und/oder Löschen.

    2. Sofern die Commitment Control vor Aufruf des Programms nicht gestartet ist und es sich bei dem Programm nicht um ein Programm mit embedded SQL handelt, jedoch native I/O unter Commit ausgeführt werden soll, stürzt das Programm ab.
    Sofern es sich um ein embedded SQL mit Insert/Update oder Delete Operationen handelt und Commitment Control noch nicht gestartet ist, wird der Befehl STRCMTCTL automatisch (mit Default-Einstellungen, also auch CMTCTL *ACTGRPDFN) gestartet.

    3. Bei der Einstellung ACTGRPDFN erfolgen COMMIT und ROLLBACK nur innerhalb der Aktivierungsgruppe! Deshalb sollte man (wenn möglich) alle (Service-)Programme mit Insert/Update/Delete-Operationen (unter Commit) immer mit Aktivierungsgruppe *CALLER umwandeln.
    Etwaige (System-)Trigger-Programme sollten aus dem gleichen Grund ebenfalls mit Aktivierungsgruppe *CALLER erstellt werden.

    ... was allerdings in gewachenen Anwendungen, in denen es noch OPM-Programme (die in der Default-Aktivierungruppe laufen) zu Problemen führen kann. Werden Dateien (für Native I/O oder auch Display Files und Printerfiles) in der Default-Aktivierungsgruppe geöffnet, können sie vor Job-Ende nicht aus dem Speicher entfernt werden.
    RCLACTGRP ist für die Default-Aktivierungsgruppe nicht erlaubt.
    RCLRSC macht die Dateien zwar zu, jedoch jeder weitere Aufruf schlägt fehl, da es aktuell keine Möglichkeit innerhalb der RPG-Programme dies zu prüfen, weder mit %OPEN(), noch mit der Erweiterung (E), noch über die Monitor Group.

    Deshalb haben viele Firmen angefangen mit benannten Aktivierungsgruppen zu arbeiten.
    Jetzt kann es jedoch sein, dass die Insert/Update/Delete Operationen in unterschiedlichen Aktivierungsgruppen erfolgen und somit ein sauberer COMMIT oder ROLLBACK nicht möglich ist.

    Ist die Commitment Steuerung einmal gestartet, kann sie nicht einfach geändert werden, sondern muss explizit beendet und wieder neu (mit anderem Commitment Scope) gestartet werden.

    Deshalb empfehlen die "Banausen", beim STRCMTCTL den Commitment Scope auf *JOB zu setzen, so dass COMMIT und ROLLBACK auf Job-Ebene sauber funktionieren.

    Kaum einer hat die Möglichkeit mit einer Anwendung auf der grünen Wiese anzufangen und dann alles sauber zu designen.
    ... von Fremdsoftware, die dann zusätzlich auf der Maschine oder im Job läuft ganz zu schweigen!

    Was den Commitment Scope in den embedded SQL (Service-)Programmen angeht, so sollte man diesen explizit durch ein SET OPTION (SQL-)Statement am Anfang des Source Codes (globale C-Bestimmungen in RPG) setzten.
    Dann ist es völlig egal, wie der Compile-Befehl eingestellt ist, das gewünschte Commitment Level wird verwendet.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #8
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Das sich CPYF durchaus mit Commit und Journal verträgt habe ich nicht bestritten.
    Copy-Files und CLRPFM laufen NICHT unter Commitment Control, auch wenn diese gestartet ist.

    Ein ROLLBACK (unabhängig davon ob mit Commitment Scope *JOB oder *ACTGRPDFN gearbeitet wird) wird die kopierten und gelöschten Datensätze nicht zurücknehmen bzw. wiederherstellen.
    Im überigen ist das Kopieren von Daten in (temporäre) Dateien auch kein gutes Design.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Ob ich nun früher ein CPYF ggf. mit OPNQRYF gemacht habe oder nun einen "CREATE TABLE as Select ... with data", wo ist das der Unterschied?
    Außerdem gibt es durchaus Gründe, temporär Daten zu extrahieren um damit performanter umzugehen.
    Gott sei dank gibt es ja die QTEMP, so dass ich nicht mit komplexen Konstrukten in Tabellen mit "temporären Schlüsseln" umgehen muss.
    Ins besonders da die QTEMP automatisch aufgeräumt wird. Von schlechtem Design würde ich da nicht sprechen, eher von "erkannten Möglichkeiten".

    Und was sind denn dann "Global tamporary tables"? Die liegen doch ebenso letztlich in der QTEMP.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    @Banausen und ACTGRP:

    Gutes Design orientiert sich nicht an den Altlasten, sondern an künftigen Anforderungen. Commit funktioniert dann "sauber", wenn Schreiboperationen, die zu einer Transaktion gehören, als gesamtes geklammert werden und komplett ausgeführt oder verworfen werden. Das erfordert zuweilen, dass mehrere Transaktionen einander überlappen können und voneinander unabhängig sind.

    Dazu hat man bei Commit Steuerung Commit Master, die für die Steuerung verantwortlich sind und Slaves. Commit und Rollback sagt immer nur der Master, die slaves laufen in ACTGRP *CALLER. Will man mehrere ACTGRPs zu einer (übergeordneten) Transaktion koppeln, macht man das wie bei mehreren Connections zu verschiedenen Datenbanken, dann wird überall commited oder zurück gesetzt.

    Startet man commit mit ACTGRP *JOB, macht man die Commit Steuerung von eingebundenen (Fremd) Anwendungen kaputt, das ist ein ernsthafter Kunstfehler!

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    CLRPFM kann man tatsächlich keinen Rollback machen da die einzelnen Zeilen nicht journalisiert werden, bei CPYF werden wieder einzelne Zeilen "inserted" so dass ein Rollback möglich sein sollte.
    Aber das kann man ja ausprobieren;-).

    Es gibt übrigens eine SQL-Optimierung bzgl. "delete from mytable":
    Wenn keine Journalisierung und kein Trigger, dann wird ein CLRPFM versucht.
    Da dieser exclusive Lock benötigt, wird im Fehlerfall wieder ein Einzelsatz-Delete durchgeführt.
    Dies kann daher schon mal zu unterschiedlichen Performanceeffekten führen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. Read failure ODBC
    By rr2001 in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 10-04-19, 11:41
  2. sql vs Nativ read delet ...
    By ILEMax in forum IBM i Hauptforum
    Antworten: 17
    Letzter Beitrag: 03-03-16, 17:09
  3. Nicht lesbare Daten nach Read aus dem IFS
    By msost in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 25-07-14, 15:54
  4. READ / READE in free-rpg
    By Gimli in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 10-03-03, 13:08
  5. VA RPG Read anweisung schlägt fehl
    By Peter Kosel in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 18-10-01, 13:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •