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

Hallo zusammen,

seit der Umstellung von Access 2000 auf 2010 haben wir große Performance-Probleme: Das Arbeiten am Frontend verlangt teilweise viel Geduld. Verschiedene Tests lassen vermuten, dass das Problem bei mit Verwendung von verknüpften Tabellen zusammenhängt: Das Anfügen von Daten in eine lokale Tabelle dauerte 10 Sekunden, das Anfügen der gleichen Daten in eine verknüpfte Tabelle dauert knapp über 3 Minuten (!!) und das Anfügen der gleichen Daten in eine externe Datenbank über das SQL-Statement
„INSERT INTO ... IN ‘\\nas\edv$\std_test.accdb‘ SELECT … FROM …“
, also ohne Verknüpfung, dauerte 11 Sekunden.

Hat jemand eine Idee, woran das liegen kann??

:)

 

Hallo empfau,

nachdem ich einen neuen Rechner gekauft habe (mit vorinstalliertem Office2010) hatte ich das gleiche Problem. Nach langer erfolgloser Suche habe ich das Office-Paket neu installiert habe (mit allen Komponenten!). Jetzt läuft wieder alles super schnell wie immer! Versuchs mal!
Wenn das nichts bringt, check mal wie die Verbindungen zur externen
Tabelle stattfinden. (ODBC Treiber usw.)

LG, Sivi

 

Hallo
evtl hilft Dir auch das:
klike in meiner Fusszeile auf Meine Doc

und lies da in der PDF-datei ab Seite: 58 (5.2 Performance Verbesserung)
das ganze Kapitel 5.2

speziel:
Tabelle Optimieren
(ob das bei 2010 noch so ist ? )
bitte sage es mir wie es in 2010 ist *wink.gif*

Permanente Verknüpfung mit der Daten–MDB zur Performance Verbesserung

aber auch :
5.2.2
• Im Zusamenhang mit Performance ist auch sehr Wichtig Kurze Pfad-namen und nicht Zuviel zu Tief
verschachtelt, das gilt für das FE aber insbesonder für das BE.

 

Hi Sivi,

wir haben das Problem auf all unseren Rechner, von daher schließe ich das mal aus, obwohl eine Neuinstallation häufig schon Wunder bewirkt hat.

VG Michael

 

Hallo Rudolf,

einige Punkte Deiner professionellen Unterlage waren in meinen DB's bereits so wie es sein sollte, die meisten anderen habe ich in den letzten Tagen realisiert. Allerdings hat es nicht wirklich etwas gebracht.

Ich habe heute noch einmal intensiv getestet und dabei festegstellt, dass es diese großen Performance-Probleme gibt, wenn viele User in den Backends arbeiten. Und die Wartezeit hängt offensichtlich auch mit der Anzahl der verknüften Tabellen zusammen. Im Frontend sind etwa 150 Verknüfungen auf 11 Backends, wenn ich mal testweise nur noch 10 Verknüfungen habe, läuft das FE wesentlich schneller.

Ist diese Anzahl von Verknüfungen zu hoch für Access oder was kann da noch das Problem sein??

VG Michael

 

Hallo Michael,

Wieviele User arbeiten gleichzeitig mit Deiner Datenbank?
Warum verwendest Du 11 verschiedene Backends?

CU

 

Hallo Thomas,

theoretisch gibt es etwa 40 User, die mit der Datenbank arbeiten können, praktisch sind immer so ca. 10 User gleichzeitig am Arbeiten. 11 Backends, weil jede einzelne Datenbank 1 - 2GB groß ist und bei 2 GB ja bekanntlich Ende ist.

VG Michael

 

Hallo Michael,

die Anzahl er gleichzeitigen User wird nach meiner Erfahrung nicht das Problem sein. Die Größe der Datenbanken und die Tatsache, dass Du auf Grund der Größe die Daten in 11 Backend aufgeteilt hast, scheint hier vielmehr der Begrenzende Faktor zu sein. Was speicherst Du für Informationen? Sind es wirklich Datensätze? Oder sind es Bilder, Dateien oder Blobs?
Vielleicht lässt sich durch eine andere Aufteilung der Daten die Netzwerklast vermindern. Dazu braucht es aber mehr Informationen über den Aufbau Deiner Anwendung.

