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

Сценарий

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

Информация о конфигурации

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

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

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

Вопрос

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

Примечания

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

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

[Обновить]

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

replication sql-server-2005 varbinary

brad 10.04.2009 источник

comment

Какой пакет обновления и / или накопительные обновления вы используете на каждом сервере издателя, дистрибьютора и подписчика? Возможно, это ошибка регресса между версиями. - devstuff 15.04.2009

comment

@devstuff Пакет обновления 3 для SQL Server в Windows Server 2003 с пакетом обновления 2 (также добавлен в вопрос) - brad 15.04.2009

Ответы (2)

arrow_upward
4
arrow_downward

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

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

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

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

Philippe Grondier 14.04.2009

arrow_upward
0
arrow_downward

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

Adam Robinson 19.04.2009