-
Die QAQQINI-Änderung könnte bewirkt haben, dass der Access Plan, der zuvor (aus welchem Grund auch immer nicht aktualisiert oder neu erstellt wurde), bei der nächsten Ausführung neu erstellt wurde.
Mich würde ja wirklich interessieren mit welcher Query Engine die Abfragen ausgeführt werden.
Führe doch die Abfrage mit und ohne der QAQQINI-Änderung und prüfe über Visual Explain welche Engine die Abfrage ausgeführt hat.
Was Du beschrieben hast, trifft eigentlich viel mehr auf die CQE als auf die SQE zu. Bei SQE bin ich bislang selten in Situtationen gelaufen, in denen ein Index vorgeschlagen und anschließend nicht genommen wurde.
Code:
Anschließend wird ein Zugriffspfad mit genau den existierenden Schlüsselfeldern erstellt !
Andererseits wird behauptet, dass ein Zugriffspfad einer weiteren Datei mit Ursache 0 verwendet wird und prompt wird trotzdem ein neuer Zugriffspfad mit identischen Schlüsselfeldern erstellt.
Wenn außerdem ein (temporärer) Zugriffspfad erstellt und auch verwendet wurde, müssten alle folgenden Ausführungen (auch von anderen Jobs aus) wesentlich schneller sein, wenn mit der SQE gearbeitet wird. Temporäre Indices werden erst seit V5R4 von der SQE erstellt bzw. verwendet. Solche MTIs (Maintained Temporary Indexes) sind quasi permanent, d.h. die bleiben existent bis der letzte Access Plan, der diesen Zugriffspfad verwendet aus dem Plan Cache (spätestenfalls bei IPL) verschwindet und können wie ein permanenter Index von allen Jobs aus verwendet werden. Wurde mit der SQE ein temporärer Index erstellt, müsste dieser auch in der Joblog-Detail-Anzeige sichtbar sein als MTI-irgendwas.
Die Diagnosenachrichten im Joblog sind die gleichen wie vorher (Index/LF wegen Kosten nicht genutzt), empfohlene Zugriffswege, die dann auch nicht genutzt werden (habe ich probiert, Index erstellt, nun folgte die Nachricht, dass der Index auf Grund der Sortierfolge nicht genutzt wird, also Index wieder gelöscht).
Die Antwortzeiten sind nun wieder wie bei V5R3.
Dann prüfe doch mal die Sortierreihenfolge in Deinem Job, bzw. des Jobs, in dem Du den Index erstellt hast. Vielleicht wurde diese irgenwann versehentlich oder für Testzwecke geändert. Zugriffswege können nur dann verwendet werden, wenn sie die gleiche Sortierreihenfolge, wie der Job, in dem die Abfrage ausgeführt wird haben.
Wenn Du eine andere Sortierreihenfolge als HEX verwendest (also LangIdShr oder LangIdUnq), wird die Abfrage sowieso von der CQE ausgeführt, zumindest noch unter V5R4.
Vielleicht war CCSID nicht die Ursache, wohl aber die Sortierreihenfolge.
Mehr kann man, wie Dieter schon gesagt hat nicht sagen, ohne das SQL-Statement zu sehen und ohne die vorhandenen Zugriffswege zukennen.
Birgitta
Similar Threads
-
By schatte in forum IBM i Hauptforum
Antworten: 8
Letzter Beitrag: 20-10-08, 19:25
-
By christian_lettner in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 16-11-06, 10:15
-
By FNeurieser in forum NEWSboard Programmierung
Antworten: 3
Letzter Beitrag: 11-10-06, 14:53
-
By Kaufmann in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 28-06-06, 14:11
-
By loeweadolf in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 01-06-06, 09:43
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks