Zugriff über ODBC

[vividcotta]

Hallo,

ich greife mit SQL über ODBC auf DDS-PF- Dateien auf der AS/400 zu. Mir ist das Handling der Key-Felder auf der AS/400 nicht ganz klar!

Wenn ich in einer DDS-PF-Datei ein Feld als Key deklariere, wäre das Feld dann schon Bestandteil eines Index? Oder muss ich zusätzlich eine LF-Datei für dieses Feld erstellen? Oder sind die LF-Dateien nur dann wichtig, um weitere/andere Felder zu indizieren?

Greift das SQL-Statement auf die PF-Datei zu oder muss/sollte die LF-Datei verwendet werden?

Wird bei einem Zugriff auf eine PF-Datei der am besten passende Index automatisch verwendet?

Vielen Dank für Eure Mühe

Viele Grüße

Vividcotta

[Fuerchau]

Zu allen Fragen im Wesentlichen ganz klar: Ja!

Ein Key einer PF ist auch ein Index.
Jede LF ohne Select/Omit und Join ist ein Index (Create Index erzeugt eine LF).

Beim Zugriff auf eine LF verwendet SQL immer die PF, die LF wird nur dann verwendet, wenn deren Index passt und sie eben keine Select/Omit enthält.

Allerdings wird intern der SQL um eine Where-Bedingung ergänzt die den Select/Omit enthält.
Anschließend wird ein passender Index gesucht wobei selbige LF wiederum ignoriert wird.

Findet SQL keinen passenden Index, entscheidet der Optimizer:
a) bilde einen temporären Index
b) durchsuche die gesamte PF (Tablescan)

[B.Hauser]

Jede LF ohne Select/Omit und Join ist ein Index (Create Index erzeugt eine LF).

Jede logische Datei mit einem Schlüssel (unabhängig davon ob select/omit-Anweisungen und/oder join-Anweisungen angegeben wurden) hat einen Zugriffsweg, der von SQL wie ein Index verwendet werden kann.

Ein Schlüssel in einer physischen Datei wird als primary key constraint gehandelt und ist ebenfalls ein Zugriffsweg, der von SQL verwendet werden kann.

Beim Zugriff auf eine LF verwendet SQL immer die PF, die LF wird nur dann verwendet, wenn deren Index passt und sie eben keine Select/Omit enthält.

Wird eine logische Datei in einem SQL Statement angegeben, muss der Query Optimizer das SQL Statement so umschreiben, dass die physische Datei verwendet wird. Dazu muss das DDS der logischen Datei analysiert und aufgelöst werden. Aus der DDS beschriebenen logischen Datei werden allerdings nur die Feld-Auswahl, die Select/Omit-Anweisungen und die Join-Informationen entnommen und aufgelöst. Die Key Informationen bleiben unberücksichtigt.

Bis vor Release 7.1 konnten solche DDS-Analysen nur von der alten/classic Query Engine (CQE) ausgeführt werden und nicht von der neuen SQL Query Engine (SQE). Das Rerouting an die alte Query Engine kann zwischen 10 und 15% Performance kosten.

Die eigentliche Optimierung, d.h. ob und welcher Zugriffsweg verwendet wird erfolgt erst nach dem Umschreiben des SQL-Statements. Zu diesem Zeitpunkt weiß der Optimizer nicht mehr, dass ursprünglich eine logische Datei mit irgendwelchen Schlüssel-Feldern angegeben war, d.h. es werden ALLE Zugriffswege analysiert und bewertet.

Deshalb NIEMALS eine DDS-beschriebene logische Datei in einem SQL-Statement angeben.

Für eine perfomante Verarbeitung von SQL Statements sind die richtigen Zugriffswege (geschlüsselte logische Dateien oder SQL Indices) unbedingt erforderlich. Im Gegensatz zu einer logischen Datei kan ein SQL Index nicht in einem SQL-Statement angegeben werden.

Birgitta

[Fuerchau]

Bis V5R4 kann ich nur sagen, dass eine LF mit Select/Omit als Index nie verwendet wird.
Auch wenn ich als SQL einen identischen Select absetze, findet der Optimizer diese LF nicht, was ich auch verstehen kann und was man an Hand der ODP's und Debug-Nachrichten auch verfolgen kann.
Wie das mit V6 oder gar V7 wird entzieht sich mir, da meine Kunden zwischen V4R3 und V5R4 arbeiten.

