Wann genau wird der Plan Cache gelöscht

[dschroeder]

Hallo Forum,

in dem anderen Thread von heute geht es ja bereits um Performance-Probleme nach einem IPL. Ich möchte dazu nochmal etwas genaueres wissen: Es heißt ja, bei einem IPL werden die temporären Indizes und der SQL Plan Cache gelöscht. Aber was genau ist mit "IPL" gemeint. Bei uns gibt es ein CL-Programm für das Herunterfahren des Systems, in dem diverse Aktionen ausgeführt werden. Es werden z.B alle Subsysteme beendet (ENDSBS *ALL), eine Sicherung wird durchgeführt usw. Zum Schluss gibt es den Befehl PWRDWNSYS OPTION(*IMMED) RESTART(*YES *IPLA) CONFIRM(*NO)

Wird das Löschen des Plan-Cache und der Indizes vom PWRDWNSYS ausgelöst oder kann es sein, dass vorherige Befehle (z.B ENDSBS) das schon auslösen?

Weitere Frage: Wenn man auf den PWRDWNSYS nicht verzichten möchte: Kann man ihn so einstellen, dass die Plan-Daten nicht gelöscht werden? Falls nicht, könnte IBM das ja mal implementieren.

Gruß,
Dieter

[Fuerchau]

Auf PWRDWNSYS könnte man verzichten, wenn man nach dem ENDSBS wieder das QSTRUPPGM startet, dass die Subsysteme ja wieder hochfährt.
Das selbe gilt auch für die Dienste (TCP, HostSvr's).

Die Plancaches werden als temporäre Daten in den SQL-Serverjobs (Systemjobs) gehalten.
Wenn man also ausschaltet und wieder einschaltet sind die temporären Daten nun mal weg.

Das kannst du genauso wie Daten in einer QTEMP sehen, ist der Job beendet wird die QTEMP automatisch gelöscht.

[dschroeder]

Was genau heißt "Ausschalten"? Strom weg? Oder heißt das, wenn man alle Subsysteme beendet (damit müssten ja alle Jobs beendet sein) sind die temporären Daten weg? Wenn man die Jobs behalten müsste, würden diese da ja sicherlich Locks auf den Dateien halten und die Sicherung bekäme Probleme, oder?

Vielen Dank schon mal.

Dieter

[Fuerchau]

Ausschalten heißt PWRDWNSYS und eben IPL mit Neustart aller Jobs, auch der Systemjobs.
Der eingeschränkte Zustand beendet nicht die QSQ-Jobs, somit müsste der Cache eben erhalten bleiben.

Aber das ist ja sowiso nur eine Umgehung deines eigntlichen Problems.
Sorge lieber dafür dass die SQLs analysiert und permanente Indizes angelegt werden.

[B.Hauser]

M.E. wird der Plancache nicht beim Herunterfahren gelöscht, sondern beim Hochfahren initialisiert.

Birgitta

[Logic IT-Services]

Plan Cache wird zur IPL Zeit gelöscht.

Dazu ein entsprechender Artikel vom "Mitbewerber-Blatt".

http://bit.ly/PbNLKQ

[dschroeder]

Danke für alle Antworten. Mit Analyse der SQLs ist doch sicher die Verwendung des Index Advisors gemeint. Oder gibt es da noch etwas besseres? Einige Vorschläge, die der Index-Advisor macht, kommen mir ziemlich suspekt vor (z.B. Indizes mit mehreren Schlüsselfeldern, bei denen der erste Schlüssel der Unique Key der Datei ist!)

Dieter

[B.Hauser]

Mit Analyse der SQLs ist doch sicher die Verwendung des Index Advisors gemeint. Oder gibt es da noch etwas besseres? Einige Vorschläge, die der Index-Advisor macht, kommen mir ziemlich suspekt vor (z.B. Indizes mit mehreren Schlüsselfeldern, bei denen der erste Schlüssel der Unique Key der Datei ist!

Es gibt 2 Möglichkeiten die SQL Statements zu optimieren:
1. durch die richtigen Indices, da bieten sich Index Advisor und Index Condenser an
2. durch die Art wie ein SQL Statement codiert ist.

Für die Analyse von SQL-Statements bietet der System iNavigator neben dem Index-Advisor und Index Condesor auch noch die SQE Plan Cach-Analyse sowie die Database Monitor Jobs mit entsprechenden Auswertungen.

Der Advisor schlägt z.T. auch Indices vor, die für einen IOA (Index Only Access) verwendet werden könnten, d.h. alle für die Abfrage benötigten Informationen sind in den Schlüssel-Feldern enthalten, so dass ein Zugriff auf den Datensatz nicht notwendig ist.

Birgitta

[dschroeder]

OK, das mit dem IOA erklärt einiges. Ich habe auch eben gesehen, dass einige empfohlene Indizes mit Primärschlüssel encoded Vector Indizes sind. Das kann natürlich doch Sinn machen. Ich bin allerdings etwas vorsichtig damit, jeden Index, den der Advisor vorschlägt, als permanenten Index anzulegen. In Tabellen, in denen viel gelesen und wenig geschrieben wird, ist das sicherlich OK. Bei Tabellen mit viel Bewegung befürchte ich immer, dass die Performance durch die Pflege der Indizes beeinträchtigt wird.

Vielen Dank für die Anworten
Dieter

[andreaspr@aon.at]

Der Index-Adviser ist nebenbei auch nur als Vorschlag zu betrachten!

Es kann durchaus passieren, dass der dadurch erstellt Index gar nicht verwendet wird, da die DB meint, dass sie ihn lieber doch nicht verwenden will.

Des weiteren sollte auch festgestellt werden, von wo aus die Empfehlung kommt. Nur weil im STRSQL einige User ein paar SELECTs absetzen (die eh schon schnell laufen) muss der dafür empfohlene Index nicht wirklich notwendig sein.

Auch auf das Alter der Empfehlung achten. Eventuell wird diese gar nicht mehr benötigt!

Was die Optimierung betrifft, sollte zuerst das SQL Statement analysiert, und erst zum schluss Indice erstellt werden.

Ich habe schon abfragen korrigiert, wo im Statement eine Logische statt der Physischen verwendet wurde.
Dadurch hab ich die Dauer der Abfrage von bis zu 10 min. auf ein paar Millisekunden verbessern können.

lg Andreas

[dschroeder]

Vielen Dank für die Infos.
Ich mache es im Prinzip so, wie du es beschrieben hast: Nur aktuelle Vorschläge werden überhaupt in Erwägung gezogen. Ich schaue mir natürlich auch an, wie oft der Index angefordert wird und weshalb (war es ein normaler User oder hat ein Programmierer einfach mit SQL "rumprobiert"). Die Sache mit der Analyse der SQL-Statements ist natürlich schwierig. Einige Abfragen werden mit dynamischem SQL zusammengebaut und sehen abhängig davon, was die User selektieren, immer wieder anders aus. Außerdem haben wir einiges über user defined functions gekapselt. Da läuft dann innen eine Mischung aus RPG und embedded sql.

Gruß,
Dieter

[Fuerchau]

Eine Selektion über UDF "... where myudf(..) = xxx" erzwingt natürlich einen Tablescan.
Hier ist ggf. aber zu prüfen ob das nicht anders gelöst werden kann oder zusätzlich Felder zur Abfrage verwendet werden können.

UDF's in der Where-Klausel gehörten aus Performancesicht auch verboten.