Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
← Октябрь 2001 → | ||||||
1
|
2
|
3
|
5
|
6
|
7
|
|
---|---|---|---|---|---|---|
8
|
9
|
10
|
11
|
12
|
13
|
14
|
15
|
16
|
17
|
19
|
20
|
21
|
|
22
|
23
|
24
|
26
|
27
|
28
|
|
29
|
30
|
31
|
Статистика
-20 за неделю
MS SQL Server - дело тонкое...
#068<< #069 |
СОВЕТЫ
Установка Merge репликации: Пошаговое руководство
В этой статье рассматриваются некоторые важные темы организации репликации Microsoft SQL Server:
топология репликации, типы и агенты репликации. Также обсуждается Merge репликация: как создать
необходимые условия для этого типа репликации и как резервировать и восстановить базы данных при
таком сценарии репликации. Во время иллюстрации этой концепции, предлагается пошаговое руководство
по установке процесса Merge репликации. Топология репликации
Microsoft SQL Server поддерживает следующие топологии репликации:
Центральный publisher Типы репликации
Microsoft SQL Server 7.0/2000 поддерживает следующие виды репликации:
Snapshot репликация является самой простой. При этом, все копируемые данные (точная копия) будут
копироваться из базы данных publisher в базу(ы) данных subscriber/subscribers на периодической
основе. Snapshot репликация является лучшим методом копирования данных, которые нечасто изменяется
и когда размер копируемых данных не очень большой. Агенты Репликации
Microsoft SQL Server 7.0/2000 поддерживает следующих агентов репликации:
Snapshot Agent - это агент репликации, который создаёт файлы снимков, хранит снимки на distributor
и производит запись информации о состоянии синхронизации в Distribution database. Snapshot Agent
используется во всех типах репликации (Snapshot, Transactional и Merge) и может управляться из
SQL Server Enterprise Manager. Проверка необходимых условий
Проверьте соблюдение следующих необходимых условий для установки Merge репликации: Пошаговый пример настройки Merge репликации В этом примере, я буду использовать только один сервер, который будет участвовать в репликации данных, как publisher, subscriber и обслуживать базу данных distributor. Я буду использовать Merge репликацию с push подпиской. Чтобы устанавливать Merge репликацию, Вы можете использовать GUI интерфейс SQL Server Enterprise Manager. Кроме того, имея права администратора можно выполнять системные хранимые процедуры SQL Server. Но поскольку первый путь проще и более понятен, я буду использовать именно его. ШАГ - 1
Прежде всего, Вы должны зарегистрировать новый удаленный сервер, который нужно реплицировать.
Поскольку я использую в репликации только один сервер, я не должен этого делать. ШАГ - 2
Теперь мы готовы начать создание публикаций и статей. Замечание автора перевода: если Вы в качестве дистрибутора выбрали SQL Server 7.0, а реплицировать собираетесь SQL Server 2000, у Вас появится не это окно, а окно, предлагающее выбрать другой сервер для дистрибутора, т.к. такой вариант репликации не поддерживается.. Далее процесс настройки дистрибутора будет схож с описанным выше.
Выберите базу данных pubs, и после нажатия кнопки "Next", выбираете Merge publication, опять же
нажав после этого кнопку "Next" в окне "Select Publication Type". В следующем окне (Select
Subscribers Types), выделите всё из имеющихся там типы подписчиков, от которых ожидается оформление
подписки на эту публикацию (publication) и опять щёлкните кнопкой "Next". В окне "Specify Articles"
поставьте галочку в чекбоксе "Publish All", что приведёт к изданию всех таблиц базы данных pubs и
щёлкните кнопкой "Next". ШАГ - 3
Теперь Вы можете создавать подписку. Щелкните кнопку "Push New Subscription" в окне "Create and
Manage Publications", которое появилось на экране после завершения создания публикации. Будет
запущен "Push Subscription Wizard", в следующем окне которого (Coose Subscribers) нужно щёлкнуть
по "SQL Server Group" выделить всех подписчиков в имеющихся у меня группах CHIGRIK и CHIGRIK\SQL2000,
после чего - "Next". ШАГ - 4 Последний шаг, который рекомендуется сделать при установке Merge репликации, предполагает создание сценария конфигурации Ваших текущих параметров репликации. Это может быть полезно при восстановлении этих параметров в случае отказа сервера. Для этого нужно выбрать в пункте "Tools", пункт из выпадающего меню "Replication", а в его окошке пункт "Generate SQL Script...". Стратегии резервирования и восстановления Резервное копирование и восстановление отличаются для каждого из типов репликации. Здесь, я хочу описать стратегии резервирования и восстановления для Merge репликации. Поскольку Merge репликации более сложная, чем Snapshot или Transactional репликации, и обычно используется, когда Вы хотите обновить данные относительно и publisher и подписчиков, Вам придётся потратить большее времени и внимания на планирование стратегий резервирования и восстановления. Есть четыре главных стратегии поддержки и восстановления Merge репликации:
- Резервирование publisher, master и model. баз данных.
Резервирование publisher, master и model. баз данных - это самая простая стратегия. Эта стратегия
имеет как преимущества, так и недостатки. Преимуществом является то, что задействуется наименьшее
количество ресурсов памяти и не требуется координации резервной копии с резервными копиями других
серверов. Главный недостаток этой стратегии - это то, что придётся заново устанавливать репликацию
в случае отказа distributor или publisher. В этой стратегии, Вы должны резервировать базу данных
publication после её изменений, после добавления новой публикации, или всякий раз, когда сделаны
изменения в копируемой схеме объектов (например, добавлен или удалён столбец).
Литература
Репликация транзакций, выполняющаяся в Non-Continous режиме Если Вы использовали репликацию транзакций, Вы вероятно обратили внимание на одну из устанавливаемых в мастере опций, где Вы должны выбрать или непрерывный или планируемый по расписанию запуск агента дистрибуции. Push Subscription Wizard/Set Distribution Agent Sedule/Using the following shedule:
Я предполагаю, что большинство подписчиков используют непрерывную работу этого агента, главным
образом потому, что этот вариант предлагается по умолчанию. Изменение этой опции позволяет
осуществлять репликацию по расписанию, что уменьшает загрузку сервера, пока агент находится в
состоянии ожидания. -Publisher [ANDY] -PublisherDB [DEADLOCK] -Distributor [ANDY] -DistributorSecurityMode 1 -Continuous
Обратите внимание на параметр '-Continuous'. Это означает, что после того, когда Вы определили
подписку, чтобы распределить транзакции подписчику, log reader не перестанет контролировать журнал
транзакций и записывать транзакции базы данных дистрибутора (издателя). Каждый log reader агент
(logread.exe, один на публикацию) использует приблизительно 1700КБ памяти. Это - не большое
отвлечение ресурсов, но высвобождение их положительно скажется на распределение памяти и уменьшит
загрузку сервера. Новости проекта SQL.RU Есть хорошая новость - скоро будет выходить печатный вариант журнала SQL Server Online, пока в виде приложения к Windows 2000. Распространяться он будет только по подписке. Первое время содержание печатного и cетевого вариантов не будут пересекаться, но приблизительно через квартал статьи, напечатанные в журнале, будут выкладываться в сеть, дополняя сетевую версию журнала. ССЫЛКИ НА СТАТЬИ
Понятие "Качество данных" и его значение для информационных технологий Новые технические статьи Microsoft
FIX:
Inconsistent Results Reported by TOP N Using Full-Text CONTAINSTABLE (Q309450) ФОРУМ SQL.RU: САМЫЕ ПОПУЛЯРНЫЕ ТОПИКИ НЕДЕЛИ
Refresh
таблиц или аналог IBEvents для MSSQL ФОРУМ SQL.RU: ВОПРОСЫ ОСТАЛИСЬ БЕЗ ОТВЕТА
Как
проверить ХП? |
#068<< #069 |
|
http://subscribe.ru/
E-mail: ask@subscribe.ru |
Отписаться
Убрать рекламу | Рейтингуется SpyLog |
В избранное | ||