[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Sep 2003
    Beiträge
    95

    Performance ODBC / JDBC Jobs 9406-520

    hallo forum,
    wir habe sehr viele Jobs -> QZDASOINITaktiv - das sind hauptsächlich Verbindungen für Access-Abfragen. diese laufen mit einer Ausführungspriorität von 20.
    Frage: ist es möglich (und wie) diese Jobs mit einer anderen Prio zu starten (zb. mit prio 50 wie batch-jobs) )) wie richtet man so was ein bzw. was muss dazu getan werden ?
    danke für die hilfe
    heinz

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.287
    ... da gibt es einen Eintrag für prestarted Jobs im Subsystem (je nach Release), der hat eine Job Description und eine Class und da hängt die Priorität dran. Zusätzlich kann man noch über Oops Nerv Anforderungen nach verschiedenen Kriterien einem SubSystem zuordnen. (Allerdings muss man da aufpassen, dass man sich nicht die Füße auf der Erde festnagelt, niedrigere Prioritäten können die Auswirkungen schlimmer machen (Stichwort: Sperren!!!)

    D*B

    Zitat Zitat von heini Beitrag anzeigen
    hallo forum,
    wir habe sehr viele Jobs -> QZDASOINITaktiv - das sind hauptsächlich Verbindungen für Access-Abfragen. diese laufen mit einer Ausführungspriorität von 20.
    Frage: ist es möglich (und wie) diese Jobs mit einer anderen Prio zu starten (zb. mit prio 50 wie batch-jobs) )) wie richtet man so was ein bzw. was muss dazu getan werden ?
    danke für die hilfe
    heinz
    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
    Aug 2003
    Beiträge
    1.508
    sowei ich weis ist QPWFSERVER die klasse für QZDASOINIT.
    also:
    CHGCLS CLS(QSYS/QPWFSERVER) RUNPTY(xx)

  4. #4
    Registriert seit
    Sep 2003
    Beiträge
    95
    die jobs laufen ja im qsyswrk, wo finde ich diesen eintrag?
    wir haben V5R3M5

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    Das Ändern der Prio hat nur geringe bis gar keine Auswirkungen, ins besonders, wenn viele Abfragen laufen.
    Wenn ein temporärer Index gebildet werden muss, interressiert die Klasse nämlich überhaupt nicht, das System wird bis zum Maximum belastet.

    Hier gilt es eher, die Abfragen von Access/Java zu optimieren, so dass die Systemlast sinkt.

    Übliche Probleme dieser Abfragen in Access sind Joins zwischen verknüpften und lokalen Tabellen.
    Diese ziehen nämlich erst den gesamten Inhalt einer Tabelle in den Speicher, führen dann den Join intern aus und verwerfen den Rest wieder.

    Das nächste Problem sind häufig fehlende Indexe für den SQL-Optimizer.
    Hierbei besteht bei Access meist das Problem, dass Access max. 32 LF's unterstütz und stirbt, wenn mehr als 32 LF's vorhanden sind.
    Alternativ hilft nur die Verknüpfung auf eine LF mit Schlüssel, die allerdings kein Select/Omit enthalten darf.
    Den Rest erledigt der Optimizer.

    Für JDBC gilt i.W. das selbe, dass hier ungünstige Abfragen (auf LF's mit Select/Omit, fehlender Index, usw.) gestartet werden.

    Im Normalfall sollten ODBC/JDBC-Abfragen in wenigen Sekunden (möglichst < 2) erfolgreich sein.
    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

  6. #6
    Registriert seit
    Jul 2005
    Beiträge
    1.053
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Das nächste Problem sind häufig fehlende Indexe für den SQL-Optimizer.
    Hierbei besteht bei Access meist das Problem, dass Access max. 32 LF's unterstütz und stirbt, wenn mehr als 32 LF's vorhanden sind.
    Alternativ hilft nur die Verknüpfung auf eine LF mit Schlüssel, die allerdings kein Select/Omit enthalten darf.
    Den Rest erledigt der Optimizer.
    Das ist doch schon von Schreiben in RPG her so ublich das man lf's erstellt um den temporären Aufbau eines Such Indexes zu umgehen.

    Ist ja auch in Holgers PDF zu den Programmiergrundlagen gut dokumentiert.

    Finde es fast erschreckend das sich scheinbar niemand einen Kopf darum macht vernümpftige Such Pfade zu erstellen sondern scheinbar nur an XP & Co im sql rumwühlt und dan die Schuld für schleichendes Arbeiten auf die i5 abwällst - so nach den Motto "Unter Windows haben wir im Excel klare Abfragen definiert".

    Gruß AS400.lehrling

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.241
    Dem kann ich nur zustimmen.
    Ich habe immer wieder Access-Anwendungen gesehen, die von Nicht-Programmierern erschreckende Antwortzeiten haben.
    Die Schuld wird dann häufig auf den Server (AS/400 oder auch SQL-Server) geschoben.
    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

  8. #8
    Registriert seit
    Jul 2005
    Beiträge
    1.053
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Dem kann ich nur zustimmen.
    Ich habe immer wieder Access-Anwendungen gesehen, die von Nicht-Programmierern erschreckende Antwortzeiten haben.
    Die Schuld wird dann häufig auf den Server (AS/400 oder auch SQL-Server) geschoben.
    Na mysql oder andere bekante sql server werden damit ähnliche performance probleme haben wie die i5.

    Gruß AS400.lehrling

Similar Threads

  1. ODBC Performance
    By KingofKning in forum IBM i Hauptforum
    Antworten: 11
    Letzter Beitrag: 12-10-07, 14:47
  2. SQL-Performance Probleme ODBC
    By berndl in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 13-10-06, 09:28
  3. ODBC performance
    By usafft in forum IBM i Hauptforum
    Antworten: 4
    Letzter Beitrag: 12-09-05, 09:53
  4. 9406 und diverse teile zu verkaufen
    By maritz in forum NEWSboard Server & Hardware Markt
    Antworten: 2
    Letzter Beitrag: 05-07-05, 20:07
  5. Welche I5 520 ist nötig bei ca 25 - 35 aktiven Jobs?
    By wolfmakiol in forum IBM i Hauptforum
    Antworten: 9
    Letzter Beitrag: 10-05-05, 12:25

Berechtigungen

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