QSQSRVR

[Fuerchau]

Das ganze heißt offiziell "Common-Table-Expression", siehe unter
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/db2/rbafzmstintsel.htm#HDRCOMTEXP

und zeitigt ganz erstaunlich Ergebnisse.

Möchte ich per ODBC (und bei JDBC findest du sicherlich ähnliche Anwendungen) dem Benutzer e.g. die Anzahl erwarteter Datensätze anzeigen (Fortschrittsanzeige ist da sehr schön) verwende ich folgende Methode (natürlich erst ab V5):



with
xTable as (fullselect)
,
xCount as (select count(*) as xRecs from xTable)

select * from xTable, xCount


Mit diesem Crossjoin bekomme ich zwar die Anzahl als letztes Feld immer übergeben, aber ich kann nun eine Fortschrittsanzeige darstellen und der Overhead ist geringfügig !

[Henrik Motzkus]

Vielen Dank für die Antworten. Wie man sieht kommen hier die Ansätze zur Perfomancesteigerung aus zwei unterschiedlichen Ecken. Einerseits eine optimal Ausschöpfung aller Möglickeiten in SQL (saubere Programmierung und durchdachtes Datenbankdesign) , was mir in meinem Fall nichts nützt, weil ich auf die Programme unserer Entwickler keinen Einfluss habe, und andererseits ein optimal konfiguriertes System. Auf letzteres habe ich Einfluss und kann schalten und walten. Trotzdem bin ich jetzt immer noch nicht schlauer, was meine Datenbankjobs angeht.

Kann ich die Performance steigern indem ich einen zusätzlichen SHRPOOL für diese Jobs anlege oder nicht? Würde das Paging nur aufhören, wenn noch mehr RAM zur Verfügung steht?

Und den WAS auch noch in einen extra Pool packen?

@Bender: Ich versuche die Ursache herauszufinden indem ich an solchen Schrauben drehe. Aber ich darf doch wohl vorher die Frage stellen ob es nun die richtige Schraube ist, ohne gleich eine Grundsatzdebatte über Sinn und Unsinn zu beginnen.
Vielleicht hat schon jemand damit Erfahrungen gemacht? Das reicht im Prinzip schon.

Vielen Dank

Gruß Henrik

[Fuerchau]

Auch hier sei nochmal gesagt !
Solange du über die Zugriffswege der Datenbankjobs keine Informationen bekommst, kannst du dein System nicht optimieren !!!

Wenn nun mal ein Select abgesetzt wird, der einen Tablescan erzwingt über e.g. 1.000.000 Sätze, erreichst du mit Speicher und Platten fast gar nix.

Du müsstest genausoviel Hauptspeicher haben wie Platten um eine einigermassen verträglich Laufzeit zu haben. Mit eigenen Pools, die der automatischen Anpassung ggf. nicht unterliegen, erschwerst du das Problem nur.
Hast du für Pools automatische Anpassung (Performance Adjust) brauchst du keine eigenen Pools ! Dein Hauptspeicher ist schließlich endlich und wo nix ist kann nix kommen.

Wenn du keine Infos bekommst, dann schau mal unter "QAQQINI" ins forum und setze den generelllen Wert für DEBUG-Nachrichten (kann man ja später wieder rausnehmen). Beobachte nun die QZDA*, dort findest du dann entsprechende Hinweise für Zugriffspfade.
Diese kannst du unabhängig von der Anwendung jederzeit erstellen !!!

Du wirst, sehen, das bringst !

Ich habe auch schon Join-Queries erstellt, die plötzlich 100.000.000 Zugriffe auf ein paar tausend Sätze erzeugen. Hier hilft auch kein Zugriffspfad sondern nur Redesign.

[BenderD]

Hallo Henrik,

ich habe damit schon Erfahrungen gemacht. Mal gute, mal schlechte, je nach Problemstellung und Rahmenbedingungen.
Wenn das mit den sparsamsten Angaben zu beantworten wäre, dann wären die defaults andere, oder das würde automatisch eingestellt werden.
Wenn man keinen Rat annehmen will, dann fragt man besser nicht.

mfg

Dieter Bender