Performanceprobleme mit Access <--> DB2 per ODBC

[Rico]

Hallo,

ich habe Tabellen auf einer 520 erstellt und diese via ODBC in Microsoft Access verknüpft.

Wenn ich jetzt in Access auf die Tabellen zugreife habe ich große Performanceprobleme. Wenn ich z.B. die Tabelle einfach öffne und darin manuell Datensätze ändere kommt die Anzeige gar nicht hinterher (die Tabelle hat gerade mal 45 Spalten und 900 Datensätze).

Wenn ich in VBA per DAO.recordset darauf zugreife kann ich erstmal Kaffee kochen gehen. Dann läuft mein Programm ca. 3-5 Minuten, was sonst bei reinen Access-Tabellen ca 15-25 Sekunden dauert. Ausserdem habe ich dabei dann auf der i5 für diesen Job eine Systembelastung von rund 50-60 %!

Ist das richtig so? An welchen Einstellungen im ODBC-Treiber oder sonstwo kann ich drehen, um dieses Problem abzustellen?

Passthrough-Abfragen laufen allerdings wieder sehr schnell. Nur kann ich in meinem VBA nicht alles per Abfrage bearbeiten.

Ich arbeite mit Microsoft Access 2000 (SP3) und iSeries Access V5R3 und dementsprechend auch mit einem ODBC-Treiber 10.00.03.00.

Ich wäre wirklich für jeden Tip dankbar.

Gruß
Rico

[Fuerchau]

Prüfe vor allen Dingen, ob die Tabellen auf der AS/400 einen UNIQUE-Zugriffspfad haben. Sonst wird bei jedem Update ein Tablescan durchgeführt, was zu diesen Problemen führen kann.

[Rico]

Hallo Fuerchau,

also die Tabellen haben alle eine ID-Spalte mit auto-Inkrement, die zumindest einen eindeutigen Schlüssel besitzt.

Teilweise habe ich noch weitere schlüssel in den einzelnen tabellen angelegt.

Nur ich verstehe nicht, dass z.B. selbst beim manuellen Ändern der Daten, die Anzeige nicht hinteher kommt.

[Fuerchau]

Aktiviere in der ODBC-Verbindung mal den Debug-Modus.
Auf der AS dann mittels "wrkobjlck myuser *usrprf" den QZDA-Job auffinden und die Nachrichten im Joblog anzeigen.

Für V5R3 gilt ggf. die SQL-Pakete (insbesonders das QZDA) in der QGPL zu löschen und neu erstellen zu lassen.

[Rico]

Hallo Fuerchau,

ich habe jetzt mal den DEBUG-Modus im ODBC-Treiber aktiviert und habe dazu dann auch ein Joblog erzeugt. Leider kann ich aus diesem JobLog nichts großes herauslesen, außer dass bei dem manuellen Update in der Tabelle folgender SQL ausgeführt wird, obwohl ich nur manuell das Feld Status von "0" auf "5" gesetzt habe:

Nachricht . . . : STATEMENT TEXT FOUND : UPDATE "LOSBEST"."LBIMPORT01_03"
SET "STATUS"=? WHERE "ID" = ? AND "STATUS" = ? AND "COUNT" = ? AND "KDID"
? AND "CCLANG" = ? AND "CCKURZ" = ? AND "XLSDAT" = ? AND "DATUM" = ? AND
"ZEIT" = ? AND "KZSPIE" = ? AND "LEZAHL" = ? AND "KZMANU" = ? AND "KZERR"
? AND "ERRTXT" = ? AND "LE" = ? AND "WKN" = ? AND "LKN" = ? AND "AKN" = ?
AND "TTL" IS NULL AND "VNM" = ? AND "NNM" = ? AND "AD1" IS NULL AND "AD2"
NULL AND "STR" = ? AND "PLZ" = ? AND "ORT" = ? AND "GEB" = ? AND "LVW" IS
NULL

Hier ist laut Statement für alle anderen Felder irgend etwas mit abgefragt worden in der WHERE Klausel.

Ist das so richtig?

Ich kann dir sonst auch gern das Joblog mal zur Verfügung stellen.

Schönen Gruß
Rico

[Fuerchau]

