AS400 zu langsam?

[infomio]

Ich greife über Client Access auf eine As400 zu mittels der BDE von Delphi.
Problem: die Zugriffe auf die Daten dauern viel zu lange. Manch Kunde muß eine halbe Minute auf ein Ergebnis warten.

Desweiteren : wie kann man Transaktionen auf der AS400 kapseln ???

Helft mir bitte, ich bin am verzweifeln !!!!!

[torsten]

Ich vermute, der Zugriff läuft über den CA ODBC Treiber.

Die Verwendung von Transaktionen setzt zunächst voraus, daß der gewünschte Committlevel gesetzt wird (erfolgt als Einstellung im Treiber).

Die Antwortzeiten sind von vielen Faktoren abhängig - ich würde damit beginnen, die
abesetzten SQL Statements zu untersuchen - oft sind fehlende oder hinsichtlich ihrer Schlüsselstruktur nicht zu den SQL-Statements passende SQL-Indizes über 'große' Tabellen ein bremsender Faktor.

Setze am besten den entsprechenden QZDASOINIT Job in Debugmode und achte auf die Diagnosenachrichten des Optimizers.

Natürlich spielt auch die Gesamtauslastung des AS400 Systems eine Rolle, wie gesagt Performance-Tuning ist im Grunde ein Thema ohne Ende ...

Gruß

Torsten

[infomio]

Danke Torsten,

das mit den indizierten Tabellen hab ich nicht verstanden! Ich arbeite mit nicht indizierten Tabellen, zugleich gibt es diese aber indiziert. Grund: die vor Urzeiten angelegten Indextabellen brauche ich nicht, da ich viel mit gejointen Tabellen arbeiten muß.

Wo kann ich den Commit-Level denn einstellen??? ich hab nix gefunden. Und wenn, welchen muß man da nehmen?

[torsten]

...
der Commitmode hängt ganz von deiner Client Anforderung ab, ich denke aber *CHG
(read uncommitted) ist generell keine schlechte Wahl.

Bei meiner jetztigen Treiberversion gelangt man auf der Registerzunge Server über den Button
Advanced (amerik. Version) in die Wahl des Levels. *NONE (Commit immediate) ist default und erlaubt keine vernünftige Transaktionskontrolle, also entsprechend ändern.

Wird ein SQL Statement an das DBMS geschickt, prüft der Optimizer unter anderem,
ob ein Zugriffspfad für die Abfrage genutzt werden kann (das kann ein SQL Index oder eine logische Datei sein). Existiert kein
passender Pfad, wird entweder ein temporärer Index angelegt oder ein 'full table scan' durchgeführt - beides braucht seine Zeit.
In den Diagnosenachrichten von QZDASOINIT wird dargestellt, welche Indizes geprüft und benutzt oder verworfen werden - und - welcher
permanente Index die Abfrage beschleunigen würde. (Stark vereinfachte Darstellung).

In jedem Fall lohnt es sich, diesen Weg auszuprobieren.

Gruß

Torsten

[infomio]

Nochmals Danke!
Ich hasse so langsam die As400...Was ist denn bitte ein QZDASOINIT-Job? Ich greife über Delphi5 Enerprise(Pascal) zu und bin in Sachen AS400, wie man sicherlich schon gemerkt hat, nicht sehr confirm.

Würde es Sinn ( schneller ) machen, die alten Indextabellen zu löschen, damit die Kiste nicht zu viel suchen muß?

Und wer weiß was Vorrang in Sachen Einstellungen hat? :::

Einst. über den ODBC
Einst. über die BDE ?????

Es ist zum K........ !!!!

Gruß mio

[Fuerchau]

Im ODBC kann man keinen Commitlevel einstellen, wenn die Dateien auf Ihrer AS/400 nicht journalisiert werden !
Über DSPFD kann man dies überprüfen.
Ein eingestellter Commitlevel wird dann ignoriert.
Vergessen Sie QZDASOINIT !

Prüfen Sie Ihre SQL-Statements auf WHERE und ORDER BY-Klauseln.
Mittels DSPDBR auf der AS/400 ermitteln Sie alle Indizes einer PF-Datei.
Mittels DSPFD der LF-Dateien können Sie die Schlüsselreihenfolge ermitteln.
Löschen Sie alle LF-Dateien, deren Schlüsselfolge nicht benötigt wird.
Legen Sie mittels CREATE INDEX genau die Schlüssel an, die Sie in Ihren WHERE oder ORDER-Klauseln benötigen !

Bei Joins achten Sie auf die Verknüpfung JOIN ON (t1.x1=t2.x1 usw) UND auf die WHERE-Klausel.
Nach Möglichkeit sollte auch hierfür ein Index erstellt werden.

