Zitat:
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.
Korrupte Datenbanken sind seit Firebird 1.x die absolute Ausnahme, wenn man forced writes aktiviert, wenn nicht hat man selbst schuld. Wenn es dann doch auftritt, dann verbunden mit irgeinem Hardwarefehler oder irgendeiner Software auf dem Server, die etwas macht was man nicht machen sollte (Backupsoftware die offenen dateien sichert, Antivirensoftware und sonstiger Kram). Beim dpa Server in Hamburg sind zum Beispiel 300 ständige Verbindungen aktiv, also aktiv arbeitende Redakteure, die entweder selbst Texte schreiben (ca 5000 pro tag) oder noch viel häufiger in den ca 5 Millionen Dokumenten recherchieren. Das ganze läuft 24 Stunden am Tag, weil die eben nie ein Zeitfenster festlegen können, an denen die Redakteure mal eben nicht arbeiten können. Wir haben für die eine Replikation programmiert, die alle Livedaten auf einem zweiten Server stets verfügabr hält, außer durch Hardwarefehler wurde dieser aber noch nie gebraucht. Die Anwender haben beim Umschalten nichts gemerkt.
Garbage Collection läuft übrigens stets im Hintergrund mit ohne das man irgendwas anwerfen muss. Selbst das Sweep Interval ist nur dafür da, das auch Tabellen und Indices verwurstet werden, die eben nicht durch sonstige Clients im Rahmen von
SQL Befehlen angepackt werden. Komplette Tabellen habe ich noch nie gesperrt gesehen, ist auch nicht so einfach wegen der Multigenerationsarchitektur. Sperren von toten clients gab es insbesondere beim classic server mal, aber da hat man wohl gerade die ursache gefunden, warum das im Netzwerkprotokoll nicht als toter client erkannt wurde. Meistens sind die angeblich toten Verbindungen, die die Garbage Collection blockieren, aber gar nicht tot, sondern durch unwissenheit eines Programmierers oder admins entstanden.
Bezgl. Garbage Collection: Einfach mal eine Tabelle anlegenn, 100000 Datensätze einspielen, committen, alle datensätze löschen und committen. beim ersten select auf dieser Tabelle kann man in IBExpert den Wert für die Fetches ablesen, das heisst wieviele Recordversionen wurden abgefragt um das Ergebnis zu erstellen. Man sieht beim ersten
sql trotz lerrer Ergebnismenge ca. 200000 fetches (2 Version, 1. originalsatz, 2. gelöschte Version). wenn man innerhalb weniger Sekunden das noch mal macht sieht man ca 100000, beim nächsten mal ca 50000 , dann einen Wert nahe 20. durch den Commit beim Löschen macht firebird noch nichts, aber sobald die nächste Transaktion einen der betroffenen Sätze fetcht, wird die dazugehörige Page an den Garbagecollectorthread übergeben und der kümmert sich dann asynchron darum. Und für die tabellen, die nie gefetcht werden ist das Sweep Interval dabei oder der sweep per Kommandozeile. Das gilt übrigens nicht nur für datenpages, sondern auch für Indizes.
unabhängig davon: Oracle ist ganz sicher technischer Marktführer bei den Datenbanken, aber das ist mal Boeing und mal Airbus bei Flugzeugen auch, aber nicht für jeden Zweck bieten die passende Flugzeuge an. In Deutschland gibt es ca 350 Flugplätze, Boeing Maschinen können davon auf maximal 50 landen. Alle anderen sind aber sehr gut anfliegbar mit Cessna, Piper und was da sonst noch so angeboten wird. Und diese können auch auf den großen Airports landen. Nun gut, auch die dicken Flieger können auf den Graspisten landen, aber ob das was dann davon übrig bleibt noch startfähig ist, sei mal dahin gestellt.
ich nehm mal ein ganz banales Beispiel eines Kunden, dessen Software Apothekenlogistik automatisiert. Deren Kunden interessiert nur die Gesamtinvestition und die Stabilität der Gesamtanlage und wie schnell die Dateneingabe, die Verarbeitung, die Anbindung an die POS, die Ausgabe von Reports, etc. ist. Wenn der vom Betrag x nun noch Oracle Serverlizenzen kaufen muss und passende Raidsysteme etc. in die Hardware einplanen muss, ist sein Ertrag für den Hersteller einfach niedriger, weil es dem Kunden einfach egal ist. Anteilig an der Gesamtinvestition kann man da zwar sagen, das das auch nicht mehr viel ausmacht, aber bei so manchem Projekt sind die Nettoerträge trotz großer Projektsummen gar nicht so doll wie man denkt, insbesondere wenn man viele Module selbst einkaufen muss. und wenn die Kiste nicht läuft ist der Hersteller des Gesamtsystems verantwortlich. Ob der nun irgendwelche Tempspaces anpassen muss oder was anderes, was ein unfähiger Admin verbrochen hat, ist dem Kunden egal. Bei der Apothekenlösung hat sich Firebird bewährt, nach anfänglichen Programmierfehlern haben die aufgrund meiner Schulungen und Hinweise Ihre Technik scheinbar im Griff udn nutzen seitdem auch unsere Hotline immer weniger.
ich will eigentlich nur deutlich machen, das nicht immer die eine Lösung das allein selig Machende ist. Bestimmt gibt es Anforderungen, bei denen man mit Oracle die beste Lösung gewählt hat. Aber wie du schon sagst, ähnlich wie beim Flieger muss die Investition immer zum Anwendungszweck passen. Wenn ich von Oldenburg nach Sylt will brauch ein kleiner Flieger ca eine Stunde, es geht auch mit dem Auto in ca 5 Stunden oder mit dem Linienflieger ab Hamburg oder Hannover, wenn denn das gerade einer abfliegt und ich muss da auch erst mal hinkommen.
Bei der dpa hatte man zum Beispiel Bauchschmerzen mit dem Oracle Server auf Laptops, insbesondere weil die Software weltweit im Einsatz ist und viele von den Redakteuren auch offline arbeiten müssen, teilweise auf sehr rustikaler Hardware mit wenig Speicher und wenig festplatte, die man aber mal nicht so eben austauschen kann. Weiterhin war wichtig was passiert nach einem Stromausfall (auf Laptoiops nicht unüblich). Für die Gesamtsoftware war eine Embedded Installation Pflicht, also nur Return drücken und nicht irgendwelche Fragen nach irgendwelches spaces oder sonstwas beantworten. Wenn der Rechner getauscht wird wegen defekt soll es möglichst einfach sein, die
db zu übertragen.
Das hat Firebird alles geleistet und man hat sich dafür entschieden. Ich würde aus heutiger Sicht sogar behaupt, das Firebird in Bezug auf die Anzahl installierter Server einen recht hohen Marktanteil hat, weil viele Leute gar nicht wissen, das man den Firebird Server im Hintergrund laufen hat. warum auch? wenn man trotz laufendem Datenbank.
bei Oracle sind übrigens auch Wartungsverträge und Supportangebote recht teuer und wenn man dafür einen kompletten Tagessatz eines Spezialisten bezahlen soll, wenn sich ein Oracle Mitarbeiter (war in wirklichkeit seit 2 Wochen mit dem Studium fertig) beim Kunden per Telefon durchsprechen lassen muss, um auch nur annähernd die mitgelieferten Tools zu bedienen, dann macht das nicht nur mir persönlich bekannte Kunden wütend. Das der Kunde den wegen unfähigkeit nach Hause geschickt hat, hat dazu geführt das der nächste Oracle Mitarbeiter dann erst 4 Wochen später kam. Ich weiss nicht worum es genau ging, aber der EDV Leiter bei dem Laden hat nicht nur in diesem Fall schlechte Erfahrungen mit Oracle gemacht, aber weil deren kaufmännische Software Oracle war, auf Oracle lief und wir für die Produktionsdaten da ran mussten, war es wichtig, das dort irgendwas eingestellt wurde, damit unsere Datenabfragen überhaupt in akzeptabler Geschwindigkeit liefen.
Nun denn, etwas ähnliches kann mit jeder anderen Plattform auch passieren, aber die Anzahl der möglichen Ansprechpartner war aufgrund des Wartungsvertrags sehr begrenzt.
Leute die was taugen sind insbesondere im Oracle Umfeld sehr teuer, dann aber auch oft Ihr Geld wert. Es gibt aber auch da sehr viele mit einem gesunden Halbwissen und wie man weiss ist der Einäugige unter den Blinden der König. das führt eben oft dazu, das man für immer noch viel Geld auf Leute trifft, die von der ganzen Materie nur begrenzt Ahnung haben und oft mehr kaputt machen als helfen.
Die Know How Entwicklung und Verfügbarkeit im Bereich Open Source Datenbanken entwickelt sich aus meiner Sicht immer noch sehr gut weiter. Wenn ein Kunden konkrete Probleme mit dem optimierer in Firebird hat und ich dann per EMail mit Arno Brinkman kommunizieren kann, der den Optimierer entwickelt, dann ist das sicher produktiver auch für meinen Kunden, der oft gar nicht formulieren kann, welches problem das ist und wie man es reproduzieren kann. Die hohen Preise bei Oracle kommen natürlich auch durch di eteuren Hobbies von Herrn Ellison zu stande, aber das sei ihm gegönnt. Ähnlich wie Bill Gates kann er nicht alles falsch gemacht haben in seinem Leben
Gruß
Holger