Lösung für Zugriffs-/Performance-Probleme per ODBC-Treiber auf Access-Datenbank

[English]Es gibt Nutzer, die mit älteren Anwendungen noch auf Access-Datenbanken per ODBC-Treiber zugreifen. Mitunter kommt es dann beim Wechsel auf neuere Hardware/Windows-Versionen zu Zugriffs- und vor allem Performance-Problemen – die Datenbankzugriffe sind langsam. Ein Blog-Leser hat mir per Mail einen solchen Fall sowie die von ihm genutzte Lösung zukommen lassen. Der Ansatz ist für andere Nutzer möglicherweise von Interesse.

Kunde mit alter Hardware/Software

Der Blog-Leser ist Software-Entwickler, der bei einem Kunden auf ein massives Problem mit Access stieß. Denn dieser Kunde setzte noch alte Software aus den 90er-Jahren ein. Dazu schrieb er folgendes:

Wir haben (hatten) bei einem Kunden nach Rechnerupdates massive Zugriffsprobleme auf bestehende Access Datenbanken. Der Kunde betreibt diese Datenbanken (Access 2000 Format *.mdb) schon seit Ewigkeiten.

Die verwendete SW stammt in ihren Grundzügen noch aus den 90ern und verwendet den 32Bit Access ODBC-Treiber. Wir haben schon mehrfach angeboten auf SQL-Server und eine neuere Datenbank-Lib umzustellen, der Kunde konnte sich aber bisher nicht entscheiden (bzw. will die allumfassende eierlegende Wollmilchsau, die dann zu teuer ist).

Ich denke, jedem Dienstleister kommt diese Beschreibung bekannt vor, etwas ähnliches hat jeder schon mal erlebt. Die alte Software kann oft nicht so einfach umgestellt werden, aber es hakt beim Wechsel auf eine neue Windows-Version.

Hardware-Wechsel lässt Situation eskalieren

Oft ist es so, dass die Kunden irgendwann auf eine neue Hardware wechseln müssen, wobei dann auch in der Regel eine neuere Windows-Version fällig wird. Und damit fangen die Probleme an. Der Leser beschreibtdie Situation beim Kunden so:

Also hat er [der Kunde] nur neue Industrie-PC bestellt und will darauf die alte SW laufen lassen. Daher wurden nur die Hardware-Treiber angepasst und die alte SW installiert.

Natürlich hat der Dienstleister das vorher getestet und der Leser schreibt: Auf verschiedenen Testmaschinen lief die Software wie zuvor auf den alten PC unter Windows 7 Professional. Datenbankzugriffe liefen im Handumdrehen unter 2 Sekunden. Aber es kam, für mich wenig überraschend, doch zu Problemen, die der Leser so beschreibt:

Auf den neuen Industrie-PC unter Windows 10 sind alle Datenbankzugriffe extrem langsam. Dabei sind die Netzverbindungen ok, normale Dateitransfers laufen mit üblicher Geschwindigkeit.

Nur SQL-Zugriffe per ODBC auf die auf dem Server liegenden Access-Dateien laufen extrem langsam. Ein Zugriff kann durchaus 5 Minuten dauern. Dabei zeigt der Rechner keine nennenswerte Netz oder CPU Aktivität. Er hängt einfach.

Der Blog-Leser hat mir noch mitgeteilt, dass die Problem-PCs die aktuelle Windows-Version verwenden, komplett gepatcht sind und kein Office im Einsatz ist.

Problem eingegrenzt

Der Leser konnte dann das Problem bei sich im Labor nachstellen und tiefer untersuchen. Sein Fazit: Es scheint einzig und allein am Rechner (seiner Meinung nach an der CPU) zu liegen. Die neuen CPUs sind i7-8700 mit 12 logischen Kernen. Er vermutet, dass da irgendwas blockiert (irgendeine Race-Condition vielleicht), weil die CPU zu schnell ist.

Ein Workaround hilft

An dieser Stelle hat der Leser einen Workaround entwickelt, den er mit der Leserschaft teilt – letztendlich geht es darum, den schnelleren Prozessor für die Datenbankzugriffe auszubremsen. Im speziellen Fall haben bei ihm folgende Maßnahmen die Lösung gebracht:

• Die Anzahl Threads im Treiber auf 1 reduziert (!)
• Im Programm die Anzahl der genutzten Prozessoren auf 1 gestellt (das geht auch per Taskmanager unter „Details", „Zugehörigkeit festlegen", aber dann nur für die aktuelle Instanz)
• Auf den 2010er Access-Treiber umgestellt (vllt. nicht unbedingt nötig, schien aber ein bisschen was zu bringen)

Danach lief das Programm wieder normal. Zum ersten Punkt, die Zahl der Threads im Treiber auf 1 zu reduzieren, hat mir der Leser noch folgenden Hinweis geschickt:

Threads im Treiber beschränken:

ODBC-Manager [aufrufen] und dann erweiterte Optionen [wählen]

[dann lässt sich die Zahl der Threads auf der Registerkarte System-DSN vorgeben (siehe Screenshot)]

Pfad zur DB am Besten in der Registry anpassen.

An dieser Stelle mein Dank an den Leser. Vielleicht hilft es mal jemand.