Office: (Office 2003) MS Access auf Server 2008 R2 X64 langsam

Hallo Zusammen,

ich hoffe ich bin hier im richtigen Bereich? Mein Problem möchte ich mal so schildern. Ein Access MDB auf Basis 2000 läuft seit Jahren auf einem Server 2003 x 32 System reibunglos und zügig! Dabei handelt es sich um das typische Prinzip FE und BE aber als lokale Verknüpfung z.B. FE liegt auf C:\DB\FE.mdb und BE: C:\DB\BE-Dateien\BE.mdb alle Tabellen sind verknüpft!

Nach einem Umbau des Netzwerkes wurde der Server auf Server 2008 R2 x64 angehoben. Wo im gegensatz zum 2003 Server mal richtig Power drin steckt!
- 6 Kern CPU
- 16 GB Ram
- Sata 3 HDDs

Als Software läuft dort fast das gleiche wie auf den 2003 Server, nur das als Office Paket 2010 x32 ohne Access läuft. Wir wollten uns hier die Lizenz sparen und mit Access 2003 SP3 weiter arbeiten. Das klappt so weit auch alles!

Die Benutzer jedoch sagen uns, dass alles was mit Access zu tun hat bestimmt 1/3 langsamer laufen würde! Wir fragen uns nartürlich woran das liegt!

Um Fragen von vorneherein zu vermeiden:
- Server OK
- HDDs OK
- Access Anwendungen keine Änderungen
- Datendurchsatz HDDs TOP

Nun habe ich gelesen, dass man ggf. in der Regestry einen Buffer Wert Ändern soll, nur weiß ich nicht welche/n!

Daher hier die Frage an euch was kann ich tun? Hat jemand einen guten Tipp?

Vielen Dank :-)

:)

 

Hallo, mal ne Verständnisfrage, Da steht ein Server und die db läuft lokal? Wurde denn vorher überhaupt über das Netzwerk auf die db zugegriffen?

Gruß hgs

Oder habe ich was falsch verstanden?

 

Ups OK die Frage kann ich verstehen ist ein Terminal Server via RDP. Und der 2003 war vorher auch einer! Habe das nur nicht erwähnt, damit hier nicht die Sprüche kommen wie oh ja Netzwerkproblem, nein nein dem ist nicht so ist ein Gigabit Lan und die Leistungsdaten sind spitze also daran liegt es nicht die User Arbeiten von Ihrem Clients aus direkt auf dem Server via Terminal-Sitzung. Der neue Server langweilt sich bei 20 Benutzer mit gerade mal 5% CPU auslastung 2,5 GB Ram auslastung!

 

Ok, mit terminalservern habe ich so gut wie nix zu tun, da habe ich im Moment auch keine Idee...
Ich würde vielleicht mal konvertieren und ne andere Version probieren, aber...
Nur so zur Info, dh alle User nutzen die gleiche frontend db?

Gruß hgs

 

Hallo,

mde/mdb und vor allem ldb-Dateien stehen im Virenscanner auf der Ignore-Liste?

Jeder User bekommt seine eigene (komrimierte) Kopie des Frontends z.B. nach %TEMP%?

Backend wird regelmäßig (1 x täglich) Komprimiert?

Ggf. könnte man das BE noch auf eine extra Partition packen und für diese die Volume Shadow Copy Services deaktiveren.

Bzgl. der Registry-"Hacks" habe ich in Erinnerung, dass ich mir das nicht getraut habe... *biggrin.gif*

PS: Ab 20 User über ich über einen SQL-Server und Frontends per ODBC nachdenken!

 

Moin,

Auch im Frontend den Debugger laufen lassen!

Woher hast Du denn den Text, was Du in der Registry ändern sollst?
Schaue mal bei donkarl vorbei, da müsste was zu Registryeinträge stehen.

Dann berate Dich mit Deinem Administrator. Datensicherung des Servers und alles was dazugehört!

Gruß
Jens

 

Hallo Zusammen,

vielen Dank für die Tipps. Ich habe so eine Idee... ichn melde mich...

 

Hallo
evtl auch was fur Dich:

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

Lies dazu in meiner Doc s. Fusszeile unten rechhts
ab Seite 61

oder gleich das ganze Kapitel 5.2 ab Seite 60

 

OK, habe jetzt mal so ein bisschen ausprobiert! Am Virenscanner liegt es nicht alle DIRs mit Datenbank habe ich ausgeschlossen! Dann sollte ich vieleicht noch hinzufügen, dass die Idee mit dem SQL verständlich ist, wir das aber so haben, dass max drei User gleichzeitig die DB öffnen können! Auf einem Terminal-Server brauch man keine extra FE für jede Instanz. Wir hatten das schon auf dem 2003 ausprobiert, das war dem Server so was von Schnuppe ob extra FE oder alle die gleichen öffnen. Das liegt aber an der Terminal-Server Technologie. Alle BE Daten und FE Daten haben unter Optionen den Befehl drin beim schließen kompremieren. Das klappt auch super der 2008 R2 macht das 90 % schneller als der Server 2003.

