DB CREATE-Datum wird von DB Restore-Datum überschrieben - ist DAS wirklich korrekt?

[Gerd]

Hallo.

Ich hätte gerne, dass die Entwickler von Firebird (noch einmal) darüber nachdenken, ob die (beispielhafte) Eintragung

...
Creation date: Sep 20, 2022 9:18:52 GMT
...

zu sehen nach einem SHOW DATABASE tatsächlich den jeweils aktuellen Datenbank-Wiederherstellungszeitstempel erhalten sollte.
Das Datenbankerzeugungsdatum wird mit dem Wiederherstellungsdatum überschrieben. Das finde ich nicht korrekt.

Ich bin der Meinung "Creation date" sollte nicht angetastet werden.
Vielmehr wäre es logischer, wenn für SHOW DATABASE zusätzlich ein "Restore date" geschrieben wird, sobald die Wiederherstellung (Restore) durchgeführt wurde.

Ein Restore (Wiederherstellung, Wiederherstellungsdatum) ist kein Create (Erstellen, Erstellungsdatum) - denke ich hier so ...


Viele Grüße
Gerd

[martin.koeditz]

Hallo Gerd,

hier meine Meinung: der Zeitstempel stimmt. Warum? Die Datenbank wurde zum Zeitpunkt des Restores (neu) erstellt. Vorher existierte die ja nicht.

Mache ich ein Restore meiner alten FB 1.5-DB von 2005, dann ist der Erstellzeitpunkt (für mich) heute. Eventuell habe ich ja verschiedene Schalter während der Wiederherstellung bemüht, die die DB-Struktur sogar ändern.

Aber ich glaube, das ist mehr so eine Philosophiefrage.

Gruß
Martin

[Gerd]

Hallo Martin.

Wenn ich am 01.01.2022 gefragt werde wie lange ich die Datenbank schon benutze und ich antworte seit ca. 5 Jahren, dann entsteht ein Missverständnis, wenn ich nach Wiederherstellung(en) bei SHOW DATABASE ein CREATE-Datum 31.12.2021 angezeigt bekomme.

Wie kann eine Datenbank bereits seit 5 Jahren benutzt werden, wenn dessen CREATE-Datum es rechnerisch ausschließt.

Das CREATE-Datum sollte unantastbar sein.

Ein Bauwerk, das in Trümmern liegt, war bspw. mal ein Gebäude mit Fertigstellungsdatum.
Wird es aus den Trümmern neu aufgebaut, dann gibt es in dessen Historie nunmehr zwei Daten:
1. Datum Fertigstellung
2. Datum Wiederaufbau.
Keiner kommt auf die Idee zu sagen, das Wiederaufgebaute ist der Originalbau.
Viele wird es interessieren, ob das (immer noch) der Originalbau ist oder ob da schon mal was Wiederhergestellt wurde.

Ich lebe sicherlich ruhig und zufrieden weiter, wenn es so bleibt, wie es ist.
Aber etwas besser, da informativer würde ich es schon finden.


Viele Grüße
Gerd

[vr2]

Hallo Gerd,

sehe das wie Martin. Was beim restore technisch passiert, ist, dass eine DB von Grund auf neu erzeugt wird, nach dem Bauplan aus dem fbk. Und nach der Umsetzung des jeweiligen Servers. Das Einzige, was nicht angepackt wird, ist der BLR-Code, deswegen sollte man bspw SPs und SFs nach Migration zu einer höheren Serverversion neu übersetzen (durch ALTER, bei identischem Quellcode).

Aber auch ohne Migration ist ein regelmäßiges restore eine sinnvolle Wartungsmaßnahme. Während der Benutzung belegte Ressourcen werden freigegeben (zb pages), das macht Firebird im Betrieb nicht automatisch, und interne Zähler werden resettet. Falls im Betrieb irgendwas kaputtging (kommt vor, Indexpage kaputt o.ä.) wird es entweder neu gebaut oder es fällt beim restore auf und das Original kann gezielt repariert und dann restoret werden. Deshalb nie restore aufs Original. Eine frisch restorte DB ist oftmals schneller und kleiner als vor dem restore. Das Zeitintervall für restore hängt von der Nutzung und verfügbaren Wartungszeitfenstern ab, üblich ist einmal nachts oder einmal die Woche.

Wer Dir Fragen stellt, wieso die DB denn so neu ist, hat das Konzept und den Zweck von restore nicht verstanden. Wenn es bei der Befragung darum ging, Deine Expertise mit Firebird abzuklopfen oder Deinen Einsatz von Firebird zu rechtfertigen, muss man sich schon was anderes einfallen lassen. Zb was sind die grundsätzlichen Unterschiede zwischen Firebird 2.5, 3 und 4? Aber um die Antwort auf diese Frage beurteilen zu können, muss man mindestens restore verstanden haben.

