schönen guten morgen!
Hi,
Die von Dir genannten Probleme kenne ich jetzt nicht.
ich leider schon 
… deswegen zuerst die methode, wie ich es - halbwegs - wieder hinkriegte: zuerst alle applikationen installieren, dann die db und das ganze nie wieder angreifen 
… aber:
aber zu meiner frage: sollte man ueberhaupt eine datenbank mit
auf einen applikationsserver (hier fuer webanwendungen fuer
ein grosses intranet) betreiben? ich bin der meinung: nicht
bei nt/2000. ,
Ich würde das verallgemeinern: gar nicht.
es funktioniert, jedoch nur mit _gewissen_ einschränkungen:
- speicher: die graphischen oracle-tools a la studio fressen und fressen und fressen speicher … diese sachen sollten bei jenen benutzern, die das auch _wirklich_ benötigen, client-seitig installiert werden
- system: diverse oracle-produkte behindern sich gegenseitig bzw. sind nur eingeschränkt bzw. unter gewissen richtlinien miteinander kompatibel (installiere bsp-weise NIE forms nach der db; web-db2.1 und oas8.0.4 laufen zwar nebeneinander, wird sogar supported, jedoch kann man bsp. keine updates durchführen)
- größen: je größer die instanz (nicht mal die db), desto mehr ein eigener server
aber ich würd’s unterlassen …
Die Erfahrung zeigt, daß jede Komponente (Webserver,
Application Server, Datenbankserver, usw.) für sich allein
fehleranfällig ist. Zusätzlich potenzieren sich die
Fehlerquellen in der Wechselwirkung der Einzelkomponenten. Nun
muß man abwägen, was billiger ist: einen eigenen Rechner z.B.
für den Webserver bereitzustellen, oder die Ausfallzeiten, die
sich daraus ergeben, daß Du den Rechner eingespart hast.
that’s the fact: erklär nun aber mal einem budget-verantwortlichen mit null-system-ahnung, daß mehrere kleinere Server „billiger“ sind als ein großer …
das problem liegt, glaube ich, im staendigen
installieren und deinstallieren von irgendwelchen programmen
und tools,
„Sonstige Programme und Tools“ haben auf einem
Applikationsserver schon gar nichts zu suchen.
a) antwort ist absolut richtig
b) wie schon oben erwähnt: bei oracle kommt sehr viel auf die reihenfolge drauf an …
Es gibt einen weiteren Grund, die Systeme zu trennen:
Sicherheit. Wenn man die Komponenten vernünftig trennt, muß
ein theoretischer Hacker, der sich Zugriff auf den Webserver
erschlichen hat, erst einmal den Datenbankserver knacken. Sind
beide auf einer Maschine, hat er schon gewonnen.
vorteil: man muß sich nicht so viele paßwörter merken (das war wirklich mal eine begründung eines edv-leiters, keinen eigenen db-server zu kaufen)
by the way: eine db auf einem web-server hat für meinen geschmack bereits aus diesen sicherheitsgründen absolut nix zu suchen …
grüße
tomh