Wahrscheinlich solltest Du Dich aber mit der Auslagerung der Daten in eine Server-Datenbank wie z.B. den SQL-Server oder MySQL beschäftigen.

CU

 

Hallo Thomas,

die 11 Backends hatte ich auch schon unter Access 2000 und da gab's solche Probleme nicht, erst seit der Umstellung auf 2010 kamen diese Probleme. Ist das nicht seltsam?? Gibt es da vlt. in 2010 ein Bug??
Aber natürlich hast Du Recht, dass für die Datenmenge ein SQL-Server besser wäre. Den haben wir auch schon angeschafft und ich habe mich da auch schon ein bisserl eingearbeitet, aber bei der Datenmenge, der Komplexität des Frontends und der begrenzten Menpower (nur ich) ist das natürlich nicht mal so eben gemacht und von daher muss das Problem also noch auf Access-Basis gelöst werden.

Zum Aufbau: Die gesamte Netzwerk-Architektur (bis auf 1 Server) ist via VMWare virtualisiert. Der Großteil der User arbeitet via Citrix auf 64bit. Office 2010 ist als 32bit-Variante installiert, da Microsoft selbst ja von der 64bit-Variante abrät.

Die Datenbanken: Zwei Backends (std.accdb und std_alg.accdb, Größe 700MB) beinhalten die Daten, die während des Tages übers Frontend verändert/eingegeben werden, wobei letztere kennwortgeschützt ist. Das 3. BE (std_abs.accdb, 1,4GB) beinhaltet unsere Absatzdaten, das 4. BE (std_bas, 500MB) beinhaltet "Basisdaten" wie Kundenstamm, Teilestamm, usw., das 5. BE (std_dbr.accdb, 1,4GB, kennwortgeschützt) beinhaltet die Daten für die Deckungsbeitragsrechnung, das 6. BE (std_gsd.accdb, 1,5 GB, kennwortgeschützt) die sog. Geschäftsdaten (Auftragsdaten, Lieferquoten, diverse Plandaten, usw.) und das 7. BE (std_rgu.accdb, 1,2GB, kennwortgeschützt) die Umsatzdaten. Dann gibt es auf dem EDI-Server (nicht virtuell) noch unter Access2000 noch die Backends der EDIFACT-Abwicklung für die Nachrichtenarten ORDERS, ORDRSP, DESADV und INVOIC, die jeweils zwischen 1,1 und 1,7 GB groß sind. Das FE ist rund 200MB groß und jeder User hat natürlich sein eigenes FE. Ich hoffe, ich konnte so einen groben Überblick über den Aufbau hier geben.

Ich bin übrigens ein wenig überrascht, dass es an der Anzahl der BE liegen kann, weil ich bisher gedacht habe, je mehr desto besser! Ich kann sicherlich das ganze um 2-3 BE reduzieren, bleibt jedoch die frage, wieso es unter Access200 die Probleme nicht gegeben hat??

VG Michael

 

Hallo Michael,

als ich nach dem Aufbau der Datenbank fragte, ging ich ganz vorsichtig von einem eventuellen Fehler im Datenmodell aus. Das ist hier offensichtlich nicht der Fall *Smilie

Der Nachteil, den ich bei mehreren Backends sehe ist, dass man referentielle Inegrität nur innerhalb eines Backends durchsetzen kann.

Wenn Du tatsächlich noch die Access-Backend-Variante optimieren möchtest, bevor Du am Ende auf einen Server wechselst, solltest Du IMHO einen Messmechanismus einabuen. Nur so kannst Du am Ende mit Sicherheit sagen, ob sich etwas verbessert oder verschlechtert hat. Ansonsten bist Du immer auf das Empfinden des Benutzers angewiesen.

CU

 

Hallo empfau,

