Datenbanksicherung

[JeVaske]

Die DB-Sicherung dauert sehr lange. Ist es möglich einen Fortschrittsbalken einzubinden, damit der User eine Rückmeldung erhält, dass das Programm arbeitet?

[FrodBRA]

Was bedeutet "sehr lange"? Ich habe gerade ein BK mit ca. 2000 Schüelern gesichert, das hat ca. 2 Minuten gedauert. Bei einer langsamere CPU dürfte man bei vielleicht 5 landen. Ist das lange? Geht bei deiner Datenbank noch etwas anderes vor? Ist die zum Testen verschickbar?

Das Verhalten von SchILD hier ist aber in der Tat verbesserungsfähig: Der Haupthread stellt sich auf "(keine Rückmeldung"), was für den typischen Windowsnutzer ja ein "Aufhängen" ist und das kleine Zusatzfensterchen geht schnell unter. Ein Fortschrittsbalken ist ja eh Augenwischerei, aber eine kleine Variable, die einfach "Gesicherte Felder (X)" hochschreibt und zeigt, das "etwas passiert" wäre bei Vorhandensein von Ressourcen schön.

[AnneSchueller]

Ich gebe zu, dass ein Fortschrittbalken sehr charmant wäre, allerdings evtl etwas schwierig zu installieren, da die Sicherung über den Server läuft. Vielleicht könnte ein Hinweisfenster "DB wird gerade gesichert. Dies kann einige Zeit dauern" hinzufügen.

[Kluesenerm]

Ich würde auf den Balken verzichten. In der Regel verlängern diese Balken den Prozess erheblich. Vielleicht einen Hinweis anzeigen, dass der Prozess länger dauern kann. Im Prinzip kennen doch alle Nutzerinnen doch die Probleme bei Schild bzgl. kleinerer und größerer Wartezeiten (Programm reagiert nicht; Erster Aufruf der Dokumentenverwaltung und Reports)

[FrodBRA]

Wie "lange" dauert das denn bei euch? Mehr als ein paar Minuten habe ich für Sicherungen, Einspielungen und Migrationen noch nicht gesehen - mit einer Ausnahme: Wenn eine größere DB aus dem Quartalsbetrieb migriert wird, dauert das Umschreiben der Quartale 30 bis 40 Minuten extra als Plus. Alles andere spielte sich auf einer "ordentlichen, aber nicht High-End" CPU (Ryzen 5 5700X) bisher im Bereich von "wenigen Minuten" ab.

[AnneSchueller]

Das Sichern und Einspielen hat bei mir noch nie länger als eine Minuten gedauert. Migration schonmal 2 Minuten. Auf meinem Surface dauert die Migration schonmal länger, aber das macht man i.d.R. ja auch nicht jeden Tag.

[JeVaske]

Vielleicht bin ich da etwas verwöhnt. Ich habe mir damals für Schild2 eine cmd-Datei gebastelt, mit der ich ich meine MSSQL-Datenbank in ca. 4 Sekunden gesichert habe. Die Backup-Datei bei Schild2 (MSSQL) ist 199 MB groß. Bei Schild3 dauert die Sicherung bei mir 3 Minuten und 7 Sekunden! Die SQLLite-Backup-Datei ist etwas kleiner (154 MB) als bei Schild2. Da der Vorgang ganze 3 Minuten dauert, würde ich mir zumindest einen Hinweis wünschen, dass es bei älteren Datenbanken länger dauern könnte, wenn der Fortschrittsbalken nicht realisierbar ist. Ich hatte jedenfalls beim ersten Backup nicht mehr damit gerechnet, dass sich noch etwas tut. Und da ich weiß, dass es mit sehr sehr einfacheren Mitteln viel schneller funktioniert, war ich irritiert, dass Schild3 so lange braucht.

[AnneSchueller]

Das könnte man hier mit hinzufügen. Evtl als Hinweis als zweiten Satz darunter "Dies kann einige Zeit dauern"

[Raffenberg]

Oder so. Ich habe mir den Prozess angeschaut und fand es jetzt auch mit der Eieruhr OK.

[JuergenRichter]

