fetch first (vor Where)???

[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.

[kitvb1]

Probier mal
Select...
Into...
blah blah blah

**Edit: heck! I didn't see there was a second page of this thread.

[Fuerchau]

"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.

[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

[Fuerchau]

Die Anwendung merkt von dem Index fast nichts.
Ein Index kostet nur Performance beim Schreiben und Löschen.
Da kommt es dann auf die Anzahl der Operationen an. Bei 10.000 und mehr Operationen pro Sekunde (gecached) merkt man das dann tatsächlich erst bei einer großen Anzahl.

Ich habe hier Dateien mit teilweise mehr als 50 Indizes (mit und ohne Select) ohne merkliche Einbuße.

Probleme gibt es nur dann, wenn die Dateistruktur geändert werden soll, dass dauert dann schon mal ein bisschen.

[svt]

Ich danke Euch, dann bin ich ja beruhigt!!

Gruß
svt