Zickiges Firebird und lahmen tut es auch (oder bin ich das?)

[alzaimar]

Hi

Kann es sein, das sich Firebird manchmal blöd verhält? Hier meine Meckerliste:

1. Ich wollte aus einer Tabelle 100.000 Zeilen per DELETE löschen. Das dauerte mehrere Minuten, da viele andere Tabellen FK-Beziehungen mit der zu löschenden hatten. Gut, man kann sich einen Kaffee holen und das wird auch noch bezahlt, aber ist schon komisch. Ein 'TRUNCATE TABLE', wie in MSSQL z.B. scheint es nicht zu geben. Aber unabhängig davon ist dies eine Performance-Schwachstelle. Andere RDBMS sind da nicht so lahm.

2. Das Umbenennen von Tabellen ist nur mit Klimmzügen möglich und wird eigentlich nicht unterstützt.

3. Das Löschen von Tabellen, die irgendwie noch benutzt werden, ist nicht möglich. Mag ja sein, das das ein Feature ist, aber wenn ich als Programmierer weiss, was ich tue, sollte mir ein RDBMS (oder liegt das an IBExpert?) keine Steine in den Weg legen. Das scheint mir hier jedoch ein kleiner Designfehler zu sein, der imho leicht zu beheben wäre. Ich wollte eigentlich o.g. Tabelle einfach entfernen und neu erstellen, da ich wusste, das es keine aktiven FK gibt.

4. Jeder Pups ist in einer eigenen Transaktion, sogar eine Query. Der tiefere Sinn erschließt sich mir nicht. Gut, kann man sich dran gewöhnen, ist aber eine Fehlerquelle mehr und nervig (für verbohrte S*cke wie mich ).

Kurzum: Die anfängliche Begeisterung ist einer ehem ambivalenten Verhältnis zu Firebird gewichen.

Mein Fazit bisher: Nett, einfach, aber umständlich. Effektiv entwickeln lässt sich damit in meinen Augen nicht. Auch ist die Unterstütztung von Zusatztools (Profiler, Monitor etc.) beschränkt, wenn man nicht bereit ist, Geld auszugeben.

Wie seht ihr das? Gibt es noch mehr Fallstricke? Oder Schwachstellen? Sind das Anfängerfehler meinerseits oder ist Firebird nun mal so?

Eigentlich möchte ich FB unbedingt pushen und als Standard in der Firma, für die ich gerade arbeite, manifestieren. Aber so mach ich mich zum Horst.

[mkinzler]

Zitat:

1. Ich wollte aus einer Tabelle 100.000 Zeilen per DELETE löschen. Das dauerte mehrere Minuten, da viele andere Tabellen FK-Beziehungen mit der zu löschenden hatten. Gut, man kann sich einen Kaffee holen und das wird auch noch bezahlt, aber ist schon komisch. Ein 'TRUNCATE TABLE', wie in MSSQL z.B. scheint es nicht zu geben. Aber unabhängig davon ist dies eine Performance-Schwachstelle. Andere RDBMS sind da nicht so lahm.

Da FB nicht mit Transaktion Log arbeiten, bruacht man auch kein Befehl, der dieses abschaltet. Was für eine Delete Rule wird verwendet? Wieviel Benutzer waren zu diesem Zeitpunkt aktiv?

Zitat:

2. Das Umbenennen von Tabellen ist nur mit Klimmzügen möglich und wird eigentlich nicht unterstützt.

Würde ich nicht als Problem betrachten

Zitat:

3. Das Löschen von Tabellen, die irgendwie noch benutzt werden, ist nicht möglich. Mag ja sein, das das ein Feature ist, aber wenn ich als Programmierer weiss, was ich tue, sollte mir ein RDBMS (oder liegt das an IBExpert?) keine Steine in den Weg legen. Das scheint mir hier jedoch ein kleiner Designfehler zu sein, der imho leicht zu beheben wäre. Ich wollte eigentlich o.g. Tabelle einfach entfernen und neu erstellen, da ich wusste, das es keine aktiven FK gibt.

