[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Aug 2005
    Beiträge
    14

    Index Advisor Empfehlung vs. "no low cardinality"

    Hallo zusammen,

    ich hätte gerne mal eure Meinung / eure Best Practice, zu den Indexempfehlungen:

    Grundsätzlich sollten Felder mit geringer Kardinalität (wenigen distinct Values, z. B. Status-Felder) nicht als erstes Keyfeld in einem Index verwendet werden. Trotzdem kommen vom Indexadvisor immer wieder genau solche Vorschläge.

    Meist ist dann als erster PrimaryKey das "Statusfeld" und als zweites Keyfeld der eigentliche PrimaryKey der Tabelle aufgeführt. In der Indexadvisor-Spalte "Leading Keys Order Independent (The keys at the beginning of the KEY_COLUMNS_ADVISED field that could be reordered and still satisfy the index being advised.)" sind dann jeweils die beiden Spalten aufgeführt, entsprechend ändere ich für den zu erstellenden Index die Reihenfolge der Felder.

    Vom Indexadvisor wird natürlich weiterhin ein entsprechender Index (1. Statusfeld, 2. PrimaryKey) empfohlen (auch in beim "komprimierten Advisor").

    Wie macht ihr das? Ignoriert ihr dies Empfehlungen einfach? Sollten die beachtet werden? Können solche Empfehlungen ausgeschaltet werden?

    Merci
    Bernd

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... das low cardinality Kriterium würde ich so nicht unterschreiben, richtig ist:
    - hat der komplette Index wenig Ausprägungen, dann (und nur dann) ist er kontraproduktiv, da der full table scan schneller ist.
    - kommen weitere Felder hinzu und der Index hat hohe Anzahl Ausprägungen ist die Performance nicht unterschiedlich.
    - der Index mit dem lc Feld vorne ist lediglich ein wenig größer
    - für andere Zugriffe (Sortierung) ist es von anderen Faktoren abhängig, was da besser ist.

    Ich würde das von sachlichen Kriterien abhängig machen, z.B.:
    - echte Keys a la Mandant, Firma, Auftragsnummer: Reihenfolge so wie dargestellt
    - Felder, die echte Klassen erzeugen (Status aktiv, gelöscht ...) näher untersuchen
    - Attribut-artige Felder: eher nach hinten

    Empfehlungen des Index Advisors sind für mich weniger als Vorschläge und tendenziell eher wertlos. Wichtiger ist es Abfragen, die zu lange dauern mit Database Monitor möglichst im Echt Umfeld tersuchen und auf Spielzeug (Visual Explain und Co.) verzichten, da verschwendet man lediglich Zeit.

    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/

  3. #3
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Ich schau selten in den Index Advisor rein.

    Im Plan-Cache kann ich mir die am längsten dauernden Pläne anzeigen lassen und diese dann optimieren.
    Bzw. kommt der Bedarf einer Optimierung meist von den Anwendern.

    Ich verwende "Spielzeug" wie Visual Explain da sie sehr schön die Verarbeitungsschritte anzeigen.
    Und zusätzlich sehe ich dort auch welcher Bereich einer Abfrage in jedem einzelnen Schritt verarbeitet wird.

    Dadurch habe ich schon viele Abfragen erfolgreich optimieren können.
    Kann ich nur jedem empfehlen sich dahin gehend etwas Zeit zu nehmen und sich das anzuschauen.

    lg Andreas

  4. #4
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Hallo Andreas,

    den Visual Explain verwende ich auch ab und zu. Man muss sich allerdings wirklich damit beschäftigen, sonst erkennt man nichts. Aber eine Frage zum Plan-Cache. Wie kann man den anzeigen? Geht das auch über den Navigator?

    Dieter

  5. #5
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    System --> Datenbanken --> deine DB --> SQL-Planungscache --> Rechts Klick --> Anweisungen Anzeigen.

  6. #6
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Vielen Dank. Jetzt habe ich es gefunden.

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... der Haken am Plan Cache ist doch, dass ich nicht erkenne welche Abfragen woher kommen und in Bezug auf Kosten/Nutzen Abschätzung ist die Häufigkeit einer Abfrage und die Relevanz bzw. Priorität einer Anfrage von eminenter Bedeutung. Kommt man über den Plan Cache verbringt man zuviel Aufwand für Dinge, die nicht optimiert werden müssen und übersieht kritische Engpässe.

    Was den Visual Explain angeht, ist der große Haken, dass er für kritische Abfragen nicht viel hergibt, weil er in einer völlig anderen Umgebung läuft. Was hilft es dem VW-Fahrer, wenn sein Auto auf dem Prüfstand wenig Sprit braucht und wenig Abgase hat, wenn das nur für den Prüfstand gilt - entscheidend sind die Verhältnissse im Echtbetrieb.

    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
    Aug 2003
    Beiträge
    1.508
    Also wie gesagt, Visual Explain ist für mich eines der Kern-Tools zur Analyse.
    Ich habe damit noch keine Probleme gehabt.
    Da mit Verwendung dieses Tools nebenbei quasi der DB-Monitor eingeschaltet wird, verhält kann die Abfrage selbst natürlich etwas länger dauern.
    Ich kann es aber nur Empfehlen.

    Du kannst dir damit auch aktive Abfragen im Echtbetrieb analysieren lassen.
    Wenn du z.B. einen Job hast, bei dem das SQL sehr lange dauert und du wissen willst, wie der Plan von dieser Abfrage aussieht, die gerade ausgeführt wird.

  9. #9
    Registriert seit
    Aug 2005
    Beiträge
    14
    Herzlichen Dank für die Feedbacks!

    Der Indexadvisor ist für mich trotz allem ein Werkzeug, das gewisse Anhaltspunkte liefert, wo und was Probleme bereitet - viele der Empfehlungen ignoriere ich, insbesondere, wenn sich noch niemand über die Performance beschwert hat.

    So wie die Antworten von euch klingen, benutzt den Advisor anscheinend niemand intensiv. Mich würde nämlich schon noch interessieren, ob ihr den Angaben von "Leading Keys Order Independent" überhaupt eine Bedeutung zukommen lasst.

    Kann mir jemand einen Link oder Leseempfehlung zum Plan Cache geben? Damit hab ich noch nicht gearbeitet. Die Abfragemöglichkeiten finde ich aber interessant.

    VisualExplain ist für mich bei komplexen Selects ein hervorragendes Spielzeug, um den Anpassungsbedarf am SQL zu erkennen - da sind mir schon mehrfach suboptimale SQLs aufgefallen, die ich sonst erst nach längeren Suchen identifiziert hätte.

    ...die Debugger-Analyse mach ich in der Regel erst, wenn ich wirklich um jedes Detail kämpfe.

    Aktuell bevorzuge ich eher die Variante Indizes gemäss Advisor-Empfehlung zu erstellen und danach die Statistikdaten abzufragen (qsys2.SYSTABLEINDEXSTAT) - nicht/wenig verwendete Indizes werden wieder gelöscht.

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von berndl Beitrag anzeigen
    Herzlichen Dank für die Feedbacks!

    Der Indexadvisor ist für mich trotz allem ein Werkzeug, das gewisse Anhaltspunkte liefert, wo und was Probleme bereitet - viele der Empfehlungen ignoriere ich, insbesondere, wenn sich noch niemand über die Performance beschwert hat.

    So wie die Antworten von euch klingen, benutzt den Advisor anscheinend niemand intensiv. Mich würde nämlich schon noch interessieren, ob ihr den Angaben von "Leading Keys Order Independent" überhaupt eine Bedeutung zukommen lasst.

    Kann mir jemand einen Link oder Leseempfehlung zum Plan Cache geben? Damit hab ich noch nicht gearbeitet. Die Abfragemöglichkeiten finde ich aber interessant.

    VisualExplain ist für mich bei komplexen Selects ein hervorragendes Spielzeug, um den Anpassungsbedarf am SQL zu erkennen - da sind mir schon mehrfach suboptimale SQLs aufgefallen, die ich sonst erst nach längeren Suchen identifiziert hätte.

    ...die Debugger-Analyse mach ich in der Regel erst, wenn ich wirklich um jedes Detail kämpfe.

    Aktuell bevorzuge ich eher die Variante Indizes gemäss Advisor-Empfehlung zu erstellen und danach die Statistikdaten abzufragen (qsys2.SYSTABLEINDEXSTAT) - nicht/wenig verwendete Indizes werden wieder gelöscht.
    ... da ist vieles richtig und vernünftig, allerdings fehlt mir das wichtigste Instrument: der Database Monitor (mit allen Details 2 Stunden mitlaufen lassen und dann die Ergebnisse nach fallenden Antwortzeiten die Langläufer analysieren).
    Der DB Monitor zeigt die Ergebnisse im echten Umfeld (anders als Visual Explain) und ich bekomme auch Informationen über den Ausgangspunkt der Abfrage und die Häufigkeit (anders als Index Advisor).

    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/

  11. #11
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    @Bender: Was meinst du eigentlich mit "echten Umfeld"??
    Visual Explain und DB Monitor gehören zusammen sind aber nicht das gleiche!
    Ich schalte den DB Monitor ein, lasse ihn eine bestimmte Zeit lang mitlaufen und analysiere das Ergebnis des DB Monitor u.a. auch mit Visual Explain.
    Das Ganze ist eine Pyramide beginnend mit den groben Infos der Zusammenfassung, bis hin ins detail der einzelnen Abfrage (Visual Explain).

  12. #12
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von andreaspr@aon.at Beitrag anzeigen
    @Bender: Was meinst du eigentlich mit "echten Umfeld"??
    Es ist ein eklatanter Unterschied, ob ein Zugriff
    - in einem Serverjob oder einem interaktiven oder einem Batchjob erfolgt
    - wieviel Speciher der Job bekommt (=> Subsystem)
    - ob ein bestimmter Zugriffspfad in einem Job schon einmal benutzt wurde (caching)
    - wie die Ressourcenauslastung der Maschine in dem Augenblick aussieht, in dem der produktive Zugriff erfolgt.

    um nur ein paar Faktoren zu nennen und genau da ist der DB Monitor der einzige Weg reale Engpässe zu erkennen.

    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/

Similar Threads

  1. Index Advisor: Was bedeutet "Empfohlene Indizes entfernen"
    By dschroeder in forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 18-11-15, 16:38
  2. MinusField falsche Darstellung "ü" statt "-"
    By Edi in forum IBM i Hauptforum
    Antworten: 8
    Letzter Beitrag: 07-11-14, 08:52
  3. Cobol/400 - "Fett", "Unterstreichen" als HEX-Wert
    By RLurati in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 05-08-14, 10:10
  4. starten Group Job in einer Interaktiven Session "vom aussen"
    By OMi in forum NEWSboard Programmierung
    Antworten: 11
    Letzter Beitrag: 17-02-14, 15:44
  5. "zu wenig Speicher" Rational Developer for Power-Systems
    By loeweadolf in forum NEWSboard Programmierung
    Antworten: 4
    Letzter Beitrag: 13-02-14, 21:58

Berechtigungen

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