Das ist wohl genau das Problem !
Bei der Verknüpfung der Tabelle konnte Access keinen eindeutigen Schlüssel feststellen.
Daher betrachtet Access den gesamten Satz auch als Schlüssel !!!
Bei der Verknüpfung wurdest du wahrscheinlich nach dem Feld für einen eindeutigen Schlüssel gefragt und hast ggf. sämtliche Felder dafür ausgewählt.
Wenn aber das Feld "ID" eindeutig ist, lege eine UNIQUE-LF über die ID an und verknüpfe die Tabelle neu (vorher unbedingt löschen).

Durch dieses Verfahren zwingt Access die DB alle Datensätze nach genau dem zu ändernden Satz zu durchsuchen.
Ist ein Schlüssel vorhanden, geht das natürlich erheblich schneller.

[Rico]

Hallo,

also ich habe bei der Definition der Tabelle einen Schlüssel hinterlegt, denn Access hat beim Verknüpfen nicht nach einem Feld für einen eindeutigen Schlüssel gefragt. Es sollte also nicht der gesamte Satz als Schlüssel betrachtet werden.

Ich habe jetzt trotzdem noch ein UNIQUE-LF für die Spalte ID erzeugt, sowohl über den iSeries Navigator als auch über Greenscreen. Hat leider bisher auch keinen Erfolg gebracht.

Uns ist allerdings aufgefallen, dass scheinbar immer 10 DS in den Cursor geladen werden, denn dann geht das ändern relativ schnell und danach wird das ganze wieder langsamer, bis er scheinbar die nächsten 10 in den Cursor geladen hat.

Sagt dir das irgend etwas?

Schönen Gruß
Rico

[Fuerchau]

Wenn du einen Schöüssel angelegt hast, musst du auf jeden Fall die Verknpfung erneuern.
Ob die Schlüssel erkannt werden kannst du über die Eigenschaften der Tabelle (Entwurfsmodus=>Schlüssel) prüfen.
Nur wenn Access einen eindeutigen Schlüssel findet, kann er den obigen Update so verkürzen, dass in der Where-Bedingung nur noch "ID=? " auftauchen dürfte.

Dass ca. 10 DS geladen werden, liegt an der Default-Blockgröße (ODBC-Konfig, 32KB).

Prüfe doch mal das Joblog sowie die Access-Eigenschaften bei einer Tabelle, die schnell zu bearbeiten ist.

[Rico]

Hallo,

wenn ich das LF-File in Access verknüpfe, dann habe ich nur noch eine Laufzeit von 2 Minuten statt 3-5 Minuten mit der Original-Tabelle, obwohl auch bei der der eindeutige Schlüssel in der Entwurfsansicht zu sehen ist.

Wenn ich allerdings eine MySQL-Datenbank hinterlege, dauert das Programm nur ca. 20 Sekunden. Ich will aber unbedingt die i5 als Datenbank nutzen, schließlich war sie teuer genug!

Schönen Gruß
Rico

[Fuerchau]

Prüfe nochmal über das Joblog (Debugmodus) wie lange die einzelnen Operationen tatsächlich dauern: Mit F1 auf dem Eintrag des Joblogs siehst du die Uhrzeit.
Ist dann tatsächlich die SQL-Zeit das Problem oder stimmt irgendwas mit der Übertragung (TCP/IP) nicht.

Im ODBC sollte im Register Pakete Extended Dynamic Support an sein sowie im Register Leistung der Vorablesezugriff. Die Komprimierung kann manchmal Probleme bereiten.
Im Register Katalog sollte Suchmuster aus sein (dies betrifft nur Lib's, Tabellen und Felder die ggf. ein "_" enthalten, da das als generisches Zeichen betrachtet wird).
Im Register Server sollte bei Erweitert Sofortiges Commit eingestellt sein, es sei denn du hast ein Journal angelegt.

Änderungen an der ODBC-Konfig haben keine Auswirkung auf verknüpfte Tabellen, wenn du diese nicht neu erstellst. Eine Aktualisierung der Verknüpfung reicht nicht, du MUSST diese löschen und neu eintragen, da die Verbindungszeichenfolge immer komplett in die Eigenschaften übernommen wird.

Im Joblog gibt es noch weitere Leistungshinweise und Empfehlungen die zu betrachten sind.