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

[IBExpert]

Zitat:

Zitat von alzaimar

Noch heine Anekdote:
...

da würde mich schon mal die datenbank dazu interesssieren, darfst du mir gerne schicken wenn das erlaubt ist.

aber mal ganz am rand:

truncate und delete from ist was völlig anderes, bei truncate geht kein rollback und keine Einschränkung
mit where o.ä.

Wenn du ein truncate als Trick willst, dann geht das auch mit firebird. Bau deine Foreign keys um in
Trigger mit Execute statements, dann sind da keine referenzen drin und du kannst jederzeit die
komplette tabelle löschen, obwohl die im Trigger benutzt wird (wenn auch dann erst zur Laufzeit
des Triggers erkannt wird das die Tabelle ja nun mal nicht da ist und du eben dann die Exception
bekommst). (Prozeduren müssen dann auch auf execute statement umgebaut werden.

Per prozedur solltest du dir vorher noch die Metadaten der Tabellen zusammenbauen und merken.
Dann DROP TABLE und ggf. gleich per execute statement aus dem gemerkten metadaten wieder erzeugen.
Alternativ speicherst du den Tabellen quelltext einfach in einem Blob udn holst den bei bedarf wieder
raus.

Drop table habe ich letzte woche mit einer 60GB Datenbank auf einer Tabelle darin mit ca 25 GB gemacht,
ca. dauerte weniger als 5 Sekunden. Wenn aber Referenzen da sind, dann geht das eben nicht mit Drop
Table, es sei denn man nimmt o.a. Weg.

So eine Datenbank aufzubauen ist kein erheblicher Mehraufwand, aber damit hast du dann ziemlich sicher
kraut und rüben in den Daten, weil eben die Konsistenzen der Datenbank auch mal weg sein können.

ich frag mich auch was MSSQL beim truncate macht wenn foreign keys da sind? vielleicht weisst du das ja
(ignorieren wäre die blödeste Lösung, aber man weiss ja nie).

Ein Foreign Key ist nichts anderes als eine Systemtrigger mit Index auf der Tabelle. Wenn du das per execute
statement in deine eigenen Trigger einbaust macht das kaum einen Unterschied.
Der Vorteil ist das dann eben alles möglich ist was du in deiner Implementation haben möchtest
Der Nachteil ist das dann eben alles möglich ist was du in deiner Implementation vergessen hast zu verbieten
Sogenannte "Weiche Foreign keys" sind damit aber möglich (nur dann prüfen wenn USER<>SYSDBA ist oder was auch
immer).

Die Laufzeit vom Delete wird immer wieder bei Firebird kritisiert, aber in der Realität muss man eben wissen,
das zu jedem Record eine neue Recordversion angelegt wird, die dann das Löschkennzeichen hat und den Vermerk,
welche Transaktion das gemacht hat. Wenn irgendwas schief läuft und die Transaktion eben noch aktiv ist und
nicht committed wird die bei nächsten Öffnen der DB auf Rollback gesetzt. Damit sind alle Records wieder da!
Weil eben der Commit auf dem Delete nicht durchlief. Und du sogar mit der lesenden Transaktion eine
Transaktionsnummer brauchst, weil die nämlich ggf erforderlich ist, um Daten, die von anderen Transaktionen
schon gelöscht wurden, trotzdem noch die für deine Transaktion weiterhin sichtbaren Records anzuzeigen und
zwar ohne Transaktionslog und anderen Schnock Schnack.

Das Verhalten ist von DB zu DB verschieden. Ich hab schon so manche FB DB gesehen ohne Foreign Key, ohne
Primary key, halt nur hier und da mal einen Unique index und fertig. Keine Prozeduren, Trigger maximal
für IDs usw. Wenn du deine DB so aufbaust wirst du auch mit drop und create keine Probleme haben, geht
schnell, leider aber auch wenn was nicht ganz zuende gedacht ist. Das povoziert eben die Fehler zur
Laufzeit und die sind am schwierigsten zu finden.

Velleicht schreib ich mal wieder genau zu dem Thema was für den Entwickler .....

[IBExpert]

Zitat:

Zitat von alzaimar

Noch heine 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.

ahch so, first 100 ist dirn, hatte ich gerade übersehen

Hängt mehr oder weniger mit der Auflösungsreihenfolge zusammen.
probier doch mal ob das mit rows 1 to 100 am ende auch so ist
(ist eine andere Syntax, wird aber auch anders behandelt)

[alzaimar]

Hi IBExpert.
Die von Dir beschriebenen 'best practices' sind sehr interessant, ein kleines Beispiel wäre allerdings noch besser, vor allen Dingen

Zitat:

Zitat von IBExpert

Zitat:

Zitat von alzaimar

Noch heine Anekdote:

Hängt mehr oder weniger mit der Auflösungsreihenfolge zusammen.

ich habe die joins auch umsortiert, brachte keinen Erfolg.

Die Query, die einen offensichtlichen Bug von Firebird zeigt, liefert genau dann korrekte Ergebnisse, wenn ein bestimmtes Feld der VIEW (das ich gar nicht benötige) mit in die Auswahl genommen wird.

Die DB hat 300MB, ich könnte sie dir per RAR zukommen lassen, wenn Du magst (schick mal ne Mail-Adresse per PN). Ich möchte scheinbar unbeteiligte Daten nicht entfernen, da dies zu Seiteneffekten führen könnte, die den Bug wieder unsichtbar machen.

Mittlerweile hat sich mein 'Ärger' auch etwas gelegt, denn die DB (nicht von mir) war mit kaskadierenden DELETE-Triggern übersäht, z.T. auch noch quasi rekursiv (DELETE-Trigger auf Tabelle A löscht aus B und der DELETE-Trigger von B löscht in A, toll).

Mittlerweile scheint Firebird doch nicht so langsam, zumindest was DELETE und INSERT anbelangt, zumindest ist mein Kaffeekonsum nun wieder auf 'normal'.

Ärgerlich ist derzeit nur noch, das FB bei offenen Transaktionen immer langsamer wird. Ich habe eine Anwendung 'A', die irgendwo eine offene Transaktion hat. Ich bin mir fast sicher, das es nur eine offene Query (DBExpress) ist. Na jedenfalls wird Anwendung 'B', die in die Datenbank schreibt, immer langsamer. Das nervt. Ist aber vermutlich genauso eine Gehirnabsenkung des DB-Erstellers. Irgendwo.

[mjustin]

Zitat:

Zitat von alzaimar

Ärgerlich ist derzeit nur noch, das FB bei offenen Transaktionen immer langsamer wird. Ich habe eine Anwendung 'A', die irgendwo eine offene Transaktion hat. Ich bin mir fast sicher, das es nur eine offene Query (DBExpress) ist. Na jedenfalls wird Anwendung 'B', die in die Datenbank schreibt, immer langsamer.

Welche Statements als Übeltäter in Frage kommen, kann man mit den Monitoring-Funktionen ja glücklicherweise schnell kontrollieren.

Cheers,

[IBExpert]

Zitat:

Zitat von alzaimar

Hi IBExpert.
Die von Dir beschriebenen 'best practices' sind sehr interessant, ein kleines Beispiel wäre allerdings noch besser, vor allen Dingen
...
Die DB hat 300MB, ich könnte sie dir per RAR zukommen lassen, wenn Du magst (schick mal ne Mail-Adresse per PN). Ich möchte scheinbar unbeteiligte Daten nicht entfernen, da dies zu Seiteneffekten führen könnte, die den Bug wieder unsichtbar machen.
...

schick mir doch eben eine email an hklemt at ibexpert.biz, ich schicke dir dann einen ftp account.

wenn du mit fb21 arbeitest kannst du ja mal einen blick in die MON$ Tabellen werfen, da ist jede offene Transaktion erkennbar, das ist dann manchmal ein guter Start um im Quälcode die stellen zu identifizieren, die da nicht ganz sauber sind. Ich mache oft Workshops bei Kunden bei denen genau das thema ist und ich hab bisher immer die Ursache in einem Programmierfehler lokalisiert, auch wenn man Stein und Bein geschworen hat das das alles super sauber unter Kontrolle ist usw. Bei älteren FB Versionen hilft dir ggf der IBExpertSQLMonitor um das zu finden.

[alzaimar]

Ich habe mir ein Trial-Monitoring Tool geholt, was wirklich hübsch ist, aber nur Basis-funktionalität bietet. Wie komme ich also an das Statement, das mir eine bestimmte alte Transaktion offen hält? Klar, im Quelltext nachschauen. Aber wenn es eine fertige Query dafür gäbe, wär das Klasse. Ich mache dafür mal einen neuen Thread auf, also bitte nicht antworten.