Office: (Office 2010) Performance-Probleme mit verknüpften Tabellen in Access 2010

Hallo!

Wie sehen diese "einfachen" Abfragen aus? Sind alle mit distinct und anderen Bremsen ausgestattet? *wink.gif*

Bezüglich Zugriffszeit kann ich bei mir nicht klagen. Ich setze auch Win7 64 bit und Access 2010 ein. Allerdings joine ich nur wenige verknüpfte Tabellen, da ich komplexere SQL-Anweisungen als Sicht oder gespeicherte Prozedur am Server ablege.

Welchen ODBC-Treiber verwendest du?
Hast du den Datentransfer schon mit dem Profiler oder ODBC trace verfolgt?

mfg
Josef

 

Hallo Josef,

Der ODBC-Treiber ist die ACEODBC.DLL vom 27.07.2011 in Version 12.00.6606.1000. Sollte das nicht allerdings unerheblich sein, solange ich mit meiner lokalen Access-Datenbank ausschließlich im Access-Frontend arbeite?

Datentransfers habe ich ich bislang noch nicht verfolgt. Ich habe bislang nur mit Oracle und MySQL-Systemen gearbeitet und verwende zum ersten mal Access. Im Kern möchte ich Access verwenden, um ein Proof of concept für eine Anwendung zur Datenanalyse zu erstellen. Mein Augenmerk lag entsprechend eher auf dem Entwurf der (konzeptuell) richtigen Abfragen und weniger auf deren Optimierung bezüglich der Performance. Wenn du mir Tipps zum Monitoring von Access geben kannst, wäre ich natürlich trotzdem dankbar.

Nach eigener Recherche braucht die gleiche Abfrage wie in meinem ersten Beitrag in der Konstellation WinXP-Access sowie mit OpenOffice/Libréoffice Base (nur Sekundenbruchteile und nicht mehr als 10 Minuten. Momentan steht mir nur leider kein XP-Rechner dauerhaft zur Verfügung und Base ist für den Entwurf von Berichten m.E. nur eingeschränkt nutzbar.

 

Ich dachte du verwendest einen aktiven Server.
Access-Tabellen kannst du gar nicht per ODBC in ein Access-Frontend einbinden.

Kurz zusammengefasst (zur Kontrolle ob ich das Problem richtig verstanden habe):
Verwendet wird ein Access-Frontend und ein Access-Backend.
Die Tabellen vom Backend werden im Frontend verknüpft.
Mit diesen verknüpften Tabellen werden Abfragen gestaltet.
Sobald mehrere Tabellen in eine Abfrage verwendet werden, wird der Zugriff extrem langsam, obwohl die Abfragen Index-freundlich gestaltet sind und die Tabellen auch über entsprechende Indizes verfügen.

Anm.: die Index-Nutzung kannst du über den Jet-Showplan beobachten.
Sascha hat dafür ein Hilfsprogramm (ShowplanCapturer) erstellt.

Welchem Dateiformat haben das Backend und das Frontend (mdb oder accdb)?

mfg
Josef

 

Hallo,

entschuldigung, da habe ich mich wahrscheinlich undeutlich ausgedrückt. Der Weg bis hier war der folgende. Access mitsamt Office 2010 Prof. Plus installiert, anschließend neue lokale Datenbank im Format accdb angelegt, drei Tabellen aus csv importiert und schließlich Datentypen, Feldlängen, Primärschlüssel und Indices erstellt. Es ist also derzeit alles in einer lokalen accdb-Datei integriert.

 

Hallo!

Wenn alles in einer einzigen Datenbank ist, fallen zumindest möglich Probleme mit verknüpften Tabellen weg. Der Thread-Titel verwirrt etwas. *wink.gif*
Die accdb befindest sich auch auf einem lokalen und ungeschützen Laufwerk/Verzeichnis, oder? => Netzwerkprobleme ausgeschlossen.

Dann wundert es mich allerdings schon, dass die gleiche Abfrage unter WinXP < 1 Sekunde dauert während sie unter Win7 mehrere Minuten läuft.

mfg
Josef

 

Genau, eigentlich sollte das Problem mit dem Hotfix KB2553116 http://support.microsoft.com/kb/2553116 behoben werden. Allerdings hat die Installation bei mir zu keiner Änderung geführt.

Auch die Verwendung des Win XP Kompatibilitätsmodus oder die Modifikation der "MaxBufferSize" auf 50000 für den Registryeintrag HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE, die ich über die Suche im Web als mögliche Gegenmaßnahmen gefunden habe bleiben wirkungslos.

Es müsste doch eigentlich weitere Nutzer mit der Konstellation Win7 64 und Access 2010 geben, die ein ähnliches Problem haben.

 

Hallo,

und danach einmal Komprimieren / Reparieren ausgeführt?

 

Hallo!

Aber unter WinXP mit Access 2010 läuft alles schnell? (Also würde eigentlich die Hotfix-Beschreibung passen.)

Vielleicht liegt es aber doch ganz einfach an einer schlecht formulierten SQL-Anweisung.
"Not in" kann beispielsweise zu einem vielfachen Durchlaufen der Datensätze führen.

Zum Ausprobieren:
Was passiert, wenn du die Abfrage nicht direkt sondern als Datenquelle eines Formulars öffnest?

Kannst du eine Beispiel-DB erstellen, in der bei dir das Problem auftritt?
Vielleicht kann es dann jemand anders mit Win7 und Ac2010 nachstellen.

mfg
Josef

 

Für so einen Satz habe ich überhaupt kein Verständnis.
Wenn einer in einen Laden geht und irgendein Gerät kauft oder eine Versicherung abschließt, will er auch immer das GÜNSTIGSTE.

Beim DB-Programmieren soll das anders sein? Irgendetwas zusammenschreiben, Hauptsache das Ergebnis zeigt etwas Gewünschtes - und dann alles umbauen (auch wenn man schon in der Sackgasse steckt), weil die Performance grottig ist?

Zu einem vernünftigen Konzept sollte es gehören, während der Entwicklung ohne Not keine Bremsen einzubauen.

Indexnutzung hat mit Betriebssystem und Accessversion erst einmal wenig zu tun, sondern nur mit sich selber. Von einem Geschwindigkeitssprung um den Faktor 2.500 beim Wechsel von "NOT IN" auf "NOT EXISTS" bei vorhandener Indizierung habe ich mir auch schon an anderer Stelle berichten lassen.

 

Hallo, meine Anmerkung bezüglich der Performanceoptimierung bitte ich nicht auf die Goldwage zu legen oder zu verallgemeinern. Natürlich ist gutes Design sehr wichtig, jedoch wunderte mich doch stark, dass das exakt gleiche Statement bspw. in einer HSQLDB (Base) 3 Sekunden und in Access mehr als 10 Minuten braucht. Gerade wenn man mit sehr unscharfen Anforderungen von dritten arbeitet ist "rapid prototyping" (natürlich inkl. "Entsorgung" der Quick&Dirty Lösungen) m. E. ein gangbarer Ansatz.

Nach diversen Tests scheint mir Access tatsächlich ein Problem mit NOT IN Konstrukten zu haben, unabhängig von der Betriebssystem- und Access-Version. Ich hatte zwischenzeitlich Gelegenheit, die Kombinationen Win7/A2010, WinXP(virtualisiert unter Win7)/A2010/2003 sowie WinXP/A2010/2003 selbst zu testen. Die krassen Geschwindigkeitsunterschiede sehen für mich nach einem Designproblem in Access selbst aus.

Ich danke euch allen auf jeden Fall sehr für die Hilfe.