[NEWSboard IBMi Forum]
Seite 1 von 3 1 2 ... Letzte
  1. #1
    Registriert seit
    Feb 2001
    Beiträge
    20.207

    SQL-Optimizer V7R1 und kein Ende

    Wieder ein mal habe ich z.T. massive Probleme mit dem SQL-Optimizer nach der Umstellung von V6R1 auf V7R1.

    Zugegriffen wird per ODBC oder OLEDB.

    SQL's die mit V6R1 noch schön schnell liefen, laufen nun mit V7R1 z.T. erheblich langsamer.
    Indexe, die früher verwendet wurden, werden nun ignoriert.
    Statt dessen tauchen vermehrt Debug-Meldungen wie "temporäre Ergebnistabelle erstellt, Dauer 1,0 Sekunden".
    Das Problem, diese Ergebnistabelle enthält genau so viele Sätze wie das Original und das bei weniger als 1000 Sätzen.

    Eine andere Tabelle enthält einen Schlüssel nach Firma/Werk/Kunde.
    Ich frage nur ab "select * from Kunde where Firma=? and Werk=?" um alle Kunden eínes Mandanten zu bekommen.
    Der Optimizer schlägt einen Index nach "Werk/Firma/Kunde" vor, ich kann mir das nicht erklären und verwendet wird dann auch noch Eingangsfolge.

    Per ODBC frage ich ebenso Schemainformationen ab.
    Hier verwende ich die Standard-ODBC-Schemaabfragen, also nichts mit eigenen -SYSCOLUMNS-Zugriffen, das regelt dann der Treiber selber.
    Es werden gezielt die Spalten einer LIB/Datei geladen.
    Im Joblog findet man dann Einträge wie "Empfohler Zugriffspfad für SYSCOLUMNS".
    Was für ein Schwachsinn!!!

    Bei der Verwendung des CA-ODBC-Treibers werden die Schemaabfragen sogar mit Querytimeout-Überschreitung abgewiesen!
    Verwende ich den IBMDASQL-OLEDB-Treiber, klappt zumindest dieses.

    Ich weiß auch nicht, was sich die IBM da mal wieder gedacht hat.

    Abfragen, die mit V6R1 noch 1-2 Sekunden gebraucht haben (mehrere 1000 Sätze) dauern nun mehrere (> 15) Minuten!
    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

  2. #2
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Ich weiß auch nicht, was sich die IBM da mal wieder gedacht hat.
    Vielleicht solltes Du genau das die IBM fragen und einen CALL aufmachen.

    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

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn ich dafür die Berechtigung hätte, würde ich dies ja gerne tun .
    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
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Ich weiß auch nicht, was sich die IBM da mal wieder gedacht hat.
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Wenn ich dafür die Berechtigung hätte, würde ich dies ja gerne tun .
    ... genau das hat sich IBM wohl dabei gedacht: wie verkaufen wir jetzt noch ein paar Software-Wartungs-Verträge (allein schon dieses Wort, Software verschleißt nicht, die ist entweder bei Auslieferung schon defekt, oder halt nicht).

    Aber vielleicht hast Du ja auch Glück und es handelt sich nur um eine vorüber gehende Winterdepression des Optimizers, der sich dann als Pessimizer gebärdet.

    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 Fuerchau Beitrag anzeigen
    Abfragen, die mit V6R1 noch 1-2 Sekunden gebraucht haben (mehrere 1000 Sätze) dauern nun mehrere (> 15) Minuten!
    Also eine Abfrage die vorher 1-2 Sekunden gedauert hat, soll plötzlich 15 minuten benötigen??
    Wenn das wirklich so ist, dann hat diese Kiste einiges an Problemen!!

    Könnte es vielleicht an der ODBC Version liegen?

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Du kannst mir glauben, dass ich diesbezüglich alles bereits geprüft habe.
    Das einzige, was ich nicht prüfen kann, das muss der Kunde selber, ist der aktuelle DB-PTF-Stand.

    Was mich ärgert ist grundsätzlich das unterschiedliche Verhalten zwischen STRSQL und ODBC.
    Selbst bei "optimize for 10000 rows" ist STRSQL einfach schneller.
    Wie gsagt, ich weiß nicht was sich IBM dabei denkt.
    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
    Jan 2007
    Beiträge
    904
    Vielleicht hilft Dir das weiter...

    http://www-01.ibm.com/support/docvie...d=nas8N1015556
    kf

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Bitte entschuldige, aber das ist bereits ein alter Hut und wird von mir immer als erstes geprüft.
    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 2009
    Beiträge
    121
    Speziell für den Datenbank-Optimierer in V7R1 gab es gerade ein Problem, das mit dem PTF MF57834 behoben wird.

    Mit freundlichen Grüßen,
    Christian Bartels.

  10. #10
    hs is offline [professional_User]
    Registriert seit
    Jun 2001
    Beiträge
    364
    Wir hatten auch so komische Effekte auf unserer neuen Anlage mit OS 7.1
    90% der SQL liefen so schnell, wie man es erwarten konnte. Aber einige - insbesondere wenn man mehrere Tabellen mit JOIN verknüpft hat, waren faktor 3 bis 4 langsamer.
    PTFs haben nichts gebracht. Erst nachdem wir passende Indizes erstellt hatten, liefen diese so flott wie man es erwartet auf einer neuen Anlage.
    Seltsam, auf der alten hatten wir die Indizes ja auch nicht...

  11. #11
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Im alten System/Release war vielleicht noch die CQE (Classic Query Engine) beteiligt, die anders arbeitet als die SQE (SQL Query Engine).
    Die CQE ermittelt die Indices basierend auf Schätzwerten, d.h. bei einer Auswahl in den Where-Bestimmungen mit = wird von 10% der Daten ausgegangen, bei <= von 33% der Daten etc. das ganze wird zusammengemischt und ausgerechnet etc.
    Die SQE arbeitet mit Statistiken, d.h. also der echten Datenzusammensetzung und bewerte die Zugriffswege auf dieser Basis.
    Ein Index-Access wird nur ausgeführt, wenn weniger als 15 max. 20% der Daten einer Tabelle/Datei ausgewählt werden.
    Damit können beide Query-Engines zu unterschiedlichen Ergebnissen kommen, d.h. Zugriffswege, die die CQE aufgrund der Schätzwerte ermittelt hatte, konnten bei der SQE basierend auf den Echt-Daten nicht mehr verwendet werden.
    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

  12. #12
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Warum ist ein Index mit max. 20% der daten ungünstig?
    Das ist doch glatt ein Designfehler.
    Selbst wenn ich 100% der Daten benötige, könnte SQL sich ja zumindest den Sort sparen, was bei ein paar Mio Sätzen durchaus performance bringt.
    Auch wenn ich 30% von z.B. 100 Mio Sätzen benötige wäre eine Indexverwendung jedenfalls die bessere Alternative.
    Da sollte IBM mal nachbessern und die Prozente ignorieren.
    Wenn ein Index passt, ins besonders ein Compound-Index (mehrere Felder) sollte dieser auch verwendet 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. V5R4 -> V7R1, Problem mit Trigger-Programmen
    By programmer400 in forum NEWSboard Programmierung
    Antworten: 13
    Letzter Beitrag: 03-12-13, 15:19
  2. QNTC ist leer auf neuer AS400 (V7R1)
    By mott in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 20-11-13, 15:08
  3. neue Maschine, V7R1, IFS
    By programmer400 in forum IBM i Hauptforum
    Antworten: 16
    Letzter Beitrag: 19-11-13, 12:05
  4. Euro-Zeichen und kein Ende
    By Herbert Schmidt in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 16-11-01, 01:26
  5. AS/400 Mod. 170 #2385 per Ende 3/2001 zvk!!!
    By tomski in forum NEWSboard Server & Hardware Markt
    Antworten: 1
    Letzter Beitrag: 05-03-01, 16:00

Berechtigungen

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