Назад | Перейти на главную страницу

Репликация слиянием SQL - сжатие снимков

У меня в нашей компании настроена репликация слиянием с центральным SQL 2005, поскольку издатель / распространитель, а все клиенты - это SQL 2005 Express.

В наших удаленных ветках возникают проблемы с начальным временем синхронизации. Размер базы данных составляет ~ 2 ГБ, и на первый запуск уходит больше часа. При устранении неполадок я заметил, что могу указать альтернативное расположение снимка, а затем при желании его сжать.

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

Самая большая загвоздка в том, что CAB-файл может быть очень большим. Если он попытается сделать CAB-файл больше, чем поддерживается, агент моментальных снимков выйдет из строя. Думаю лимит 2 гига.

Для сжатия снимка требуется много ресурсов процессора. У некоторых людей может не хватить мощности процессора. А в локальной сети действительно не было бы никакого смысла, поскольку время создания моментального снимка увеличилось бы без реального уменьшения времени передачи.

Если оба отмечены, то используются оба параметра. Вы не можете сказать ему использовать один или другой, если оба включены.

«Фактически, вы никогда не должны инициализировать подписку со стороны издателя» - не знаю, откуда это взялось, но я определенно не думаю, что это правда. Вы должны создать моментальный снимок публикации, при необходимости опубликовать его на сервере распространения и инициализировать оттуда. Стратегия резервного копирования и восстановления - это устаревшая альтернатива, которая не является рекомендуемым методом.

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

В вашем случае (снимок ~ 2 ГБ) это абсолютно неправильный способ инициализации репликации (путем применения снимка). Фактически, вы никогда не должны инициализировать подписку со стороны издателя. Скорее используйте стратегию резервного копирования и восстановления. http://technet.microsoft.com/en-us/library/ms152488.aspx

  1. Резервная копия публикации db. Разархивируйте (сожмите) файл резервной копии и отправьте его подписчику любым способом.
  2. Восстановите его по подписке db. Обязательно снимите флажок Сохранить параметры репликации (WITH KEEP_REPLICAITON) на странице параметров. Я обычно предпочитаю установить флажок Перезаписать существующую базу данных. и, конечно же, не забудьте проверить имена файлов, поскольку они будут соответствовать пути, присутствующему на издателе.
  3. Создайте подписку и убедитесь, что вы сняли флажок «Инициализировать подписку» в мастере, поскольку вы уже инициализировали ее вручную.

Интересно, почему они пометили это решение как устаревшее с 2005 года, если MS не может предложить его альтернативу.