Optimizer Verständnisproblem

[harkne]

Hallo zusammen,

ich nochmal.

Wir haben zwei Systeme gleiches Release V7R2M0 aber der PTF-Stand des einen Systems ist etwas neuer TL20114 im Gegensatz zum anderen System TL19297

Nur erst mal als Voraussetzung, ob das was mit meinem Problem zu tun hat weiß ich nicht.

Bei beiden Systemen sind die gleichen Programme und die gleichen Dateien die ich verwende installiert. Auf beiden Systemen haben beide Dateien ca 19 Mio Datensätze.

Das SQL was je nach Auswahl zusammengebaut wird sieht wie folgt aus

SELECT ...ne Menge Einzelfelder ... FROM CHTRNP AS CH LEFT OUTER JOIN CHTTRNP ON CHID = CHTCHID AND CHWHCU = CHTDWHS WHERE CHPAID = 0 ORDER BY CHCRDT DESC, CHCRTI DESC

Im Programm selbst mache ich folgendes:

c/exec sql                                                  
c+ prepare s_caseoverview from :w@SqlString                 
c/end-exec                                                  
c/exec sql                                                  
c+ declare c_caseoverview scroll cursor for s_caseoverview  
c/end-exec                                                  
c/exec sql                                                  
c+ open c_caseoverview                                      
c/end-exec                             

Schleife bis 15 Sätze eingelesen sind                    
3214.00 c/exec sql                                                   
3215.00 c+ fetch next from c_caseoverview into :ChNumB,              
3216.00 c+                                     :ChId :w@NullChId,    
und wieder viele weitere Felder 

Auf dem System 1 geht die Anzeige sehr schnell und das Jobprotokoll unter STRDBG sagt mir wegen des verwendeten Zugriffspfades

SPEFIL/CHTRNL24 5, SPEFIL/CHTRNL14 5, SPEFIL/CHTRNL13 5,
SPEFIL/CHTRNL21 5, SPEFIL/CHTRNL20 5, SPEFIL/CHTRNL11 17, SPEFIL/CHTRNL12 0.

Also er verwendet den Zugriffspfad CHTRNL12
Der sieht wie folgt aus

1 CHPAID     PARENT CASE ID                             A S    10  10   
2 CHCRDT    CREATION DATE ISO                        A L    10       
3 CHCRTI     CREATION TIME                              A S     6   6 

Das andere Systeme braucht ca 2 Minuten bis er was anzeigt und hat folgendes im Joblog stehen

SPEFIL/CHTRNL24 5, SPEFIL/CHTRNL14 5, SPEFIL/CHTRNL13 5,
SPEFIL/CHTRNL05 5, SPEFIL/CHTRNL21 5, SPEFIL/CHTRNL58 5, SPEFIL/CHTRNL11
17, SPEFIL/CHTRNL12 4.

Hier hat er dann seltsamerweise bei CHTRNL12 die 4 stehen was bedeudet
4 - The cost to use this access path, as determined by the optimizer, was
higher than the cost associated with the chosen access method.

Das 2. System ist das Produktivsystem. Soll heißen mehr frequentiert aber das sollte den Optimizer doch nicht stören.

Kann mir das jemand erklären?

Vielen Dank

[Fuerchau]

Nein, erklären kann ich nicht, warum die Systeme unterschiedlich entscheiden (PTF, Plattenverteilung, Zufall, ...).
Allerdings würde ich dir einen DESC-Index empfehlen, also identisch zum Order By.
Leider kann man bei deinem SQL nicht sehen, welche Felder aus welcher Tabelle kommen.
Besser ist es halt, wenn where und order-Felder aus derselben Tabelle kommen.

[harkne]

WHERE und ORDER BY Felder sind aus CHTRNP. CH-Felder von CHTRNP CHT-Felder aus CHTTRNP. Leider ähnliche Namen.

DESC habe ich als zusätzliche Logische Datei (CHTRNL25) auf dem langsamen System probiert, die hatte er dann gar nicht in seiner Auswahl dabei.

[Andreas_Prouza]

Der Optimizer entscheidet auch basierend von Statistiken der einzelnen Objekte (PFs und LFs).
Diese werden grundsätzlich vom System gepflegt.
Es ist auch möglich diese Manuell zu konfigurieren, mach ich aber nur, wenn es z.B. eine Tabelle gibt, mit vielen Mio Sätzen, die sich sehr oft ändern (Insert, Delete, Update) und der Statistik Manager nicht hinterher kommt.
Ein Anzeichen dafür ist, wenn der Job QDBFSTCCOL sehr viel zu tun hat.

[Fuerchau]

Man kann auch mal den Indexanalyser (z.B. via ACS) bemühen.

[BenderD]

... unterschiedlicher PTF Stand ist hierbei immer ein Kandidat.
Wichtige Einflussfaktoren sind auch die geschätzte Selektivität der Abfrage, die auch von der Balance der zugrunde liegenden Indexe und der Reihenfolge der Anlage der Indexe sowie von der Frequenz bestimmter Abfragen und der Variabilität des dynamischen Cursors abhängen könnte.
Generell ist das Laufzeitverhalten von static SQL kalkulierbarer.
Anzumerken ist noch, dass die Verwendung eines Kurzalias für Tabellen und das qualifizieren der Feldnamen die Lesbarkeit der Statements verbessert.

D*B