https://www.firebirdsql.org/en/firebird-5-0-0-beta1/
Nachtrag: bei den paar Änderungen ist das eher eine 4.1.
Firebird 5 geht in den Beta-Test
Moderator: martin.koeditz
Hallo.
"[22.12.31] Ein frohes Jahr 2023 für alle! Was können wir im neuen Jahr erwarten?
2.022 war sicherlich ein einzigartiges Jahr, um es vorsichtig auszudrücken!
Wenigstens hat sich die Pandemie ein wenig beruhigt und wir waren in der Lage, persönliche Veranstaltungen wieder aufzunehmen, einschließlich des Firebird Developers Day!
Und gerade als wir dachten, dass die Dinge besser werden würden, kam die Nachricht von einem Krieg zwischen Russland und der Ukraine! In einer globalisierten Welt hat ein solches Ereignis eine Reihe von Konsequenzen für alle. Einige der Kernentwickler von Firebird leben in diesen beiden Ländern und obwohl wir im Laufe des Jahres drei kleinere Versionen herausgebracht haben (4.0.2, 3.0.9 und 3.0.10), hat der Krieg die Entwicklungsgeschwindigkeit des Projekts sowohl psychologisch als auch finanziell beeinträchtigt (aufgrund der Finanzblockade, unter der Russland leidet, was es sehr schwierig macht, den russischen Kernentwicklern ihre Gehälter zu schicken). Aus diesem Grund wurde Firebird 5 beta 1, das bereits hätte erscheinen sollen, auf das erste Quartal 2.023 verschoben.
Natürlich können wir alle Firebird-Benutzer helfen, indem wir weiterhin einen finanziellen Beitrag zum Projekt leisten, entweder durch Spenden oder durch eine Mitgliedschaft in der Firebird Foundation. Aber es gibt auch eine andere Möglichkeit, einen Beitrag zu leisten: indem man Firebird-Entwickler wird! Es ist Jahre her, dass wir einen neuen Kernentwickler in das Projekt aufgenommen haben. Natürlich ist es keine leichte Aufgabe, schließlich muss man den Projektcode verstehen, bevor man Änderungen vornimmt, aber es ist alles andere als eine unmögliche Aufgabe! Der Tipp ist, mit etwas Kleinem und sehr Speziellem anzufangen, zum Beispiel mit der Lösung eines Fehlers. Die fb-devel Liste kann eine Quelle der Hilfe für diejenigen sein, die anfangen, sich mit dem Firebird Code zu beschäftigen und konzeptionelle oder Code-Verständnis-Zweifel haben, da alle Kernentwickler des Projekts daran teilnehmen.
2.023 wird ein Jahr der Herausforderungen sein, aber was war es nicht? Hier bei FireBase werde ich mich weiterhin der Erweiterung des Firebird Wissens und der Nutzung widmen, qualitativ hochwertige technische Inhalte, Support, Rabatte auf Partnerprodukte anbieten und natürlich die 20. Ausgabe der FDD vorbereiten - wahrscheinlich die am längsten laufende I.T.-Veranstaltung der Welt!
Ein großartiges neues Jahr für Sie alle!
Dmitry Yemanov hat gerade die Firebird RoadMap aktualisiert."
Autor: Carlos H. Cantu
Quelle: https://www.firebase.com.br/noticias.php?id=3278
Übersetzt aus dem Portugiesischem mit https://www.deepl.com/translator (kostenlose Version)
Viele Grüße
Gerd
"[22.12.31] Ein frohes Jahr 2023 für alle! Was können wir im neuen Jahr erwarten?
2.022 war sicherlich ein einzigartiges Jahr, um es vorsichtig auszudrücken!
Wenigstens hat sich die Pandemie ein wenig beruhigt und wir waren in der Lage, persönliche Veranstaltungen wieder aufzunehmen, einschließlich des Firebird Developers Day!
Und gerade als wir dachten, dass die Dinge besser werden würden, kam die Nachricht von einem Krieg zwischen Russland und der Ukraine! In einer globalisierten Welt hat ein solches Ereignis eine Reihe von Konsequenzen für alle. Einige der Kernentwickler von Firebird leben in diesen beiden Ländern und obwohl wir im Laufe des Jahres drei kleinere Versionen herausgebracht haben (4.0.2, 3.0.9 und 3.0.10), hat der Krieg die Entwicklungsgeschwindigkeit des Projekts sowohl psychologisch als auch finanziell beeinträchtigt (aufgrund der Finanzblockade, unter der Russland leidet, was es sehr schwierig macht, den russischen Kernentwicklern ihre Gehälter zu schicken). Aus diesem Grund wurde Firebird 5 beta 1, das bereits hätte erscheinen sollen, auf das erste Quartal 2.023 verschoben.
Natürlich können wir alle Firebird-Benutzer helfen, indem wir weiterhin einen finanziellen Beitrag zum Projekt leisten, entweder durch Spenden oder durch eine Mitgliedschaft in der Firebird Foundation. Aber es gibt auch eine andere Möglichkeit, einen Beitrag zu leisten: indem man Firebird-Entwickler wird! Es ist Jahre her, dass wir einen neuen Kernentwickler in das Projekt aufgenommen haben. Natürlich ist es keine leichte Aufgabe, schließlich muss man den Projektcode verstehen, bevor man Änderungen vornimmt, aber es ist alles andere als eine unmögliche Aufgabe! Der Tipp ist, mit etwas Kleinem und sehr Speziellem anzufangen, zum Beispiel mit der Lösung eines Fehlers. Die fb-devel Liste kann eine Quelle der Hilfe für diejenigen sein, die anfangen, sich mit dem Firebird Code zu beschäftigen und konzeptionelle oder Code-Verständnis-Zweifel haben, da alle Kernentwickler des Projekts daran teilnehmen.
2.023 wird ein Jahr der Herausforderungen sein, aber was war es nicht? Hier bei FireBase werde ich mich weiterhin der Erweiterung des Firebird Wissens und der Nutzung widmen, qualitativ hochwertige technische Inhalte, Support, Rabatte auf Partnerprodukte anbieten und natürlich die 20. Ausgabe der FDD vorbereiten - wahrscheinlich die am längsten laufende I.T.-Veranstaltung der Welt!
Ein großartiges neues Jahr für Sie alle!
Dmitry Yemanov hat gerade die Firebird RoadMap aktualisiert."
Autor: Carlos H. Cantu
Quelle: https://www.firebase.com.br/noticias.php?id=3278
Übersetzt aus dem Portugiesischem mit https://www.deepl.com/translator (kostenlose Version)
Viele Grüße
Gerd
Linux Mint 21.3 Virginia Cinnamon 6.0.4
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Firebird 5.0.0., Embedded, ISQL: LI-V5.0.0.1306
Lazarus 3.0.0 - FPC 3.2.2
Ja, da sind aber einige Kracher dabei. Paralleles Backup/Restore und parallele Indexerzeugung, SQL profiing ist spannend, MERGE wird wesentlich nützlicher, und RETURNING mit mehr als einem Satz sowie partielle Indizes. Ein altes Ticket von mir haben sie auch erledigt. Bin ja froh, dass nicht wieder alles auf den Kopp gestellt wurde, die Umstellung von 2.5 auf 4 war für Firebird-Verhältnisse schwierig.
Parallele Indexerstellung ist nicht so wichtig, da auch größere Indizes mit 20 Millionen Zeilen nur wenige Minuten benötigen.
Dabei gibt es bzgl. Transaktionen nämlich einen Trick zu beachten:
Wenn ich einen Index per Transaktion
- Begin Transaction
- Create Index
- Commit Transaction
erstelle, wird der Index beim Commit aufgebaut.
Während dieser Aktion ist ein weiteres Ändern von Metadaten, also Create/Drop/Alter/... nicht möglich und wird mit dem Daten-Versionsfehler abgewiesen.
Da ich häufig temporäre Tabellen und auch Indizes erstelle und wieder lösche, war das immer ein Knackpunkt.
Die Lösung ist folgendes:
- Begin Transaction
- Create Index Bla
- Set index bla inactive
- Commit Transaction
Nun wird ein Index erstellt aber nicht aktiviert, so dass der Commit sofort fertig ist.
Nun kommt der 2. Schritt:
- Begin Transaction
- Set index bla active
- Commit Transaction
Mit Commit wird nun der Index aktiviert uxnd aufgebaut, aber nun sind parallele Änderungen an den Metadaten möglich, da in dieser Transaktion nur die eine Zeile der RDB$INDICES (o.ä.) gegen Änderungen geschützt ist.
Dies funktioniert bei mir seit der 2.1 bis zur 3.0.10.
Für 5.0 hätte ich eher tatsächliches "parallel Query" erwartet.
Was vor allem bei komplexen Queries mit mehreren Joins, Group und Aggregat doch erheblich dauert.
Z.B. braucht die FB 3.0 für einen derartigen Query aus ca. 1 Mio Zeilen der Haupttabelle und ca. 20 beteiligten Joins für das Gruppen-Ergebnis von ca. 10.000 Zeilen über 1 Minute.
In unserer BI-Anwendung erfordert dies, Abfragen bereits zu früher Stunde fertig im Mmemory-Cache abzulegen.
Dabei gibt es bzgl. Transaktionen nämlich einen Trick zu beachten:
Wenn ich einen Index per Transaktion
- Begin Transaction
- Create Index
- Commit Transaction
erstelle, wird der Index beim Commit aufgebaut.
Während dieser Aktion ist ein weiteres Ändern von Metadaten, also Create/Drop/Alter/... nicht möglich und wird mit dem Daten-Versionsfehler abgewiesen.
Da ich häufig temporäre Tabellen und auch Indizes erstelle und wieder lösche, war das immer ein Knackpunkt.
Die Lösung ist folgendes:
- Begin Transaction
- Create Index Bla
- Set index bla inactive
- Commit Transaction
Nun wird ein Index erstellt aber nicht aktiviert, so dass der Commit sofort fertig ist.
Nun kommt der 2. Schritt:
- Begin Transaction
- Set index bla active
- Commit Transaction
Mit Commit wird nun der Index aktiviert uxnd aufgebaut, aber nun sind parallele Änderungen an den Metadaten möglich, da in dieser Transaktion nur die eine Zeile der RDB$INDICES (o.ä.) gegen Änderungen geschützt ist.
Dies funktioniert bei mir seit der 2.1 bis zur 3.0.10.
Für 5.0 hätte ich eher tatsächliches "parallel Query" erwartet.
Was vor allem bei komplexen Queries mit mehreren Joins, Group und Aggregat doch erheblich dauert.
Z.B. braucht die FB 3.0 für einen derartigen Query aus ca. 1 Mio Zeilen der Haupttabelle und ca. 20 beteiligten Joins für das Gruppen-Ergebnis von ca. 10.000 Zeilen über 1 Minute.
In unserer BI-Anwendung erfordert dies, Abfragen bereits zu früher Stunde fertig im Mmemory-Cache abzulegen.
Guter Tipp mit dem Aufsplitten der Indexerzeugung, danke!
Außerdem: SKIP_LOCKED ist evtl für Dich interessant. Wir hatten ja mal das Thema, wie man Ressourcenzugriff synct, mit dem Ergebnis select with lock. Über SKIP_LOCKED lassen sich mit Firebird 5 queues umsetzen, die nur da blockieren, wo es unbedingt nötig ist.
Hat jemand von euch mitllerweile Firebird 5 mal getestet? Habe bisher paralleles Backup/Restore getestet, das ist deutlich schneller als bisher, ca Faktor 2 bis 3. Auch hab ich mal zwei große BI-Anwendungen (Desktop und Web) mit komplexem DB-Code mit Firebird 5 betrieben, das lief alles ohne Probleme. Schön auch das minor ODS upgrade, denn damit kann man 4er DBs einfach mit gfix auf ODS 13.1 upgraden und braucht kein backup restore.
Dann wollte ich den profiler testen, das sträubt sich aber noch. Man führt eine profiler-Session so durch
Anschließend kann man die profiling views auswerten, deren Basistabellen bei dieser Aktion mit Daten gefüllt wurden,
usw, siehe Doku. Löschen der profiledaten mit delete from plg$prof_sessions, das leert über delete cascade auch die zugehörigen Daten in allen anderen snapshot-Tabellen.
Das klappt soweit auch. Die Session bezieht sich immer nur auf das bei start_session genannte attachment - wenn man nix angibt, ist es current_connection.
Beim profiling komplexer SPs scheint es noch zu haken. Während eine einfache SP Profildaten erzeugt, wirkt es bei einigen komplexeren (die genaue Ursache kenne ich noch nicht), als wäre gar keine Session erzeugt worden. Es wurden aber Profildaten in die snapshot-Tabellen geschrieben, Flamerobin zeigt das beim commit von finish_session an:
PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 19 inserts.
PLG$PROF_CURSORS: 35 inserts.
PLG$PROF_RECORD_SOURCES: 92 inserts.
in firebird.log steht dann sowas:
Wenn es funktioniert, sieht es hingegen zb so aus:
PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 5 inserts.
PLG$PROF_CURSORS: 3 inserts.
PLG$PROF_RECORD_SOURCES: 4 inserts.
PLG$PROF_REQUESTS: 5 inserts.
PLG$PROF_PSQL_STATS: 11 inserts.
PLG$PROF_RECORD_SOURCE_STATS: 4 inserts.
Dh, die letzten 3 Snapshot-Tabellen werden im Fehlerfall nicht gefüllt und das ganze nicht committet.
Außerdem: SKIP_LOCKED ist evtl für Dich interessant. Wir hatten ja mal das Thema, wie man Ressourcenzugriff synct, mit dem Ergebnis select with lock. Über SKIP_LOCKED lassen sich mit Firebird 5 queues umsetzen, die nur da blockieren, wo es unbedingt nötig ist.
Hat jemand von euch mitllerweile Firebird 5 mal getestet? Habe bisher paralleles Backup/Restore getestet, das ist deutlich schneller als bisher, ca Faktor 2 bis 3. Auch hab ich mal zwei große BI-Anwendungen (Desktop und Web) mit komplexem DB-Code mit Firebird 5 betrieben, das lief alles ohne Probleme. Schön auch das minor ODS upgrade, denn damit kann man 4er DBs einfach mit gfix auf ODS 13.1 upgraden und braucht kein backup restore.
Dann wollte ich den profiler testen, das sträubt sich aber noch. Man führt eine profiler-Session so durch
Code: Alles auswählen
select rdb$profiler.start_session('Profile Session 1') from rdb$database -- default current_connection
-- den zu profilenden Code ausführen
execute procedure rdb$profiler.finish_session(true)Code: Alles auswählen
select * from plg$prof_sessions
select * from plg$prof_psql_stats_viewDas klappt soweit auch. Die Session bezieht sich immer nur auf das bei start_session genannte attachment - wenn man nix angibt, ist es current_connection.
Beim profiling komplexer SPs scheint es noch zu haken. Während eine einfache SP Profildaten erzeugt, wirkt es bei einigen komplexeren (die genaue Ursache kenne ich noch nicht), als wäre gar keine Session erzeugt worden. Es wurden aber Profildaten in die snapshot-Tabellen geschrieben, Flamerobin zeigt das beim commit von finish_session an:
PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 19 inserts.
PLG$PROF_CURSORS: 35 inserts.
PLG$PROF_RECORD_SOURCES: 92 inserts.
in firebird.log steht dann sowas:
Code: Alles auswählen
Profiler flush
violation of FOREIGN KEY constraint "PLG$PROF_RECORD_SOURCES_CURSOR_FK" on table "PLG$PROF_RECORD_SOURCES"
Foreign key reference target does not exist
Problematic key value is ("PROFILE_ID" = 12, "STATEMENT_ID" = 62247, "CURSOR_ID" = 3)PLG$PROF_SESSIONS: 1 inserts.
PLG$PROF_STATEMENTS: 5 inserts.
PLG$PROF_CURSORS: 3 inserts.
PLG$PROF_RECORD_SOURCES: 4 inserts.
PLG$PROF_REQUESTS: 5 inserts.
PLG$PROF_PSQL_STATS: 11 inserts.
PLG$PROF_RECORD_SOURCE_STATS: 4 inserts.
Dh, die letzten 3 Snapshot-Tabellen werden im Fehlerfall nicht gefüllt und das ganze nicht committet.
Bei reinen Queries nützt SKIP_LOCKED auch nichts, da mittels ReadCommitted sowieso nur für die Transaktion sichtbare Daten gelesen werden.
Unser ETL-Prozess packt auch alles in eine Transaktion, also den Delete vorher und den Insert anschließend. Somit bekommen aktive Abfragen immer die bisherigen Daten und erst nach Abschluss der Transaktion dann beim nächsten Mal die neuen Daten.
Da ein ETL auch mal abstürzen kann (SQL-Datenfehler) hat es den Vorteil, dass keine Daten verschwinden.
Ich habe das mal mit SSIS versucht, aber da muss man den Delete und den Insert in 2 Aufgaben splitten, die auch 2 Transaktion sind.
Stirbt also die 2. Transaktion, aus o.a. Gründen, sind die Daten erst mal weg.
Was den Metadatenupdate angeht, also Create/Alter/Drop usw. scheint es da eher so zu sein, dass die RDB$-Tabellen anders verarbeitet werden, da z.B. 2 parallele Create Table der 2. wegen des Konflikterrors abgebrochen wird, so dass ich dies mit einem explizitem "Select ... For Update" sequentialisieren muss.
Unser ETL-Prozess packt auch alles in eine Transaktion, also den Delete vorher und den Insert anschließend. Somit bekommen aktive Abfragen immer die bisherigen Daten und erst nach Abschluss der Transaktion dann beim nächsten Mal die neuen Daten.
Da ein ETL auch mal abstürzen kann (SQL-Datenfehler) hat es den Vorteil, dass keine Daten verschwinden.
Ich habe das mal mit SSIS versucht, aber da muss man den Delete und den Insert in 2 Aufgaben splitten, die auch 2 Transaktion sind.
Stirbt also die 2. Transaktion, aus o.a. Gründen, sind die Daten erst mal weg.
Was den Metadatenupdate angeht, also Create/Alter/Drop usw. scheint es da eher so zu sein, dass die RDB$-Tabellen anders verarbeitet werden, da z.B. 2 parallele Create Table der 2. wegen des Konflikterrors abgebrochen wird, so dass ich dies mit einem explizitem "Select ... For Update" sequentialisieren muss.
-
martin.koeditz
- Beiträge: 445
- Registriert: Sa 31. Mär 2018, 14:35
Funktioniert der Kompatibilitätsmodus für FB 3.0 noch? Dieser kann in der database.conf oder firebird.conf gesetzt werden
Gruß
Martin
Habe mir FB 5.0 noch nicht angesehen. Der Modus ist für uns derzeit aber noch entscheidend.DataTypeCompatibility = 3.0
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
ja, das ist unverändert und funktioniert weiterhin. Zu der profiler-Geschichte gibts ein Ticket https://github.com/FirebirdSQL/firebird/issues/7553martin.koeditz hat geschrieben: ↑Mo 24. Apr 2023, 15:07 Funktioniert der Kompatibilitätsmodus für FB 3.0 noch? Dieser kann in der database.conf oder firebird.conf gesetzt werdenDataTypeCompatibility = 3.0
Der Profiler-Bug ist behoben, die Logik hatte Probleme mit subselects. Nun geht es noch darum, die Zahlen zu interpretieren.
Derweil hab ich parallele Indexerzeugung getestet. Das bringt was, in einer Testtabelle mit 2 Mio Sätzen braucht die Aktualisierung von 5 Indizes ohne Parallelisierung 46 Sek, mit aber nur 19. Sowas in der Art:
Dabei hatte ich ParallelWorkers = 6 in firebird.conf konfiguriert, der Testrechner hat 8 logische Prozessoren. Mehr muss man dafür nicht machen, also insbesondere ist kein API-Aufruf nötig, der die Anzahl der worker übergibt. @bfuerchau: Das Feature könnte auch für euch interessant sein.
Derweil hab ich parallele Indexerzeugung getestet. Das bringt was, in einer Testtabelle mit 2 Mio Sätzen braucht die Aktualisierung von 5 Indizes ohne Parallelisierung 46 Sek, mit aber nur 19. Sowas in der Art:
Code: Alles auswählen
ALTER INDEX TBL_X1 ACTIVE;
ALTER INDEX TBL_X2 ACTIVE;
ALTER INDEX TBL_X3 ACTIVE;
ALTER INDEX TBL_X4 ACTIVE;
ALTER INDEX TBL_X5 ACTIVE;Wenn man die Indizes über parallele Connections aktiviert erreicht man allerdings ähnliche Geschwindigkeiten, da jede Connection in einem Thread ausgeführt wird, bleibt für parallele Workers ja nicht so viel übrig.
Eine Web-Anwendung verwendet für jede Sitzung mindestens eine eigene Connection. Mehrere Tabellen werden berreits parallel abgefragt.
Dabei kann dann jede Connection bei Bedarf einen neuen Index, abhängig vom SQL, erstellen.
Wenn also z.B. 5 Tabellen parallel abgefragt werden, können auch 5 Indizes parallel erstellt werden. Dein Beispiel hat mit unserer Realität wenig zu tun.
Teste doch mal 5 Tabellen mit je eigenem Index und aktiviere diese über 5 parallele Connections.
Bei 2.5 ging das über den Classic-Server auch prima, da für jede Connection ein Prozess gestartet wurde und somit auch da bereits parallele Abfragen und Indexerstellung aus einer DB möglich waren. Zur Laufzeit der Web-Anwendung waren da schon mal über 30 Prozesse aktiv. Mit dem Superclassic konnte man das vergessen.
Eine Web-Anwendung verwendet für jede Sitzung mindestens eine eigene Connection. Mehrere Tabellen werden berreits parallel abgefragt.
Dabei kann dann jede Connection bei Bedarf einen neuen Index, abhängig vom SQL, erstellen.
Wenn also z.B. 5 Tabellen parallel abgefragt werden, können auch 5 Indizes parallel erstellt werden. Dein Beispiel hat mit unserer Realität wenig zu tun.
Teste doch mal 5 Tabellen mit je eigenem Index und aktiviere diese über 5 parallele Connections.
Bei 2.5 ging das über den Classic-Server auch prima, da für jede Connection ein Prozess gestartet wurde und somit auch da bereits parallele Abfragen und Indexerstellung aus einer DB möglich waren. Zur Laufzeit der Web-Anwendung waren da schon mal über 30 Prozesse aktiv. Mit dem Superclassic konnte man das vergessen.