MS SQL-Server oder Interbase (Firebird) ?

[Ralf Eberhard]

Hallo,
wir haben bisher mit Delphi4.0 und Interbase 5.6 (Firebird 1.5).
Programme entwickelt.
Im neuen Jahr wollen wir auf Delphi 7.0 und mit ADO auf eine Datenbank zugreifen.
Aber welche sollen wir benutzen (MS-SQL-Server oder Firebird 1.5) ?
Da wir im Produktionsbereich tätig sind und Daten sehr schnell (Zeiten <= 1 sec, Anzahl Datensätze in DB > 300000)) der Maschinensteuerung übergeben werden müssen, hatten wir mit Interbase/Firebird Probleme.
Was spricht für und was gegen die entspr. DB
(auch im Hinblick auf Erlernbarkeit, Installation,Wartungsfreundlichkeit,Performance).
Unter dem Stichpunkt Wartungsfreundlichkeit war z.B. bei
Interbase eine Performancesteigerung wenn man das Tool gbak in regemäßigen Abständen ausführte. Nur dazu mußten wieder alle Programme beendet werden, die mit dieser DB connected waren, wie umständlich.

Danke.

Gruß

Ralf Eberhard

[hwoess]

Hallo Ralf,

hatte vor etwa 3 Jahren dasselbe Problem mit einer Interbase-Db und D5 mit IBX bei einem großen Kunden. Die Schnelligkeit war soweit okay, aber es lief in einem 24x7 Betrieb und so nach 2 bis 3 Tagen ging die Db immer voll in die Knie bis zum Absturz. Angeblich war die Netzwerkumgebung (diverse Hubs und Router und verschiedenste Clients mit unterschiedlicher Hardware und OS) daran schuld. Da ich dem Kunden nicht sagen konnte, er solle seine etwa 50 Pc's komplett erneuern und das Netzwerk auch gleich, blieb mir nur der Umstieg auf die MSDE. Seither läuft meine Software dort ohne Probleme durch, und das bei unveränderter Hardware.
Bin darum seitdem auch beim SQL-Server geblieben (jetzt D7/ADO) und habe das bisher noch nie bereut. Vor allem kann man ja ebenfalls kostenlos mit der MSDE (jetzt besser mit SQLExpress) starten und wenn's wirklich erforderlich ist, auf einen SQL-Server upgraden, der dann auf entsprechende Speicher- und CPU-Nutzung ausgelegt ist, umsteigen. Das geht bei Interbase/Firebird ja nicht.
Mein persönlicher Favorit ist daher auf jeden Fall der SQL-Server. Da hat es einfach mehr Manpower und die bei MS wissen natürlich am besten, wie sie diese DB in ihr OS einbinden. Außerdem habe ich mit Unix und Co nichts am Hut und daher ist diese Möglichkeit der Firebird-DB für mich höchstens Overhead.
<br>
bye,
Helmu

[Ralf Eberhard]

Hallo Helmut,
Danke für Deine Antwort.
Wieviel Zeit muß man in etwa für den Umstieg auf den
MS-SQL-Server rechnen, auch im Hinblick, daß wir Neulinge sind ?
In unseren jetzigen Projekten auf Interbase/Firebase haben wir
die SQL-Statements in Stored Procedure verpackt, so daß ich
eigentlich "nur" 2 Schwerpunkte sehen:
1. Stored Procedure auf den Syntax von MS-SQ-Server konvertieren.
2. Zuriff auf DB mittels ADO.
Oder habe ich etwas übersehen ?
Wie sieht das mit der Wartung der DB unter MS SQL-Server aus ?

Noch eine Anmerkung: die Interbase/Firebird-Fraktion hüllt sich hier in Schweigen, sind sie nicht von íhrer DB überzeugt ?

Gruß

Ralf Eberhar

[hwoess]

Hallo Ralf,

