fetch first (vor Where)???

[T.Dahl]

Könntest du bitte einmal deine SQL abfrage posten.
Sonst können wird leider nichts mit der Fehlermeldung anfangen.

LG
Tobi

[B.Hauser]

Fetch 500 Rows only wird wahrscheinlich auch nicht helfen, sofern ein Zugriffspfad, der anders als die Order By-Anweisung geschlüsselt ist verwendet wird.

Das oberste Ziel des Optimizers ist so schnell wie möglich an die gewünschten Daten zu kommen und da werden die Where-Bedingungen vorrangig geprüft und erst anschließend die Order By-Anweisungen. Die Daten werden also sehr oft in temporären Objekten gespeichert und erst anschließend sortiert.

Wird also zusätzlich ein Fetch For 500 Rows angegeben, läuft zunächst die komplette Abfrage durch und aus dem kompletten Ergebnis werden dann die ersten 500 Sätze ausgegeben.

Die kannst die Abfrage nur dadurch beschleunigen, dass Du die Abfrage analysierst (z.B. mit STRDBG oder Visual Explain) und die optimalen Zugriffswege anlegst.

Birgitta

[svt]

Hallo Birgitta,

kannst du mir beim Umbauen des SQl helfen, da relativ Neuland für mich!!!

Danke svt

[andreaspr@aon.at]

Hi svt,

nur als Info:
Zugriffspfad = Index

Du musst also Prüfen ob es für diese Tabelle einen Entsprechenden Index gibt der als Key-Felder deine WHERE-Bedingung abbildet.

Interessant wäre auch (wie Sam schon schrieb) um wieviele Sätze es sich hier handelt?

UND wieviele Sätze du als Ergebnis erhälst?

In welcher Umgebung rufst du das Statment auf? RPG? ODBC? STRSQL?

[svt]

Hi svt,

nur als Info:
Zugriffspfad = Index
iSeries Navigator
S658680.brkdatv6.phisttp

Du musst also Prüfen ob es für diese Tabelle einen Entsprechenden Index gibt der als Key-Felder deine WHERE-Bedingung abbildet.

Interessant wäre auch (wie Sam schon schrieb) um wieviele Sätze es sich hier handelt?
circa 1 Mil.
UND wieviele Sätze du als Ergebnis erhälst?
im Moment ca. 30000
In welcher Umgebung rufst du das Statment auf? RPG? ODBC? STRSQL?

über ODBC und eine 2 MGBit Standleitung

Ich hoffe das Du damit was anfangen kannst

[andreaspr@aon.at]

Ich hoffe das Du damit was anfangen kannst

Du müsstest mal die SQL Anweisung über den Visual Explain analysieren lassen.
1 Million Sätze sind wirklich nicht viel.
30.000 Sätze als Ergebnis hingegen schon!

Also du solltest wie folgt vorgehen:
1. Schau ob ein Index vorhanden ist. Wenn nein, solltest du einen entsprechenden erstellen.
Visual Explain oder der Index Advisor im iSeries Navigator kann dir dabei helfen.
2. Was passiert mit den Sätzen. Wenn du z.B. 30.000 Sätze in .Net in ein DataGrid ausgeben lässt, dauert das auch seine Zeit.
3. Umgebungsvariablen prüfen (Cachen der Daten usw.)
4. Hoffe du hast für eure 2 MGBit Standleitung einen Waffenschein

[Fuerchau]

Wenn du über ODBC arbeitest, solltest du nur prüfen ob für die Felder der Where-Klausel ein Index exisitiert, falls nicht, erstelle einfach per "CREATE INDEX brkdatv6.phisttpIX on brkdatv6.phisttp (tpkonz, TPVART, TPNBHF)"

Das dauert dann einen Moment, aber es hilft bei der Abfrage.

Den "Order By" kannst du weglassen, da du das Resultset (Java)/Recordset (ADODB) am besten dann selber sortierst.

Ein Problem für den Optimizer existiert immer dann, wenn die Order-By-Klausel komplett andere Felder enthält als die Where-Klausel.
Das kannst du lösen, in dem du in die Order-By-Klausel die Where-Felder an den Anfang mit aufnimmst und den Index nach inten um die restlichen Felder ergänzt.

Wenn du mit ADODB arbeitest, kannst du auch einen Server-Cursur verwenden, so dass das Recordset nicht sofort komplett abgerufen wird (bei einer 2MBIT-Leitung ggf. sinnvoll), sondern erst mit einem MoveNext.

In Java müsste es ähnliches geben.

[BenderD]

In Java müsste es ähnliches geben.

... depends on driver, aber ich kenne keinen Treiber, der versucht die fremde Datenbank rüber zu zerren.

D*B

[svt]

Hallo Zusammen,

Vielen Dank für Eure schnelle Hilfe,
es funktioniert jetzt wunderbar, ich glaube
der Index war der größte bringer, toll!!

Gruß
svt

[Fuerchau]

@Dieter
Bei ADODB (ActiveX, OLEDB/ODBC) ist es leider so, dass beim Öffnen eines Recordsets in abhängigkeit des CursorTyps (Client, Server), bei einem Client-Cursor (Default!) das komplette Recordset tatsächlich geladen wird, wobei da der Speicher schon mal knapp werden kann. Ein wenig kann man da noch mit den Page-Einstellungen arbeiten.

Bei .NET habe ich ja auch zuerst mal einen DBReader, wende ich allerdings den Reader auf eine DataTable per Fill-Methode an, werden auch hier alle Daten geladen.

Ich muss also selber entscheiden, ob ich alles lade oder nicht.

In Java habe ich ja auch erst mal nur das Resultset, was dem Reader in .NET entspricht.
Daher auch die unterschiedliche Benennung.

[svt]

Hallo Fuerchau,

ich habe noch mal eine Frage zu den erstellten Index, hat dieser irgend welche anderen (evtuell negativen)Auswirkungen auf die Tabelle.
Ich habe sonst keinen weiteren Index
auf unserer AS400 gesehen und da ich auf diesen Gebiet noch ein Anfänger bin, frage ich lieber nochmal nach!!!!

Danke

Gruß
svt

[B.Hauser]

Ein Index ist eine geschlüsselte logische Datei, die mit SQL erstellt wurde.

Ein einzelner (zusätzlicher) Index wird keine negativen Auswirkungen auf die Performance haben.

Viele zusätzliche Indices, wie auch viele geschlüsselte logische Dateien können die Performance beim Einfügen, Ändern und/oder Löschen von Datensätzen in der darunterliegenden physischen Datei oder SQL Tabelle beeinträchtigen. Bei Datenänderung werden jeweils alle Zugriffswege (Indices und geschlüsslete logische Dateien) aktualisiert.

Birgitta