empfolene Indices

[andreaspr@aon.at]

Man(n) müsste sich den Zugriffsplan anschauen den die DB derzeit verwendet.
Du kannst dir im Navigator mit Rechts-Klick auf "Datenbanken" den Job anschauen der die Abfrage durchführt --> dann Details --> und auf Visual Explain.

Dann könntest du vielleicht erkennen warum er diese Reihenfolge vorschlägt.

Alles was > ein paar Sekunden und überhaupt bei über 1 Stunde braucht, liegt das Problem entweder an der Abfrage selbst.
Oder an gewissen Datenbankeinstellungen (SRTSEQ=*HEX?, QAQQINI, Logische File im FROM statt Phyische usw.)

Und was MQTs betrifft ist es so wie Obv gesagt hat.
Nur dass es derzeit auf der IBM i noch nicht möglich ist ein automatisches Refresh zu machen. Das gibt es nur bei DB2 LUW.
MQTs sind optimal, wenn die benötigten Daten auch ein paar Stunden oder Minuten alt sein dürfen.
Du kannst sie sowohl über eine als auch mehrere Tabellen anlegen.
Damit verlagerst du die Zeit für das Sammeln der Daten auf einen eigenen JOB der je nach Interval die Vorselektion startet.

[Obv]

Nur dass es derzeit auf der IBM i noch nicht möglich ist ein automatisches Refresh zu machen.

REFRESH IMMEDIATE funktioniert nicht?

[Robi]

Ok,
die Leitung zum Kunden war eben weg, das Statement ist abgebrochen.

also hab ich es in eine Source kopiert,
create table davor, with data dahinter und einen runsqlstm submittet.
nach 4 Minuten hatte ich eine richtig gefüllte datei!!!

also strsql
select ... group ...

Nix geht, aber auch gar nix .
Ich verstehe das nicht.

Die analyse mit v.expl. werd ich versuchen (einmal hab ich das ja schon für ein anderes prob. gemacht ... )

@Dieter
die geforderten indices kann (darf) ich nicht 'mal eben' anlegen.
Der Grund warum er die existierenden Pfade nicht nimmt ist lt Joblog: dauer zu lange
Order by werd ich versuchen, dachte das macht sql automatisch intern bei group by. die key1, 2, 3 Felder sind übrigens nicht die group Felder)
@glaskugel
ja das kenn ich, meine ist auch dauern defekt.

danke und Gruß
Robi

[andreaspr@aon.at]

Wenn es im Batch schneller läuft, schau dir die Einstellungen im STRSQL an.
Sortierfolge . . . . . . . . . *HEX
Datenkopie zulässig . . . . . *YES

[Robi]

Wenn es im Batch schneller läuft, schau dir die Einstellungen im STRSQL an.
Sortierfolge . . . . . . . . . *HEX
Datenkopie zulässig . . . . . *YES

Steht beides so, das ist es also nicht.
Robi

[Obv]

versuch es doch so

CREATE TABLE MQT2          
AS (
select statement
) DATA INITIALLY IMMEDIATE  REFRESH DEFERRED  
ENABLE QUERY OPTIMIZATION MAINTAINED BY USER

...
 
 
 refresh table MQT2

...

SELECT Sp1, ... FROM  MQT2 WHERE ... GROUP BY Sp1 ...

[andreaspr@aon.at]

CREATE TABLE MQT2          AS (
select statement
) DATA INITIALLY IMMEDIATE  REFRESH DEFERRED  ENABLE QUERY OPTIMIZATION MAINTAINED BY USER

Das DATA INITIALLY IMMEDIATE führt quasi gleich nach dem CREATE TABLE auch gleich das REFRESH TABLE aus.

[Obv]

ich war jetzt komplett bei deferred
das refresh table nachher ist also hinfällig.

[andreaspr@aon.at]

Steht beides so, das ist es also nicht.

Du musst die beiden Umgebungen komplett miteinander vergleichen. Irgendeinen Unterschied gibt es sicher.

lg Andreas

[Robi]

Hi,
wie vergleiche ich das den?
Interaktiv ist klar, F13 und 1,
Aber batch?

Robi

[andreaspr@aon.at]

DB Monitor und dann Visual Explain (bei beiden Varianten).
Dort siehst du auch noch mehr als im Debug oder beim STRSQL F13.
Oder

Du kannst dir im Navigator mit Rechts-Klick auf "Datenbanken" den Job anschauen der die Abfrage durchführt --> dann Details --> und auf Visual Explain.

[Robi]

und was ich dann sehe, ist das, was bei

sbmjob cmd(runsqlstm ...) verwendet wird ?

ok, ich versuchs

Robi