Die stored Procedures lassen sich relativ schnell umschreiben, etwas anders sieht es bei Triggern aus, da der SQL-Server keine Before-Trigger kennt, dafür aber InsteadOf-Trigger. Aufpassen muss man etwas bei Mehrplatzanwendungen, da der SQL-Server keine Multigenerationenarchitektur hat und es daher schneller zu Locks kommen kann.
Der Zugriff über ADO ist optimal, läuft ja über SQLOLEDB, das ja standardmäßig im OS integriert ist.
Bezüglich Wartung: aus meiner jetzt ganz persönlichen Sicht weniger als bei Firebird. Ich habe bei einer Firma einen SQL-Server am Laufen, der seit zweieinhalb Jahren durchläuft (auf NT4) und ohne das ich da seitdem was getan habe.
Ein wesentlicher Punkt war weiters: alleine das Online-Manual hat etwa 32 Mb, ist frei verfügbar und glänzt mit vielen praktischen Beispielen. und wenn ich mal wo hänge, in den MS-Newsforen zum SQL-Server musste ich nie länger als 24 Stunden warten, um zu einer (meist von einem MVP!) kompetenten Antwort (sprich Lösung) zu kommen.

servus,
Helmu

[Klemmo]

ich würde einfach mal sagen das die von Helmut geschilderten Probleme nicht an Interbase oder Firebird liegen, sondern an der Programmierung. Es gibt immer wieder Beispiele, wo eigene Programmierfehler (thema älteste aktive transaktion) den firebirdserver und seine Multigenerationsarchitektur lahm legen, die aber immer vermeidbar sind.

Die Performancesteigerung durch gbak deutet übrigens ganz deutlich auf genau die oben geschilderten Probleme hin.

wir haben einige Kunden, bei denen der Firebirdserver einige hunderttausend neue Datensätze pro Tag verwurstet und das rund um die Uhr, gerade wenn die Daten aus Maschinen kommen.

Mit ADO haben wir gerade mal wieder bei einem großen Kunden extreme Probleme bekommen, weil ADO zwar angeblich alles so kompatibel macht, aber das mit extrem hohem Aufwand auf dem Server erkauft. Native Zugriffe sind wesentlich performanter. Der ADO Zugriff rödelt bei jedem noch so banalen Zugriff in den Systemtabellen herum und man kann nichts machen, um das abzuschalten. Alternativ bleibt dann noch native SQL commands über ADO, aber dann kann man auf ADO auch gleich verzichten und native Komponenten einbauen.

Das Schweigen rührt daher, das die Firebird und Interbase Truppe hier meist nur die dafür vorgesehenen Foren betrachtet. Daher kann das allgemeine SQL Forum schon mal untergehen.

bezüglich CPU und Speicher: beim Superserver geht 1GB Cache pro Datenbank, das ist schon einiges. Und bei der dpa in Hamburg wird eine Multiprozessormaschine mit firebird cassic server eingesetzt, das unterstützt auch mehrere CPUs und bis zu 1 GB Cache pro User (wenn man ausreichend RAM hat). Und mit der demnächst zu erwartenen VULCAN Variante wird beides schon mal kombiniert (vulcan ist kompatibel zu firebird).

Best Regards

Holger Klemt

p.s.:
Firebird Datenbank Training pro Person ab 199 Euro
ANMELDUNG UND DETAILS: www.h-k.de/fbct/fbct.pd

[Heiko Luettge]

Ich stimme Klemme zu,<p>
das Performance-Problem wird durch den Client verursacht, der z.B. eine Transaktion nicht schliesst.<br>
Im Unterschied zum MS-Sql-Server nimmt das IB/FB sehr übel.<p>
Vor 2-3 Jahren gab es dummerweise keine einfache Möglichkeit, herauszufinden, welche Transaktion das ist. Ab der 7-er IB gibt es ja die Monitor-Tabellen.<p>
Ich persönlich ziehe IB/FB wegen der einfachen Installation , Wartung (ausser Backup und viell. gfix-Sweep über Nacht), Pflege (keine) vor. Das Dateikonzept der Datenbanken finde ich sehr einfach. Ein Backup->Restore nachts in ein eigenes Verzeichnis und ein kleiner Zettel für den Dau "Folgendes Verzeichnis sichern" reicht.<p>
Bei MS-SQL finde ich es allerdings schön, dass Foreign Keys zur Laufzeit (als mehr als ein Connect) möglich sind. Ab FB2.0 geht das dann ja auch.<br>
Ausserdem hat er hübsche Assistenten, die z.B. eine Replikation zum Kinderspie machen.
<p>
Bei IB/FB nervte allerdings das Multiprozessor-Problem bei der Superserver. Da ich die Server meist selber installiere, geht das aber (Stichwort IBAffinity)
<p>
Heik

[hwoess]

Hallo Klemmo, hallo Heiko,