[andreaspr@aon.at]

Bis V5R4 kann ich nur sagen, dass eine LF mit Select/Omit als Index nie verwendet wird.
Auch wenn ich als SQL einen identischen Select absetze, findet der Optimizer diese LF nicht, was ich auch verstehen kann und was man an Hand der ODP's und Debug-Nachrichten auch verfolgen kann.
Wie das mit V6 oder gar V7 wird entzieht sich mir, da meine Kunden zwischen V4R3 und V5R4 arbeiten.

Sowas, jetzt darf ich auch mal den großen Meister korregieren (und hoffe ich schreib keinen Blödsin)
Bei V5R4 greift er auch auf Select/Omit-LFs zu. Es gibt dafür in der QAQQINI auch den Eintrag "IGNORE DERIVIDE INDEX" damit er solche LFs ignoriert, da diese von der SQE nicht unterstützt werden (glaub ab 7.1 schon) und daher mit der alten CQE abgearbeitet werden.
Bei V5R4 ist dieser QAQQINI Parameter mit Default *NO, ab 6.1 ist er Default auf *YES.
Gehör ich jetzt auch zu den Großen?

[BenderD]

... welche Query Engine da was abarbeitet - das sollte einem sowas von Wurscht (in Worten: Wurscht) sein, man verwende das, was am besten passt und den Rest sollte die Query Engine erledigen, wenn sie denn was taugt (und die alte Query Engine hat was getaugt und die neue fängt langsam an was zu taugen - wie kann man nur so blöd sein, zwei parallel zu haben...).
Das mit den Indexen, das ist so eine Sache, die IBM vor lauter Redundanz im Query Engine Bereich verschlafen hat, aber vielleicht kommen sie ja jetzt dazu, wo sie den Kunden keine Ausreden über CQE und SQE mehr verkaufen müssen, eine taugliche Strategie für das automatische anlegen von Indexen (temporär werden die eh erzeugt) zu implementieren, damit DB2 auf der AS/400 wieder zur einfachst zu administrierenden Datenbank wird, was sie klassischerweise einmal war.

D*B

[holgerscherer]

Wie das mit V6 oder gar V7 wird entzieht sich mir, da meine Kunden zwischen V4R3 und V5R4 arbeiten.

Ab V6 ist da einiges passiert, und ich muss gestehen, der Optimizer in V7 holt teilweise interessante Ergebnisse raus. Wenn immer es meine Zeit erlaubt, vergleiche ich die Releases, da ich derzeit viel mit ODBC und co. arbeite; habe leider momentan keine drei baugleichen Kisten frei.

Empfehle Deinen Kunden mal ein Upgrade, das kann bei Problemen etwas Abhilfe schaffen.

-h

[andreaspr@aon.at]

... welche Query Engine da was abarbeitet - das sollte einem sowas von Wurscht (in Worten: Wurscht) sein, man verwende das, was am besten passt und den Rest sollte die Query Engine erledigen

Meiner Erfahrung nach ist genau DAS das Problem. Viele Kollegen kennen sich mit den Engines nicht aus. Bzw wissen gar nicht dass es eine CQE oder SQE gibt. Dementsprechend wird dann eine Abfrage erzeugt die elends langsam ist, weil zb statt einem PF eine DDS Keyed-LF verwendet wird. Und dann kommen Aussagen wie: SQL ist ja ur langsam und schlecht.

... aber vielleicht kommen sie ja jetzt dazu, wo sie den Kunden keine Ausreden über CQE und SQE mehr verkaufen müssen, eine taugliche Strategie für das automatische anlegen von Indexen (temporär werden die eh erzeugt) zu implementieren, damit DB2 auf der AS/400 wieder zur einfachst zu administrierenden Datenbank wird, was sie klassischerweise einmal war

Gibt es sogar schon teilweise. Ab 6.1 bleibt der temporäre Index bestehen (bis zum nächsten IPL oder der Index nicht mehr benötigt wird)
Und zB mit dem Index-Adviser muss man sich mit "Wie erstelle ich einen Index" auch nicht auskennen --> Einfach nur bestätigen.

[BenderD]

@Query Engines: wer Statements auf eine spezifische Eigenschaft eines bestimmten Releases hin frisiert, koppelt sich von künftigen Verbesserungen von Hardware oder Software ab! Was zum Zeitpunkt x richtig war oder ist, kann zum Zeitpunkt y falsch sein. SQL ist eine Schnittstelle, die Datenbank und Hardware entkoppelt und das soll sie auch!

@Index Cache: geht durchaus in die richtige Richtung, aber andere Datenbanken sind da besser und der Index Advisor, das soll ja wohl ein Scherz sein, der Oops Nerv, auch wenn er sich sonst wie nennt, das ist doch immer noch Murks (in Worten: Murks!). Das ist ja mit den Releases sogar schlechter geworden, die alten Diagnostic Meldungen und die Daten des Database Monitors sind das richtige Leben, jede Empfehlung aus einer Umgebung außerhalb dessen basieren auf oft falschen Voraussetzungen.

D*B

[Fuerchau]

Und was den empfohlenen Upgrade angeht so ist dieser von einigen Kunden schlicht unbezahlbar, insbesonders was die Lizensierung so angeht.
Ausserdem gibts da so manche Alt-Software die nicht V6-fähig ist, das Softwarehaus nicht mehr existiert oder der Upgrade auch dieser Software oft schlicht zu teuer ist.
Auch was das Finden von Nachfolgeprodukten angeht gestaltet sich das auch mitunter als schwierig bis unmöglich, weil es da für AS/400 einfach nichts gibt.

Solange die Hardware mitspielt und von Brokern noch entsprechende Hardware zu bekommen ist wird eben noch mit V4R3 (noch keine User-Lizenzen) bis V5R4 gearbeitet werden.

Bei ClientAccess stoßen wir da schon auf nicht unerhebliche Schwierigkeiten mit Windows7, Windows2008 Server oder gar 64-Bit.

Aber das ist sicherlich ein anderes Thema.

[BenderD]

... aber ein heißes Thema!
- die Kunden, die heute ihre EDV in einem EDV Museum betreiben sind die nächsten Kandidaten für einen Wechsel zu anderen Plattformen; das ist genau das, wo die Erosion der Kundenbasis herkommt, ob die dann mit dem Zwischenschritt SAP auf AS/400, oder gleich komplett vollzogen wird, ist im Resultat identisch.
- neue Hardware mit neuem Release bringt ganz sicher für die SQL Perfomance was, alleine die vervielfachte CPU Power plus Hauptspeicher bringt die Kuh zum fliegen.
- Releasewechsel auf dem selben Blech, dass das dann schneller wird, das wäre eine ganz neue Erfahrung für mich - neues Release kann mehr und von nix kommt nix... naja, Ausnahmen mögen die Regel bestätigen, es soll da schon bei allen Betriebssystemen so lausige Releases gegeben haben, dass man das Nachfolgerelease dann ordentlich gemacht hat und das dann schneller als die Gurke vorher war.

D*B

D*B

Und was den empfohlenen Upgrade angeht so ist dieser von einigen Kunden schlicht unbezahlbar, insbesonders was die Lizensierung so angeht.
Ausserdem gibts da so manche Alt-Software die nicht V6-fähig ist, das Softwarehaus nicht mehr existiert oder der Upgrade auch dieser Software oft schlicht zu teuer ist.
Auch was das Finden von Nachfolgeprodukten angeht gestaltet sich das auch mitunter als schwierig bis unmöglich, weil es da für AS/400 einfach nichts gibt.

Solange die Hardware mitspielt und von Brokern noch entsprechende Hardware zu bekommen ist wird eben noch mit V4R3 (noch keine User-Lizenzen) bis V5R4 gearbeitet werden.

Bei ClientAccess stoßen wir da schon auf nicht unerhebliche Schwierigkeiten mit Windows7, Windows2008 Server oder gar 64-Bit.

Aber das ist sicherlich ein anderes Thema.

[Pikachu]

Ab V6 ist da einiges passiert, und ich muss gestehen, der Optimizer in V7 holt teilweise interessante Ergebnisse raus.

Na hoffentlich die selben wie die anderen vor V7 auch.