SQL Server 2005: репликация, VARBINARY

Question

Сценарий

В нашей схеме репликации мы реплицируют количество таблиц, включая photos таблицы, которая содержит двоичные данные изображения. Все остальные таблицы повторяются, как и ожидалось, но таблица фотографий не работает. Я подозреваю, что это связано с большим объемом данных в таблице фотографий или, возможно, потому, что данные изображения являются полем varbinary. Однако использование полей меньшего размера varbinary не помогло.

Config Info

Вот некоторая информация конфигурации:

• Каждое изображение может быть от 65-120 Kb
• Пересмотр и утвержденный экземпляр хранится вместе с эскизами, так однорядные может приблизиться к ~ 800Kb
• У меня когда-то была проблема с полем конфигурации «max text repl size», но я установил его на максимальное значение, используя sp_configure и reconfigure with override
• Фотографии фильтруются на основе «опубликованной» поле, но так и другие рабочие столы
• Базы данных используют один и тот же локальный сервер БД (в среде разработки) и настроены для репликации транзакций
• Реплицированные использует базу «push» подписка

Кроме того, я заметил, что иногда регенерация моментального снимка и повторная инициализация подписки заставляют изображения реплицироваться. Принимая это во внимание, я настроил агент моментального снимка для регенерации моментального снимка каждую минуту или около того для целей отладки (очевидно, это избыток для рабочей среды). Однако это не помогло.

Вопрос

Что вызывает photos таблицу, чтобы не повторить, а все остальные не имеют проблемы? Есть ли способ обойти это? Если нет, как я буду продолжать отладку?

Примечания

Я использовал SQL Server Profiler для поиска ошибок, а также Replication Monitor. Ошибок нет. Насколько мне известно, операция просто терпит неудачу.

Я использую SQL Server 2005 с пакетом обновления 3 на пакет обновления для Windows Server 2003 2.

[обновление]

я обнаружил трудный путь, что Philippe Grondier абсолютно прав в своем ответе ниже. Изображения, видеоролики и другие двоичные файлы не должны храниться в базе данных. IIS обрабатывает эти файлы много более эффективно, чем я могу.

Answer 1

У меня нет прямого ответа на вашу проблему, так как наша стандартная политика всегда была «никогда не хранить (картировать) файлы в (базе данных)».Наше решение, которое относится не только к изображениям, но и любой файл или документ, в настоящее время стандарт:

• У нас есть «документ» таблицы в нашей базе данных, где имена документов/файлов и относительные папки сохраняются (для получения уникальных имен документов/файлов мы генерируем их из значения первичного ключа/uniqueIdentifier таблицы «Документ»).

Этот «документ» таблица реплицируется среди наших различных suscribers, как и все другие таблицы

• У нас есть «документ» папку и вложенные папки, доступные на каждом из наших серверов баз данных.
• Папки документов затем реплицируются независимо от базы данных, с некоторыми программами репликации файлов и папок (allwaysynch является опцией)
• Папки главного издателя полностью доступны через ftp, где пользователь пытается прочитать документ (по-прежнему) недоступен на его локальном сервере будет предложено загрузить его с основного сервера через клиентское программное обеспечение ftp (например, coreFTP и его параметры командной строки)

Answer 2

С таблицей изображений, подобной этому, рассмотрели ли вы перемещение этой статьи на односторонний (или двусторонний, если хотите) объединить публикацию? Это может облегчить некоторые из ваших проблем.