Anhänge in DB's auslagern

[w3dev]

Hallo liebe Leute,

hat sich von euch schon mal jemand Gedanken um die Auslagerung von Anhängen in andere DB's gemacht?

Ich steh momentan vor der Aufgabe Anhänge aus einer DB, die so langsam die 64GB grenze erreicht, in kleinere DB's (4GB, damit sie auch auf ne CD passen) auszulagern. Ein Konzept für die Funktionalität des Auslagerns und Erstellens der Auslagerungs-DBs, sowie die Synkronisierung der Zugriffsrechte hab ich bereits gemacht.

Grobe Konzeptbeschreibung:

Agent auf Server (Neue und gespeicherte Dokumente, läuft auf allen Repliken):
Nimmt Anhänge (Typ und mind. Größe wählbar) aus Dokumenten und kopiert jeden in ein eigenes Dokument in einer Auslagerungs-DB. Replik-ID und UNID speichert er gemeinsam mit dem Namen des Anhangs in einem Feld im Original Dokument. Im RT-Feld wird der Original Anhang entfernt und eine Dokumentverknüpfung mit dem Namen des Anhangs an diese Stelle gesetzt (so lässt sich später wieder eine Verbindung von Position im RT und Anhang herstellen). Die Auslagerungs-DBs werden mit auf alle Server repliziert, sodass immer Zugriff besteht.
Ausserdem Synkronisiert er bei erneut gespeicherten Dokumenten mit ausgelagerten Anhängen die Zugriffsrechte zu den Anhangsdokumenten.

Für Gleiche ACLs wird gesorgt.


Jetzt stellt sich bei mir die Frage nach Gefahren durch die Replizierkonflikte oder
vielleicht hat ja jemand von euch andere Ansätze oder sieht andere Gefahren, die ich noch nicht sehe.

Bin für alle Anregungen dankbar. Merci


Ronny

[koehlerbv]

Was mir jetzt spontan einfällt: Speichere unbedingt einen eindeutigen Key in beiden Dokumenten (Haupt-DB, Auslagerungs-DB). Falls es mal die Auslagerungs-DB reisst und nur noch eine neue Kopie hilft, kannst Du dann die ganzen Links rekonstruieren.

Bernhard

[w3dev]

Stimmt, Sicher is sicher 

[koehlerbv]

Eben. Für mich ist Murphy's law oberste Regel. Damit bin ich - auch wenn das manchmal einen ordentlichen Aufwand bedeutet, der einem aber wieder entschädigt wird! - bisher immer bestens gefahren. Meine Kunden natürlich auch 
Ich glaube, mein Rekordhalter ist ein Agent, der nach knapp 500 Zeilen Code erst anfängt, seinen eigentlichen Job zu tun. Vorher wird alles mögliche abgeprüft, damit dabei auch ja nichts schief geht.

Bernhard

[w3dev]

In diese Richtung (Sicherheit) geht auch meine Arbeitsweise. Meine Bedenken bei dieser ganzen Funktionalität sind einfach Replizierkonflikte mit Clients, die ein neues Dokument erstellen, was nach dem Replizieren auf dem Server vom agenten bearbeitet wird und bevor der Client erneut repliziert nochmals dort geändert wird.

[LN4ever]

Jedesmal, wenn ein Client ein Dokument abspeichert, wird ein Feld gesetzt, dessen Existenz ein erneutes Editieren durch den Client verhindert (POSTOPEN und QUERYMODECHANGE-Events). Der Agent entfernt dieses Feld wieder.

Damit ist es dem Anwender möglich, ein Dokument zu erstellen und nach der Bearbeitung durch den Agenten auch wieder zu ändern, aber es ist nicht möglich, das Dokument zwischen zwei Agentenläufen zu ändern.

Das verhindert Replizierkonflikte.

Dein Satz "(Neue und gespeicherte Dokumente, läuft auf allen Repliken)" macht mich stutzig. Das "läuft auf allen Repliken" kann dir Replizierkonflikte en mass bescheren. Ich würde nie einen Stern für den Servernamen einsetzen, auf dem ein periodischer Agent ausgeführt wird, der Dokumente ändert.

Gruß

Norbert

[w3dev]

Feld setzen:
Normalerweise würde ich auch so vorgehen, nur handelt es sich bei dieser Anwendung um ein Ablagesystem, in das Dokumente importiert und abgelegt werden. Da muss ein mehrmaliges Bearbeiten (Importieren, Ablegen usw) in kurzen Abständen gewährleistet sein. aber nichts desto trotz kann man diesen Flag nach der Ablage setzen und so vorgehen, wie von dir vorgeschlagen.


Neue und gespeicherte Dokumente, läuft auf allen Repliken:
Stimmt, war'n gedanklicher Fehler.

Merci für deine Tips

[LN4ever]

Du kannst natürlich die Sperrung mit dem "Schalter" erweitern um eine Abfrage, ob dein Datensatz (mit Schalter) nach dem LASTMODIFIED bereits repliziert wurde und die Editierung so lange offen halten.

Ich habe gerade eine Klasse gefunden, mit der man die ReplicationHistory auslesen kann.

http://forum.codeby.net/topic12026.html

Der Beitrag vom 25.1.2007 13:55 ist gemeint.

Auszug (zum Suchen):
Public Function IsReplicatedAfter(TimeMark As Variant, Mode As Integer) As Integer
'    Mode = 1 - Send
'          2 - Receive    or 1+2


Wenn du jetzt ganz sicher gehen willst, mußt du auch noch beim Abspeichern prüfen, ob es bereits eine Replikation gab. Die Dankbarkeit der Anwender wird sich in Grenzen halten, wenn du ihnen das Editieren erlaubst, aber das ABspeichern untersagst.

Gruß

Norbert