46758
Goto Top

Windows 2003 enterprise

Wir haben in der Firma mehrere Server einer davon hat win 2003 Server Standard edition 32bit version.

Es laufen auf dem Backup Arc Serv software, 50 User sind angeschlossen die Hotline programm über dem Server ausführen und irgendwelche Masaccess abfragen die dann den Srevr in die Knie zwingen, das haben wir ständig.
Ausstatung vom Server ist :

Windows 2003 Server 32 Bit Standard Editon
3,19 GHZ XEON CPU
4 GB Ram Speicher

Physikalischer Ram:
Auslagerungsdatei liegt bei 2,8 GB

CPU Schwankt auch zwischen 40 und 80 %

was kann mann den tun damit das bischen besser wird vom Performance her.
Im Hinetrgrund laufen keine Programme wie Firewall oder Antivirus usw.

Es laufen nur gewisse Abfragen und dieser Abfragen zwingen den Server in die Knie.

Meine überlegung ist bringt den Ram Speicher aufstocken bei diesem Win Version etwas oder nicht.


Für jeden Tipp wäre ich an euch dankbar.


Danke

Content-Key: 56947

Url: https://administrator.de/contentid/56947

Ausgedruckt am: 28.03.2024 um 17:03 Uhr

Mitglied: Logan000
Logan000 18.04.2007 um 12:12:37 Uhr
Goto Top
Verstehe ich das richtig? 50 User arbeiten auf einer Access DB auf dem Server?
In einer mehrbenutzer umgebung ab 10 User kein Access mehr.
Mitglied: 46758
46758 18.04.2007 um 12:42:45 Uhr
Goto Top
Nein kein Acces Db ist ein Programm für Hotline entwickelt und ich denke es läuft nicht mit Accecs DB.
Aber es gibt 4 User die Accesc Db Abfrage über den Server machen.
Mitglied: SlainteMhath
SlainteMhath 18.04.2007 um 12:49:36 Uhr
Goto Top
In einer mehrbenutzer umgebung ab 10 User
kein Access mehr.

Also dem kann ich so nicht zustimmen. Bei uns arbeiteten bis vor kurzen knapp 100 User auf einer Access Datenbank und was war eigentlich nie ein wirkliches Problem.

@46758:
Wie greifen denn die user auf die MDB zu? Wird die Datenbank direkt über ein Share/Netzlaufwerk geöffnet? Oder hat jeder User eine eigene MDB deren Tabellen mit der MDB am Server verknüpft sind? Oder werden die Abfragen direkt vom Server (Über Terminalsession o.Ä.) ausgeführt?

Generell würd ich das Problem eher durch geschicktes Anlegen von Indizies in den Tabellen oder durch verteilen der Tabellen auf mehrere MDBs lösen, anstatt den Server aufzurüsten.

Evtl. kannst Du auch mal prüfen ob sich eine Umstellung auf SQL durchführen lässt, der Server ist jedenfalls grß genug gesized für SQL ;)
Mitglied: Logan000
Logan000 18.04.2007 um 12:57:05 Uhr
Goto Top
Also dem kann ich so nicht zustimmen. Bei
uns arbeiteten bis vor kurzen knapp 100 User
auf einer Access Datenbank und was war
eigentlich nie ein wirkliches Problem.

Ich sage ja gar nicht das es nicht geht. Aber abhängig vom Frontend, den Datenbankdesign, dem Datenvolumen, ... wirst Du eher Probleme haben als mit anderen DBs.
Mitglied: SlainteMhath
SlainteMhath 18.04.2007 um 13:50:51 Uhr
Goto Top
Ich sage ja gar nicht das es nicht geht. Aber abhängig vom Frontend, den
Datenbankdesign, dem Datenvolumen, ... wirst Du eher Probleme haben als mit anderen DBs.

Ok, der Aussage kann ich uneingeschränkt zustimmen face-smile
Mitglied: 46758
46758 18.04.2007 um 15:15:31 Uhr
Goto Top
Danke zuesrt einmal für die unterstützung,

ich bin noch nicht ganz in dem System hineingewachsen in unserem Unternehem aber wir haben 2 Server eine ist eben dieser Server wo sehr manchmal in die Knie geht und wir haben einen neuen SQL Server wo generell die Abfragen über den 2. Server erfolgt.

Ein User arbeitet und erstellet selber Abfragen über MSACCES Datenbank Tabellen und aufwendige Datenbanekn mir ODBC usw. damit kenn ich mich wenig aus.
Aber er greift und andere User auch die im Hintergrund das MSACCESS aufgerufen wird und das ist ja unser Problem was diesen Server in die Knie zieht.
Soweit ich sehe finden hier ganz aufwendige Abfragen in Acces statt die auf dem Server in verbindung mit dem SQL server sattfindet.
Mitglied: 46758
46758 18.04.2007 um 15:24:16 Uhr
Goto Top
Früher gingen die Abfragen auf diesen Problematischen Server jetzt ist es umgestellt worden, d.h. es gibt den neuen Server den SQL Server.
Aber ich denke es läuft nicht so optimal.