SQL Server 2005: Replikation, varbinär

Question

Szenario

In unserem Replikationsschema replizieren wir eine Reihe von Tabellen, darunter eine photos Tabelle, die binäre Bilddaten enthält. Alle anderen Tabellen werden wie erwartet repliziert, die Tabelle "Fotos" jedoch nicht. Ich vermute, dass dies an der größeren Datenmenge in der Fototabelle liegt oder vielleicht daran, dass die Bilddaten ein varbinary Feld. Die Verwendung kleinerer varbinary Felder haben nicht geholfen.

Informationen zur Konfiguration

Hier sind einige Informationen zur Konfiguration:

• Jedes Bild kann zwischen 65 und 120 Kb groß sein.
• Eine überarbeitete und genehmigte Kopie wird zusammen mit Miniaturbildern gespeichert, so dass eine einzelne Zeile bis zu 800 KB groß sein kann.
• Ich hatte einmal Probleme mit dem " max text repl size "Konfigurationsfeld, aber ich habe es auf den Maximalwert gesetzt, indem ich sp_configure y reconfigure with override
• Fotos werden auf der Grundlage eines Feldes "veröffentlicht" gefiltert, aber auch andere Arbeitstabellen
• Die Datenbanken verwenden denselben lokalen DB-Server (in der Entwicklungsumgebung) und sind für die transaktionale Replikation konfiguriert
• Die replizierte Datenbank verwendet ein "Push"-Abonnement

Außerdem ist mir aufgefallen, dass die Bilder manchmal durch die Wiederherstellung des Snapshots und die Neuinitialisierung des Abonnements repliziert werden. Aus diesem Grund habe ich den Snapshot-Agenten so konfiguriert, dass er den Snapshot zu Debugging-Zwecken etwa jede Minute neu generiert (was in einer Produktionsumgebung natürlich übertrieben ist). Dies hat jedoch nicht geholfen.

Die Frage

Was ist die Ursache für die photos Tabelle nicht zu replizieren, während bei allen anderen kein Problem auftritt? Gibt es eine Möglichkeit, dieses Problem zu umgehen? Wenn nicht, wie könnte ich die Fehlersuche fortsetzen?

Notas

Ich habe SQL Server Profiler verwendet, um nach Fehlern zu suchen, und auch den Replikationsmonitor. Es liegen keine Fehler vor. Der Vorgang schlägt einfach stillschweigend fehl, soweit ich das beurteilen kann.

Ich verwende SQL Server 2005 mit Service Pack 3 auf Windows Server 2003 Service Pack 2.

[Update]

Ich habe auf die harte Tour herausgefunden, dass Philippe Grondier hat mit seiner nachstehenden Antwort völlig recht. Bilder, Videos und andere binäre Dateien sollten nicht in der Datenbank gespeichert werden. IIS verwaltet diese Dateien viel effizienter als ich es kann.

Answer 1

Ich habe keine direkte Antwort auf Ihr Problem, da unsere Standardpolitik schon immer lautete: "Speichern Sie niemals (Bild-)Dateien in (Datenbank-)Feldern". Unsere Lösung, die nicht nur für Bilder, sondern für alle Arten von Dateien oder Dokumenten gilt, ist jetzt Standard:

• In unserer Datenbank gibt es eine Tabelle "Dokument", in der Dokument-/Dateinamen und die zugehörigen Ordner gespeichert werden (um eindeutige Dokument-/Dateinamen zu erhalten, werden diese aus dem Primärschlüssel/uniqueIdentifier-Wert der Tabelle "Dokument" generiert).

Diese "Dokumententabelle" wird, wie alle anderen Tabellen auch, zwischen unseren verschiedenen Teilnehmern repliziert.

• Wir haben einen Ordner "Dokument" und Unterordner, die auf jedem unserer Datenbank-Servern.
• Die Dokumentenordner werden dann unabhängig von der Datenbank mit einer Software zur Replikation von Dateien und Ordnern repliziert (allwaysynch ist eine Option).
• die Ordner des Hauptverlags sind vollständig über ftp zugänglich, so dass einem Benutzer, der ein auf seinem lokalen Server (noch) nicht verfügbares Dokument lesen möchte, vorgeschlagen wird, es über eine ftp-Client-Software (wie coreFTP und seine Befehlszeilenoptionen) vom Hauptserver herunterzuladen

Answer 2

Haben Sie bei einer solchen Bildtabelle schon einmal darüber nachgedacht, den Artikel in eine einseitige (oder zweiseitige, wenn Sie wollen) Merge-Veröffentlichung zu verschieben? Das könnte einige Ihrer Probleme lindern.