none
Access 2003 Backend - Hardware

    Frage

  • Hallo

     

    Ich hoffe ich beziehe jetzt keine virtuelle Prügel bei meiner Frage:

     

    Ich bin auf der Suche nach dem zur Zeit optimalen System (Geschwindigkeit) für die Backend mdb von MSAccess 2003 in einem Netzwerk.

     

    Ich denke da an ein NAS System – nur weiß ich nicht wirklich wie sich Access im Netz verhält – ich denke dass das System viele kleine Zugriffe schnell abarbeiten muss, damit die Datenbank performant arbeitet.

     

    Gedacht ist das Gerät via 1 oder 2 Gbit Lan Schnittstellen ins Netz zu stellen und NUR die mdb drauf zu lagern – evtl. noch eine USB Platte daran um zwischendurch eine Datensicherung der mdb zu fahren – (am besten dann USB 3)

     

    Getestet habe ich selber einen Windows Server 2008 mit 2 SSD Platten im Raidverbund (für die mdb) und einer Systemplatte – aber das war ein Reinfall – ich denke mal dass da das Problem der Komprimierung der ssd’s war, dass das Ganze tierisch ausgebremst hat.

     

    Aber das Ganze sind einfach nur Vermutungen – ich habe leider nicht das Geld und das Know How die richtige Hardware/Software zusammen zu stellen.

    Das Ganze soll auch bezahlbar bleiben (max. 1500 €) also kein 10gbit Lan oder so, weil der Switch das nicht kann und ein Neuer nicht in Frage kommt.

     

    Wer kann mir hier technisch weiterhelfen

     

    Danke

    Michael

    Dienstag, 13. Dezember 2011 10:36

Antworten

  • der nächste schritt wäre der ms sql server über eingebundene tabellen(odbc) aber da bin ich mir nicht wirklich sicher ob ich damit geschwindigkeit heraushole

    Das kommt auf die Gestaltung der FE an. Wenn diese bereits "Datenbanktechnik" (Massendatenverarbeitung)  für die Datenauswertung nutzen, werden per ODBC verknüpfte Tabellen flott laufen, da Access/Jet über ODBC die Filterung vom Server erledigen lassen kann.
    Einen weiteren (vermutlich viel größeren) Geschwindigkeitsvorteil erhältst du, wenn du die Jet-Abfrage mit vielen Joins als Sicht im MSSQL gestaltest und diese Sicht als Access-Tabelle verknüpfst.

    Falls du den MSSQL einsetzt, werden aber andere Hardwareanforderungen für die maximal herausholbare Geschwindigkeit anfallen als für ein filebasiertes System. Wobei ich relativ wenig Wert auf die Hardware lege, da dem MSSQL-Server bei vielen DB-Anwendungen, die früher einmal ein Jet-BE nutzen (z. B. nur ein paar hundertausend DS in den Tabellen), nur langweilig wird. ;-)
    Mein Argument für ein aktives DBMS ist aber gar nicht die Geschwidnigkeit sondern ein stabiles Backup während dem Betrieb.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    • Bearbeitet Josef Pötzl Dienstag, 13. Dezember 2011 18:29
    • Als Antwort markiert MCDPone Dienstag, 20. Dezember 2011 15:58
    Dienstag, 13. Dezember 2011 17:31