ihr habt es ja schon ausgesprochen - das Problem mit offenen Transaktionen. Schlimm, wenn das durch ein instabiles Netzwerk passiert. Da kann man gar nicht so gut programmieren, um sowas zu verhindern. Meine Clients konnten sich zwar neu connecten, aber es war aus dem Log ersichtlich, wie sich das Problem aufgeschaukelt hat. Und ich fand da einfach keine Lösung. Habe damals sogar mit Thomas bei einem Bierchen darüber diskutiert, aber wenn etwas nur beim Kunden auftritt und im Büro überhaupt nicht reproduzierbar ist, das zieht einem schon den Nerv. War der einzige Grund warum ich damals dann zum SQL-Server wechselte, der dort seitdem bei gleichem Netzwerk problemlos seinen Dienst verrichtet. Ansonsten wäre ich wahrscheinlich auch Firebird-Benutzer.

bye,
Helmu

[Klemmo]

mit tools wie unserem IBMonitor findet man auch solche Transaktionen in Firebird und noch einiges mehr.

Aber so mancher blick in die Statistik lässt mich erschaudern, wenn man sieht, das die älteste aktive Transaktion sich überhaupt nicht ändert. Aber Heiko und ich kennen eben das Problem mit der ältesten aktiven Transaktion und können das in der eigenen Programmierung auch problemlos umgehen. Es erschliesst sich aber nicht jedem Programmierer intuitiv.

Ich arbeite gerade an einem großeren Dokuprojekt zu Firebird und da wird auch das Thema sein. In welcher Form und wo das erscheinen wird, ist noch nicht ganz klar, aber es wird auf jeden Fall in absehbarer Zeit ein Buch geben, was ganz klar als für Einsteiger und Umsteiger gedacht ist und auch die Probleme in der Reihenfolge des Auftretens behandelt.

Wenn man dem Einsteiger sagt, das liegt an der MGA (Multi Generational Architecture) ist das zwar nett, hilft aber nicht wirklich weiter, wenn man die Ursache nicht im eigenen Code lokalisieren kann.

Holger

www.ibexpert.co

[hwoess]

Ich glaube ja, dass man mit den Tools solche Transaktionen findet, allerdings hilft einem das nicht weiter, wenn der Connect aufgrund von Störungen im Netzwerk abbricht. Das hat mit der Programmierung nichts zu tun. Der springende Punkt ist für mich, wie der Server mit sowas umgeht. Und wenn er das von selber nicht auflösen kann, ist es nur eine Frage der Zeit, bis nichts mehr geht. Oder gibt es dieses Problem jetzt definitiv nicht mehr?
Und falls das auf mich bezogen sein sollte, ich habe dem Einsteiger nirgendwo gesagt, dass das an der MGA liegt. Im Gegenteil, ich habe ihn darauf hingewiesen, das es beim SQL-Server aufgrund dieser fehlenden Architektur schneller zu Deadlocks kommen kann.
Mach mal das Buch/die Doku fertig, dann werde ich mir das zulegen und nochmal einen Versuch mit Firebird starten :-)

bye,
Helmu

[Klemmo]

Die Aussage mit der MGA habe ich einfach mal so zitiert, ist so immer wieder in der Interbase Newsgroups zu lesen, also nicht von dir zitiert.

Das mit den abbrechenden Connections ist bekannt, beim classic server noch immer ein Problem, was nicht ganz gelöst ist, aber der ist ja eh noch in arbeit.

Beim superserver unter windows kenn ich das problem kaum noch, obwohl ich auch einige Server über das internet direkt betreibe und da sind abbrechende Verbindungen gang und gebe.

Das kann in anderen Umgebungen aber wieder anders aussehen, aber wie schon gesagt, bei mir taucht das Problem mit der aktuellen fb152 nicht mehr auf. Nach einem timeout sind deren connections auch nicht mehr sichtbar.

Früher war das Problem mit Interbase sehr oft aufgetreten, wenn man zum beispiel über cisco isdn router ging, aber das kommt mittlerweile relativ selten vor.

Zum Buch melde ich mich dann sicherlich noch

Holger
www.ibexpert.co

[Heiko Luettge]

Hallo hwoess,<p>
eine Transaktion bleibt nicht offen, wenn das Netz zusammenbricht. Der Server beendet die Transaktion nach einer gwissen Zeit (unter IB6 waren das glaube ich 3 Minuten). <br>Was der Client macht, ist ein anderes Problem.
<p>
Unterm Superserver werden dann auch die Connections (Threads) geschlossen, beim Classic kam es wohl vor, dass die Prozesse macnhmal weiterliefen.
<p>
Ich habe in der Produktion einige solcher "Supernetzwerke" , es gibt keine Probleme (unter fb1.5).
<p>
Heik

