Oder ist "FIX_FSS_METADATA" = "Fix malformed UNICODE_FSS metadata"
Die Ähnlichkeit sollte durchaus übrzeugend sein oder?
unsere Bezeichnung hat da noch 2 extra wörter drin, ist aber funktional exakt das selbe
Als Hintergrund info:
fb<=20 hat char/varchar/blob subtype text felder in den Systemtabellen
mit charset NONE.
Wenn du da in einem trigger oder SP source oder einer Description zum Beispiel Umlaute
benutzt hast war das technisch kein Problem, aber zeigte bei Verbindungen mit anderem
charset auf den Systemtabellen unsinn an (malformed string usw).
Durch den Fix werden die in den Systemtabllen benutzten Zeichen äöüß € etc meistens sauber
erkannt und nach dem fix in
fb>=21 als saubere UNICODE_FSS Zeichen gespeichert.
das Euro zeichen hätte dann zB 3 statt vorher 1 byte belegt. wenn man den
backup/Restore danach noch mal mit dem parameter macht, schaut der sich aber die
neuen 3 bytes einzeln an weil der ja meint, das es NONE wäre und macht daraus wieder
neue UNICODE_FSS Codes. klingt zwar erst mal nicht schlimm, aber ein Kunde hat dabei
seine ca 50MB große Datenbank, die schon fb2.5 war, bei jedem wöchentlichen backup/restore
lauf aufgeblasen, so das die nach einem halben jahr ohne annähernd so viele neue Daten
auf ca 2GB aufgeblasen, weil er das beim gbak restore in seiner batch immer als param drin
hatte (doofe idee).
ca 95% von dem ganzen Platz in der
DB belegten dabei daher Systemtabellen, das meiste glaub ich
rdb$relation_fields, weil dort die descriptions intensiv benutzt wurden, dadurch aber völllig
explodiert sind und auch alles lahm gelegt haben.
Konnten wir durch sum(char_length( auf den feldern dann rausfinden, weil es ganz sicher blobs
der Systemtabellen waren. Und auf den haben wir dann die quatschigen inhalte, die eh keiner
lesen kann, pr update gelöscht, danach backup/restore ohne den parameter und es war wieder klein
und schnell.