Andere Benutzer aktiv? Singleusermode getestet?

Zitat:

4. Jeder Pups ist in einer eigenen Transaktion, sogar eine Query. Der tiefere Sinn erschließt sich mir nicht. Gut, kann man sich dran gewöhnen, ist aber eine Fehlerquelle mehr und nervig (für verbohrte S*cke wie mich Stupid ).

Liegt dann aber an den Zugriffskomponenten

[Hansa]

Zitat von alzaimar:

1. Ich wollte aus einer Tabelle 100.000 Zeilen per DELETE löschen. Das dauerte mehrere Minuten, da viele andere Tabellen FK-Beziehungen mit der zu löschenden hatten.

Wieviele Datensätze sind denn insgesamt betroffen ? Also, wieviele Foreign DS hängen an den 100.000 ?

[hanspeter]

Zitat von alzaimar:

Hi

Kann es sein, das sich Firebird manchmal blöd verhält? Hier meine Meckerliste:

Zu 1.
Mit etwas mehr Aufwand läßt sich das sicher beschleunigen. Kommt es öfters vor, dann ist auch eine SP möglich.
Man kann z.B. das kaskadierende Löschen selbst auflösen. Erst Records in abhängigen Datein löschen. Das temporäre Löschen der Indexdatei könnte einen Performancegewinn bringen, da nicht nach jedem gelöschten Satz der Index bearbeitet werden muss.
Jeder Pub eine Transaction? das klingt nach automatischer Transaction und jedes Delete in einer Transaction?
Abhängig vom Zugriffssystem kann man eine Transaction explizit öffnen und wieder schließen. Also alle Löschvorgänge im Kontext einer Transaction ablaufen lassen.

zu. 2
Es müßten dann ja auch noch FK, Trigger und SP angepasst werden. Kann das MSQL?
Besonderst ärgerlich ist das, wenn wie von Version 2.0 zu 2.1 plötzlich ohne Vorankündigung neue reservierte Worte eingeführt werden (START) und die Datenbank damit nicht mehr portierbar ist.

Wenn man die Liste noch fortschreiben will, dann ist die Unterstützung in Net noch ein Manko.
Der Provider sind noch im Betastatum und wird eher zögerlich weiterentwickelt.

Der DDX Driver für VS2008 ist ein wenig störrisch:
Ansonsten ist die Datenbank eigentlich ganz brauchbar und im Vergleich zu anderen Monstern eher schlank.

Mit der Personalversion von IBExpert kommt man weit. Richtig ist das für eine vernünftige Administration für den Entwickler die kostenpflichtige Version notwendig ist.

Gruß
Peter

[alzaimar]

Hi, zu euren Fragen:
Es ist nur eine Verbindung aktiv, nämlich IBExpert. Es handelt sich um die gesamte Tabelle, dessen Inhalt einfach gelöscht werden sollte.

Zitat von mkinzler:

Was für eine Delete Rule wird verwendet?

Keine Ahnung, wo kann man das verändern?

Zitat von mkinzler:

Zitat:

2. Das Umbenennen von Tabellen ist nur mit Klimmzügen möglich und wird eigentlich nicht unterstützt.

Würde ich nicht als Problem betrachten

Ich schon, denn ich will während des Designs ab und an machen.

Zitat von mkinzler:

Zitat:

3. Das Löschen von Tabellen ... ist nicht möglich.

Andere Benutzer aktiv? Singleusermode getestet?

Nein und Nein. Die Tabelle kann nicht gelöscht werden, da sie von SP verwendet wird. Vielleicht meckert nur IBExpert, nervt aber.

Zitat von mkinzler:

Zitat:

4. Jeder Pups ist in einer eigenen Transaktion, sogar eine Query. ....

Liegt dann aber an den Zugriffskomponenten

