automatisches Backup und Zwischenspeichern (flush) bei externer hsqldb

[Aubergino]

Danke, Freischreiber, für Deine Nachforschungen... Ja, so habe ich es auch gerade nachvollzogen.
Nur mit .spript, der "Scriptdatei", als "eigentlichem Speicherort" kann ich mich nicht anfreunden:
In der Scriptdatei sehe ich per Texteditor nur Tabellendefinitionen.
Meine Daten erkenne ich sehr klar (anhand der Textfelder) in der .data Datei.

Wenn nun also Änderungen während der geöffneten DB nur in die log-Datei geschrieben werden und erst beim Schließen der DB die .data mit diesen Daten aktualisiert wird, würde ja diese Aktualisierung genau dem "Flush" in der internen HSQLDB entsprechen.

Wenn ich nach einem Programmabsturz / Stromausfall usw. also eine nicht in die .data übertragene .log-Datei stehen geblieben ist, müsste ich diese Übertragung beim Programmstart nachholen. Evtl. ist das genau das, was beim "Wiederherstellen" nachgeholt wird?

Dennoch wäre es m.E. vorteilhaft, wenn man dieses Übertragen von der .log in die .data auch während des Programmlaufes auslösen könnte. "Flush" tut das offensichtlich nicht, sondern "spült" nur die - eigentlich unveränderte - .odb.

[Aubergino]

Erst selbst lesen, dann das Forum beschäftigen...
...und zwar die HSQLDB-Dokumentation...

Was bei der internen HSQLDB das "Flush" ist, ist bei der externen mit
dem SQL-Befehl CHECKPOINT zu erreichen.

Mit

Code: Alles auswählen

SUB Zwischenspeichern
Dim oController AS Object
Dim oStatement AS Object
Dim strQuery AS String
Dim oResult AS Object
  oController = ThisDatabaseDocument.CurrentController
  If not (oController.isConnected()) Then oController.connect() ' Connect to the database, if necessary
  oStatement = oController.ActiveConnection.CreateStatement()
  strQuery = "CHECKPOINT"
  oResult = (oStatement.executeQuery(strQuery))
END SUB

wird die .data und die .backup aktualisiert und die .log geleert.

Einwände gegen dieses Vorgehen nehme ich gerne entgegen...

Bezüglich des Speicherorts der Daten steht in der HSQL-Dokumentation

Code: Alles auswählen

Database is closed correctly
State after using the command SHUTDOWN
    The test.data file is fully updated.
    The test.backup contains the compressed test.data file.
    The test.script contains the information in the database, excluding data for CACHED and TEXT tables.
    The test.properties contains the entry 'modified' set to 'no'.
    There is no test.log file. 

Database is closed correctly with SHUTDOWN SCRIPT
State after using the command SHUTDOWN SCRIPT
    The test.data file does not exist; all CACHED table data is in the test.script file
    The test.backup does not exist.
    The test.script contains the information in the database, including data for CACHED and TEXT tables.
    The test.properties contains the entry 'modified' set to 'no'.
    There is no test.log file. 

Den zweiten Teil kann ich allerdings nicht einordnen, schon weil ich nicht weiß, wann die DB mit "SHUTDOWN SCRIPT" schließt...

[Freischreiber]

Hallo Aubergino,

Nur mit .spript, der "Scriptdatei", als "eigentlichem Speicherort" kann ich mich nicht anfreunden:
In der Scriptdatei sehe ich per Texteditor nur Tabellendefinitionen.
Meine Daten erkenne ich sehr klar (anhand der Textfelder) in der .data Datei.

Solltest du aber. Oder was glaubst du, wo nach einem "shutdown script" deine Daten geblieben sind?
Der Normalfall in HSQLDB sind memory tables. Nur bei Libreoffice ist das anders, das legt standardmäßig cached tables an.

Wenn ich nach einem Programmabsturz / Stromausfall usw. also eine nicht in die .data übertragene .log-Datei stehen geblieben ist, müsste ich diese Übertragung beim Programmstart nachholen. Evtl. ist das genau das, was beim "Wiederherstellen" nachgeholt wird?

Du selbst mußt gar nichts. Die Datenbank erkennt beim nächsten Start anhand dem "modified=yes" in der properties-Datei, daß Änderungen einzubauen sind und tut das einfach. Wichtig ist nur, daß die log-Datei, wo die Änderungen drinstehen, noch da ist.

Dennoch wäre es m.E. vorteilhaft, wenn man dieses Übertragen von der .log in die .data auch während des Programmlaufes auslösen könnte. "Flush" tut das offensichtlich nicht, sondern "spült" nur die - eigentlich unveränderte - .odb.

Warum? Dieses Übertragen findet generell erst beim Schließen der Datenbank statt. Ob das direkt nach dem Schließen der Fall ist oder beim nächsten Start, ist egal. Die Daten sind in der einen Datei nicht sicherer als in der anderen.

Was bei der internen HSQLDB das "Flush" ist, ist bei der externen mit
dem SQL-Befehl CHECKPOINT zu erreichen.

Ja, mit diesem Nebeneffekt laut Handbuch:

Closes the database files, rewrites the script file, deletes the log file and reopens the database.

Es gibt übrigens eine eigene Backup-Routine in HSQLDB, die das checkpoint vorher automatisch macht:

BACKUP DATABASE TO <directory name> BLOCKING [ AS FILES ]

Auch Backups ohne vorherigen Checkpoint (hot backup) sind ausdrücklich vorgesehen. Nochmal das Handbuch:

Normal backup may take a long time with very large databases. Hot backup may be used in those situations. This type
of backup does not perform a checkpoint and allows access to the database while backup is in progress.
BACKUP DATABASE TO <directory name> NOT BLOCKING [ AS FILES ]

und

Hot backup is performed if NOT BLOCKING is specified. In this mode, the database can be used during backup. This
mode should only be used with very large databases. A hot backup set is less compact and takes longer to restore and
use than a normal backup set produced with the BLOCKING option. You can perform a CHECKPOINT just before
a hot backup in order to reduce the size of the backup set.

Also gehen tut alles.

Ich wollte auch sicher keinen Disput, und schon gar nicht mit Robert. Ich wollte nur darauf hinweisen, daß HSQLDB eine erwachsene Datenbank ist, auch wenn Java zur Zeit offenbar nicht so beliebt ist.

Gruß
Freischreiber

[Aubergino]

Hallo Freischreiber und Robert, das mit dem Disput war absolut positiv gemeint! Ich war gespannt auf eine konstruktive Diskussion zweier Fachleute, denen ich als staunender Laie beiwohnen darf... Das nur zur Klärung, mit großem Dank für Euer Engagement!

[Freischreiber]

zweier Fachleute

Wenn Robert hier mit mir diskutiert, dann ist nur 1 Fachleut beteiligt. Und das bin nicht ich.