Und von wegen creation date: Keins der Objekte in der DB hat einen Zeitstempel. Du konntest vor 5 Jahren eine leere DB anlegen. Die lässt Du 4 Jahre 11 Monate liegen und erzeugst dann 100 Tabellen und 100 SPs. In eine der SPs schreibst Du einen Kommentar mit Datum von vor 5 Jahren. Wie alt ist die DB?

Grüße Volker

[Gerd]

Hallo Gerd,

...
Und von wegen creation date: Keins der Objekte in der DB hat einen Zeitstempel. Du konntest vor 5 Jahren eine leere DB anlegen. Die lässt Du 4 Jahre 11 Monate liegen und erzeugst dann 100 Tabellen und 100 SPs. In eine der SPs schreibst Du einen Kommentar mit Datum von vor 5 Jahren. Wie alt ist die DB?

Grüße Volker

Hallo in die Runde.

Ein anderes recht bekanntes Datenbanksystem (RDMS) hatte bis zur 5.7 keine Möglichkeit den Erstellungszeitpunkt der Datenbank wirklich festzuhalten.
Dessen Nutzer benötigen es für unterschiedliche Zwecke. Das ist im Netz nachzulesen.
Man vertröstet(e) auf kommende Updates.
Ob mittlerweile so ein Update für dieses System vorliegt, entzieht sich meiner Kenntnis.
Übrigens, mir ist bekannt, dass Tabellen-Objekte dieses RDMS automatisch einen CREATE-Stempel erhalten. Kann man für 'GUT' halten.

Alleine bin ich offenbar nicht mit dieser Überlegung.
Firebird ist (oder inzwischen war?) zumindest diesem RDMS in puncto "Creation date:" ein Stück voraus.
Es hat auch etwas mit der Dokumentation der Datenbank(en) zu tun.

Ich nutze diese Krücke:
Ich werde einfach den Wert für "Creation date:" (siehe SHOW DATABASE) in den Kommentar zur Datenbank (siehe RDB$DATABASE - RDB$DESCRIPTION) festhalten.
Dieser Wert entsteht nach dem 'CREATE DATABASE COMMIT' und mir geht es darum, diesen für die Ewigkeit festzuhalten - irgendwo, irgendwie.
Und wird er benötigt, nutze ich in diesem Fall: SHOW COMMENT DATABASE


Viele Grüße
Gerd

[bfuerchau]

Es hindert doch niemanden daran, eine eigene DBInfo-Table in die DB zu schreiben, die alle benötigten Infos der DB beinhaltet.
Dies muss nicht nur das Erstelldatum sein, sondern kann auch Versions- und Updateinformationen in Form eines Logs der jeweilige App enthalten.
Vom Restore her wird die DB tatsächlich neu erstellt. Das Filesystem führt das Erstelldatum und wird nur in der RDB$DATABASE gespiegelt.
Wenn du das echte Erstelldatum tatsächlich benötigst und die Ursprungsinfo noch vorhanden ist, kann man das Dateiobjekt ja noch anpassen.
https://learn.microsoft.com/en-us/windo ... etfiletime

[Gerd]

Hallo bfuerchau.

Du benennst eine eigene Tabelle "DBInfo" - ich nenne sie mal "Entwicklung". Ja, das sehe ich auch als eine Möglichkeit an (wo es passt).

Ich komme kurz am besten noch einmal auf den Ausgangspunkt dieses Thema zurück, damit er nicht aus dem Fokus gerät:
Unbestritten ist, dass nach einer (Minimal)Eingabe von

Code: Alles auswählen

CREATE DATABASE '/Pfad/datenbank.fdb' USER 'name' PASSWORD 'geheim';

Firebird eine neue Datenbank erstellt. Dabei wird ihr auch ein entsprechender Zeitpunkt als "Creation date:" zugewiesen.

Eigentlich kommt der Wert von "Creation date:" dem Charakter eines 'Fingerabdrucks' recht nahe. Das Erstelldatum wird lobender Weise automatisch und nicht leicht änderbar von Firebird dargereicht.
Aber irgendwann kommt eine angestoßene Firebird Funktion und hinterlegt dort still und leise ein anderes (neueres) Erstelldatum. Ich kenne die gbak-Schalter - und auch das, was sie bei ihrer Verwendung jeweils bewirken. Dennoch komme ich zu der Auffassung, dass das daraus erneuerte Erstelldatum im Feld "Creation date:" in Ermangelung eines zusätzlichen Felds (z.B. "Modify date:") seine Informationskraft verliert. Wie ich bereits oben erwähnte; "Creation date:" sollte aus meiner Sicht besser unangetastet bleiben.


