Anmelden

View Full Version : Wechsel auf 7.1 - .net SQL-Abfragen jetzt langsam



Seiten : [1] 2 3

Oli001
17-11-14, 15:46
Hallo,
am Wochenende wurde hier die AS400 auf V7.1 umgestellt. Nun sind die SQL-Abfragen extrem langsam. Aber nur bei journalisierten Tabellen.

Hat dazu jemand eine Idee oder schonmal das gleiche Problem gehabt?


Danke für Eure Hilfe,

Oli

Fuerchau
17-11-14, 15:56
Das hat mit Journalisierung nichts zu tun, da Abfragen kein Journal verwenden sondern nur Insert/Update/Delete.
In einem anderen Beitrag habe ich über diese Probleme bereits berichtet.
Hier musst du die langsamen SQL's erneut analysieren (Debug-Mode, Diagnose-Nachrichten, Opsnav-Indexadvisor ...) und entsprechend anpassen.

Das Hauptproblem sind ggf. Joins/Where-Klauseln mit nicht passenden Typen die nun eine Indexverwendung ausschließen, Beispiel:

Tabelle mit "Feld char(3)"
Select * from table where Feld = 001

Der Optimizer macht daraus
vor V7: select * from table where Feld = cast(001 as char(3))
=> Index über Feld verwendet
Ab V7: select * from table where cast(Feld as dec(3, 0)) = 001
=> Kein Index und ggf. Absturz bei Datenfehler

Natürlich hat man hier einen Tippfehler gemacht und die Konstante nicht in Hochkomma gestellt.

Dies betrifft aber ggf. auch Join's oder Feldvergleiche von Feldern mit unterschiedlicher Typisierung.
Das sollte auf jeden Fall zuerst geprüft werden.

BenderD
17-11-14, 16:02
... erst mal Group PTFs Database einspielen, bei neuen Releases ist die DB ohne hireichenden PTF Stand zumeist ziemlich Buggy

D*B

Oli001
17-11-14, 16:02
Hi,
danke für die Antwort. Aber das Problem liegt ja schon hier:

select * from table

Vor dem Wechsel 8 sek. - jetzt: 2 min!

Grüße Oli

Fuerchau
17-11-14, 16:14
Das kann nicht sein, da gibt's ein V7-Update-Problem!
Folgende Sachverhalte:

Falsches SQLPKG QZDAPKG in der QGPL. Dies muss gelöscht werden, es wird automatisch erneuert (ENDHOSTSVR *DATABASE nötig).

Ggf. falsches SQL-Repository in QSYS2!
Dies hatte ich auch schon, das heißt, dass in den SYS-Views nicht alle Tabellen eingetragen sind und der SQL-Optimizer dann Indizes nicht findet.

Hierfür gibt's den RCLDBXREF (leider nur im eingeschränkten Zustand!).

BenderD
17-11-14, 16:31
Hi,
danke für die Antwort. Aber das Problem liegt ja schon hier:

select * from table

Vor dem Wechsel 8 sek. - jetzt: 2 min!

Grüße Oli

... im interaktiven SQL? Da sind doch schon 8 sec. völlig daneben!!! Oder hast Du da 200 Millionen gelöschte Sätze am Anfang der Datei?

Fuerchau
17-11-14, 16:52
@Dieter
Der Hinweis ist hier ".NET", also ODBC.
Da wird meist das Ergebnis direkt in eine interne Tabelle geladen und dann sind je nach Anzahl Zeilen 8 Sekunden durchaus schnell.
Ich bekomme da durchaus 250 - 1000 Sätze/Sekunde geladen.

Oli001
17-11-14, 19:07
Hallo, das ist ein initialer select der 120000 Sätze lädt. Vor dem Wechsel 8 sek. Jetzt fast 2 min. Mach ich den select über Java, hab ich das Phänomen nicht. Dann sind es wie vorher mit odbc nur 8 sek...
Bin Softwareentwickler und hab relativ wenig Ahnung von der AS400... Werde das morgen mal weiterleiten und hoffe, dass das dann klappt...

Oli001
18-11-14, 04:48
Guten Morgen,
ich möchte das Problem nochmal etwas konkretisieren, mein Quellcode sieht so aus:

string sql ="select * from bibl.table";
OleDbDataReader dr=new OleDbCommand(sql, AS400Connection.getConnection()).ExecuteReader();
//Diese Anweisung wird innerhalb von 1 sek ausgeführt!
int c=0;
while(dr.Read())
c++; <-- Wenn ich hier nur den Counter laufen lasse braucht er 2 min bis er durch ist für 120.000 Sätze!

Wie gesagt seltsam ist halt, dass das bei Tabellen auftritt, die ein Journal haben. Wenn ich eine Tabelle ohne Journal nehme, und durch Schleife rumpeln lasse ist das in 2 sek. erledigt. Und das bei 16.000.000 Sätzen!

Grüße Oli

BenderD
18-11-14, 05:56
.. was verwendet ihr denn hier für ein isolation (commit) level?