Hi Holger,
in Versionen <10 waren die Defaults schon fast absichtlich so getrimmt, dass sie ein admin ändern musste.
Nicht unbedingt total dämlich, da selbst ein 10G mit "smart defaults" nichtmal 20% der Leistung haben *kann*, die ein vernünftiges Setup haben kann.
Wer mehrere Tausend Euronen für ene RDMS Lizenz ausgibt wird sicherlich auch noch etwas in der Portokasse haben um sich ein schniekes NAS zuzulegen, um dort Tablespaces so auf unterschiedlichere Arrays zu verteilen, dass die Datenbank einzelne Phasen oder Teilmengen eines Statements parrallel ausführen kann.
(mehrere Prozis/Server wollen ja genutzt werden und die Suche im Index soll ja das Ausgeben der selektierten Daten nicht bremsen, right? )
Eine Ora
DB die ihre Temp spaces überstopft ist entweder komplett dämlich aufgesetzt oder die Daten wurden "unschlau" eingefügt.
Oracle kennt nunmal DiretPathLoading, welches an der
SQL Engine vorbei operieren kann um sehr große Datenmengen in einem Bruchteil der Zeit reinzuschieben.
Ich bin immer noch der Meinung, dass Ora momentan die Krönung der Schöpfung im RDMS Segment ist. Aber neben den Anschaffungskosten darf man die nötige Hardwarekosten nicht unterschätzen (ebenso wie das Geld für denjenigen, der sie für dich installiert
)
Firebird ist nicht wirklich schlecht. Es ist eigentlich sogar absolut fantastisch als embedded Briefcase RDMS.
Aber ehrlich gesagt habe ich mit
FB schon zu oft eine korrupte Datenbank Datei erlebt, die Tatsache, dass man die GC sweeps manuell anschubsen muss oder Transaktionen, die irgendwo im Nirwana laufen und Tabllen sperren, obwohl die dazugehörige Connection längst tot ist.
Ich habe sowas nicht ein einziges Mal mit Oracle erlebt, noch nichtmal davon gehört.
Eine hochverfügbare
DB würde ich nicht mit
FB realisieren wollen, aber für alles darunter ist es sicherlich exzellent.
Außerdem ist
FB wahrscheinlich die optimale Wahl wenn AppServer und
DB Server die gleiche Maschine sind: der Overhead eines
FB servers im Idle-Mode ist praktisch null
Ein Oracle, DB2, whatsoever frisst sich immer die max. Speichermenge, die du ihm zusicherst um sofort sprungbereit zu sein. Deshalb sind solche großen RDBMS absolut uneffizient, wenn sie nicht ihre eigene Maschine(n) haben.