Anonym.
Hi there,
in Sachen Tuning wollen wir uns mal ins Thema HINTs einarbeiten. Wir manipulieren schon mal Statistik-Daten; das kann aber durch ungeplante RUNSTATSe und REBINDs schnell wieder in die Hose gehen. Leider werde ich aus der Literatur nicht schlau (genug), um SQL-Statements über einen Hint auf einen anderen Zugriffsweg zu bringen.
ZPARM ist gesetzt, PlanTable natürlich vorhanden, OPTHINT gefüllt. Leider bekomme ich beim BindPackage immer SQL-Code 0 (und nicht +394/5) … >:(
Gebt mir bitte mal nen Hint ;), was ich in welcher Reihenfolge machen muss. Habt Ihr auch Erfahrungen damit gemacht? Der Denne hält sich da auch sehr bedeckt ("… und der Optimizer der Empfehlung auch wirklich folgt").
Danke
Alexander
Hallo Alexander,
meines Wissens muss
a) der Installationsparameter "OPTIMIZATION HINTS YES" gesetzt sein,
b) die PLAN_TABLE mind. im 49-Spalten-Format vorliegen und die Spalte OPTHINT
gefüllt sein, z.B. OPTHINT=’MyAccess‘ und
c) der BIND … mit der Option OPTHINT(‚MyAccess‘) durchgeführt werden.
Anschließend sollte SQLCODE +395 (Optimizer hat den Zugriffspfad nicht genutzt) oder
+394 (Zugriffspfad wird benutzt) und in der PLAN_TABLE die Spalte HINT_USED gefüllt sein.
Ich wünsche viel Erfolg
Hansi
Guten Morgen Hansi,
wenn es so einfach wäre …
a) – c) sind erfüllt, deshalb >:(!
Wer hat denn schon mal Hints eingesetzt?
Alexander
Die Zeile muss in der PLAN_TABLE vorhanden sein mit der gleichen COLLID / PROGNAME und vor allem der gleichen Statementnummer.
( Also eine neue Zeile ins Programm eingefügt, neu umgewandelt und schon stimmt die Statement-Nummer nicht mehr … )
Versuch mal einen normalen Bind mit EXPLAIN (YES)
dann UPDATE PLAN_TABLE SET OPTHINT = ‚MYPATH‘ WHERE …
dann REBIND PACKAGE() OPTHINT(‚MYPATH‘)
und schau auf den SQLCODE
Danke Ulrich, genau das habe ich im Laufe des Vormittags ausprobiert; und siehe da: SQL-Code +394. (Kaum macht man es richtig, funktionierts auch ;))
Mein Fehler war, dass ich zu einem einzelnem (identischen) SQL-Befehl einen EXPLAIN erstellt habe; das reicht aber eben nicht. Die Umgebung muss absolut passen (eben CollID, ProgName …).
Wenn man also vorhat, mit Hints zu arbeiten, gibt man den SQL-Statements im Programm feste QUERYNO (mit dieser Option in der Syntax) mit. Rest wie von Ulrich beschrieben.
Grüsse
Alexander
Hi,
habe soeben alles so gemacht wie im Thread beschrieben. Der Bind eines Package mit ca 50 Queries drin mit dem OPTHINT – Parameter läuft aber jetzt schon seit ca 30 Minuten.
In der Plan table sind 2.4 Mio Einträge drin, kann es daran liegen? BRauch ich einen Index? Wenn ja wie muss der aussehen?
Gruß Peter
Für OPTHINTS wird ein Index empfohlen über:
QUERYNO , APPLNAME , PROGNAME , COLLID , VERSION
HAllo,
danke für die Info.
Gruß Peter
Hi Peter,
haeufig werden PLAN_TABLE’s einfach nicht gepflegt, so dass sich dort EXPLAIN Ouput von Monaten oder Jahren ansammelt. Deswegen anhand des Tiemstamps einfach immer wieder mal eine Loeschung durchfuehren. Das klappt besonders gut, wenn regelmaessig REBIND’s mit EXPLAIN(YES) durchgefuehrt werden. Wenn nicht, einfach den letzten Explain Output (je Package) stehen lassen. (Einer der anwesenden Kollegen hat bestimmt ein "Plan Table House Keeping Statement" griffbereit!)
Werden Reorgs, Runstats auf den PLAN_TABLE Tablespace gemacht? Evtl. lohnt sich hier auch PCTFREE 0 und FREEPAGE 0 mit MEMBER CLUSTER, damit Neueintraege ganz unkompliziert einfach ans Ende gehaengt werden. Siehe Thread https://www.ruban.de/cgi-bin/yabb2/YaBB.pl?num=1136542708/11#11
Gruss
Gernot
Ich empfehle, die *beiden* letzten Explains pro Package stehenzulassen. Wenn nämlich dann ein Programmierer sich beschwert, dass sein Programm plötzlich langsam geworden ist, obwohl er "überhaupt nichts gemacht hat" , dann kann man prüfen, ob sich durch die letzte Änderung ein Zugriffspfad geändert hat.
Das Löschen der veralteten Versionen erledigt bei uns ein kleines PL/1-Programm
You must be logged in to reply to this topic.