Alle Antworten

  • Hallo!

    Bezüglich Hardware kann ich dir kein optimales System empfehlen, ich könnte mir aber vorstellen, dass bei der heute erhältlichen HW keine besonderen Unterschiede erkennbar sind.

    Vor der Investition würde ich prüfen, ob im Frontend bereits dafür gesorgt ist, dass die meisten Performance-Tipps (wie Vermeidung von ldb-Locking & Co.) umgesetzt sind.

    Noch etwas bezüglich Sicherung: eine Sicherung während dem Betrieb kann mit Glück klappen, sie kann aber auch schiefgehen - ich hatte vor einigen Jahren das Problem, dass mir eine Sicherungssoftware regelmäßig das BE zerschossen hat, weil es kurzfristig die Datei sperrte, während noch User damit arbeiteten.
    Falls du Geschwindigkeit und Datensicherung benötigst, könntest du dir überlegen, das BE in ein aktives DBMS zu verschieben. Ob sich der Aufwand lohnt, hängt von deinen Anforderungen ab.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen

    Dienstag, 13. Dezember 2011 11:34
  • Am 13.12.2011 schrieb MCDPone:

    Ich denke da an ein NAS System – nur weiß ich nicht wirklich wie sich Access im Netz verhält – ich denke dass das System viele kleine Zugriffe schnell abarbeiten muss, damit die Datenbank performant arbeitet.

    Wenn das FE das BE verliert ist Access sehr zickig. Bezüglich
    Performance leg ich dir das PDF ans Herz:
    http://access.joposol.com/artikel/PerfTuning.pdf und
    http://www.team-moeller.de/?Tipps_und_Tricks:Verbesserung_der_Performance

    Gedacht ist das Gerät via 1 oder 2 Gbit Lan Schnittstellen ins Netz zu stellen und*NUR* die mdb drauf zu lagern – evtl. noch eine USB Platte daran um zwischendurch eine Datensicherung der mdb zu fahren – (am besten dann USB 3)

    Zur Datensicherung hat Josef schon das wichtigste gesagt, die
    Geschwindigkeit ist IMHO völlig ausreichend.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Dienstag, 13. Dezember 2011 12:11
  • Danke für die Info's -

    Von der Performance seite her habe ich "alles" gemacht - mir geht es nicht darum das die datenbank zu langsam ist - sondern ich möchte einfach das maximum heraus holen an geschwindigkeit - und das eben von der hardwareseite

    die datensicherung lasse ich über robocopy laufen weil ich einfach die erfahrung gemacht habe das das am besten läuft - auch im laufendem betrieb

    ich traue es mich ja nirgends zu sagen aber an dem system welches das ganze beschleunigen soll hängen über 30 FE an der BE und es läuft gut

    der nächste schritt wäre der ms sql server über eingebundene tabellen(odbc) aber da bin ich mir nicht wirklich sicher ob ich damit geschwindigkeit heraushole

     

    darum eben die hardware frage

     

     

    Dienstag, 13. Dezember 2011 16:33
  • der nächste schritt wäre der ms sql server über eingebundene tabellen(odbc) aber da bin ich mir nicht wirklich sicher ob ich damit geschwindigkeit heraushole

    Das kommt auf die Gestaltung der FE an. Wenn diese bereits "Datenbanktechnik" (Massendatenverarbeitung)  für die Datenauswertung nutzen, werden per ODBC verknüpfte Tabellen flott laufen, da Access/Jet über ODBC die Filterung vom Server erledigen lassen kann.
    Einen weiteren (vermutlich viel größeren) Geschwindigkeitsvorteil erhältst du, wenn du die Jet-Abfrage mit vielen Joins als Sicht im MSSQL gestaltest und diese Sicht als Access-Tabelle verknüpfst.

    Falls du den MSSQL einsetzt, werden aber andere Hardwareanforderungen für die maximal herausholbare Geschwindigkeit anfallen als für ein filebasiertes System. Wobei ich relativ wenig Wert auf die Hardware lege, da dem MSSQL-Server bei vielen DB-Anwendungen, die früher einmal ein Jet-BE nutzen (z. B. nur ein paar hundertausend DS in den Tabellen), nur langweilig wird. ;-)
    Mein Argument für ein aktives DBMS ist aber gar nicht die Geschwidnigkeit sondern ein stabiles Backup während dem Betrieb.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    • Bearbeitet Josef Pötzl Dienstag, 13. Dezember 2011 18:29
    • Als Antwort markiert MCDPone Dienstag, 20. Dezember 2011 15:58
    Dienstag, 13. Dezember 2011 17:31
  • ok - ich denke ich muss richtung mssql denken - nur habe ich dort 5000 fragen auf einmal - also eigentlich nur die wann weiss ich das der sql server die arbeit macht und wann das FE - nur mal ein beispiel - ich habe ein formular als datensatzherkunft eine tabelle beim öffnen des formulares setze ich einen filter - schiebt der sqlserver erst mal alle daten rüber und filtert das FE dann oder erledigt das dann der sql server

    ok noch ein beispiel

    ich habe ein unterformular - wie läuft es da mit den daten - wieder alle daten vom sql server zum FE und er "filtert" oder erledigt das auch der server

    CurrentDb.Execute - FE oder mssql

    also die mich grundlegend beschäftigende frage ist wohl wann erledigt der sql server die arbeit und liefert mir ein ergebniss und wann das FE also wohl die jet weil ich denke wenn die jet das über odbc auf dem sql server das machen muss wird es doch bestimmt langsamer als wenn es von der jet in der mdb gemacht wird?

    Mittwoch, 14. Dezember 2011 08:26
  • Hallo!

    Grundsätzlich versucht JET über ODBC die Filterung dem Server zu überlassen. Diese Filterweiterreichung wird aber z. B. bei Filterungen auf berechnete Felder mit Jet-Funktionen scheitern.

    Auch beim Filtern der Datensätze in einem Verknüpften UF wird der Server nur noch die passenden DS zurückliefern.

    Du kannst du das mit dem SQL-Profiler oder auch über OCBC-Trace ansehen. Die Anzeige vom SQL-Profiler finde ich übersichtlicher.

    mfg
    Josef


    Code-Bibliothek für Access-Entwickler
    AccUnit - Testen von Access-Anwendungen
    Mittwoch, 14. Dezember 2011 10:56
  • Hallo Josef

    den SQL-Profiler kannte ich noch garnicht - klasse teil  Danke

    gibt es irgendwo eine dokumentation  worauf man bei der umstellung auf den sql server achten muss

    ich würde meine datenbank gerne zweigleisig fahren - entweder mssql oder direkt mdb zb. bekomme ich jetzt oft den "fehler"

    Wenn Sie auf eine SQL Server-Tabelle zugreifen, die eine IDENTITY-Spalte enthält, müssen Sie für die OpenRecordset-Methode die dbSeeChanges-Option verwenden. (Fehler 3622) - ok ich gebe jetzt die option dbSeeChanges dazu - nur läuft die mdb mit dieser option und ich denke eben das es ein paar stolpersteine geben könnte auf die man jetzt achten muss

    also meine frage - gibt es irgendwo eine kurzanleitung was zu beachten ist?

    Danke

    Michael

    Freitag, 16. Dezember 2011 11:04
  • Am 16.12.2011 schrieb MCDPone:

    also meine frage - gibt es irgendwo eine kurzanleitung was zu beachten ist?

    https://www.xing.com/net/dbs/produkte-20821/migration-einer-access-db-ms-sql-server-2501315/2501315/
    http://support.microsoft.com/default.aspx?scid=kb;de;237980
    http://sqlfaq.de/blog/?cat=9

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Freitag, 16. Dezember 2011 17:19