Letztes backup/restore datum

[jobo]

Das klingt eher nach einem Punkt, wo man im Sinne von Professionalität ein Schleife über seine Supportleistungen und deren Bedingungen drehen sollte.
Wenn es Programme gibt (eins?), die einen Backupstempel schreiben, muss man evtl. deren Einsatz verlangen. Andernfalls gibt es nur Support nach Aufwand.

Außerdem denke ich, solche "Effekte" sollten auch die Opensource Anbieter in ihre Entwicklung einbeziehen. Bei closed source Systemen und entsprechenden Wartungsverträgen ist es relativ einfach, hier klare Kante zu fahren. Solche Features entscheiden m.E. am Ende auch über Erfolg und Einsatzbreite eines Systems.

[mkinzler]

Man könnte sich überlegen, in das Programm eine Backupfunktion einzubauen, die neben dem Backup der Datenbank noch andere Sachen sichert. Diese Funktion (bzw. die Verwendung) wäre dann verpflichtent und entscheidend bei einem Supportfall. Man könnte dann auch im Programm auf "fehlende" Backups hinweisen.

[MyRealName]

Zum Verständnis :

Ich will natürlich schon länger eine Funktion, wo nicht nur regelmässig ein backup gemacht wird, sondern es auch kostenpflichtig zur Sicherung auf unserem Firmenserver hochgeladen werden kann, um zum Bsp. die letzten 7 oder 30 Tage als Kopien zur Sicherheit da zu haben.

Bei dem Backup/Restore geht es natürlich darum, eventuell Index- oder Seitenfehler der Datenbank sicher zu beheben, von daher soll natürlich nicht nur ein Backup gemacht werden, sondern auch ein Restore, um darin weiter zu arbeiten. Nur ein backup bringt da natürlich nichts, da ich in derselben Datei weiterarbeite und die Fehler sich nur verschlimmern :p

[jobo]

Das Anliegen bzw. das Ziel der Backup "Erkennung" war denke ich schon relativ klar.
Diese Backuperkennung wäre also auch nur die halbe Miete. Man müsste dann zusätzlich ein Restore feststellen, vielleicht reicht auch das Letztere.
Vielleicht kann man es auch andersrum sinnvoll für den akuten Zweck sein, eigenständig eine Prüffunktion anzustoßen, die Index oder Seitenfehler wenigstens findet. Es reicht ja schon auf Existenz zu prüfen.
Damit spart man sich den Datenverkehr und ist dennoch aussagefähig bzw. kann es im notfalls on demand aufrufen.
Ich weiß nicht, ob fb die reine Erkennung bietet ohne ein backup/restore wirklich durchzuführen.

[Delphi.Narium]

Zu Jobos Idee aus der Doku von FireBird:

Code:

fbsvcmgr [host:]service_mgr [user <...>] [password <...>]
   action_validate dbname <filename>
   [val_tab_incl <pattern>]
   [val_tab_excl <pattern>]
   [val_idx_incl <pattern>]
   [val_idx_excl <pattern>]
   [val_lock_timeout <number>] 

where
   val_tab_incl      pattern for tables names to include in validation run
   val_tab_excl      pattern for tables names to exclude from validation run
   val_idx_incl       pattern for indices names to include in validation run, 
                  by default %, i.e. all indices
   val_idx_excl      pattern for indices names to exclude from validation run
   val_lock_timeout    lock timeout, used to acquire locks for table to validate,
                  in seconds, default is 10 sec
                   0 is no-wait
                  -1 is infinite wait

siehe README.online_validation.txt im Verzeichnis doc zu FireBird.

Man müsste hier dann die Konsolenausgabe abfangen/in Datei umleiten, um das Ergebnis auszuwerten.

Oder sporadisch laufen lassen und die Ergebnisse per Mail schicken lassen. Dann kann man zumindest zum Kunden sagen: "Schau mal bitte nach, Deine DB geht kaputt ;-)"

[MyRealName]

Ich denke, IbDAC hat da eine Komponente dazu. Das ist aber eine gute Idee :)

[tsteinmaurer]

Zitat:

Ich hatte gehofft, sowas wie die OSD Version etc, die man ja auslesen kann, dass da vllt. auch eine Info steht, wann die DB erzeugt wurde (über script oder restore oder was auch immer).

"Creation Date" steht in der Header Page der Datenbank, z.b. mit "gstat -h ..." oder mit Komponenten (IBDAC) deines Vertrauens abrufbar.

Siehe z.B.: https://www.firebirdsql.org/pdfmanua...le-header.html

[MyRealName]

Sowas habe ich gesucht, danke!