Ja, das Dateiobjekt unter diesem Betriebssystem und unter Verwendung von "SetFileTime function (fileapi.h)" könnte wohl in diesem Sinne funktionieren. Allerdings sieht das unter Linux schon etwas anders, da anspruchsvoller, aus.
Der "touch"-Befehl, den man dafür zuerst ins Auge fasst, schafft in diesem Fall leider keine Lösung. Beispiel:
touch -t 202210291100.22 adressen.fdb
"touch" ändert nicht das Erstelldatum - hier von adressen.fdb.

Was wohl in dieser Umgebung tatsächlich (vgl. SetFileTime function) zum Ziel führen könnte, wäre das tiefgreifende Verständnis des Inode-Konzept (Unix, Linux). Jedoch habe ich dies für mich noch nicht umfassend erschlossen. Also gehe ich da vorerst nicht ran.


Viele Grüße
Gerd

[Gerd]

... Das Filesystem führt das Erstelldatum und wird nur in der RDB$DATABASE gespiegelt. ...

Hallo bfuerchau.

Da ich damit nicht wirklich etwas anfangen konnte, habe ich mich auf die Suche gemacht, wo denn nun Firebird das Erstelldatum einer Datenbank speichert. Ich denke, dass ich den Ort gefunden habe, an dem Firebird das Erstelldatum einer Datenbank speichert.

Habe es auch mit der Firebird 4 Sprachreferenz gegen geprüft:
Tabelle: MON$DATABASE
Diese Monitoringtabelle (MON$) zeigt Header-Daten der Datenbank an, mit der der aktuelle Benutzer verbunden ist.
Dort ist das Folgende (aber hier nur Auszugsweise) hinterlegt:
::Spaltenname: MON$CREATION_DATE
::Datentyp: TIMESTAMP
::Beschreibung: Datum und Zeit zu der die Datenbank erstellt oder wiederhergestellt wurde.


Demnach liefert eine Abfrage des Felds MON$CREATION_DATE in der Monitoringtabelle MON$DATABASE den folgenden beispielhaften Zeitstempel (mit Zeitzone) zu einer Firebird Datenbank als Abfrageergebnis:

Code: Alles auswählen

SQL> SELECT MON$CREATION_DATE FROM MON$DATABASE;

                                        MON$CREATION_DATE 
========================================================= 
2020-05-06 15:32:57.2100 GMT                              

SQL>

Diese Datenbank wurde also am 06.05.2020 15:32:57 Uhr GMT (Greenwich Mean Time - dt: Mittlere Greenwich-Zeit) erstellt oder wiederhergestellt.

Zur Erinnerung (siehe oben):

SHOW DATABASE; liefert diese Anzeige zum Erstelldatum:

Creation date: May 6, 2020 15:32:57 GMT


Nun mal auch noch das Firebird Kommandozeilen-Tool gstat mit header-Schalter (-header):

gstat meinedatenbank.fdb -header

Liefert diese Anzeige zum Erstelldatum:
...
Creation date May 6, 2020 15:32:57
...


Viele Grüße
Gerd

[vr2]

Hallo Gerd,

mir ist nicht klar, was Du erreichen willst. Nach dem restore hast Du eine neue Datenbank, in einer neuen Datei. Die alte DB und Datei gibt es nicht mehr, das neue creation_date wird auch nicht von der alten übernommen. Wo der Server das creation_date einer DB speichert oder hernimmt, ist letztlich egal. Denn selbst wenn Du es ändern könntest, welche Aussagekraft hätte das? Wenn Du eine Änderungshistorie führen willst, musst Du die selber organisieren, zb mit Hilfe von DDL-Triggern, mit denen Du Strukturänderungen loggst.

Grüße, Volker

[bfuerchau]

MON$-Tabellen sind ja keine echten DB-Tabellen sondern interne Tabellen die zum Teil auch nur zur Laufzeit bestehen.
Da man ja per Connection nicht an die Dateiinformationen kommt, ins besonders beim Zugriff via Alias, gibt die DB ihr Erstelldatum zurück.
Interessant ist, dass das Erstelldatum von der Datei von dem Erstelldatum in der MON$DATABASE genau die Differenz von Start bis zum Ende eines Restores widerspiegelt.
Bei einer gerade neu erstellten DB ohne irgendwelche Tabellen, ist das Datum beider Informationen identisch.
Durch die Änderung der Dateiinformation (API, touch) wird das interne Erstelldatum nicht verändert.