Man muss ja auch berücksichtigen, dass hier kein Backup "im engeren Sinne" stattfindet (mit dem entsprechenden Tool des Datenbanksystems), sondern eigentlich eine Migration (mit Mitteln des SVWS-Servers) von einem System in ein anderes. Das dauert halt entsprechend länger. Für ein "echtes" Backup gibt es ja auch einfach zu verwendenden Tools (z.B. https://sqlbackupandftp.com/ ). Dafür wurde ha auch schon mal (von Frau Schüller?) eine Anleitung geschrieben.

[FrodBRA]

Einen reinen DB dump zu erzeugen geht auch mit dbeaver in wenigen Sekunden. Ich habe den Dump auch gerade wieder über dbeaver eingelesen. Die DB startet jedenfalls.

Scheint zu gehen, aber supportet ist das Vorgehen wohl nicht. ;)

(Rechte Maustaste auf die DB, Werkzeuge (bzw. Tools), dann "dump database" oder "restore database".)

[JuergenRichter]

Wie sieht das eigentlich aus, wenn die Datenbank auf einem Server liegt? Kann man dann das "systemeigene" Backup von einem Client aus starten?

[kroerig]

Was meinen Sie mit "systemeigene Backup"? Außer dem MS SQL Server ist mir kein DBMS bekannt, das Backuproutinen direkt im Server mitliefert. Ggf. noch Oracle, aber da kenne ich mich nicht aus.

Bei allem anderen muss man sich da schon selbst drum kümmern. Und sofern möglich nutze ich die Tools, dir mir die Software zur Verfügung stellt. Und das möglichst serverseitig.

Bei MySQL/MariaDB also entsprechend mysqldump bzw. mariadb-dump mit etwas Logik drum herum (Dedup, Versionierung,...). Die Backups laufen bei mir zweimal am Tag: ein Job am späten Abend und einer um die Mittagszeit. Die kurzen Table-Lock sind so schnell durch, das fällt im Betrieb gar nicht auf.

Mit dem SVWS könnte man jetzt auch ein logisches Backup über die API erstellen. Aber das ist wie oben beschrieben eigentlich eine Datenmigration.

Ich denke, ich werde das mit dem Go Live von SchILD3 kombinieren. Tagsüber regelmäßig einen Dump der DB und nachts zusätzlich einen Export über die API. Aber alles serverseitig.

Bei einer hohen Dichte an Änderungen pro Tag, könnte man auf dem Server noch Transaktionlogs aktivieren. Dann ist ein minutengenaues Rollback möglich. Aber ob man das braucht?

BTW: Nutzen SchILD3 und der SVWS eigentlich Transaktions bei Schreiboperationen?

[hmt]

Mit dem SVWS könnte man jetzt auch ein logisches Backup über die API erstellen. Aber das ist wie oben beschrieben eigentlich eine Datenmigration.

Über die API kann man Backup/Restore mit Hilfe von SQLite machen. Das wird dann auch so genannt. Das unterscheidet sich dann schon von einer Migration, die Daten aus Schild2 in den SVWS-Server importiert.

[kroerig]

Man muss ja auch berücksichtigen, dass hier kein Backup "im engeren Sinne" stattfindet (mit dem entsprechenden Tool des Datenbanksystems), sondern eigentlich eine Migration (mit Mitteln des SVWS-Servers) von einem System in ein anderes. Das dauert halt entsprechend länger. Für ein "echtes" Backup gibt es ja auch einfach zu verwendenden Tools (z.B. https://sqlbackupandftp.com/ ). Dafür wurde ha auch schon mal (von Frau Schüller?) eine Anleitung geschrieben.

Das lese ich so, dass Schild für das DB Backup den Endpunkt /api/schema/export/{schema}/sqlite und für den Restore /api/schema/import/{schema}/sqlite anspricht. Dabei findet aber jedesmal eine Transformation der Datenbank statt.

Ein klassisches Backup mit den Bordmitteln eines DBMS wäre ein Dump in eine Textdatei. Und der geht schneller.

[FrodBRA]

Ist das hier noch ein Issue?

Das Backup funktioniert ja. Wer es schneller mag, kann selbst mit einem DB-managementtool oder einer API dumpen und hinterher direkt in die DB einlesen. Supporten würde ich dieses Vorgehen aber nicht, ein Hinweis im Wiki in Bezug die Export-Dauer wäre hier genug.

@AnneSchueller @JuergenRichter