[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Mar 2015
    Beiträge
    15

    Rollender SQL-Cursor --> eingefrorenes System

    Hallo AS/400-Gemeinde.

    In einem RPG-ILE-Programm verwende ich einen rollenden SQL-Cursor der wie folgt definiert wird:
    exec sql prepare CRS_QUERY from :lv_cQuery
    exec sql declare C1 insensitive scroll cursor for CRS_QUERY

    Wenn ca. 25 User mit dem Programm arbeiten, friert das System ein. Dabei kann man sich nicht einmal mehr am System anmelden.

    Nach Stundenlagen recherchen konnte ich keine Antwort auf diesen Fehler finden.
    Deswegen wende ich mich an Euch.

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Ich denke mal, die AS/400 wird mit dem Cursor überlastet da ggf. keine Indizes verwendbar sind.
    Starte mal per Debugger dein Programm und schau dir an, was den so im Joblog steht.
    Wahrscheinlich ist der SQL so komplex, dass es einfach etwas dauert, die benötigten Daten zusammen zu suchen.
    Das Problem ist häufig bei dynamischem SQL zu finden.
    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

  3. #3
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Bei fehlenden Indices geht die Kiste nicht in die Knie, da dauert dann einfach nur die Verarbeitung sehr lange.

    Bei INSENSITIVE wird das SQL als read-only ausgeführt.
    Dabei wird das Ergebnis temporär gespeichert.
    Wenn es sich also um eine große Datenmenge handelt, kann das mit jedem weiteren User ordentlich Speicher kosten.
    Das solltest du auch mit WRKSYSSTS beobachten können. Oder auch wenn du dir den verwendeten temp. Speicher der Jobs ansiehst.

    lg Andreas

  4. #4
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    Bei fehlenden Indices geht die Kiste nicht in die Knie, da dauert dann einfach nur die Verarbeitung sehr lange.

    Bei INSENSITIVE wird das SQL als read-only ausgeführt.
    Dabei wird das Ergebnis temporär gespeichert.
    Wenn es sich also um eine große Datenmenge handelt, kann das mit jedem weiteren User ordentlich Speicher kosten.
    Das solltest du auch mit WRKSYSSTS beobachten können. Oder auch wenn du dir den verwendeten temp. Speicher der Jobs ansiehst.

    lg Andreas
    ... selbstredend kann die temporäre Erstellung eines Indexes die Kiste in die Knie zwingen!!! Sowohl mit hohem CPU Verbrauch, als auch mit extensivem Paging.

    Das mit dem temp Speicher ist auch nur die halbe Wahrheit - temp Speicher ist der benutzte Swap Speicher und temporäre Kopie heißt auch keineswegs, dass die gesamte Datei beim open dupliziert wird, wenn ich keine where Klausel habe...

    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/

  5. #5
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Zitat Zitat von BenderD Beitrag anzeigen
    Das mit dem temp Speicher ist auch nur die halbe Wahrheit - temp Speicher ist der benutzte Swap Speicher und temporäre Kopie heißt auch keineswegs, dass die gesamte Datei beim open dupliziert wird, wenn ich keine where Klausel habe...
    Natürlich wird keine Kopie der Datei erstellt! Das wäre ja der Killer eines jeden DB System wo größere Datenmengen gespeichert werden.
    Es werden jene Sätze markiert die vom Select betroffen sind.
    Werden jene Sätze geändert/gelöscht muss das Original ja irgendwo gespeichert werden --> temporäre Tabelle.
    Zusammengefasst: Je länger der Cursor offen bleibt und je mehr von den Daten geändert werden, desto mehr Daten müssen temporär gespeichert werden.
    Und das multipliziert sich mit der Anzahl der geöffneten Cursor.
    Deshalb sollte so ein Cursor nie sehr lange geöffnet sein.

  6. #6
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    Es werden jene Sätze markiert die vom Select betroffen sind.
    Zusammengefasst: Je länger der Cursor offen bleibt und je mehr von den Daten geändert werden, desto mehr Daten müssen temporär gespeichert werden.
    Und das multipliziert sich mit der Anzahl der geöffneten Cursor.
    Deshalb sollte so ein Cursor nie sehr lange geöffnet sein.
    Beides wieder mal nur fast richtig:
    ersteres würde genau bedeuten, dass bei einem select ohne where clause das gesamte Resultset dupliziert wird, zweiteres besagt genau das Gegenteil, wenn die Daten schon dupliziert sind, wäre es völlig belanglos, wie lange ich dieses Resultset halte. In Realität ist es wohl so, dass die temp copy sich auf die Daten bezieht, ide per fetch bereits geholt wurden: es geht also um das manövrieren im cursor.

    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/

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Bevor wir uns hier weiterhin in den wildesten Spekulationen ergehen, würde ich vorschlagen einen CALL bei IBM zu starten.

    Die Speicherverwaltung sollte so gestaltet sein, dass SQL nicht in der Lage ist, wie auch immer durch zwischengespeicherte Daten, offene ODPs, das Rein- und Rausschaufeln von Daten aus den Memory Pools ..., die Maschine lahm zu legen.

    ... wenn das nicht klappt ist etwas faul.
    Die IBM ist auch nur ein großes Softwarehaus, das nicht alle Eventualitäten testen kann.
    Wenn keiner den Fehler meldet, den IBM nicht gefunden hat, kann man auch nicht erwarten, dass sich das Ganze in Wohlgefallen auflöst.
    Wir alle hier in diesem Forum sind nicht nahe genug an der Entwicklung, die in den Labs erfolgt dran, um daran irgendwas zu ändern.

    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
    Feb 2001
    Beiträge
    20.206
    Nun ja, da das Thema Indexerstellung (eben auch temporäre) das System schon häufiger (seit V4!) mit bis zu 100% (und mehr +++) belastet weiß ich nicht warum die IBM dieses Problem nicht schon längst gelöst hat.
    Häufiger sind das i.Ü. eher die QZDA-Jobs, da User in Unkenntnis der Datenbank auf Tools wie Query, Web-Query, MS-Query (Excel) losgelassen werden und durchaus gerne mit irgendwelchen Abfragen die Systemlast hochtreiben.
    Machen das eben mehrere Job's kann es durchaus zu Systemstillständen kommen.
    Lieber wäre mir dann, die Indexerstellung per QAQQINI zu verbieten und halt einen Tablescan zu machen. Da dauert das halt nur für den einen Job etwas länger, kann per Zeitscheibe ggf. besser unterbrochen werden und das System läuft noch.
    Außerdem zwingt es ggf. dazu, bessere SQL-Analysen durchzufü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

  9. #9
    Registriert seit
    Aug 2001
    Beiträge
    2.644
    Zitat Zitat von B.Hauser Beitrag anzeigen
    Die Speicherverwaltung sollte so gestaltet sein, dass SQL nicht in der Lage ist, wie auch immer durch zwischengespeicherte Daten, offene ODPs, das Rein- und Rausschaufeln von Daten aus den Memory Pools ..., die Maschine lahm zu legen.
    Es gibt Eimerweise PTFs, die sich genau mit diesem Problem (temp. Speicher) beschäftigen, da muss man am Ball bleiben. IIRC war vor etwa einem Jahr in V7R1 sogar ein Maschinenstillstand in einer gewissen Konstellation drin - prima.

    Auch wenns IBM und i ist - da wird auch nur mit Wasser gekocht. Manchmal destilliert, manchmal vom falschen Brunnen geklaut. Damit man in eine solche Falle nicht im vollen Produktivbetrieb reinknallt, empfiehlt es sich, nach jeder PTF-Aktion die Abfragen oder Programme in einer Testumgebung (mit möglichst vielen Daten) unter Beobachtung der temp. Speicherangaben laufen zu lassen.

    Wir haben hier einen Kunden, der (warum auch immer) unter V5R3 eine kleine 570 damit zum Platzen gebracht hat, weil via CL ein Query in einer Endlosschleife lief. Etwa 1000 Iterationen ohne besondere Vorkommnisse, danach platzte auf einmal der temp. Speicher bis zur Vollbelegung des ASP.

    -h
    www.RZKH.de
    IBM Champion 2022, 2023, 2024
    IBM i Community Advocate https://www.youracclaim.com/badges/6...c-7ad4ba147af6
    Common / CEAC
    http://pub400.com

  10. #10
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Probleme mit temp. Speicher kann man leider nie ausschließen.
    Wir hatten auch mal so einen Fall wo der temp. Speicher den ASP fast voll laufen hat lassen.
    Nach einigen Analysen fand ich dann den Täter und nachdem ich den Job beendet hatte ging es dann auch dem System wieder gut.
    Aber wie schon gesagt, mit einer entprechenden Überwachung und gezielten Analyse kann man gröberes verhindern.

  11. #11
    Registriert seit
    Mar 2015
    Beiträge
    15
    Hallo,

    erstmal vielen Dank für die ganzen Infos.
    Es wurde zu dem Thema ein CALL bei der IBM aufgemacht. Zur Zeit gibt es jedoch noch keine Rückmeldung.

    Im Testsystem wird ein Testfall generiert, wo wir den Systemspeicher genauer unter die Lupe nehmene werden.

  12. #12
    Registriert seit
    Mar 2015
    Beiträge
    15
    Hallo,

    scheinbar ist es wirklich ein Problem Seitens der IBM. Genaueres konnte ich von unserer Basis leider nicht erfahren.

    Nur das für das Für das o.g. Problem es für Release R710 und höher ein PTF geben wird. Ein genaues Zieldatum gibt es noch nicht. "

    Gruß Sebastian

Similar Threads

  1. Bezeichnung der DB2 system i
    By TARASIK in forum NEWSboard Programmierung
    Antworten: 15
    Letzter Beitrag: 17-04-15, 09:43
  2. Datei ohne eindeutigen Schlüssel mit SQL Cursor abarbeiten und updaten
    By dschroeder in forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 21-06-14, 19:54
  3. Artikel: SQL: dynamisches Select ohne Cursor
    By NEWSolutions Redaktion in forum NEWSolutions artikel
    Antworten: 0
    Letzter Beitrag: 05-12-13, 19:03
  4. System 9401-150
    By tomski in forum NEWSboard Server & Hardware Markt
    Antworten: 6
    Letzter Beitrag: 16-05-03, 14:29
  5. 236 System gesucht !!!!!!!!!!!!!!!!!!!!!!
    By TARASIK in forum NEWSboard Server & Hardware Markt
    Antworten: 1
    Letzter Beitrag: 24-04-03, 22:33

Berechtigungen

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