Office: (Office 2007) Server-Hardware?

Hallo zusammen,

in unserem Betrieb läuft eine Access-Anwendung mit Access-Frontend und Access-Backend. Momentan liegt das Backend auf einem PC, der per Netzwerk mit dem Zweiten verbunden ist. Da jetzt ein dritter und vierter PC dazukommen, wollen wir einen Server anschaffen. Das Backend bleibt zunächst mal Access.

Folgende Fragen bzw. Bitte um Meinungen:

- Auf was muss ich hinsichtlich der Hardware achten beim Kauf des Servers? Priorität hat die Performance der Anwendung. Was ist besonders wichtig (Speicher/Festplatte/Prozessor...?)

- Klappt das mit meinem Backend zB mit Windows Server 2008 oder muss ich beim Betriebssystem etwas beachten?

- Ist ein Server im Gegensatz zur "alten" Lösung der Performance zuträglich?

Danke für Eure Meinungen!

Gruß

Manuel

:)

 

Hi Manuel,

schnelle Festplatte ist schon mal ein guter Ansatz, empfehlen würde ich mindestens ein (Hardware-)Raid 1 aus 2 SAS- oder Nearline-SAS-Platten. Du wirst stehen, dass es hier schon empfindliche Preisunterschiede gibt.

Was IMHO am meisten bringt ist, ein möglichst schnelles LAN (mindestens Gigabit) sowie einen nicht so ganz billigen GigE-Switch. Im Optimalfall "Marken-Chipsätze" auch bei den Netzwerkkarten der Clients (hier ebenfalls mindestens GigE).

RAM und CPU sind auch wichtig, aber ehr für das Windows auf dem Server, d.h. durch eine "Verdopplung" bekommst du nicht umbedingt eine bessere Perfomance bei der Access-Anwendung.

Windows Server 2008 R2 ist i.o., je nachdem für welche Edition du dich entscheidest (d.h. die Dienste die du sonst noch betreiben willst) solltest du dann die Hardware etwas üppiger dimensionieren.

"Zuträglich" wird die Perfomance sicherlich etwas, aber das grundsätzliche Performance-Problem von Access-Backends im Multiuser-Szenario (ab 4..5 gleichzeitigen Usern deutlich zu spüren) kannst du nicht mit dickerer Hardware bekämpfen, sondern nur durch eine Migration auf einen SQL-Server (über ODBC).

 

Hi,

solange ihr das BE auf Access lasst, könnt ihr von einem Server kaum profitieren.

Denn Access ist kein aktives Datenbanksystem. Es kann nicht "eigenverantwortlich" Jobs auf dem Server ausführen, die diesen ausnutzen und nur die Ergebnisse zurückliefern. Ein Access-BE ist nur ein relativ dummes Datenlager, auf das nach wie vor der Client zugreift. Sein Prozessor glüht, nicht der des Servers.

Ein Server ist sinnvoll für aktive DBS wie MSSQL, MySQL, Oracle etc. Aber für Access ist er ziemlich witzlos. Jedenfalls nicht sinnvoller, als das BE auf einen starken Normalrechner umzubetten.

 

Bis auf die Windows-Version gelten meine obigen Bemerkungen analog auch für "starke Normalrechner".... wo auch immer der Unterschied sein soll.

Ein "starker Normalrechner" an dem niemand "sitzt" bzw. arbeitet und auf den nur per LAN zugegriffen wird ist auch nix anderes als ein Server. Wohingegen auch "schwache Normalrechner" durchaus Server sein können.

 

Hallo
ich habe das schon mit einem
NAS (Network Attached Storage) (dt.am Netzwerk angeschlossene Festplatten)
da hat dann jeder der am Netz hängt zugriff.
Kliener instalations Aufwand.
NAS gibt es schon ab ca. 100 CHF bis > 500 CHF je nach Grösse und ausstattung.

Bedingung für eine Reibungs lose Funktion:
Das FE (auf demLokalen PC) und das BE sind gut optimiert. (sauber Programmiert)

ich habe so eine sehr befridigende Performance erreicht ohne riesen Aufwand*Smilie
z.B. mit 3 User und einem NAS für Ca. 250 CHF

ich bin mit der NAS Lösung sehr zufrieden das läuft so schnell wie wenn ich das BE auch Lokal hätte.

 

Das sollte heißen: es lohnt kaum, Geld für einen neuen Computer auszugeben, wenn der Zweck der Anschaffung Performancesteigerung ist und das BE auf Access bleibt.

Da ist mehr gewonnen, wenn man aus den vorhandenen Rechnern den stärksten bzw. am wenigsten belasteten aussucht.

 

Vielen Dank für Eure Antworten! Das mit dem NAS klingt sehr spannend, das werde ich mal in Erwägung ziehen.
Irgendwann werde ich das Backend mal umstellen (müssen), aber noch scheue ich den Aufwand..die Anwendung hat recht viele Abfragen, die ich ja dann alle migirieren müsste..

 

Hallo Manuel,
für solche Kleingruppen beforzuge ich wie Ruedi auch einen NAS-Server.

Bedingung: Das Backend bleibt ein Filebackend.
Vorteile:
- Da die meisten NAS schon ein RAID mitbringen muss kein bestehender PC umgerüstet werden.
- Zentrale Ordner, auf die alle User Zugriff haben sollen, können ebenfalls dort platziert werden.
- Hat i.d.R. eine komfortabel einzurichtende Ein-/Aus-Zeitsteuerung
- ...

Für die Performance dürfte ein schnelles Netzwerk den größten Ausschlag geben.

 

Nein.

