Firebirdforum.de

Es gibt noch einen Einfluss, der gerne übersehen wird.
Man muss die Transaktionszähler Älteste und Nächste prüfen, ob diese ggf. weit mehr als 20.000 Differenz haben. In diesem Fall könnte in der MON$STATEMENTS noch ein SQL stehen, der eine Transaktion festhält, was das Reorganisieren der Transaktionsdaten (Satzversionen) verhindert.
Anhand des Zeitstempels kann man dann sehen, wie lange die schon da drin steht.
Per Delete + Commit kann man diese auch entfernen. In MON$TRANSACTIONS und MON$ATTACHMENTS sollten alte Transaktion und Verbindungen dann auch verschwinden.
Falls die Verbindungen nicht verschwinden, kann man diese mit Delete auch entfernen.

Warum macht das das System langsam?
Jede Datenänderung (Update, Delete) sorgt dafür, dass die vorherigen Informationen für die alten Transaktionen noch sichtbar bleiben muss. Dies führt bei neuen Transaktion zum Überlesen der alten Daten. Da hilft dann auch kein Index, da die alten Daten ja ebenso im Index stehen.

Ursachen?
Es könnte bei ungeplanten Shutdowns oder bei Datensicherung des Servers passieren, dass der FB-Server entweder seinen Cache nicht mehr schreiben kann und/oder einfach abgewürgt wird.
Der FB-Server hat noch keinen Volume-Schattenkopie-Driver, der vom Backup angestoßen wird um während des Backups in nicht geschützte Bereiche seine Updates schreibt und nach dem Ende des Backups dann in die DB übernimmt (wäre mal eine Anfrage an diei Entwicklung wert).
Wichtig bei FB-Servern ist, dass diese gezielt heruntergefahren werden müssen, bevor ein System-Backup oder ein Shutdown erfolgt.

Ggf. gibts in den Firebid.log's (Programmvezeichnis) auch Hinweise auf kaputte Blöcke. In dem Fall ist ein Save/Restore erforderlich.

Macht mal ein IO-Benchmark der Virtualisierung, zb mit CrystalDiskmark. Wenn die Werte schrittweise besser werden, bis sie erst nach mehreren Runden einen brauchbaren Wert erreicht haben, wisst ihr, das ist die Ursache. Dann könnt ihr den Admins der VM sagen, schaltet die mal auf Durchzug bzw der Ressourcenzuteiler der VM soll sich raushalten.

Es kann gut sein, dass die IO-Zuteilung den DB-Anforderungen nicht gerecht wird. Firebird ist kein Office-Programm - wenn der DB-Server Leistung sehen will, braucht er die JETZT und nicht erst nächste Woche oder nachdem die Virtualisierung scheibchenweise nachgelegt hat. Das betrifft nicht nur den Plattendurchsatz, sondern auch CPU-Zuteilung, schlägt sich aber beides in dem IO-Benchmark nieder.