Wechsel auf 7.1 - .net SQL-Abfragen jetzt langsam

[Oli001]

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]

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]

... erst mal Group PTFs Database einspielen, bei neuen Releases ist die DB ohne hireichenden PTF Stand zumeist ziemlich Buggy

D*B

[Oli001]

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]

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]

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]

@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]

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]

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]

.. was verwendet ihr denn hier für ein isolation (commit) level?

[Oli001]

Hallo,
erstmal vielen Dank für eure Hilfe!
Ich habe nun eine Lösung gefunden. Ich verwende nicht mehr den OleDb-Treiber sondern den IBM.Data.DB2.iSeries. Damit geht es gefühlt nochmal schneller als vorher...

Nun hab ich allerdings eine kleine Problemchen: Wenn ich mit dr.GetString(0) ein Feld aus der DB hole, dann ist das Ergebnis mit Blanks gefüllt (Soviele Blanks bis die Feldgröße erreicht ist). z.B. 'oli001 ' bei einem char(10). Kann man das irgendwie umgehen? Der OleDb hat hier nur 'oli001' geliefert.

Grüße Oli

[andreaspr@aon.at]

Du könntest mit Trim() die Blanks abschneiden. Entweder im SQL oder du machst das in einer View.