Ich finde die Begleitunterlagen Super von Rudolf, jedoch bezieht sich das ja alles auf die optimierung der DBs! Das die DB ein Profi geschrieben hat, der den ganzen Tag nichts anderes zu tun hat, finde ich auch vieles wieder was damals bei dem Projekt so umgesetzt wurde! Der Hatte wohl dein Handbuch immer neben sich liegen!

Ergo: Wenn die FE u. BE auf dem alten Server um 1/3 schneller ist, muss es an was anderem liegen, Virenscanner ist es nicht! Neuste Updates für Betriebssystem und Access ist drin! Benutzerkontensteuerung ist aus! Firewall in 2008 R2 ist aus. Das Problem ist eindeutig bei Aufruf der Forms zu erkennen, weil doch zich Kombis beladen werden müssen! Wir haben damals den Kunden darauf hingewiesen das Kombis nicht imm doll ist jedoch wollte er so. Der Kunde behilt auch so weit Recht bis auf den Umzu auf den 2008 R2.

Also stelle ich jetzt einfach mal in den Raum, was ist für die schnelligkeit beim laden von Form bzw. zum befüllen der Kombis im Form im Betriebsystem verantwortlich die Jet? Liegt es vieleicht am DDR3 RAM mit 1333 MHZ das dieser einfach von Access 2003 nicht voll ausgelastet werden kann?


Es ist tasächlich so, wenn ich die DB auf den alten Server 2003 mit 2 GB DDR 2 Ram umkopiere, ist die Dantenbank um 1/3 schneller beim laden bzw. befüllen der Kombis im den Forms...

 

Hallo,

dein Problem liegt wahrscheinlich anderswo, jedoch kann man einige Deiner Aussagen m.E. so nicht stehen lassen:

Wenn das stimmen würde, dann bräuchte man die im klassischen Szenario (BE verlinkt via SMB FileShare) auch nicht. Und wenn man das im klassischen Szenario nicht brauchen würde, dann könnte man sich die Trennung von FE und BE auch gleich komplett sparen, das kostet dann nämlich nur Performance.

Google dir mal ein Tool welches aus einer ldb-Datei die angemeldeten User auslesen kann und lass das Tool auf die ldb-Datei deines Frontends los, wenn 2 oder 3 User angemeldet sind. Wenn es stimmt was du sagst, dann dürfe die ldb entweder nicht vorhanden sein oder dort nur einen User anzeigen.

Ok, d.h. die FE's komprimieren sich, die BE's komprimiert aber niemand, da hierbei das Setzen der Option nicht ausreicht. Der Zugriff auf eine verknüpfte Tabelle reicht nicht aus das BE dazu zu bringen sich selbst zu Komprimieren.

Man könnte auf die Idee kommen, dass eine Mischinstallation (z.B. Access 2003 und restl. Office 2010) eine Fehlerquelle sein könnte. Da ich sowas aber selbst im Einsatz hab, würde ich nicht denken dass es daran liegt, aber einen Versuch wäre es vllt. Wert, mal alles was Office ist zu deinstallieren und Office 2003 komplett zu Installieren.

 

OK danke für deine Hinweise, werde das mal abarbeiten und hier schon mal der Schlüssel...

So ich habe den Schalter gefunden in der Reg.:


[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0]

Dort:

"MaxBufferSize"=dword:00000fa0 (Dezimalwert 4000, sollte immer max die Hälte des RAM sein ich habe jetzt mal die 0 auf 4000 geändert) mal sehen was passiert, laut Messung: ist das Ganze jetzt um 50% schneller, ich hoffe nicht das ich mir das einbilde...

 

Hallo Mike,

hast Du eine Quelle für diese Aussage?

TIA

 

Hallo
Das ehrt mich natürlich sehr wen der Entwickler meine Unterlagen gelesen hat
und dann noch alles richtig gemacht hat *wink.gif*

habt ihr auch Kurze Pfad – Namen und Datei- Namen Max 8 zeichnen Lang ?
lies auf Seite 63

 

Die Quelle lautet:

Intersoft Systems - Technical Support Bulletins

 

Mit dem Pfaden ist so ne Sache in den meisten Fällen hat er sich an die 8 stellen gehalten, bei manchen Fällen geht bis zu 15 Zeichen.

Habe das aber mal spielerisch ausprobiert und die Pfade verlagert! Macht in unserem Fall nichts aus!