[hwoess]

Servus Heiko,

ich hatte das Problem ja wie gesagt mit dem Interbase 6.0.X, wobei die Clients von einem eigenen Kontrollprogramm bei einem Hänger geschlossen und neu gestartet wurden. Nur mit dem Server kam ich einfach nicht klar. Es könnte jetzt auch anders laufen. Aber meine Erfahrungen der letzten Jahre mit dem SQL-Server waren stets positiv, sodass ich aus meiner Sicht einfach eine Empfehlung dafür aussprechen kann, so wie du es aufgrund praktischer Erfahrungen jetzt auch für Firebird machst. Für Ralf ist das insofern schön, da er so gesehen eigentlich keine falsche Wahl treffen kann.

bye,
Helmu

[Ralf Eberhard]

Hallo,
erstmal vielen Dank für die rege Beteiligung, habe mit Interesse eure Beiträge gelauscht.
Für mich stellt sich die entscheidene Frage: welcher DB-Server fügt schneller Daten ein (Insert, Update) und liest die Daten
schneller aus einer großen Datenmenge aus.
(z.B. muß aus einer Datenmenge von ca. 300000 Datensätzen
( 1 Datensatz hat 40 Spalten)
1000 Dimensionsgrößen(Länge,Breite,Höhe) sortiert ausgelesen werden
und einer Fremdmaschine ("Blackbox") über Socket übergeben werden. Am besten in einer Zeit < 2sec.
Der Auswahlgenerator. welche Dimensionen ausgegeben werden dürfen, ist zu komplex, um Ihn an dieser Stelle näher darstellen zu können, ein einfacher Select-Befehl reicht nicht.
Welches DB-System läßt dabei die Ohren eher hängen ?
(Kundenvorgabe: Der Datenbank-Server bekommt keinen eigenen Rechner, alles soll am besten ein Rechner machen...)
Nebenbei angemerkt muß die Datenbank auch immer mit neuen Daten gefüttert werden.

Also mein Problem ist unter anderem : in einem sehr kleinen Zeitintervall müssen aus einer großen Menge Daten einige viele Ergebnisdaten zurückgegeben werden.

Gruß

Ralf Eberhar

[Heiko Luettge]

Hallo Ralf,<p>
das kannst du nur durch einen Test mit realen Daten machen.<br>
Ich sehen hier keine Möglichkeit, zu sagen, <br>
"Ja, der FB1.5, er schafft das in 1.3 sec".<p>
Wenn ein normales Select nicht reicht, muss als ne SP ran. Das können beide ganz gut. <br>
Kein eigener Rechner -> geht auch bei beiden
<p>
Zu der Geschwindigkeitsfrage muss natürlich auch berücksichtigt werden, was an dem Rechner noch so gemacht wird (Beim CD-Brennen werden die 2 sec wohl nicht erreciht )
<p>
Heik

[hwoess]

Man sollte vielleicht auch nicht übersehen, auf eine konstante Leistung zu testen. Wenn FB doppelt so schnell ist, aber nach 2 Stunden aus irgendeinem Grund irgend ein GarbageCollect machen muss und dann für 5 Minuten keine Daten liefert, wäre das auch fatal. Hey, bevor ihr über mich herfällt, das ist nur mal ein theoretischer Denkanstoss, soll nicht heissen, dass sowas bei FB wirklich passiert, könnte genausogut umgekehrt sein.
Ausserdem hängen zB. Inserts geschwindigkeitsmäßig auch von der Indexverwaltung ab, ohne die es da sicher nicht abgehen wird. Und da ist dann die Frage, was passiert, wenn der Baum umsortiert werden muss?
Also ohne Praxistest würde ich mir nicht zutrauen, eine Aussage zu treffen.
Aber abgesehen davon wundere ich mich schon, dass eine Firma, die schnelle Reaktionszeiten haben will, dann keinen eigenen Server für die DB hinstellt. Bei sowas würde ich als Verantwortlicher gleich mal abwinken. Na ja, vielleicht ist der neue Mercedes des Chefs etwas teuerer als geplant ausgefallen, da muss man dann woanders sparen ;-))

Grüße an alle,
Helmu