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

Helfe beim Thema Performance-Probleme mit verknüpften Tabellen in Access 2010 in Microsoft Access Hilfe um das Problem gemeinsam zu lösen; Hallo zusammen, seit der Umstellung von Access 2000 auf 2010 haben wir große Performance-Probleme: Das Arbeiten am Frontend verlangt teilweise viel... Dieses Thema im Forum "Microsoft Access Hilfe" wurde erstellt von empfau, 4. Juni 2011.

  1. 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??

    :)
     
    empfau, 4. Juni 2011
    #1
  2. 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
     
  3. 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.
     
    Lanz Rudolf, 6. Juni 2011
    #3
  4. Performance-Probleme mit verknüpften Tabellen in Access 2010

    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
     
    empfau, 16. Juni 2011
    #4
  5. 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
     
    empfau, 16. Juni 2011
    #5
  6. Hallo Michael,
    Wieviele User arbeiten gleichzeitig mit Deiner Datenbank?
    Warum verwendest Du 11 verschiedene Backends?

    CU
     
    Thomas Möller, 16. Juni 2011
    #6
  7. 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
     
    empfau, 16. Juni 2011
    #7
  8. Performance-Probleme mit verknüpften Tabellen in Access 2010

    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
     
    Thomas Möller, 16. Juni 2011
    #8
  9. 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
     
    empfau, 17. Juni 2011
    #9
  10. 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
     
    Thomas Möller, 17. Juni 2011
    #10
  11. 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
     
  12. 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.
     
    robster1704, 14. Januar 2012
    #12
  13. Performance-Probleme mit verknüpften Tabellen in Access 2010

    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.
     
  14. 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.
     
  15. 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.
     
Thema:

Performance-Probleme mit verknüpften Tabellen in Access 2010

Die Seite wird geladen...
  1. Performance-Probleme mit verknüpften Tabellen in Access 2010 - Similar Threads - Performance Probleme verknüpften

  2. Performance Probleme beim Makro

    in Microsoft Excel Hilfe
    Performance Probleme beim Makro: Hallo zusammen, ich habe mir folgendes kleines Programm gebastelt. Als "Laie" macht es zumindest was es soll... aber wenn es über 36 TSD Zeilen läuft, ist die Performance unterirdisch. Habt ihr...
  3. KPIs (Key Performance Indicators) in Power Pivot

    in Microsoft Excel Tutorials
    KPIs (Key Performance Indicators) in Power Pivot: KPIs (Key Performance Indicators) in Power Pivot Excel für Microsoft 365 Excel 2019 Excel 2016 Excel 2013 Mehr... Weniger...
  4. For Schleife, schlechte Performance

    in Microsoft Excel Hilfe
    For Schleife, schlechte Performance: Hallo zusammen, ich habe eine Tabelle mit 22.000 Ids, welche ich in einer 55.000 Zeilen großen Bestandstabelle Suche und bei Treffer einen Wert in einer Nachbarspalte überprüfe. Je nach...
  5. Performance / langsames Netzwerk / Frontend

    in Microsoft Access Hilfe
    Performance / langsames Netzwerk / Frontend: Hallo zusammen, Ich habe mal eine Frage an die erfahrenen hier: Situation: - Netzwerk ist unglaublich langsam - Aufteilung in Front- und Backend war notwendig Lösung: jegliche Stammdaten sind...
  6. Performance verbessern

    in Microsoft Access Hilfe
    Performance verbessern: Hallo. Ich versuche gerade meinen Code etwas zu "überarbeiten" dabei würde ich gerne solche Blöcke etwas performanter gestalten, weiß aber nicht so recht wie ich das angehen soll. Kann mir jemand...
  7. einen BIS-Wert aus Tabelle auslesen

    in Microsoft Access Hilfe
    einen BIS-Wert aus Tabelle auslesen: Hallo zusammen, stehe wieder auf dem Schlauch.... :(. Folgendes Problem: In einer Abfrage habe ich eine Prozentwert. In einer Tabelle habe ich mehrer Prozentbereiche und einen...
  8. Performance Probleme

    in Microsoft Outlook Hilfe
    Performance Probleme: Hallo, leider bekomme ich immer häufiger "Keine Rückmeldung" von Outlook 2010. Es scheint sich bei diversen Aktionen selbst zu überlasten und dann abzustürzen. Ist es normal, das Outlook...
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Auf dieser Website werden Cookies für die Zugriffsanalyse und Anzeigenmessung verwendet.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden