Hallo zusammen,


ich werde für mein größtest Softwarepaket in den nächsten Monaten(Jahren) die Datenbank wechseln. Weg von ADS auf einen SQL-Server. Mein Favorit ist grade Firebird.

Ein Problem, was ich immer habe, ist die riesige Datenmenge an Dokumenten. Dokumente werden nur zugefügt und werden nicht gelöscht. Das macht bei einem Backup (manchmal über das Internet) regelmäßig Probleme.



Was ich mir nun vorgestellt habe. Alle bestehenden Tabellen kommen in eine Datenbank.

myData.fdb

Die Dokumente (in Blobs gespeichert) landen in einer zweiten Datenbank

myDataDokuments.fdb

Ich möchten nun, dass ab einer bestimmten Größe (ca. 1GB) eine weitere Datenbank angelegt wird

myDataDokuments1.fdb

Die neue Datenbankdatei soll readonly werden. Diese muss nur ein einziges mal gesichert werden. Alle neuen Dokumente landen weiterhin in der bestehenden, nun wieder kleinen Datenbank.

myDataDokuments.fdb.

Sollte diese wieder größer als 1 GB werden, dann wird die nächste Datenbank angelegt

myDataDokuments2.fdb

u.s.w.



Nun zu meiner Frage:

Ist Firebird in der Lage, dies automatisch zu erledigen? Oder muss ich ein Serviceprogramm schreiben, welches regelmäßig aufgerufen wird, die Größe kontrolliert und die beschriebene Aktion durchführt?



Gerne hätte ich auch Ideen, wie man Dokumente ggf. anders speichern kann, ohne immer für ein Backup riesige Datenmengen schaufeln zu müssen.

Hallo Gerd,

Firebird kann das nicht automatisch erledigen.

Generell ist das Aufteilen auf mehrere Datenbanken mit Vorsicht zu genießen, da Dinge wie z.b. FOREGIN KEY Constraints nicht Cross-DB funktionieren, wenn du z.B. archivierte Dokumente auf Stammdaten referenzieren möchtest. Du kannst auch in einem

markieren

Code:

SELECT ...

keine mehreren Datenbank ansprechen, sondern nur umständlicher via

markieren

Code:

EXECUTE STATEMENT ... ON EXTERNAL ...

in PQSL Blöcken.

LG

Vielleicht hilft Dir der Link:
http://www.firebirdsql.org/file/docu...s-clone-nodump

Man kann dann mit GBAK z.B. sowas unter Linux machen:
ALTER DATABASE BEGIN BACKUP
<Backup Prozess>
ALTER DATABASE END BACKUP

konkret:
ALTER DATABASE BEGIN BACKUP
gbak -backup emptest stdout | gbak -replace stdin emptest_2
ALTER DATABASE END BACKUP

Etwas umständlicher dann halt entsprechend unter Windows.

Dateien würde man per se wahrscheinlich gar nicht in die DB speichern, sondern daneben und nur die Links in der DB verwalten. Der einzige Grund, es anders zu machen ist m.E. ein Zugriffsschutz für die Dateien auf dem Client (oder sogar auf dem Server).
Sprich, speziell die Nutzung von FB als Client DB wäre ein Grund, auch Dateien "sicher" in der DB abzulegen um sie dem direkten Nutzerzugriff zu entziehen.
Wenn Du allerdings davon redest, einen Backup Service zu schreiben, könnte man genau das auch gleich für Dateien tun. Also einen Dienst schaffen, der Dateien gezielt an einem sicheren (und uU lokalen) Ort ablegt oder ggF. einen bestehenden einbinden.

Jein. Ist gibt die Möglichkeit eine Datenbank zu erstellen, welche aus mehreren Dateien besteht. (multi-file database). Man kann dan definieren bei welchen Bedingungen dann Sekundärdateien erstellt werden. Dies hat aber einen negativen Effekt auf die Performance.

Von Oracle her kenn ich da nur die "partitioned Tables", da kann man sowas autoatisch machen (Soweit ich weiß, kann das auch MS-SQL).

Denkansätze:

a) Backup-Strategie

Wenn du jedesmal ein Fullbackup machst (also die komplette DB), würd ich erstmal auf inkrementelles Backup umstellen. Dabei erstellst du nur einmalig ein vollständiges Backup, danach werden nur noch die Änderungen gespeichert.


b) Dokument auslagern

Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.


Gruß

Uwe

Zitat von Ghostwalker:

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

Hallo Holger,

Zitat:

Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren ...

Ja, wenn man dann selbst (sehr) viel herumbaut, was du ja mit deiner 9 Punkteliste gezeigt hast. Wollte Gerd nur vermitteln, dass man hier "Out-Of-The Box" wenig Wunder erwarten kann bzw. dass es Cross-DB gewisse Einschränkungen gibt und z.b. kein Löschen in deiner Stammdaten-DB unterbunden wird (z.B. Adresse, Rechnung, Kunde etc.), obwohl dieser Datensatz in der Archiv-DB noch referenziert wird.

LG

Zitat von IBExpert:

Zitat von Ghostwalker:

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