Sie können den Join auch mit CREATE VIEW direkt auf der AS/400 erstellen. Es wird dann eine entsprechende LF-Datei angelegt.

Der SQL-Optimizer prüft alle WHERE, ORDER, JOIN, GROUP-Klauseln, ob ein Index besteht, verwendet werden kann oder ein temporärer Index angelegt werden muss, der leider anschließend sofort wieder entfernt wird.

Ich hoffe ich konnte etwas helfen.

[infomio]

Herzlichen Dank Herr Fuerchau!
Noch eins: wenn man sich zum erstenmal eingeloggt hat, und sich Daten von der AS400 holt, dann dauert diese Aktion merklich länger(bis über 30 Sekunden), als wenn man danach erneut Daten holt. Ich habe schon den Cache auf 8 MB gesetzt und eine kleine Verbesserung in der Performance bemerkt. Aber kann es sein, daß die AS400 'schläft', so wie ein Sleep-Modus bei PC's ?
Holt man sich dann längere Zeit keine Daten, bleibt aber eingeloggt, dauerts wieder so lang!

Sollte ich hiefür eine Lösung erfahren, gibts ein Snickers!!!

mfg mio

[Fuerchau]

Die AS/400 schläft NIE !!!

Wenn Sie eine AS/400-Verbindung aufbauen erscheint normalerweise im SysTray (das Fenster unten rechts) der Verbindungsmanager. Wenn nun ein zeitlang keine Aktivitäten stattfinden, erfolgt eine automatische Abmeldung (das Icon verschwindet wieder). Mit der nächsten Aktion wird wieder automatisch angemeldet, da ja Benutzer und Kennwort bereits bekannt sind.
Dies erfordert einen Neustart der Serverjobs auf der AS/400. Je nach Leistung Ihres Systems kann das schon mal dauern.

Eine Lösung, die ich verwende: Über einen Zeitgeber (z.B. 30 Sekunden) wird ein einzelner Zugriff auf eine Tabelle durchgeführt. Dies zwingt ClientAccess die Verbindung aufrecht zu erhalten.

Noch ein Tipp für die Performance !

Verwenden Sie nach Möglichkeit für wiederholte identische SQL-Zugriffe ParameterMarker (z.B. SELECT F1, F2, F3, ... FROM T1 WHERE F1=? AND F2=? ...) in dem Sie ein QUERYDEF-Objekt erstellen.
Dieses SQL wird von der AS/400 vorcompiliert (prepared) und nach der 1. Ausführung bleibt die Tabelle geöffnet bis die Verbindung geschlossen wird.
Nun brauchen Sie nur noch die Parameter zu füllen und das RECORDSET zu öffnen.

Verwenden Sie NICHT die DAO/ADO-Methoden RECORDSET.FIND / .FINDNEXT usw. !!!!
Dies führt dazu, dass die Daten auf Ihren PC übertragen werden, von der SQL-Runtime untersucht und ggf. wieder verworfen werden. Setzen Sie hierzu lieber einen neuen dazu passenden SQL ab und benutzen Sie MOVENEXT (FETCH).

Kleiner Tipp am Rande: Wenn Sie vom PC aus eine Tabelle geöffnet haben, können Sie mittels WRKOBJLCK LIB/FILE *FILE die Serverjobs für Ihren PC ermitteln und dann mittels '5' mit Job arbeiten, die geöffneten Tabellen sehen, ggf. Nachrichten des Joblogs prüfen usw.

Und noch ein Tipp:
Wenn Sie SQL auf Ihrer AS/400 haben (STRSQL) können Sie alle SQL-Befehle natürlich vorher auf ihre Performance untersuchen:
1. STRDBG (dies startet den Debugger)
2. STRSQL (dies startet SQL im Debugmodus)
3. SQL-Befehle ausführen
4. Im Joblog die Nachrichten über Zugriffswege nicht nur lesen sondern STUDIEREN !
Wenn Sie SQL verlassen, vergessen Sie nicht den Befehl ENDDBG.

Eine weitere Analysemöglichkeit ist der Befehl CHGQRYA. Probieren Sie ihn aus.

mfg
Baldur Fürchau

[molter]

hallo, es gibt initalisierungseinstellung für ODBC-Datenbanken.

mit regedit

im ordner

\HKEY_LOCAL_MACHINE\Software\Microsoft\Jrt\4.0\Eng ines\ODBC

git es einen Eintrag ConnectionTimeout welcher warscheinlich auf 600(sec) eingestellt ist. Diesen Wert erhöhen und der Timeout verändert sich beim nächsten aufruf der entsprechenden Verbindung auf diesen Wert.