Und an IBExpert.... Stimmt DBExpress macht das nicht, aber die Kompos sind (für mich) eh nicht zu gebrauchen.

@Hansa: Auch so an die 100k Datensätze. Trotzdem scheint das schlecht umgesetzt zu sein. FB prüft die FK offensichtlich für jeden Record einzeln, anstatt sich mal die Mühe zu machen, zunächst eine Kandidatenliste zu erstellen, die in einem Abwasch getestet wird.

@hanspeter: Klar, mit Klimmzügen geht alles. Aber das hier ist Basisfunktionalität (imho) bzw. tägliche Arbeit und wenn ich mir jedesmal einen abbrechen muss, um eine Tabelle zu leeren, dann wechsle ich doch lieber zu einem anderen System.

Zitat von hanspeter:

Abhängig vom Zugriffssystem kann man eine Transaction explizit öffnen und wieder schließen. Also alle Löschvorgänge im Kontext einer Transaction ablaufen lassen.

Ich habe in IBExpert 'DELETE FROM TABELLE' eingetippt. Mehr nicht.

Zitat von hanspeter:

zu. 2 ...Es müßten dann ja auch noch FK, Trigger und SP angepasst werden. Kann das MSQL?

Jupp.

Ich dachte mir, das FB kein Schrott ist, und es teilweise an mir/Zugriffskomponenten liegt. Unterm Strich ist die *Arbeit* mit dem Teil jedoch extrem verbesserungswürdig...

Ich habe gleich noch einen Korken, für den ich einen separaten Thread aufmache

[hanspeter]

Kleiner Tip.
Für solche Aufgaben wie Tabelle löschen oder die ganze Datenbank leeren hat IBExpert einen eigenen Menüpunkt.

Ich setze FB in mehreren großen Applikationen ein und die Probleme halten sich eher in Grenzen.
Zumindest MSQL erschien uns bei einschlägigen Tests als aufwendiger.
Probleme entstehen jetzt eher beim Übergang zu Net, egal ob Prism oder C#, da die Unterstützung vpn MSQL einfach
besser ist.

Gruß
Peter

[omata]

Was ist den MSQL? Ist das aus der OLAP-Technik für mehrdimensionale Abfragen? Oder meinst du MSSQL?

[mquadrat]

Zitat von alzaimar:

1. Ich wollte aus einer Tabelle 100.000 Zeilen per DELETE löschen. Das dauerte mehrere Minuten, da viele andere Tabellen FK-Beziehungen mit der zu löschenden hatten. Gut, man kann sich einen Kaffee holen und das wird auch noch bezahlt, aber ist schon komisch. Ein 'TRUNCATE TABLE', wie in MSSQL z.B. scheint es nicht zu geben. Aber unabhängig davon ist dies eine Performance-Schwachstelle. Andere RDBMS sind da nicht so lahm.

Da kann ich wenig zu sagen, da wir keine festen FK Relationen verwenden, sondern das alles über menschliche Logik machen.

Zitat:

2. Das Umbenennen von Tabellen ist nur mit Klimmzügen möglich und wird eigentlich nicht unterstützt.

Hab ich ehrlich gesagt noch nie probiert. Müsste aber über die System-Tables gehen, oder? Dann müsste man allerdings alle abhängigen Stored-Procedures neu compilieren, oder nicht? *grübel*

Zitat:

3. Das Löschen von Tabellen, die irgendwie noch benutzt werden, ist nicht möglich. Mag ja sein, das das ein Feature ist, aber wenn ich als Programmierer weiss, was ich tue, sollte mir ein RDBMS (oder liegt das an IBExpert?) keine Steine in den Weg legen.

Das find ich nun wieder gut. Hindert Kollegen dran, einem die Tabelle, die man unbedingt braucht unterm Hintern weg zu löschen

Zitat:

4. Jeder Pups ist in einer eigenen Transaktion, sogar eine Query. Der tiefere Sinn erschließt sich mir nicht. Gut, kann man sich dran gewöhnen, ist aber eine Fehlerquelle mehr und nervig (für verbohrte S*cke wie mich ).

