View Full Version : Query und die kopie der Datei
KingofKning
10-07-08, 13:34
Hallo,
ich beschäftige mich gerade mit einem kleinem Query unter V5R4 und habe eine ph. und logi. Datei über 2 Felder verknüpft. Wenn ich jetzt die Auswertung laufen lasse, sagt der mir immer das eine Kopie der logischen Datei erstellt wird, was bei schlapp 300 MB etwas dauert.
Warum macht der das besser noch wie kann ich dem das abgewöhnen?
Gruß
Gregor
In dem du für die verknüpften Felder einen Index anlegst.
Ausserdem kann noch die Satzauswahl, Sortierung oder Gruppenstufen Einfluss nehmen.
Auch hierfür sind ggf. Indizees erforderlich.
kuempi von stein
10-07-08, 15:50
..... Indizees .....
Ein böses Wort, was ich seit mindestens 10 Jahren nicht mehr gehört habe....
Los, raus aus euren Löchern und los die Diskussionen über Datenbanken und Regeln der Normalform...
k. (dem wohl gerade der Schalk im Nacken sitzt)
Naja, über die Mehrzahl von Index bin ich mir nicht im Klaren:
- Indexe
- Indizees
- oder Wie lautet die mehrzahl von "Index"? | Lycos iQ (http://iq.lycos.de/qa/show/1048262/Wie+lautet+die+mehrzahl+von+%22Index%22%3F/)
Indexe wäre eingedeutscht, igitt igitt,
fast so wie Frisör (neue Deutsche ...schreibe)
Indizes ist korrekt (soweit humanistisch gebildet),
aber nicht mit 2 E's, auch wenn es ein langes E ist.
Ich müsste nochmal im Duden nachschlagen, aber ich denke Indices ist die korrekte Schreibweise, wobei Indizes durchaus (eingedeutscht) zulässig ist.
Indexe ist m.E. falsch (zumindest hat man uns füher am Gymnasium dafür die Ohren langezogen). Aber die Zeiten und die Rechtscheibung ändern sich und wer wie ich noch nichteinmal richtig Hochdeutsch reden kann ...
Indexes ist der IBM Terminus (das zumindest lernt man wenn man Redbooks schreibt;))
Warum machen wir es uns nicht einfach und sagen Zugriffsweg oder logische Datei?
Ok bei SQL brauchen wir wieder das Wort Index!
Birgitta
Du schreibst, daß Du eine physiche und eine logische Datei im Query miteinander verknüpfst. Beide Dateien haben für die SQL-Engine anscheinend nichts miteinander zu tun, also keinen gemeinsamen Key. Und nach der Prüfung der zur Verfügung stehenden Indizes fällt der SQL-Engine nichts Besseres ein, als erstmal beide Dateien zu scannen und im Hauptspeicher das kartesiche Produkt aller zueinander passenden und nicht ausgeschlossenen Sätze zu bilden.
Wenn Du in SQL die Indizes bzw. besser die primary und foreign keys exakt definierst, gibt es eine kleine Chance, daß die SQL-Engine das ganze verstehen lernt. Oft ist es hilfreich, vor dem Query mal einen debug zu starten, und nach den dann erscheinenden Meldungen der SQL-Engine zu schauen, nachdem da Query einmal gelaufen ist.
Wenn immer nur sehr wenige Sätze von den 300 MB selektiert werden, ist es u.U. auch schneller, eine Correlation zwischen einem schnellen ersten Select (nur auf eine Datei) und einem JOIN unter Verwendung des foreign Keys zu definieren. Es ist aber nicht ganz so leicht, darauf zu kommen ...
Mit einer Stored Procedure kann man das natürlich auch in zwei Schritten erledigen, was übersichtlicher und nicht so schwer verständlich ist.
Man sollte sich auch abgewöhnen, in Query auf eine LF zu referieren (es sei denn es ist bereits eine fertige SQL-View oder ein Join.
Da Query nun mal intern auch SQL nutzt, wird die LF gar nicht verwendet.
Enthält die LF Select/Omit, werden diese Bedingungen der Satzauswahl hinzugefügt.
Die Keyfolge einer LF mit Select/Omit kann von SQL nicht verwendet werden !
Man benötigt daher ggf. eine weitere LF mit dem selben Schlüssel aber eben ohne Select/Omit, falls die Schlüssel dann noch passen.
Man sollte sich auch abgewöhnen, in Query auf eine LF zu referieren (es sei denn es ist bereits eine fertige SQL-View oder ein Join.
Da Query nun mal intern auch SQL nutzt, wird die LF gar nicht verwendet.
Sorry, aber Query/400 verwendet sowenig SQL wie OPNQRYF nämlich gar keins!
Query/400 ist und wird auch in Zukunft nicht von der SQL Query Engine (SQE) bearbeitet, sondern nur von der klassischen Query Engine (CQE), in die die Query-Verarbeitung integriert ist. Deshalb wird ja auch DB2 Web Query, das komplett SQL basierend ist als Nachfolge-Produkt forciert.
Enthält die LF Select/Omit, werden diese Bedingungen der Satzauswahl hinzugefügt.
Die Keyfolge einer LF mit Select/Omit kann von SQL nicht verwendet werden !
Man benötigt daher ggf. eine weitere LF mit dem selben Schlüssel aber eben ohne Select/Omit, falls die Schlüssel dann noch passen
Der Zugriffsweg in einer logischen Datei mit Select/Omit-Anweisung kann sehr wohl von beiden Query Engines verwendet werden. In echten SQL-Interfaces, werden SQL-Abfragen in denen DDS beschriebene logische Datein verwendet werden grundsätzlich an die CQE übergeben. Die CQE analysiert die DDS beschreibene logische Datei und schreibt die SQL-Abfrage neu basierend auf der physischen Datei mit den Informationen aus der logischen Datei (z.B. Select/Omit-Anweisungen als Where-Bedingungen). Erst dann beginnt die eigentliche Optimierung bei der alle Zugriffswege, die auf der physischen Datei liegen analysiert werden.
Durch die Option IGNORE_DERIVED_INDEX = *YES in der Abfrage-Options-Datei QAQQINI können SQL-Statements, die eigentlich von der CQE verarbeitet werden müssten (weil auf der physischen Datei logische Dateien mit Select/Omit-Anweisungen liegen), auch von der SQE verarbeitet werden können. In diesem Fall werden bei der Optimierung alle Zugriffswege in DDS beschriebenen logischen Dateien mit Select/Omit-Anweisungen ignoriert.
... In solchen Fällen werden dann u.U. zusätzliche benötigt, da die notwendigen Zugriffswege bei der Optimierung ignoriert wurden.
... Eine Abfrage in der allerdings eine DDS beschriebene logische Datei verwendet wird, wird trotz IGNORE_DERIVED_INDEX = *YES an die CQE reroutet.
Diese Regeln gelten für alle echten SQL-Interface, z.B. interaktives SQL, embedded SQL, QMQuery, ODBC, JDBC, DB2 WebQuery ...
... nicht jedoch für Query/400 und OPNQRYF!
Müssen neue Zugriffswege angelegt werden, sollte man wie folgt vorgehen sollte:
DDS beschriebene logische Datei mit Select/Omit-Anweisung löschen
SQL Index mit den entsprechenden Schlüssel-Feldern anlegen
DDS beschriebene logische Datei neu erstellen.
In diesem Fall wird der Zugriffsweg von dem SQL-Index auch von der DDS beschriebenen logischen Datei mitbenutzt. Erstellt man die DDS beschriebene logische Datei zuerst, werden 2 unabhängige Zugriffswege erstellt, die auch beide bei jedem Insert, Update oder Delete auf die Basis-Datei aktualisiert werden müssen.
Birgitta