Firebirdforum.de

Hi alle,

auf der Konferenz 2019 gab es einen Vortrag von Vlad, dass Firebird nun verschiedene Operationen, die sich dafür eignen, parallelisiert ausführen kann. Dazu gehört bisher sweep, backup, restore (teilweise) und Indexerzeugung, soll aber nicht auf diese beschränkt sein. Die Idee ist dabei immer die gleiche, es werden Ressourcen ermittelt, die sich nicht überschneiden und diese werden dann von einer einstellbaren Anzahl von Threads parallel abgearbeitet. Beim Backup sind das bspw die Pages. Performancegewinne in der Größenordnung bis zu 4-fache Geschwindigkeit (natürlich je nach Kontext, System usw) sind die Folge. Interessant für Systeme mit großem Datenvolumen (Reporting bspw), wo diese Verwaltungsaktivitäten regelmäßig durchgeführt werden und zeitkritisch sind.

Bei zwei Punkten geben meine Aufzeichnungen nicht mehr exakt her, wie die Nutzung ist.

- es hieß, das Feature sei bereits von Firebird 4 bis zu Firebird 2.5.9 inklusive zurückportiert worden. Kann das jemand bestätigen oder ist das nur der Plan?
- Ich habe die Aufrufparameter nicht notiert, weil ich davon ausging, dass die Folien im Anschluss an die Konferenz im Netz stehen. Tun sie aber noch nicht. Es war so was wie gbak ... -parallel 4, wenn man 4 Threads parallel laufen lassen wollte. Weiß jemand genaues?

Grüße, Volker

Gerade die Indexerstellung scheiterte bei mir immer wieder an den Satzversionen, da der nächste Create Table/View/Index wegen "Nichtaktualität" abgewiesen wurde.
Nun wird der Index aber erst während eines Commits erstellt. Somit ist z.T. eine Systemtabelle gegen Veränderungen während der Dauer gesperrt.

Dies führte bei mir zur zwanghaften Serialiserung von DDL's via Globalem Lock.
Ich habe eine Tabelle mit nur 1 Satz, die per "Select ... for update" gesperrt wird.
Der Index wird erstellt, auf Inaktiv gesetzt und dann commited.
Durch den Commit wird die globale Sperre aufgehoben, der Index aber noch nicht gebildet.
Die anschließende Aktivierung des Indexes stört nun weitere DDL's nicht mehr.

Evtl. kann man solche Verfahren irgendwie einbringen, denn zu Anfangszeiten meiner BI-Lösung mit intensiven parallelen Create/Drop-DDL's kam es immer zu Störungen der DB-Struktur, die z.T. keinen Backup mehr zuließen.
Erst die obige Serialisierung hat dieses Problem behoben.

Guten Morgen,

die Folien sind nun abrufbar unter https://www.ibphoenix.com/resources/doc ... ontributed.

Für 3.0.4 sind die Funktionen noch nicht implementiert.

Gruß
Martin

Hi Martin,

cool, danke! Aus der Folie geht nicht klar hervor, ob die Funktionen teilweise schon in 2.5.9 / 3.0 re-implementiert sind. Weißt Du, ob sie noch für Firebird 3 vorgesehen sind oder nur für die HQBird -Versionen < 4?

Grüße, Volker

Hallo Volker,

leider habe ich auch keine genauen Infos hierzu. Aber das Video zur Konferenz ist online. Vielleicht geht daraus ja noch etwas hervor.

https://firebirdsql.org/en/news/firebir ... d-restore/

Gruß
Martin

Ja, im Video und auf den Folien steht ziemlich am Anfang
...
front ported to the v3 code base
including SuperServer, of course

und darunter wird dann HQBird und deren Versionen erwähnt. Das sollte eigentlich bedeuten, dass es in aktuellen 3ern drin ist. Da hilft wohl nur ausprobieren oder die firebird-users-liste nutzen.

Gruß, Volker