[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2017
    Beiträge
    3

    SQL Script Ausführung dauert sehr lange (Table: QSYS2.SYSPARTITIONSTAT)

    Hallo zusammen,


    wenn ich ein SQL Script auf eine DB2 ausführe dauert es sogar nach Angabe einiger Such Kriterien (siehe SQL Script unten) sehr lange bis das Script durch ist.


    Ich versuche hier eine embedded SQL Abfrage zu erstellen mit der ich, durch Angabe eines Suchworts,verschiedene Bibliotheken nach Sourcen durchsuchen kann.
    Jedoch ist diese Abfrage mit einer Laufzeit von über 10 Minuten für mich unbrauchbar.


    Code:
    SELECT SYSTEM_TABLE_MEMBER, SYSTEM_TABLE_NAME, SYSTEM_TABLE_SCHEMA, SOURCE_TYPE, PARTITION_TEXT, LAST_SOURCE_UPDATE_TIMESTAMP
    FROM QSYS2.SYSPARTITIONSTAT


    WHERE SYSTEM_TABLE_SCHEMA LIKE 'AB%'
    AND SOURCE_TYPE <> ''
    AND SYSTEM_TABLE_MEMBER LIKE :SUCHWORT


    OR SYSTEM_TABLE_SCHEMA LIKE 'CD%'
    AND SOURCE_TYPE <> ''
    AND SYSTEM_TABLE_MEMBER LIKE :SUCHWORT


    OR SYSTEM_TABLE_SCHEMA LIKE 'EF%'
    AND SOURCE_TYPE <> ''
    AND SYSTEM_TABLE_MEMBER LIKE :SUCHWORT


    ORDER by SYSTEM_TABLE_MEMBER;




    Meine Frage ist nun: Gibt es einen Weg speziell diese Abfrage (oder auch generell alle SQL Abfragen) zu beschleunigen?


    Mit der suFu der Seite und mit der Suche durch Duckduckgo konnte ich leider keine Ergebnisse erzielen.




    Zum testen der SQL Abfragen benutze ich Access Client Solutions




    Viele Grüße und frohes schaffen

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    18.139
    Dein Problem ist, dass du nach Feldern suchst und sortierst, die das Ergebnis einer Prozedur sind (mach mal DSPFD SYSTSTAT). Dies erzwingt einen Tablescan nebst der Ermittlung aller statistischen Informationen, wovon du das meiste wieder wegschmeist.

    Mache lieber eine Abfrage von SYSTABLES, das geht est mal schneller.
    Wenn du dann noch Statistik brauchst, verknüpfte das Ergebnis mit der Prozedur (analog der SYSTSTAT).

    Oder schau dir die SYSTSTAT genau an und suche und sortiere die Felder, die nicht aus der Prozedur kommen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Aug 2017
    Beiträge
    3
    Vielen Dank für die schnelle Hilfe!

    Habe es jetzt so gelöst:

    SELECT SYSTEM_TABLE_MEMBER, SYSTEM_TABLE_NAME, SYSTEM_TABLE_SCHEMA, SOURCE_TYPE, PARTITION_TEXT
    FROM QSYS2.SYSPARTITIONSTAT


    WHERE SYSTEM_TABLE_SCHEMA = 'LIB1'
    AND SYSTEM_TABLE_MEMBER LIKE 'PROG%'
    AND SOURCE_TYPE <> ''
    OR SYSTEM_TABLE_SCHEMA = 'LIB2'
    AND SYSTEM_TABLE_MEMBER LIKE 'PROG%'
    AND SOURCE_TYPE <> ''
    OR SYSTEM_TABLE_SCHEMA = 'LIB3'
    AND SYSTEM_TABLE_MEMBER LIKE 'PROG%'
    AND SOURCE_TYPE <> ''


    ORDER by SYSTEM_TABLE_MEMBER;


    So bleibt die Laufzeit im ms Bereich

  4. #4
    Registriert seit
    Aug 2003
    Beiträge
    1.425
    Du kannst das SQL auch wie folgt zusammenfassen:

    Code:
    SELECT SYSTEM_TABLE_MEMBER, SYSTEM_TABLE_NAME, SYSTEM_TABLE_SCHEMA, SOURCE_TYPE, PARTITION_TEXT
    FROM QSYS2.SYSPARTITIONSTAT
    
    
    WHERE SYSTEM_TABLE_SCHEMA in ('LIB1', 'LIB2', 'LIB3')
    AND SYSTEM_TABLE_MEMBER LIKE 'PROG%'
    AND SOURCE_TYPE <> ''
    
    ORDER by SYSTEM_TABLE_MEMBER;
    lg Andreas

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    18.139
    Bleibt allerdings zu testen, wie der Optimizer ein "in"-Konstrukt auflöst;-).
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    Aug 2003
    Beiträge
    1.425
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Bleibt allerdings zu testen, wie der Optimizer ein "in"-Konstrukt auflöst;-).
    Genauso wie beim OR ;-)

  7. #7
    Registriert seit
    Aug 2017
    Beiträge
    3
    Guter Tipp Andreas

    das fertige Script sieht jetzt so aus:
    SELECT b.OBJLONGSCHEMA as OBJLIB,
    b.OBJNAME as OBJNAME,
    b.OBJTYPE as OBJTYPE,
    a.SYSTEM_TABLE_SCHEMA as SRCLIB,
    a.SYSTEM_TABLE_NAME as SRCTABLE,
    a.SYSTEM_TABLE_MEMBER as SRCNAME,
    a.SOURCE_TYPE as SRCTYPE,
    a.PARTITION_TEXT as DESCRIPTION,
    a.LAST_SOURCE_UPDATE_TIMESTAMP as SRC_LAST_UPDATE
    FROM QSYS2.SYSPARTITIONSTAT a
    FULL JOIN TABLE (QSYS2.OBJECT_STATISTICS('*ALL','*PGM *SRVPGM *FILE *QRYDFN', '*ALLSIMPLE')) b
    on a.SYSTEM_TABLE_MEMBER = b.OBJNAME


    WHERE a.SYSTEM_TABLE_SCHEMA in ('LIB1', 'LIB2', 'LIB3', 'LIB4', 'LIB5', 'LIB6', 'LIB7', 'LIB8', 'LIB9')
    AND a.SYSTEM_TABLE_MEMBER LIKE '%SRCWORD%'
    AND a.SOURCE_TYPE <> ''


    ORDER by a.SYSTEM_TABLE_MEMBER


    Ich war mir nicht ganz sicher mit dem ON Statement im JOIN Segment, aber da es vorkommen kann dass bei uns die gleichen Sourcen in verschiedenen Libls vorkommen und die Sourcen in einem anderen Libl als die Objekte gespeichert sind (fragt mich bitte nicht nach dem Sinn, versteh es selbst nicht wirklich), sieht diese Abfrage für mich so i.o. aus.

    Nochmals vielen Dank an euch beide!
    Für weitere Tipps bin ich gern zu haben

    Viele Grüße

Ähnliche Themen

  1. JDBC:AS400 - Zugriff auf DB dauert SEHR lange
    Von David1608 im Forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 07-09-18, 11:33
  2. SQL Select Statement - Execute dauert sehr lange
    Von max40 im Forum NEWSboard Java
    Antworten: 19
    Letzter Beitrag: 20-02-15, 17:39
  3. Telnet connection dauert extrem lange
    Von Mr-Ferret im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 28-02-14, 10:35
  4. SAVSECDTA mit BRMS dauert sehr lange
    Von Peter Kosel im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 27-11-02, 11:32
  5. Table QSQPTABL in QSYS2
    Von KB im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 18-06-01, 07:35

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •