[NEWSboard IBMi Forum]
Seite 2 von 3 Erste 1 2 3 Letzte
  1. #13
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Ich glaub die IBM wird sich diese Werte nicht aus den Fingern herbeigezogen haben
    Bei einem Sort wird natürlich, wenn vorhanden, ein Index benützt!

    Der Performance-Nachteil (außer bei einem Index-Only-Access) ist, dass bei einem Index für die Werte der Spalte der Baum von Oben bis Unten durchgegangen werden muss. Und wenn die DB dann den entsprechenden Wert am Ende des Baumes hat muss sowieso nochmal zusätzlich auf die entsprechende Stelle in der Tabelle zugegriffen werden um sich den ganzen Satz zu holen.
    Wenn also sowieso ein sehr großer Teil der Daten benötigt wird, kann die DB gleich die eigentliche Tabelle lesen gehen und braucht nicht ständig hin und her springen.

    Wenn man sich diesen Prozess auf Blockebene ansieht und sieht wann, was, wie, wohin gelesen werden muss ist es einfacher.
    Nebenbei: bei Oracle ist es nicht anders.

    lg Andreas

  2. #14
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Wenn ich mir so die Zugriffsverfahren ansehe und die Ergebnisse betrachte, so kann ich die 20%-Regel nicht nachvollziehen.
    Mache ich einen Select, der mir aus 10Mio Sätzen ca. 1/3 der daten liefert, und ein passender Index vorhanden ist, so weist der Optimizer diesen zumindest aus.
    Das Ergebnis kommt auch schneller als bei einem Select, der einen Tablescan durchführt.

    Bei Oracle kann ich das z.T. nachvollziehen. Beim Laden von Daten aus einer Oracle-DB, die Daten werden per View bereitgestellt, dauert es mitunter doch sehr lange bis der 1. Satz geliefert wird obwohl (angeblich) Indizes vorhanden sind.

    Ich habe aber auch festgestellt, dass ins besonders beim Group by der zwangsweise Verzicht auf die Verwendung eines Index, wenn eine Where-Bedingung mit passendem Index vorhanden ist, schneller zum gewünschten Ergebnis führt.
    Dazu behelfe ich mir mit folgendem SQL:

    select coalesec(key1, key1) key1, coalesec(key2, key2) key2, sum(feld)
    from mytable
    where "Irgendeine Bedingung"
    group by coalesec(key1, key1), coalesec(key2, key2)

    Durch das coalsece wird die Verwendung eines Index für Group By verhindert, da dies ja ein "berechnetes" Ergebnis darstellt.
    Allerdings wird für das Where der korrekte Index verwendet.
    Lass ich den coalesce weg, wird der Index der Key-Felder verwendet, wobei diese ja durch die Where-Klausel noch eingeschränkt werden müssen.

    Klar, jede DB implementiert anders um schnell zum Ergebnis zu kommen, manchmal halt nicht so schnell.
    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. #15
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... wie sich Klein Fritzchen/Erna die Berechnung eines Zugriffsplans so vorstellt...
    Im richtigen Leben werden immer Blöcke in den Hauptspeicher geladen und das ist das, was wirklich Zeit verbraucht. Alles, was dann Speicher resident passiert, wird vernachlässigt, da dies um Größenordnungen schneller ist, als Ein/Auslagerung von Platte. Von Zeit zu Zeit ändert sich dieses zeitliche Verhältnis, durch anders balancierte Hardware (seit RISC hat die AS/400 wesentlich mehr CPU Power, in letzter Zeit sind die Hauptspeichergrößen stark gestiegen) und dann passen sich die Optimierungs Algorithmen daran an.
    Bei allen Optimierungsvorgängen sind Schätzungen über die Größe und Verteilung von Ergebnismengen (können auch Zwischenresultate sein) im Spiel, da helfen auch run Statistiken nur sehr begrenzt. Ändert sich bei neuen Releases was zum Negativen sind das mit höchster Wahrscheinlichkeit Bugs, wohl dem der Database Monitor Daten zum Vergleich hat, der findet hier schnell Work arounds. Für alle Daumenregeln, wie die genannten gibt es reichlich Ausnahme Konstellationen. Sind die Zugriffsprobleme kritisch, weil z.B. ein Programm nicht mehr in der benötigten Zeit fertig wird, hilft nur eine saubere Analyse (Database Monitor) alle Schnellschuß Empfehlungen sind Klugschwätzerei und/oder Scharlatanerie. Letzteres gilt nicht nur für DB2/400, sondern für alle Datenbanken.

    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/

  4. #16
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Eins kannst Du glauben, die Schätzwerte beruhen auf Erfahrungswerten.

    Begingt durch die Baum-Struktur sind Zugriffe mit (Binary Radix Tree) Indices bei größerem Datenvolumen zu langsam.
    Der Optimizer kann jedoch für eine einzige Abfrage mehrere Indices gleichzeitig und auch sub-optimale Indices verwenden und die Ergebnisse in Bitmaps zwischenspeichern und die Bitmaps angschließend auswerten.

    Eine Sortierung ist keine Voraussetzung für die Verwendung eines Idices. Die Sortierung ist das letzte Kriterium, das bei der Optimierung herangezogen wird. Das Hauptziel ist es so schnell wie möglich an die Daten zu kommen. Da ist es manchmal geschickter Informationen in temporären Objekten zwischen zu speichern und erst am Schlusse das Zwischen-Ergebnis zu sortieren.

    IBM hat allerdings nachgearbeitet, indem sie EVIs (Encoded Vector Indicses) zur Verfügung gestellt hat, die jedoch entweder ignoriert oder als Lachnummer abgetan werden.
    Sofern die passenden EVIs vorhanden sind, können diese verwendet werden sofern zw. ca. 20 und 80% der Daten ausgewählt werden.

    ... ansonsten ist die Optimierung halt doch noch ein bisschen komplexer.

    @Baldur: Wenn der Index passt, warum nimmt Du dann nicht native I/O, der verwendet die angegebene logische Datei oder SQL Index ohne Wenn-und-Aber.

    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

  5. #17
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Weil ich keine Lust habe mir beim Native-IO auch noch Group-By's selber zu programmieren.
    Außerdem enthebt mich SQL sämtlicher Levelcheck-Probleme!
    Zusätzlich ist der Index ja nur die halbe Wahrheit.
    Subselect's, CTE, Joins verschiedener Ausprägungen sind nun mal nicht mehr selber in einer vorgegebenen Zeit zu programmieren.
    Es reicht mir, mit meinen Methoden SQL's so zu optimieren, dass der Optimzer zufrieden ist, die Daten vor allem schnell genug kommen und (meistens) der korrekte Index verwendet wird.
    Da ich nicht mit "updatable Selects" arbeite ist es mir häufig lieber, SQL kopiert die benötigten Daten in Zwischentabellen, was man ja nicht beeinflussen kann.
    Bei BI habe ich festgestellt, dass es um Faktoren schneller ist, Teilergebnisse selber in temporäre Ergebnistabellen zu packen als alles in einem gigantischen SQL zu verpacken.
    So habe ich schon Abfragezeiten von zig Minuten auf wenige Sekunden reduziert.
    SQL kann eben nicht alles ersetzen, es hilft es schon mal, auch hier "schrittweise" zu denken.
    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. #18
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nun muss ich diesen Beitrag noch mal aufwärmen.
    Ein Kunde ist nun von V5R4 nach V7R1 umgezogen. Von der Anwendung her war das auch problemlos.
    Allerdings weigert sich die Maschine einen speziellen SQL, der mit V5R4 performant war, nun ebenso performant abzuarbeiten.
    Wie gesagt, es dreht sich nur um SQL per ODBC und kann auch nicht mit ILERPG abgelöst werden.

    Der SQL ist schon sehr komplex, mit 2 CTE's mit "Group By" und 4 derived Tables.
    Sämtliche Indexanalysen wurden durchgeführt, ALLE vorgeschlagenen Indizes wurden angelegt.
    Zur Ausführungszeit wird aber keiner dieser Indizes (mit Aussage 5) verwendet.

    Täglich werden damit ca. 350.000 Sätze abgeholt, was auf der alten Maschine (V5R4) mit ca. 320 Sätzen /Sekunde was also ca. 20 Minuten dauerte.
    Nun wird das Abholen mit ca. 12 Sätzen/Sekunde durchgeführt (manchmal auch weniger), was ca. 8 Stunden oder mehr dauert. Damit kann die Aktualität der Daten nun nicht mehr gewährleistet werden.
    Wer wartet schon 8 Stunden auf aktuelle Daten, die morgens um 08:00 Uhr zur Verfügung stehen sollen und bei einem 24/7-Betrieb noch bis 07:00 Uhr verändert werden können.

    Leider zeigt der Kunde da nicht das geringste Verständnis für die Aufwände, um diesen SQL zu überarbeiten, damit er für V7R1 passt.

    Ach ja, es muss noch gesagt werden, dass die Abfrage ausschließlich auf DDS-Tabellen geht, die NICHT in SQL-Tables umgewandelt werden können. Auch sonstige Modifikationen an den Tabellen (Trigger o.ä.) sind nicht erlaubt, da es ja die aktuelle Anwendung auf der AS/400 betrifft und außerdem das Unternehmen des amerikanischen SOX-Audit's unterliegt.
    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. #19
    Registriert seit
    May 2002
    Beiträge
    2.641
    Hallo Baldur,
    ich würde einmal nach diesen Ptfs schauen:

    MF58235, MF58352, MF58026,SI52257

  8. #20
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Ob diverse Indice (EVI, Binary) oder sonstige Einstellungen daran schuld würde man ja am besten bei einem Vergleich der alten und neuen Zugriffspläne sehen ... das wird - so schätze ich - jetzt nicht mehr möglich sein.

    Die Indexvorschläge sollten auch nur als solches wahrgenommen werden ... einen Vorschlag.
    Ob und welche Indice schlussendlich angelegt werden sollte man, basierend auf einer näheren Analyse, lieber selbst entscheiden.

    Es gibt sehr viele Faktoren die sich auf die Performance auswirken können ... aber das weist du sicher selbst auch.
    Stimmen die Einstellungen (Caching, QAQQINI), sind die "RICHTIGEN" Indice angelegt, usw. usw.

    lg Andreas

  9. #21
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Leider zeigt der Kunde da nicht das geringste Verständnis für die Aufwände, um diesen SQL zu überarbeiten, damit er für V7R1 passt.
    ... da muss er sich halt beim Lieferant der Datenbank beschweren, entweder hat die Datenbank oder ein Index ein defect Problem.
    Wenn er da nicht durchdringt oder ihm das zu lange dauert, gibt es da vielleicht schon noch Software technische (Selektivität über UDTF vorziehen) oder Datenbanktechnische (mehr Redundanz über MQT) Möglichkeiten, eventuell auch in der Kombination.

    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/

  10. #22
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    Wie gesagt, es dreht sich nur um SQL per ODBC und kann auch nicht mit ILERPG abgelöst werden
    Hast du den die Möglichkeit es in einem embeddet SQL (oder sogar interaktiv in eine andere Tabelle)
    auszuprobieren? Zur Klärung der Frage: Ist es die DB oder ist es der ODBC Treiber.
    Robi
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  11. #23
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    @Robi
    SQL kann nie von einem ODBC-Treiber ausgeführt werden. Dieser stellt ja nur die Verbindung zum System her und reicht dies dann an die DB weiter.
    Man sieht das dann auch schön im Joblog des QZDASOINT.

    Zumindest hat der Kunde mal versprochen, die DB-/PTF's noch zu installieren, ich werde berichten.
    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

  12. #24
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    Ok, trotzdem gib es zwischen verschiedenen Treibern teilweise erhebliche performance Unterschiede.
    Und ich meine, das wir mal den Fall hatten, wo ein ODBC Treiber ein SQL deutlich schneller ausführte als ein JDBC Treiber. Eine andere Anforderung (selbe AS400, selber PC) aber vom JDBC schneller bedient wurde. Daher denke ich schon, das der Treiber am Rande mitspielt.
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

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
  •