Du legst das Backend auf den neuen Speicherplatz, wo immer das nun sein möge. Dann bindest du die TABELLEN des Backends neu in das Master-Frontend ein - sofern es alle Tabellen sind, geht das per Dreizeiler in VBA, oder manuell einmalig auswählen, was verknüpft werden muss, ist auch kein großer Aufwand.

Außer den Tabellen musst du nach dem Backendumzug nichts neu einbinden. Dann noch das aktualisierte Frontend einmalig neu verteilen, fertig.

Ahja: Access 2007 / 2010? Dann neuen Speicherort des Backends in die vertrauenswürdigen Pfade von Access aufnehmen.


Edit meint nach dem zweiten Mal lesen: Habt ihr tatsächlich Abfragen im Backend angelegt und ins Frontend verknüpft? Dann müssen auch die neu verknüpft werden, was aber nur 2-3 Mausklicks "Mehraufwand" bedeutet.

 

Hallo
Lies einmal hier
http://dl.dropbox.com/u/46590638/ACC...unterlagen.zip
die seiten: 39-41
3.16 Splitten einer Applikation in Frontend und Backend

und
ab Seite: 59 bis Seite: 67 (Ganzes Kapitel 5.2)
5.2 Performance Verbesserung

diese Anpassungen kann ich dir nur Empfelen
vor allem seite 59/60

@Andre.Heisig

Dazu empfehle ich AutoLink von hcscherzer
Suche hier im Forum nach AutoLink *Smilie

 

Kenn ich sogar, hab mir aber da, wo ich's regelmässig benötige, was eigenes als VBA Prozedur gestrickt. dennoch Danke für den Hinweis ;-)

Ich hielt manuell in dem fall hier (einmaliger Bedarf) für den schnelleren weg.

 

Hallo
nur noch was
Denke daran wenn Du einen NAS nimst schon von begin an, an die 8 Zeichen Regel
das gilt jedoch generell
nich zu lange Pfad Namen und nicht zu tief verschachtelt !
lies in meiner Doc
auf Seite 62 das:
• 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.
z.B. D:\Aproj (hier FE-MDE evtl .ini Starter.Bat oder Starter.MDE evtl.benötigte .dll’s)
\Daten (hier BE DatenMDB wenn sie nicht auf einem Server ist etwa Y:\Aproj)
\Picture (hier benötigte Grafiken, Bilder und .Ico’s)
\Source (hier die Quellen MDB’s)
\Backup (hier Sicherstellungen von FE und evtl. BE)
………
Und auch der Name des BE sollte möglichs kurz sein z.B. ProjBE.mdb
Der FE-name und der BE-Name sollte ohne .mdb od. .mde nicht länger als 8 Zeichen Sein !Was ich auch für Pfad und Sub-Pfade immer öffters so mach wenn möglich auch auf den Server
Alle Pfad-Namen ico, Bilder und ini Dateien auch nicht länger als 8 Zeichen
Diese 8 Zeichen Regel und möglichst kurze Pfad-namen nicht zu tief verschachtelt
besteht natürlich auch für die MDW!
Im weiteren Keine Leerstellen Sonderzeichen (äöü-$£! etc.) in Pfad- und Datei- Namen
Bspl. eins BE- Pfad: X:\P1Max8ZL\P2Max8ZL\ ProjBE.mdb oder
\\NetDrv\P1\P2\ ProjBE.mdb

 

Wenn ich das Backend von accdb auf zB mySQL umstelle, gehe es ja nicht nur um den Speicherort; es müssen ja alle Tabellen von Access auf SQL umgestellt werden-ist das wirklich so schnell gemacht wie es hier klingt?

Abfragen habe ich bislang alle im FE, wobei ich gehört habe, dass man diese ebenfalls in ein SQL-BE auslagern sollte, damit der Server die Rechenarbeit macht und nur die Abfrageergebnisse anstatt ganze Tabellen übers Netzwerk schicken muss.

Was wären die nötigen Schritte für eine Umstellung auf SQL-BE? Und ist mySQL gut dafür oder sollte es Microsoft SQL Server sein?

 

Das ist nun schon eine dezent andere Fragestellung. Wenn ein aktives DMBS gewünscht ist, kannst Du Dir die NAS-Idee gleich wieder abschminken, da brauchts dann doch einen "echten" Server drunter.

 

Nein, nicht wirklich. Aber es lohnt sich. MySQL würde ich nur jemandem Empfehlen der schon Erfahrung mit ODBC + Access gemacht hat. Es gibt im Speziellen schon ein paar Bugs und Unschönheiten die man umschiffen muss. Der MS SQL-Server (z.B. in der kostenfreien Express-Version) ist da um einiges netter.

Wobei ich auch klar sagen muss, dass die Installation von MS SQL Server etwas kompizierter ist als MySQL. Diesen Mehraufwand hat man dann aber beim leichteren Umgang mit Access via ODBC dreichfach wieder raus.

Jaein, bei Access + ODBC werden auch nicht mehr die kompletten Tabellen übertragen. Klar ist es super Abfragen als Views im SQL-Server / MySQL abzubilden, dann hat sich aber spätestens beim ersten InnerJoin die Aktualisierbarkeit erledigt, welche hingegen beim gespeicherten Query im Frontend teilweise noch vorhanden ist. Wenn man das nicht braucht, ist höchtens noch der Nachteil zu nennen, dass man dem im FE gespeicherten Paththrough-Query umbedingt einen DNS zuweisen muss ... dumm nur wenn man ohne festen DSN arbeiten will...

Für MS SQL Server: SSMAAccess.docx von http://www.microsoft.com/en-us/downl...s.aspx?id=8775