Репликация слиянием SQL - сжатие снимка
В нашей компании настроена репликация слиянием с центральным SQL 2005 в качестве издателя / распространителя, и все клиенты являются SQL 2005 Express.
В наших удаленных ветках у нас возникают трудности с начальным временем синхронизации. База данных составляет ~2 ГБ и занимает более часа для первого запуска. При устранении неполадок я заметил, что могу указать альтернативное расположение снимка, а затем при необходимости сжать его.
Я попробовал это (сжатие), и это сжимает это значительно, но мне интересно, что я должен знать при включении этого. Я заметил, что это один файл.cab в сжатом виде по сравнению со всеми отдельными файлами сценариев ранее.
Какие уловы?
Почему бы вам не всегда использовать сжатый формат?
Если оба параметра оставлены отмеченными, по умолчанию и поочередно сжаты, как я могу сказать ему использовать один или другой?
3 ответа
Самый большой улов в том, что CAB-файл может быть настолько большим. Если он попытался сделать CAB-файл больше, чем поддерживается, агент моментальных снимков потерпит крах. Я думаю, что предел составляет 2 гига.
Для сжатия снимка требуется много ресурсов процессора. У некоторых людей может не хватить мощности процессора. А в локальной сети не было бы никакого смысла, поскольку время для создания моментального снимка увеличилось бы без реального уменьшения времени передачи.
Если оба проверены, то используются оба параметра. Вы не можете сказать ему использовать один или другой, если оба включены.
"Фактически, вы никогда не должны инициализировать подписку со стороны издателя" - не знаю, откуда это берется, но я определенно не думаю, что это правда. Вы должны создать моментальный снимок в публикации, опционально опубликовать его на сервере распространения и выполнить инициализацию оттуда. Стратегия резервного копирования и восстановления - это устаревшая альтернатива, которая не рекомендуется.
Правильный ответ mrdenny: компромисс со сжатой папкой моментальных снимков - это вычислительная мощность, необходимая для сжатия для издателя и распаковки для подписчика. Для меньших снимков вы получите лучшую производительность из несжатого снимка, но для больших (как у вас) вы, скорее всего, получите лучшую производительность с помощью сжатия, испытания помогут определить лучший метод.
В вашем случае (снимок ~ 2 ГБ) это абсолютно неправильный способ инициализации репликации (путем применения снимка). На самом деле вы никогда не должны инициализировать подписку со стороны издателя. Скорее используйте стратегию резервного копирования-восстановления. http://technet.microsoft.com/en-us/library/ms152488.aspx
- Резервное копирование БД. Разархивируйте (сожмите) файл резервной копии и отправьте его подписчику любым способом.
- Восстановите его по подписке на БД. Обязательно снимите флажок "Сохранить параметры репликации" (WITH KEEP_REPLICAITON) на странице "Параметры". Я обычно предпочитаю проверять перезапись существующей базы данных. и, конечно же, не забудьте проверить имена файлов, поскольку они будут иметь путь, указанный в издателе.
- Создайте подписку и убедитесь, что вы сняли флажок Инициализировать подписку в мастере, поскольку вы уже инициализировали ее вручную.
Интересно, почему они пометили это решение как устаревшее с 2005 года, если MS не может предложить свою альтернативу.