View Full Version : fetch first (vor Where)???
Hallo Tobi,
anbei das SQL:
SELECT TPANR1, TPNBHF, TPBENR, TPIDEN, TPKMEN, TPVORT, TPVREG, TPVHOR, TPVVER, TPBMEN
FROM brkdatv6.phisttp
fetch first 500 rows only
WHERE tpkonz='LCV' And TPVART='PAZ' And TPNBHF='PACKSTUBE'
ORDER BY TPANR1 DESC , TPBENR, TPZUNR, TPTIA, TPPALN, TPANRP
Gruß
svt
Hallo.
Existiert ein passender Zugriffspfad?
Gruß Joe
andreaspr@aon.at
26-09-11, 11:27
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?
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
26-09-11, 12:27
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 ;)
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.
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
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
@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.
Probier mal
Select...
Into...
blah blah blah
**Edit: heck! I didn't see there was a second page of this thread.
"Select ... Into" geht nur bei embedded SQL und da dann auch nur bei genau 1 Satz.
ODBC ist aber CLI-Basiert, da muss man mit Cursor und Resultsets arbeiten.