Verstehe ich nicht. Meiner Meinung nach sollte eine moderne Client/Server Anwendung sowieso niemals einem Client direkten Zugriff auf Daten ermöglichen. Weder auf eine Datenbank noch auf serverseitig gespeicherte Dateien. Moderne IT Umgebungen lassen dass sowieso seit Jahren bei uns nicht mehr zu. Es gibt genau eine TCP Verbindung von den Clients zum Server. Demzufolge ist dann der Server exklusiv für die Datenhaltung zuständig. In unserem Fall können dies auch mehrere Terrabytes umfassende Videodaten (=Dateien) sein. Diese in Blobs in einer Datenbank zu speichern wird dann eher schwierig.

Zitat von IBExpert:

Zitat von Ghostwalker:

b) Dokument auslagern
Dokumente würd ich im Filesystem speichern, in der DB nur Links zu den entsprechenden Dateien. Dabeneben stehen in der DB nur die Meta-Daten.

genau das würde ich nicht machen, weil dafür jeder Client Zugriff auf diese Dateien im Dateisystem braucht, das freut jeden Trojaner.

Und wenn die jemand mal in seiner Trotteligkeit versehentlich eine Datei oder gleich ganze Ordner von da verschoben hat, sind deine
Metadaten unbrauchbar, weil da zwar was sein müsste, aber nix ist und keiner weiß warum. Das Filesystem ist in dem Sinne
nicht wirklich transakionssicher, alles readonly machen kann zwar helfen, ist aber umständlich, Filesysteme sind auch nur begrenzt
skalierbar und in der Microsoft Welt auch lizenztechnisch nicht ganz banal.

a) Das ein Client direkten Zugriff auf die Dateien braucht, wär mir neu.

b) Ja...wenn der Administrator Scheiß baut, kann die beste Software nix mehr retten (sprich wenn der die Dateien löscht oder verschiebt).

c) Ein Dateisystem kann genauso skalierbar sein wie jede Datenbank. Wie das bei MS liezenztechnisch aussieht kann ich nicht sagen. Bisher kenn ich nur Systeme
die sowas auf Unix/Linux Ebene machen.

Gruß Uwe

Das kann Firebird sehr wohl und wir machen genau den Ansatz schon so seit Jahren, mit Blobdatenmengen bis hin in den Terabyte Bereich (Ich geh mal davon aus, das dein Begriff Dokument als Blob zu verstehen ist, also pdf oder sonstwas)

Genereller Ansatz:

-Du speicherst deine blobs (pdfs etc.) am besten in eigene Tabelle, in den Tabellen die dazu gehören packst du zum Beispiel nur den fk zu dem Blob in der Blob Tabelle

-Wenn ein neuer Blob inhalt gespeichert werden soll, speicherst du den ganz normal in deiner aktiven Produktionsdatenbank

-Wichtig: wenn dein Client auf einen Blob Inhalt später lesend zugreift, dann machst du das nicht direkt per select auf der Tabelle, sondern über einen select auf einer sp, die den PK als parameter bekommt (ich nenn die hier mal getblob, ist aber nichts eingebautes, sondern ganz simpel selber zu erstellen)

-Du legst dir entweder jährlich oder in welchen Arten auch immer extra DBs an, in denen nichts als die blob tabelle baugleich ist (B2020.fdb, B2019.fdb, B2018.fdb usw)

-In einem simplen Reorg job, der zum Beispiel jede Nacht auf deiner Produktions DB läuft, schiebst du die blob daten, die z.B. älter als x Tage sind oder wie bei uns alle die gestern oder noch älter sind von der Produktions DB in die aktuelle offene Jahres DB (diese ist readwrite)

-Das übertragen geht per execute statement on external in einer sp oder einem execute block transaktionssicher, also delete in production und insert into jahres db ist ein einziger commit, obwohl 2 dbs

-Wenn du einen blob lesen willst, kann anhand der blob tabellen metadaten (timestamp) erkannt werden, wo die zu finden sind. Deine sp getblob macht nun als nicht anderes, als die metadaten zu dem blob auszulesen und per execute statement on external den eigentlich blob inhalt aus der jahres db in den speicher der production db holen und von da als rückgabe von der sp im client anzeigen, in datei packen oder was auchimmer damit machen.

-am jahresende setzt du die jahresdb auf readonly, select mit execute statement on external geht weiterhin, es muss nicht mal eine db auf dem eigenen server sein, sondern kann irgendwo aus der cloud kommen. Deine Getblob sp kann ja zu den metadaten irgendwelche Connectionstring aus einer tabelle auslesen und die dann benutzen.

-archivierte readonly jahresdbs packen wir auch meistens nicht auf schnelle ssds, sondern durchaus auf große hdds, weil die nur ein mal beim read only setzen gesichert werden müssen und dann nie wieder, weil die ja auch nie wieder geändert werden. Da alte Dokument selten geschwindigkeitskritisch sind, reciht das auch von hdds.

Wenn Interesse besteht können wir genau das Thema auch gerne mal nächsten Mittwoch um 17 Uhr im Stammtisch besprechen, weil ich weiss, das viele so eine Anforderungen haben und gerne den ganzen Kram in die db packen, aber dann in Probleme laufen, wenn die db nach wenigen Monaten oder Jahren dann dutzende oder hunderte Gigabyte haben und Backup/Restores endlos dauern.


Ganz wichtig aus meiner sicht: Mit "Nicht Blob Daten" ist das Mumpitz, geht auch, z.B. per datebase trigger oder table trigger, ist aber dann extrem umständlich, damit foreignkey beziehungen in abfragen sauber über mehrere Datenbank abzubilden und bringt nichts an Speed, ganz im Gegenteil.