Datenbankserver und Terminalserver

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo,

ich bin mir nicht sicher, ob’s hierher passt, aber ich poste mal:

Wir haben ein Lohn-und-Gehalts-Projekt, bestehend aus einer Datenbank (Oracle), und Client-Programmen unter Windows. Die monatliche Abrechnung (Windows-Clientbasierend) dauert sehr lange. Unsere Technologieabteilung möchte eine Beschleunigung der Laufzeit erreichen. Nun ist die Idee, Datenbank, Filebereiche und Clientseitige Abarbeitung auf einer Maschine und einer Betriebsysteminstanz abzuarbeiten, wobei die Clientseitige Abarbeitung in einer Terminaldienstesession erfolgen soll. Nebenbei wird von anderen Nutzern übers Netz weiterhin mit der Datenbank gearbeitet.

Jetzt meine Frage:
wer hat Erfahrungen bzw. Argumente für oder gegen die gleichzeitige Installation von Terminaldiensten und Datenbankdiensten (vorzugsweise oracle) auf einem Windows 2003 Standard-server ?
Wie könnte sich die Prozeß/ Lastverteilung entwickeln ? Wie ist die Stabilität einzuschätzen ?

Danke für Hinweise
Jens

#2

Hallo,

  1. es wird sich nicht groß beeinflussen
  2. es wird nichts helfen

Als erstes sollte man mal feststellen, wo das Problem überhaupt liegt.
Es kann sein, dass die DB lahm ist, es kann aber auch am Client liegen, der die Verarbeitung macht. Das lässt sich ganz einfach testen: lass das Programm laufen und schau auf die CPU- und Netzwerk-Auslastung vom Client und vom Server.

a) der Client ackert wie blöde. Wo da wohl der Fehler liegen mag?
b) Netzwerk ist auf über 20 % plus. Hier werden zu viele Daten transferiert und man kann optimieren, indem man Prozeduren auf den Server auslagert.
c) der Server ackert wie blöde. Vermutlich geht das hand in hand mit einem Dauerfeuer der Festplattenanzeige. Hier ist eine ganz normale Datenbankoptimierung nötig. Manchmal reichen einfach ein paar MB mehr, ein analyze table oder der richtige Index und es läuft.

Gruß

Peter

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#3

Danke erstmal für deine Antwort.

Die Abarbeitung ist Clientlastig, an einem PC getestet ergibt sich fast eine lineare Abhängigkeit von der CPU-Geschwindigkeit, wobei die Anzeige keine 100% CPU-Belastung ergibt. Da es ein fertig gekauftes Programm ist, kann man da wohl nichts dran drehen…

Gruß Jens

#4

Na dann stellt euch doch einfach einen möglichst fetten Client (sprich schnelle CPU, eventuell mehrere CPUs/Kerne dahin … Wenn das Ding so Clientlastig ist, ist es eine schlechte Idee, das mit auf den DB-Server zu packen. Wenn der nicht völlig überdimensioniert ist, braucht der seine CPUs schließlich selbst.

Jens

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#5

Hallo All, Hallo Namensvetter,

Ja, natürlich. die Hoffnung der Technologieabteilung und des Datenbankadmins ist einfach, Packt man alles lokal auf eine Maschine, gehts schneller als übers Netz. Es wird hier nach dem Sprichwörtlichem Strohhalm gesucht…

Und ich als Systemadmin such Argumente für oder gegen so eine Variante. Aus der Erfahrung heraus kanns nicht gut gehen, das seh ich genau so. Das Szenario hab ich aber auch noch nicht durchgespielt.

Wie skaliert eine Terminalserversession, wenn Datenbankdienst läuft ?
Wie skaliert überhaupt eine Terminalsession, wenn dort ein CPU-lastiges Anwenderprogramm läuft ?

Vieleicht ist es gar nicht mal ein DB-Thema. Sondern ist ein windowsServer-Thema. @MOD: bitte verschieben.

Gruß Jens

#6

Hi,
startet ihr die App über das Netz - also aus einem Netzwerk Share heraus oder ist der Client komplett lokal installiert?
Terminal-Server Lizenzen sind teuer. Da sollte man die Schwachstelle erst gut analysieren und nicht auf dem Pronzip „Hoffnung“ was machen.

Gruss
Q