SQL Server 2005: репликация, varbinary - PullRequest
Новая
       10

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

3 голосов
/ 10 апреля 2009

Сценарий

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

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

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

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

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

Вопрос

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

Примечания

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

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

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

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

Ответы [ 2 ]

4 голосов
/ 15 апреля 2009

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

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

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

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

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

...