[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Mar 2009
    Beiträge
    53

    SQL Select Statement - Execute dauert sehr lange

    Moin,

    ich führe mehrere Statements hintereinander aus.
    - Connectionpool getConnection
    - connection create statement
    - statement execute
    - statement close
    - connection create statement
    - stament execute
    - statement close
    - connection close
    Ab dem 2. Statement braucht er für das execute sehr lange. Wobei da nichts groß gemacht wird. Hin und wieder gehts es auch mal sehr zügig.
    Ich habe mal das Log angeschaltet und folgendes kommt raus:

    (Die xxxx = as400: ConnectionPool com.ibm.as400.access.AS400JDBCConnectionPool@1f1d1 f1d (522002205) )
    Code:
    Toolbox for Java - Open Source Software, JTOpen 8.1, codebase 5770-SS1 V7R2M0.00 built=20131021 @J5
    java.home=/QOpenSys/QIBM/ProdData/JavaVM/jdk60/64bit/jre java.vm.version=2.4 java.version=1.6.0 os.name=OS/400 os.version=V7R1M0
    ...
    
    Thread[main,5,main] 09:15:04:475  Getting version level.
    Thread[main,5,main] 09:15:04:475  Version level:  7
    Thread[main,5,main] 09:15:04:475  Bidi layout transformation of SQL meta-data: SELECT FELD1, FELD2, FELD3, FELD4 FROM LIB/DATEI WHERE  FELDX = 111111 AND FELDY between 201101 AND 201112 ORDER BY 1
    Thread[main,5,main] 09:15:04:475  Bidi layout transformation from 5 to 5 of SQL statement: SELECT FELD1, FELD2, FELD3, FELD4 FROM LIB/DATEI WHERE  FELDX = 111111 AND FELDY between 201101 AND 201112 ORDER BY 1
    Thread[main,5,main] 09:15:04:476  as400: PreparedStatement STMT0002 (915355279)  open. Parent: Connection S4405619 (486612225) .
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Escape processing = "true".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Fetch direction = "1000".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Fetch size = "0".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Max field size = "0".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Max rows = "0".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Query timeout = "0".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Result set concurrency = "1007".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Result set holdability = "1".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Result set type = "1003".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Behavior Override = "0".
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Data to correlate statement with cursor Cursor CRSR0002 (924333848) .
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : isjvm16Synchronizer=false.
    Thread[main,5,main] 09:15:04:477  as400: PreparedStatement STMT0002 (915355279) : Preparing [SELECT FELD1, FELD2, FELD3, FELD4 FROM LIB/DATEI WHERE  FELDX = 111111 AND FELDY between 201101 AND 201112 ORDER BY 1].
    Thread[main,5,main] 09:15:04:477  com.ibm.as400.access.BidiConversionProperties@48104810:Setting bidi string type:0
    Thread[main,5,main] 09:15:04:477  Converting string to byte array for ccsid: 1141
    Thread[main,5,main] 09:15:04:477  Destination byte array for ccsid: 1141
    Thread[main,5,main] 09:15:04:477  com.ibm.as400.access.BidiConversionProperties@4ac44ac4:Setting bidi string type:0
    Thread[main,5,main] 09:15:04:477  Converting string to byte array for ccsid: 1141
    Thread[main,5,main] 09:15:04:477  Destination byte array for ccsid: 1141
    Thread[main,5,main] 09:15:04:477  send(): send request...
    Thread[main,5,main] 09:15:04:477  Data stream sent (connID=1767926112) ...
    Thread[main,5,main] 09:15:04:478  com.ibm.as400.access.BidiConversionProperties@4ebb4ebb:Setting bidi string type:0
    Thread[main,5,main] 09:15:04:478  Converting string to byte array for ccsid: 13488
    Thread[main,5,main] 09:15:04:479  Destination byte array for ccsid: 13488
    Thread[main,5,main] 09:15:04:479  send and receive(): ...
    Thread[main,5,main] 09:15:04:479  send(): send request...
    Thread[main,5,main] 09:15:04:479  Data stream sent (connID=1767926112) ...
    Thread[main,5,main] 09:15:04:480  AS400Server.receive
    Thread[main,5,main] 09:15:04:480  receive(): Reply not found. Waiting...
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:670  Data stream data received (connID=1767926112) ...
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:670  Data stream data received (connID=1767926112) ...
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:671  run(): Adding reply:  7
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:671  run(): Notifying threads.
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:671  run(): Threads notified.
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:15:04:671  run(): Waiting for reply...
    Thread[main,5,main] 09:15:04:672  receive(): Valid reply found:  7
    Thread[main,5,main] 09:15:04:674  decompressRLE() sourceLength: 1003
    Thread[main,5,main] 09:15:04:674  decompressRLE() destinationLength: 1330
    Thread[main,5,main] 09:15:04:675  Received empty parameter marker format.
    Thread[main,5,main] 09:15:04:687  as400: PreparedStatement STMT0002 (915355279) : Prepared STMT0002*, SQL Statement -->[SELECT FELD1, FELD2, FELD3, FELD4 FROM LIB/DATEI WHERE  FELDX = 111111 AND FELDY between 201101 AND 201112 ORDER BY 1].
    Thread[main,5,main] 09:15:04:690  send and receive(): ...
    Thread[main,5,main] 09:15:04:690  send(): send request...
    Thread[main,5,main] 09:15:04:690  Data stream sent (connID=1767926112) ...
    Thread[main,5,main] 09:15:04:690  AS400Server.receive
    Thread[main,5,main] 09:15:04:690  receive(): Reply not found. Waiting...
    
    --- Was passiert hier ? ? ? ? --- 
    
    Thread[ACPM,5,main] 09:20:04:368  as400: xxxx : ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:20:04:368  as400: xxxx :    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:20:04:368  as400: xxxx :    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:20:04:368  as400: xxxx :    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:20:04:368  as400: xxxx :    PretestConnections: false.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx : Idle Connections: 0.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx : Active Connections: 1.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx : Dead Connections: 0.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx : com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx : ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx :    Idle Connections: 0.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx :    Active Connections: 1.
    Thread[ACPM,5,main] 09:20:04:369  as400: xxxx :    Dead Connections: 0.
    Thread[ACPM,5,main] 09:25:04:403  as400: xxxx : ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    PretestConnections: false.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx : Idle Connections: 0.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx : Active Connections: 1.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx : Dead Connections: 0.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx : com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx : ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    Idle Connections: 0.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    Active Connections: 1.
    Thread[ACPM,5,main] 09:25:04:404  as400: xxxx :    Dead Connections: 0.
    Thread[ACPM,5,main] 09:30:04:437  as400: xxxx : ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx :    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx :    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx :    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx :    PretestConnections: false.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx : Idle Connections: 0.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx: Active Connections: 1.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx: Dead Connections: 0.
    Thread[ACPM,5,main] 09:30:04:439  as400: xxxx: com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:30:04:440  as400: xxxx: ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:30:04:440  as400: xxxx:    Idle Connections: 0.
    Thread[ACPM,5,main] 09:30:04:440  as400: xxxx:    Active Connections: 1.
    Thread[ACPM,5,main] 09:30:04:440  as400: xxxx:    Dead Connections: 0.
    Thread[ACPM,5,main] 09:35:04:474  as400: xxxx: ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:35:04:474  as400: xxxx:    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:35:04:474  as400: xxxx:    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:35:04:474  as400: xxxx:    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:35:04:474  as400: xxxx:    PretestConnections: false.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx: Idle Connections: 0.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx: Active Connections: 1.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx: Dead Connections: 0.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx: com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx: ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx:    Idle Connections: 0.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx:    Active Connections: 1.
    Thread[ACPM,5,main] 09:35:04:475  as400: xxxx:    Dead Connections: 0.
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx: ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx:    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx:    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx:    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx:    PretestConnections: false.
    Thread[ACPM,5,main] 09:40:04:508  as400: xxxx: Idle Connections: 0.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx: Active Connections: 1.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx: Dead Connections: 0.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx: com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx: ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx:    Idle Connections: 0.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx:    Active Connections: 1.
    Thread[ACPM,5,main] 09:40:04:509  as400: xxxx:    Dead Connections: 0.
    Thread[ACPM,5,main] 09:45:04:544  as400: xxxx: ConnectionPool cleanup....
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    MaxLifeTime: 86400000.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    MaxUseTime: -1.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    MaxInactivity: 3600000.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    PretestConnections: false.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx: Idle Connections: 0.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx: Active Connections: 1.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx: Dead Connections: 0.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx: com.ibm.as400.access.AS400JDBCPooledConnection@1d011d01.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx: ConnectionPool cleanup finished..
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    Idle Connections: 0.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    Active Connections: 1.
    Thread[ACPM,5,main] 09:45:04:545  as400: xxxx:    Dead Connections: 0.
    Thread[AS400 Read Daemon [system:localhos;job:173298/QUSER/QZDASOINIT],5,main] 09:46:25:183 Data stream data received (connID=1767926112) ...
    Thread[AS400 Read Daemon [system:localhost;job:173298/QUSER/QZDASOINIT],5,main] 09:46:25:183  Data stream data received (connID=1767926112) ...
    Was macht er da? Muss ich noch irgendwelche Einstellungen setzen? PTFs?

    Danke+Gruß
    Max

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das hängt nun ganz von der AS/400 ab.
    Wie viele Daten enthält die Datei?
    Gibt es einen Index?
    Bei solchen Problemen hilft eher selten ein lokaler Trace sondern ein STRDBG im AS/400-Job.
    Dieser wird durch eine Trace-Angabe in der Java-Connection gestartet.
    Anschließend kannst du per "WRKOBJLCK USER *USRPRF" (User = dein Anmeldeuser) den QZDASOINIT-Job feststellen und die dortigen Nachrichte bzgl. des langsamen SQL's untersuchen und ggf. darauf reagieren.
    Dies ist die 1. Variante.

    Nun bin ich nicht tief genug in Java um zu wissen, ob es hier die Differenz zwischen Client- und Servercursor gibt.
    Ggf. wird beim Execute ein Resultset gebildet, dass alle Daten des Selects beinhaltet. D.h., dass der Execute erst zurückkommt, wenn alles geladen ist.
    Auch dies sieht man ggf. im AS/400-Job, da durch blocken dort immer steht "XXX Zeilen von Cursor abgerufen" (o.ä.).
    Dies kann natürlich auch dauern.
    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
    Mar 2009
    Beiträge
    53
    Es werden ca. 15 Statements ausgeführt, die jeweils max 20 Datensätze mit max 20 Feldern zurückliefern.

    Habe jetzt mal ein -Dcom.ibm.as400.access.ServerTrace.JDBC=126 hinzugefügt.
    Der QZDASOINIT steht auf QDBGETMQO und Jobprotokoll steht:
    Der Zugriffsplan der Abfrage wurde erneut erstellt.
    ****: Debug-Nachrichten für Abfrage werden beendet.
    ODP erstellt.
    Blockung für Abfrage.
    Cursor CRSR0002 eröffnet.

    Und das Java-Programm wie bisher.

  4. #4
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... die Infos sind ein wenig rudimentär, aber alles was länger als millisekunden pro Satz dauert sind fehlende Zugriffspfade oder Ressourcenengpässe. Im Joblog des Database Servers müssen unter Debug noch mehr Infos zu finden sein. Generell noch ein paar Hinweise:
    - wenn extended dynamic in den Driver Properties aktiviert ist, package löschen und deaktivieren
    - andere Treiberversion probieren
    - ich würde auch einen ordentlichen ConnectionPool nehmen und nicht diesen Dollschachtel Kram
    - log4j einsetzen, das ist flexibller und bei SQL unumgänglich
    - alle warnings und SQLCode mit level warning o.ä. protokollieren

    D*B

    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
    Jun 2001
    Beiträge
    1.973
    Recourcenengpässe sind es M.e. nicht denn...
    hier nicht erwähnt wurde ...

    1.) Wenn ich genau das SQL -Statement aus dem LOG kopiere und in einer grünen Sitzung ausführe,
    habe ich (je Statement) nach maximal 9 Sekunden mein Ergebnis

    2.) Die Laufzeit scheint vom Wetter / Tagesform / ... ab zu hängen. Es gibt Tage, da ist die gesamte Statistik nach 1,5-2 Minuten durch, andere Tage (Heute!) läuft das mehrere Stunden!
    Die Auslastung der AS400 ist immer gleich, da gibt es keine Lastspitzen durch irgendwelche großen Läufe. CPU immer so bei 35-39 %

    @DB kannst du das bitte übersetzen
    ich würde auch einen ordentlichen ConnectionPool nehmen und nicht diesen Dollschachtel Kram
    Danke
    Robi (der gerade wieder testet, da nun alle PTF eingespielt sind)

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Ich würde da schon auf ein massives Indexproblem tippen.
    QDBGETMQO deutet auf eine MaterializedQuery-Table hin.
    M.a.W., ier wird ein Tablescan durchgeführt der eine temporäre MQ-Table erstellt. Diese sind nach IPL meist wieder weg.
    Außerdem ist es immer wieder faszinierend, wie SQL ganz anders bei STRSQL optimiert als bei embedded oder ODBC/JDBC. Alle QAQQINI-Einstellungen haben bei mir noch nie zu einer gleichartigen Optimierung geführt.

    Deshalb (bei Java kenne ich die Option nicht) nochmal:
    Du musst mal die DEBUG-Nachrichten aktivieren und die Joblog-Nachrichten prüfen.

    Zur Not kannst du die SQL's auch mal per Opsnav ausführen.
    Hier kannst du dir, nach Einschalten, die Diagnosenachrichten direkt ansehen.
    Wenn das nicht klappt, versuche es mal mit Excel und Import via ODBC-Quelle.
    Hier kannst du den Debugmodus in ODBC konfigurieren.

    Beim Debugmodus sollte mehr als "Der Zugriffsplan wurde neu erstellt" stehen.
    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
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Robi Beitrag anzeigen
    Recourcenengpässe sind es M.e. nicht denn...
    hier nicht erwähnt wurde ...

    1.) Wenn ich genau das SQL -Statement aus dem LOG kopiere und in einer grünen Sitzung ausführe,
    habe ich (je Statement) nach maximal 9 Sekunden mein Ergebnis

    2.) Die Laufzeit scheint vom Wetter / Tagesform / ... ab zu hängen. Es gibt Tage, da ist die gesamte Statistik nach 1,5-2 Minuten durch, andere Tage (Heute!) läuft das mehrere Stunden!
    Die Auslastung der AS400 ist immer gleich, da gibt es keine Lastspitzen durch irgendwelche großen Läufe. CPU immer so bei 35-39 %

    @DB kannst du das bitte übersetzen

    Danke
    Robi (der gerade wieder testet, da nun alle PTF eingespielt sind)
    ... der grüne macht meist optimize for 1 row (oder wenige), das kann bei optimize for all anders aussehen (da werden full table scans eher favorisiert).

    Die wechselnden Zugriffszeiten sind geradezu typisch für einen schlechten Connection Pool. Wenn das statemet und temp. indexe in einer Connection gecached sind, dann funzt es, fängt er bei nix an, dann dauert es. (Dollschachtel wie Toolbox) Bessere Pools machen prepared statements und geben Dir diesselbe Connection, wenn es geht, für dasselbe Statement.

    Den Debug kannst Du per Connection Property setzen.

    Dennoch bleibt es dabei, dass hier was am Index Design krumm ist. Auf einem anderen Blatt steht, ob man durch ziehen von Extrakten, bzw. mit mehr Redundanz im Datenbankdesign hier was machen kann/muss - das ist aber alles eh Kaffeesatz, wenn die Infos nur homöopatisch verabreicht werden.

    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/

  8. #8
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    Ganz ehrlich?
    Ich raff es nicht!
    Die Kiste fährt jede Nacht runter!
    Wir haben eben den Debug wieder eingeschaltet (ging vorher nie, da die Berechtigung für strtrc fehlte)
    Aufgerufen, 21,22,23 fertig (so wie's sein soll)
    Den QZDASOINIT Job hab ich beim 2 versuch grad noch so erwischt, aber da steht nix im Joblog, ein Spool hängt da auch nicht dran.
    Das Log, das der Java Job geschrieben hat ist riesig, sagt uns aber nix. Ok, heute ist es mal wieder schnell gewesen.
    Zu den Daten:
    Wir erstellen eine View über 5 Dateien, die Verknüpfung ist immer der unique key, hier meist als indexiertes PF.
    Diese View wird mit einer 2. View nach Mandant selektiert (immer 1 Mandant) und nach Monat/Jahr Summiert und ausgegeben 12 Sätze eines SQL's + 3 (Konstante) Kopf Sätze die separat, NICHT aus der View selektiert werden.
    Die View's werden nach dem Aufruf des letzten Mandanten gelöscht ( Statistik, wird nur ein mal / Monat gebraucht)

    also : select '31.01.2015', '17.02.2015', '31.01.2015' from sysibm/sysdummy1
    dann select feld1, feld2, ...from view2 where Mandant = m_Nr and jjmm between 201101 and 201112
    dann select feld1, feld2, ...from view2 where Mandant = m_Nr and jjmm between 201201 and 201212
    ... 2013,14,15

    (die between Daten sind variablen, das ist also eine Schleife)
    Der Block (andere Felder im select) 3 mal, fertig

    Heute morgen: mehrfach aufgerufen, so schnell wie es sein soll,
    Gesten nachmittag, quälend langsam (fast 2 Stunden)

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das deutet auf einen IPL am Wochenende hin, so dass temporäre, aber gemerkte Indizes dann wieder weg sind.
    Das Löschen eine View ist eigentlich unnötig, sie kostet nichts.
    Das Problem sind ggf. nicht die Verknüpfungen sondern die Where-Bedingung.
    Hier entscheidet die AS/400 den Indexaufbau bzw. Tablescan.

    Um den Debug einzuschalten benötigst du Berechtigung an STRDBG und nicht an STRTRC.
    Also muss deine Einstellung für Debug in der Connection noch falsch sein, das deutet auch auf die Menge an Joblog-Einträgen hin.
    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
    Jun 2001
    Beiträge
    1.973
    ? IPL am Wochenende?
    äh, ja, nicht nur das. Ich schrieb:
    Die Kiste fährt jede Nacht runter!
    Das sollte bedeuten: jeden Tag IPL

    Hmm,
    unser erster versuch mit Debug brachte im Joblog die Meldung, das die Berechtigung für strtrc fehlt.
    Ich frag nochmal in der Java Abteilung
    Danke
    Robi

  11. #11
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    So, nun mit debug ...

    einzig diese Meldung könnte auf ein Prob. hin deuten:
    Nachrichten-ID . . . . : CPI4338 Bewertung . . . . . . : 00
    Nachrichtenart . . . . : Information
    Sendedatum . . . . . . : 18.02.15 Sendezeit . . . . . . : 11:23:16

    Nachricht . . . : 1 Zugriffspfad(e) für die Bitmap-Verarbeitung von Datei
    FMD_STAT1 verwendet.
    Ursache . . . . : Bitmap-Verarbeitung wurde für den Zugriff auf Sätze aus
    Teildatei FMD_STAT1 der Datei FMD_STAT1 in Bibliothek BECKERF0 verwendet.
    Bitmap-Verarbeitung ist eine Methode, bei der für den Zugriff auf
    ausgewählte Sätze in einer Datei ein oder mehrere Zugriffspfade verwendet
    werden können. Bei Bitmap-Verarbeitung wird zum Erstellen einer Bitmap die
    Satzauswahl an jedem Zugriffspfad angelegt, ähnlich der
    Schlüsselspaltenpositionierung. In der Bitmap sind nur die Sätze der Datei
    markiert, die ausgewählt werden sollen. Wird mehr als ein Zugriffspfad
    verwendet, werden die resultierenden Bitmaps mit Hilfe Boolscher Logik
    gemischt. Die resultierende Bitmap wird verwendet, um den Zugriff nur auf
    Weitere ...

    die aus der Datei ausgewählten Sätze zu beschränken.
    Bitmap-Verarbeitung wird gemeinsam mit zwei primären Zugriffsmethoden
    verwendet: Zugriffsmethode nach Eingangsfolge (CPI4327 oder CPI4329) oder
    Zugriffsmethode nach Schlüsselfolge (CPI4326 oder CPI4328). Die Nachricht
    mit einer Beschreibung der primären Zugriffsmethode ist dieser Nachricht
    vorangestellt.
    Wird die Bitmap mit der Zugriffsmethode nach Schlüsselfolge verwendet,
    dient die Bitmap zur Reduzierung der Anzahl der vom primären Zugriffspfad
    ausgewählten Sätze, bevor die ausgewählten Sätze aus der Datei abgerufen
    werden.
    Wird die Bitmap mit der Zugriffmethode nach Eingangsfolge verwendet,
    können bei der sequenziellen Suche in der Datei alle nicht von der Bitmap
    ausgewählten Sätze der Datei übersprungen werden. Dieses ist auch als
    sequenzielle Verarbeitung mit Überspringen (Skip Sequential Processing)
    bekannt.
    Die im folgenden aufgeführte Liste zeigt die Namen der Zugriffspfade, die
    in der Bitmap-Verarbeitung verwendet werden:
    TESTF/AKTENL11
    Falls es sich bei Datei FMD_STAT1 in Bibliothek BECKERF0 um eine logische
    Datei handelt, ist Teildatei AKTENP der physischen Datei AKTENP in
    Bibliothek TESTF die eigentliche Datei, auf die zugegriffen wird.
    Fehlerbeseitigung: Die Themensammlung "DB2 for i - Database Performance and
    Query Optimization" der Kategorie Datenbank im IBM i Information Center
    enthält weitere Hinweise zur Bitmap-Verarbeitung.
    Die anderen Nachrichten, die einen Zugriffspfad empfehlen beziehen sich auf sehr kleine Dateien mit 30-40 Sätzen, die überwiegend der Textung einzelner Kennzeichen dienen.

    Und eine Datei, deren Key key1 und key2 ist. Die Empfehlung lautet key2 und key1!
    Diese Datei ist IMMER mit beiden Feldern verknüpft, eine Where Bedingung ist nicht auf diese Keyfelder vorhanden.

    Wenn es das nächste mal 2 Stunden läuft leg ich die mal an

    Ist schon komisch ...
    Jetzt geht es gerade wie es soll und man hofft das es wieder langsam wird ...

    Robi
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  12. #12
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Der Optimizer ist schon manchmal eine Katastrophe!
    Bei einer Verknüpfung baut dieser die Reihenfolge der Joins schon mal um.
    Beispiel:
    Aus
    select * from filea a
    inner join fileb b on a.key=b.key
    wird dann gerne
    select * from fileb b
    inner join filea a on a.key = b.key

    Je nach Satzanzahl und Auswahl ist der umgedrehte Weg aber ungünstiger da ggf. erheblich mehr Daten gelesen werden müssen.
    Wenn schon umgedreht, kann man ggf. Bedingungen der Where-Klauses in die Join-Klausel legen und einen Index drüber legen, z.B.:

    select *
    from filea a
    inner join fileb b on a.key = b.key

    where b.F1 = 'Wert1'
    and a.f2 = 'Wert2'

    Where-Klauseln aus 2 (oder mehr Dateien) sind eher selten per Index auswählbar da immer beide Seiten verarbeitet werden müssen.
    Hier bietet sich das Anhängen von teilen der Where-Klauseln an die Joinbeziehung an sowie Anlegen des entsprechenden Indexes:

    select *
    from filea a
    inner join fileb b on b.F1 = 'Wert1' and a.key = b.key
    where b.F1 = 'Wert1'
    and a.f2 = 'Wert2'

    oder je nach Volumen der beteiligten Dateien die Abfrage umzudrehen und den Index zu erstellen:

    select *
    from fileb b
    inner join filea a on a.F2 = 'Wert2' and a.key = b.key

    where b.F1 = 'Wert1'
    and a.f2 = 'Wert2'

    Ziel ist es einfach, die Anzahl der benötigten Lesezugriffe zu minimieren.
    Auch hier hat sich für mich gezeigt, dass der Optimizer leider das Umdrehen selber übernimmt und dadurch ungünstiger wird.
    Hier hilft das gezielt Einsetzen von "Left Join" und das Abfragen im Where per Coalesce, da der Optimizer ja sonst automatisch wieder einen "Inner Join" daraus strikt.

    select *
    from filea a
    left join fileb b on b.F1 = 'Wert1' and a.key = b.key
    where coalesce(b.F1, '') = 'Wert1'
    and a.f2 = 'Wert2'

    Der Optimizer will schon mal überlistet werden.
    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. Telnet connection dauert extrem lange
    By Mr-Ferret in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 28-02-14, 11:35
  2. TCP/IP sehr langsam auf AS/400
    By Sho2 in forum IBM i Hauptforum
    Antworten: 11
    Letzter Beitrag: 01-12-02, 16:49
  3. SAVSECDTA mit BRMS dauert sehr lange
    By Peter Kosel in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 27-11-02, 12:32
  4. AS/400 Modems sehr billig
    By stefan400 in forum NEWSboard Server & Hardware Markt
    Antworten: 0
    Letzter Beitrag: 17-10-02, 10:47
  5. FTP Anmeldung dauert ewig!
    By cassandra in forum IBM i Hauptforum
    Antworten: 8
    Letzter Beitrag: 10-09-02, 16:01

Berechtigungen

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