Naja, entweder man nimmt ein RDBMS mit Transaktionen oder man lässt. Ein Mittelding wäre schlecht möglich. Hier verstehe ich das "sogar eine Query" nicht ganz. Gerade da brauch ich's doch um mich z.B. for Dirty Reads zu schützen.

[Elvis]

Firebirds Vorteil liegt darin, dass es sehr schlank und X platform ist. Außerdem finde ich es schon praktisch, dass es anonyme Blöcke gibt, die wie eine normale Query genutzt werden können.
Der Nachteil ist, dass es vieles schlechtweg gar nicht kann, oder nur um 5 Ecken und 7 Kanten...

Das Langsamwerden kann sich mit der Art wie FB Transaktionen verwaltet erklären. Man sollte NIEMALS eine Transaktion länger auflassen als nötig. Ganz einfach weil FB sicherstellt, dass diese Transaktion weiterhin die DB zum Zeitpunkt vom Transaktionsstart sieht. Selbst wenn zwischendurch viel geändert wurde.
FB löst das indem Records versioniert werden. Aber genau hier entsteht die Performancefalle, da er sich, mit etwas pech, an 10.000 Versionen pro Record entlanghangeln muss wenn du in deiner Transaktion etwas löschst.
Gutes Beispiel sind Connectionpools. Wenn ein Service seit 3 Tagen eine Transaktion duch eine Connection im Pool aufhält, dann sieht diese Transaktion den Zustand von vor 3 Tagen. Jede Änderung seitdem erzeugte eine neue Version des Records und das bremst die Zugriffe auf diese Tabelle aus.
Beendet man diese andauernde Transkation wird es nicht lange dauern und FB wird alleine aufräumen und die Tabelle wieder neu so anordnen, dass sie möglichst performant genutzt werden kann.
FB ist relativ einfach zu bedienen, weil man in wenigen Tagen den kompletten Umfang erfassen kann. Aber Fallen gibt esfür viele, die von anderen DBMS' kommen (ich hebe hier mal selbst den Arm ), da Tansaktionen und Recordversionen doch anders gehandhabt werden und auch eine gewissen Sorgfalt benötigen.

Momentan können in manchen Situationen/Anwendungsgebieten die teilweise großen Implementierungslücken in FB überwiegen.
FB 3 wird einiges neues auf den Tisch bringen, aber bis dahin ist es IMHO nur für den embedded Betrieb interessant (Wobei SqLite da besser punktet). Oder da wo man ein DBMS braucht, was komplett ohne Admin klar kommt und was nicht skalieren können muss.
Das klingt vllt strenger als es gemeint ist, denn wirklich skalieren können die wenigsten Apps, selbst wenn sie Multi-Tier Designs sind. Und viele Designs für skalierende Apps können eine schlecht/gar nicht skalierende DB oftmals besser verschmerzen als man denkt.
Wir werden zum Beispiel zukünftig stärker als bisher durch verteilte Caches skalieren und somit die doch extremen krassen Kosten von Cluster-fähigen DBMS' ignorieren können.
Das DBMS ist dann nur noch ein Mittel der Wahl um Daten einfach ablegen und auslesen zu können (wenn der Cluster aus Caches es nicht schon vorhält)

[alzaimar]

Noch eine Anekdote:
Folgende Query liefert 1000 Datensätze:

SQL-Code:

select * from View_A a 
  join Table_B b on a.ID = B.ID
  Join Table_C c on c.ID = B.CID

Wohingegen diese Query keine einzige Zeile liefert (die where-klausel wurde *nicht* verändert!);

SQL-Code:

select a.Field1, b.Field2, c.Field3 
from View_A a 
  join Table_B b on a.ID = B.ID
  Join Table_C c on c.ID = B.CID

Die View enthält ein 'FIRST 100', ansonsten JOINt sie sich durch die Gegend, nichts Dolles.