wir hatten nach der Neuinstallation von Office komischerweise nur kurzfristig das Problem behoben. Nach langer Suche bin ich auf einige interessante Artikel gestossen. Das Problem besteht bei uns definitiv aus folgenden Grund:
Neuer PC mit Windows 7 (64BIT) und Access 2007/2010 sowie SQL Server 2005/2008.
Ich habe bemerkt, das es auch lange dauert direkt am SQL Server
mittels Managmentkonsole Tabellen und Querys zu öffnen. (Also nicht nur
ein Problem von Access2007/2010!)
Die Lösung mit der wir jetzt arbeiten: Beim Starten von Access bzw.
SQL-Managment Tool diese im Kompatibilitäsmodus (XP) zu starten.
Seither läuft alles wir vorher!! Anscheinend gibt es mit den ODBC Treibern
unter Win7 mit 64 BIT Probleme. Habe leider auch keine entsprechenden Treiber gefunden, die dieses Problem lösen. Wenn jemand eine Treiberlösung hat, wäre auch ich sehr Dankbar dafür.

Ich hoffe, Dir eine Lösung für Dein Problem geliefert zu haben.

LG, Sivi

 

Danke für den Tipp, der hat mich echt gerettet. Hatte bei einem Kunden das selbe Problem. Die Performance schwankte zwischen "Ich geh mir mal einen Kaffee kochen und fahre grad ne Kaffeemaschine kaufen" bis zu "geil ist das schnell". Teilweise waren beim Laden eines gebundenen Formulars mit einer Abfrage über zwei verknüpfte Tabellen Wartezeiten von 30-40 Sekunden auf der Tagesordnung. Irre.

 

Hallo,

auf meinem System (intel core i5 M560 2,67GHz, 4Gb RAM, Win7 64bit, Office 2010 Prof. Plus 32bit) versuche ich seit geraumer Zeit die Probleme mit der Performance von Access 2010 in den Griff zu bekommen. Ich arbeite lokal mit dem Access Frontend mit momentan drei Tabellen zu je etwa 21000 Einträgen. Sobald ich SQL Statements ausführe, welche mehr als eine Tabelle betreffen, ist produktives Arbeiten nicht mehr möglich.

Ein Beispiel hierfür wäre etwa (die Tabellen teilen in diesem Fall den gleichen Schlüssel, die Felder sind dabei indiziert und die Tabellen über diese verknüpft.):

SELECT DISTINCT Tabelle1.Schluessel
FROM Tabelle1
WHERE Tabelle1.Schluessel NOT IN ( SELECT DISTINCT Tabelle2.Schluessel FROM Tabelle2 );

Bei der einfachen Einbindung des Ergebnisses in einen Bericht habe ich bereits Laufzeiten von 25 Minuten erlebt.

Das Grundsätzliche Problem scheint nach der Recherche bei Windows 7 zu liegen. Zur Fehlerbehebung habe ich bereits, wie teilweise ja auch hier vorgeschlagen, den Win XP Kompatibilitätsmodus, den Microsoft Hotfix KB2553116 sowie die Modifikation der "MaxBufferSize" auf 50000 für HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE probiert, leider bisher vollkommen erfolglos.

Für Ideen, wie Access unter Windows 7 betrieben werden kann, wäre ich sehr dankbar.

 

Zur allgemeinen Frage kann ich weniger beitragen, zur gezeigten SQL-Anweisung allerdings schon: Ein NOT-IN-Konstrukt bietet keine Indexnutzung und verschenkt logischerweise erhebliche Performance. Das DISTINCT in der Unterabfrage ist m.M. nach ungünstig (könntest Du aber separat testen):
Code:

Nebenbei:

Diese Kombination ist etwas "durchwachsen". 4 GB als Arbeitsspeicher kann 32Bit-Windows beinahe noch ausnutzen, dagegen muss bei 64Bit-Windows und 32Bit-Anwendungen (laienhaft ausgedrückt) umgerechnet werden, was Zeit kostet.

 

Hallo Eberhard,

zunächst vielen Dank für die Antwort. Nach deiner Anmerkung zur fehlenden Indexnutzung durch das NOT IN Statement bin ich nun sicher, dass das Problem zwischen Win7 und Access an den Indizes hängt. Während das SQL Statement mit NOT IN > 10 Minuten braucht um mir 897 Ergebnisdatensätze zu liefern, liegt das NOT EXISTS Statement bei < 1 Sekunde.

Wenn jemandem dennoch eine Idee hat, warum der Hotfix von Microsoft das prinzipielle Problem nicht löst, wäre ich sehr dankbar. Ausführungszeiten im Minutenbereich sind bei den kleinen Datenmengen und der Einfachheit der Abfrage indiskutabel würde ich denken.