Как удалить репликацию ms sql

Как исправить испорченную репликацию на MS SQL Server

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

Сначала я пытаюсь избавиться от подписки (на сервере издателя):

Это похоже на работу. SELECT * FROM syssubscriptions не показывает результатов. Глядя на сервер подписчика, SSMS> > Репликация> Локальные подписки — подписки там нет.

Тогда я пытаюсь удалить публикацию. SSMS> <Сервер>> Репликация> Локальные публикации> > Удалить. Это дает следующее сообщение об ошибке:

Итак, я пытаюсь отбросить статьи:

и получите эту ошибку:

Итак, я пытаюсь запустить агент моментальных снимков и получаю следующее внутреннее исключение SQL:

Поэтому я попробовал альтернативный метод удаления статьи DELETE FROM sysarticles . Кажется, это сработало — теперь я избавился от статей, но все равно получаю ту же ошибку «Невозможно удалить публикацию, потому что существует хотя бы одна подписка на эту публикацию» при попытке удалить публикацию.

Я также перезапустил SQL Server — не помогло.

Я не знаю, что здесь происходит и как мне это исправить?

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

Вручную удалите репликацию в SQL Server

В этой статье объясняется, как вручную удалить репликацию в SQL Server.

Оригинальная версия продукта: SQL Server
Исходный номер КБ: 324401

Сводка

В этой статье описывается, как удалить репликацию с компьютера, на который Microsoft SQL Server. Чтобы удалить репликацию, необходимо отказаться от подписок, публикаций и дистрибьютора, настроенного для репликации. Репликацию можно удалить, запуская сценарий Transact-SQL, созданный SQL Server Enterprise manager или SQL Server Management Studio. Однако если вы не можете создать сценарий Transact-SQL для удаления репликации, вы можете вручную удалить репликацию с помощью системных процедур и других SQL отчетов. В этой статье содержатся сведения о системных процедурах, которые можно использовать в этом процессе.

Дополнительные сведения о процедурах, хранимых в системе, которые упоминаются в этой статье, см. в SQL Server Books Online.

Вручную удалить репликацию

Репликацию вручную можно удалить с помощью системных процедур и других SQL transact-SQL. Чтобы полностью удалить репликацию, выполните следующие действия:

1. Отбросить все подписки, настроенные для репликации.
2. Отбросить все публикации, настроенные для репликации.
3. Отобьют дистрибьютора, настроенного для репликации.

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

Сброс подписки

Чтобы отказаться от подписки из экземпляра SQL Server, можно использовать следующие сохраненные процедуры и соответствующие параметры:

sp_dropsubscription : С помощью процедуры системного хранения можно отказаться от подписки на определенную статью, публикацию или набор подписок на sp_dropsubscription Publisher. Необходимо выполнить процедуру хранения на сервере Publisher в базе данных публикации.

sp_droppullsubscription : Вы можете использовать процедуру хранения системы, чтобы отказаться sp_droppullsubscription от подписки в текущей базе данных абонента. Необходимо выполнить сохраненную процедуру в абоненте в базе данных подписки pull.

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

sp_dropmergepullsubscription . Вы можете использовать sp_dropmergepullsubscription процедуру хранения системы, чтобы отказаться от подписки на объединение. Необходимо выполнить сохраненную процедуру в абоненте в базе данных подписки pull.

Drop snapshot subscriptions

Чтобы отказаться от push-подписки на все статьи для публикации снимков, запустите следующий сценарий в Publisher:

Чтобы отказаться от подписки на снимок снимка во все статьи для публикации снимка, выполните следующие действия:

Запустите следующий SQL скрипт в Абоненте:

Запустите следующий сценарий в Publisher:

Drop a transactional subscription

Чтобы отказаться от push-подписки на все статьи для транзакционной публикации, запустите следующий сценарий в Publisher:

Чтобы отказаться от подписки на тянуть все статьи для транзакционной публикации, выполните следующие действия:

Запустите следующий скрипт в абоненте:

Запустите следующий сценарий в Publisher:

Drop a merge subscription

Чтобы отказаться от push-подписки, запустите следующий сценарий в Publisher:

Чтобы отказаться от подписки на тянуть, выполните следующие действия:

Запустите следующий скрипт в абоненте:

Запустите следующий сценарий в Publisher:

Падение публикаций

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

• sp_droppublication : Вы можете использовать процедуру хранения системы, чтобы отказаться от публикации и статей, связанных sp_droppublication с публикацией. Процедуру хранения необходимо выполнить в Publisher в базе данных публикации.
• sp_dropmergepublication : Вы можете использовать процедуру хранения системы, чтобы отказаться от публикации слияния и агента моментального снимка, связанного sp_dropmergepublication с публикацией слияния. Статьи, связанные с публикацией, также отброшены. Процедуру хранения необходимо выполнить в Publisher в базе данных публикации.
• sp_replicationdboption . Вы можете использовать процедуру хранения системы для набора параметра базы данных sp_replicationdboption репликации для текущей базы данных. Необходимо выполнить процедуру хранения на Publisher сервере.

Чтобы снять публикацию снимка, запустите следующий сценарий в Publisher:

Чтобы отказаться от публикации транзакций, запустите следующий сценарий в Publisher:

Чтобы отказаться от публикации слияния, запустите следующий сценарий в Publisher:

Drop the distributor

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

sp_dropsubscriber : Вы можете использовать процедуру хранения системы, чтобы отбросить обозначение sp_dropsubscriber абонента с зарегистрированного сервера. Сохраненная процедура удаляет запись реестра для абонента. Сохраненная процедура работает по Publisher в базе данных публикации.

sp_dropdistributor . Вы можете использовать sp_dropdistributor процедуру хранения системы для удаления дистрибьютора. Сохраненная процедура проводится в дистрибьюторе. Чтобы отбросить обозначение абонента из Publisher, запустите следующий сценарий в Publisher:

Чтобы удалить дистрибьютора, запустите следующий скрипт в дистрибьюторе:

Использование сохраненных процедур

При удалите репликацию можно также использовать следующие сохраненные процедуры:

sp_removedbreplication : Вы можете использовать процедуру хранения системы, чтобы удалить все объекты репликации из базы данных без обновления данных sp_removedbreplication в дистрибьюторе. Вы должны выполнить процедуру хранения в Publisher в базе данных публикации или в Абоненте в базе данных подписки. Ниже приводится синтаксис для этой сохраненной процедуры:

sp_droparticle : Вы можете использовать процедуру хранения системы, чтобы снять статью из публикации снимка sp_droparticle или из транзакционной публикации. Нельзя удалить статью, если еще существует одна или несколько подписок на опубликованную статью. Процедуру хранения необходимо выполнить в Publisher в базе данных публикации. Ниже приводится синтаксис для этой сохраненной процедуры:

SQL-Ex blog

Внутренняя структура транзакционной репликации в SQL Server

Транзакционная репликация в SQL Server является одним из наиболее общих методов репликации, используемой для копирования, распределения или предоставления данных множеству потребителей. В этой статье мы обсудим репликацию, её различные виды, уделив особое внимание работе транзакционной репликации.

Что такое транзакционная репликация SQL?

Репликация — это технология SQL Server для копирования или распределения данных из одной базы данных в другую с поддержкой согласованности данных.

• на том же экземпляре или на другом экземпляре того же сервера;
• или по серверам в одном или нескольких местах.

Архитектура и методы репликации в SQL Server

• Издатель (Publisher) — экземпляр базы данных источника, который публикует изменения данных, которые могут распределяться на другие базы данных. Данные от единственного издателя могут посылаться единственному подписчику или множеству подписчиков.
• Подписчик (Subscriber) — экземпляр базы данных места назначения, куда мы распространяем изменения данных, происходящие в базе данных издателя. Подписчиком может быть либо экземпляр издателя, либо другой экземпляр на сервере издателя или другой сервер в том же местоположении или удаленном местоположении. Перед распределением изменений данных на экземпляр базы данных подписчика данные сохраняются в распределителе (Distributor).
• Распределитель (Distributor) — это база данных, которая хранит журналы изменений, взятые из баз данных издателя. Если сервер включен как распределитель, он создаст системную базу данных с именем distribution database.

— Локальный распределитель — база данных распределителя, находящаяся на экземпляре базы данных издателя.
— Удаленный распределитель — база данных распределителя, находящаяся либо на экземпляре базы данных подписчика, либо на любом другом экземпляре SQL Server вне экземпляра базы данных издателя.

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

В зависимости от способа, каким образом будут пересылаться данные из базы данных распределителя на экземпляр подписчика, он может классифицироваться либо как Push, либо как Pull подписка.

• Статьи (Articles) — основная единица репликации. Она указывает на любые изменения данных на этом объекте базы данных, или статье, которые будут реплицированы из издателя на подписчика. Статьей может быть таблица, представление, индексированное представление, хранимая процедура или определенная пользователем функция.
• Публикации (Publications) — коллекция одной или более статей из базы данных на издателе.
• Подписка (Subscription) определяет, какая публикация будет получена. Кроме того, она определяет, из какой публикации и по какому расписанию реплицируются данные. Подписка может быть либо Push, либо Pull (из публикации в подписку).
• Агенты репликации (Replication Agents) — автономные программы, ответственные за отслеживание изменений и распределение данных от издателя к распределителю и подписчику. Все агенты репликации выполняются как задания (job) под управлением SQL Server Agent. Таким образом, этим можно управлять через SSMS в разделе SQL Server Agent Jobs или Replication Monitor. Имеются следующие типы агентов репликации:
• Агент снимка (Snapshot Agent) — используется почти всеми типами репликации. Агент снимка выполняется на сервере, содержащем базу данных распределения. Он подготавливает схему и исходные данные всех статей, включенных в публикацию на издателе. Кроме того, он создает файлы снимка в папке снимков и записывает подробности синхронизации в базу данных распределения.
• Агент читателя журнала (Log Reader Agent) — используется транзакционной репликацией. Целью является чтение изменений данных статей, доступных для репликации из журналов транзакций базы данных издателя и хранящихся в базе данных распределения. Агент читателя журнала выполняется на сервере распределителя.
• Агент распределения (Distribution Agent) — используется транзакционной репликацией и репликацией снимка. Он применяет исходные файлы снимка и инкрементальные или доступные ожидающие транзакции из базы данных распределителя к базе данных подписчика. Агент распределения выполняется на сервере распределителя для подписок Push и на сервере подписчика для подписок Pull.
• Агент слияния (Merge Agent) — используется только в репликации слиянием. Он применяет исходные файлы снимка и согласовывает дифференциальные или инкрементальные изменения на подписчике или издателе. Агент слияния выполняется на сервере распределителя для репликации Push и из сервера подписчика для подписок Pull.
• Агент читателя очереди (Queue Reader Agent) — Агент читателя очереди используется транзакционной репликацией с опцией обновления очереди. Он перемещает обновления от подписчика на издателя. Агент читателя очереди выполняется из сервера распределителя.
• Задания обслуживания репликации (Replication Maintenance Jobs ) — Как объяснялось ранее, все агенты репликации являются автономными программами, устанавливаемыми во время конфигурирования репликации. Они выполняются как задания (job) из раздела SQL Server Agent Jobs. Следует отметить несколько важных задач очистки распределения — Distribution Clean Up: Distribution, Agent History Clean Up: Distribution, and Expired Subscription Clean Up.

Типы репликации в SQL Server

1. Транзакционная репликация. Как говорит название, каждая транзакция или изменение данных в рамках транзакции на издателе будет посылаться подписчику почти в реальном времени с минимальной задержкой, зависящей от пропускной способности сети и ресурсов сервера. Транзакционная репликация использует агента читателя журнала для чтения изменения данных из журналов транзакций в базе данных издателя. Она также использует агента распределения для применения изменений на подписчике. Иногда может использоваться агент снимка для получения исходных данных снимка всех реплицированных статей. Публикация транзакционной репликации может подпадать под следующие категории:
   • Стандартная транзакционная репликация — подписчик представляет собой базу данных только на чтение с точки зрения транзакционной репликации. Любые изменения, выполняемые кем угодно в базе данных подписчика не будут отслеживаться и обновляться в базе данных издателя. Стандартная транзакционная репликация часто называется просто транзакционной репликацией.
   • Транзакционная репликация с обновляемыми подписками является расширением стандартной транзакционной репликации, которая отслеживает изменения данных, имеющих место на подписчике. Всякий раз, когда изменения происходят на обновляемой подписке, они будут сначала распространяться на издателя, а затем по другим подписчикам.
   • Одноранговая репликация является расширением стандартной транзакционной репликации. Она распространяет транзакционно согласованные изменения почти в реальном времени по множеству экземпляров сервера.
   • Двунаправленная репликация является расширением стандартной транзакционной репликации, которая позволяет двум серверам (ограничение только на 2 сервера — отсюда название «двунаправленная») обмениваться изменениями данных между собой с каждым из серверов, работающих как издатель (для пересылки изменений на другой сервер) или как подписчик (для получения изменений с другого сервера).

2. Репликация слиянием — поддерживает регистрацию изменений данных, происходящих как на издателе, так и на подписчике, и распространяет их на другой сервер. Репликация слиянием требует наличия столбца ROWGUID в таблицах статей, вовлеченных в репликацию слиянием. Она использует триггеры для захвата изменений данных на издателе и подписчике. Кроме того, доставляет изменения на серверы, когда оба и издатель, и подписчик, подключены к сети. Репликация слиянием использует агента слияния для репликации изменений данных на издателе и подписчике.
3. Репликация снимками — как говорит название, репликация снимками не опирается ни на журналы транзакций, ни на триггеры для регистрации изменений. Она берет снимок статей, участвующих в публикации и применяет его на подписчике с записями, имеющимися на время создания снимка. Репликация снимками использует агента снимка, чтобы взять снимок издателя, и использует агента распространения, чтобы применить эти записи на подписчике.

Транзакционная репликация в SQL Server

Транзакционная репликация обычно предпочтительна в сценариях, когда база данных OLTP на издателе испытывает интенсивное изменение данных операторами INSERT/UPDATE и/или DELETE.

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

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

Мы можем обобщить работу транзакционной репликации. Посмотрите ниже диаграмму архитектуры транзакционной репликации, заимствованную из официальной документации Майкрософт.

Публикация создается в базе данных издателя, которая состоит из списка статей для репликации в базу данных подписчика.

Транзакционная репликация обычно будет инициализироваться к распространителю на издателе через агента снимка или полные резервные копии. Агент снимка поддерживается мастером конфигурации репликации. Полный бэкап поддерживается посредством операторов T-SQL для инициализации транзакционной репликации.

Агент читателя журнала сканирует журнал транзакций в базе данных издателя для отслеживания статей. Затем он копирует изменения данных из журнала транзакций в базу данных распределения.

База данных распределения может находиться либо на издателе, либо на подписчике; это также может быть и другой независимый экземпляр SQL Server.

• Агент читателя журнала работает непрерывно с сервера распределителя, чтобы сканировать новые команды, помеченные для репликации. Однако, если вы не хотите непрерывного выполнения, и запускать его по расписанию, то можете изменить созданное задание Log Reader Agent SQL.
• Агент читателя журнала собирает все записи, помеченные для репликации, из журнала транзакций в пакеты и посылает их в базу данных распределителя.
• Агент читателя журнала собирает только зафиксированные транзакции из журнала транзакций в базе данных издателя. Поэтому любые долго выполняющиеся запросы в базе данных издателя могут непосредственно влиять на репликацию, т.к. процесс ожидает завершения активной транзакции.

После успешного распределения записей из базы данных распределения в базу данных подписчика они будут помечаться как распределенные и готовые для удаления из базы данных распределения. Одно из ключевых заданий поддержки репликации с именем Distribution Clean Up: Distribution job выполняется раз в каждые 10 минут для удаления распределенных записей из базы данных распределения, чтобы держать размер базы данных распределения под контролем.

С подробным объяснением концепций репликации и транзакционной репликации мы можем приступить к конфигурированию репликации для базы данных AdventureWorks и проверить репликацию для каждого компонента, который обсуждался теоретически.

Пошаговое конфигурирование транзакционной репликации (посредством интерфейса SSMS)

1. Конфигурирование базы данных распределения
2. Создание публикации
3. Создание подписки

В SSMS подключитесь к экземпляру базы данных издателя и выполните щелчок правой кнопкой на Replication:

Распределение не конфигурируется прямо сейчас. Поэтому у нас есть опция Configure Distribution. Мы можем конфигурировать базу данных распределения либо с помощью мастера конфигурации распределения, либо посредством мастера создания публикации.

Чтобы сконфигурировать базу данных распределения и публикацию, выполните следующие шаги:

Разверните Replication и выполните правый щелчок на New Publication (новая публикация).

Будет запущен мастер новой публикации. Щелкните Next (далее), чтобы увидеть опции конфигурации распределителя.

По умолчанию он выбирает сервер издателя для хранения базы данных распределения. Если вы хотите использовать удаленную базу данных распределения, выберите вторую опцию. Щелкните Next.

Следующая опция служит для конфигурирования папки снимков (Snapshot Folder). Выберите подходящую папку. В противном случае, она будет создана в папке по умолчанию по пути установки SQL Server. Щелкните Next.

Выберите базу данных публикации (Publication Database). Здесь это AdventureWorks, и щелкните Next.

Выберите Publication Type – Transactional Replication. Щелкните Next.

Выберите Articles для этой публикации. В целях тестирования выберите все таблицы (Tables) и представления (Views):

Прежде, чем щелкать Next, разверните таблицы еще раз, чтобы проверить некоторые моменты.

Некоторые таблицы помечены красными иконками. Если щелкнуть на этих таблицах, мы увидим предупреждение, указывающее, что таблицы не могут быть реплицированы, поскольку они не имеют первичного ключа — одного из принципиальных требований транзакционной репликации. Мы позже обсудим это более подробно. Теперь щелкнем Next.

Появится страница с проблемами статей (Article Issues), относящихся к зависимостям. Щелкните Next.

Следующая опция — Filter Table Rows (фильтрованные строки таблицы). Поскольку мы тестируем базовую репликацию, проигнорируем её. Щелкните Next.

Конфигурирование агента снимка — игнорируем и щелкаем Next.

Agent Settings (установки агента) – щелкните Security Settings (установки безопасности), чтобы сконфигурировать аккаунт для выполнения агента снимка и агента читателя журнала ниже.

Затем измените процесс агента снимка для выполнения под аккаунтом SQL Server Agent Service.

Установите агента читателя журнала в Connect to Publisher > By impersonating the Process Account. Щелкните ОК.

Безопасность агента обновится.

Таким образом, мы сконфигурировали распределителя и все элементы публикации, подобные статьям, агенту снимка, агенту читателя журнала и безопасности агента. Мы почти закончили создание публикации с помощью мастера.

Если вы хотите познакомиться со скриптами T-SQL, использованными для создания публикации, можете включить опцию Generate a script file to create the Publication (генерация файла скрипта для создания публикации). В противном случае щелкните Next.

Поскольку я выбрал сохранение файла, мастер предлагает установить путь к файлу скрипта и его имя. Указываем и щелкаем Next.

Наконец, мастер спрашивает имя публикации. Я назвал её AdventureWorks_pub — имя базы данных и ключевое слово для упрощения идентификации, указывающее, что это публикация.

Проверим все данные, выводимые на странице Summary, и щелкнем Finish.

Мастер отобразит прогресс в создании публикации. По завершению мы увидим подтверждение. Щелкните Close.

Для проверки успешного создания распределителя (база данных распределения), разверните системные базы данных:

Для проверки успешного создания публикации разверните Local Publication:

Мы успешно сконфигурировали базу данных распределения и создали базу данных публикации в базе данных AdventureWorks. Теперь мы можем продолжить с созданием подписки.

Выполните щелчок правой кнопкой на новой публикации, которую мы только что создали, и выберите New Subscriptions:

Появится мастер новой подписки (New Subscriptions Wizard). Для начала процесса щелкните Next.

Страница Publication просит убедиться, что обе базы — публикации и издателя — созданы. Щелкнем Next.

Установите агента распределения либо на Push, либо на Pull подписку. Мы собираемся использовать сервер издателя в качестве подписчика, и этот тип не окажет никакого влияния. Следовательно, мы оставляем подписку по умолчанию Push. Щелкаем Next.

Выберите подписчиков (база данных). Я выбираю AdventureWorks_REPL, восстановленную из бэкапа той же самой базы данных AdventureWorks. Щелкаем Next.

Установим безопасность агента:

Поскольку я собираюсь все делать на одном сервере, то использую аккаунт Agent service.

Следующее окно представляет уже сконфигурированные значения безопасности агента распределения. Щелкните Next.

Расписание синхронизации (Synchronization Schedule) — оставьте его по умолчанию. Щелкните Next.

Инициализация подписок (Initialize Subscriptions) — оставьте и здесь значения по умолчанию. Щелкните Next.

После предоставления всех необходимых деталей вы сможете завершить процесс создания подписки. Пометьте опцию Generate Script file… для изучения скриптов позже, и щелкните Next.

Укажите путь для сохранения файлов, щелкните Next.

Посмотрите резюме и проверьте все сконфигурированные значения. После проверки щелкните Finish.

Создание подписки завершено. Щелкните Close.

Теперь мы можем увидеть подписку, отображаемую под нашей публикацией.

Конфигурирование агента снимка

Наш следующий шаг — это поработать над агентом снимка для передачи исходных данных с издателя на подписчика.

Но сначала нам необходимо обратить внимание на монитор репликации (Replication Monitor). Этот критический инструмент имеется в SSMS для наблюдения статуса репликации на различных уровнях, уровне сервера, уровне базы данных издателя, уровне подписки и на уровне агентов репликации.

Выполните щелчок правой кнопкой на Replication/Local Publication/Local Subscription/Publication или на созданной нами подписке, чтобы запустить монитор репликации, как показано ниже:

В мониторе репликации разверните Publisher Server (RRJ) > Publication ([AdventureWorks]: AdventureWorks_pub) для отображения деталей подписки. Пыполните щелчок правой кнопкой на Subscription и выберите View Details.

Как можно видеть, информации о первоначальном снимке (Initial Snapshot) для вашей публикации AdventureWorks_pub еще нет. Нам потребуется выполнить задание агента снимка, чтобы послать начальные данные в базу данных подписчика.

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

Щелкните правой кнопкой на Publication > View Snapshot Agent Status:

Сообщение «The agent has never been run (агент еще не запускался)» говорит о том, что мы еще никогда не выполняли агента снимка. Щекните Start.

Пока выполняется агент снимка мы можем наблюдать прогресс.

Когда все снимки созданы, будет получено подтверждающее сообщение:

Мы можем увидеть вновь созданные файлы снимков в папке снимков, путь для которой мы предоставили ранее.

После применения всех снимков агентом распределения к базе данных подписчика это будет отображаться ниже в статусе в открытом окне монитора репликации:

Поздравляем! Мы успешно сконфигурировали транзакционную репликацию с помощью агента снимка.

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

Проверка компонент репликации

Все компоненты репликации могут быть проверены как с помощью SSMS, так и запросов T-SQL. Мы обсудим это в последующих статьях. Здесь же мы вкратце объясним, как проверить свойства нижеприведенных компонент.

Издатель

В SSMS выполните щелчок правой кнопкой Replication > Publisher Properties > Publication Databases:

Для просмотра подробной информации об издателе выполните следующие запросы к базе данных распределения.

Подписчик

Информацию о подписчике можно получить с помощью такого запроса в SSMS:

Распределитель

Выполните правый щелчок в SSMS Replication > Distributor Properties:

Щелкните Publishers для отображения списка всех издателей, использующих базу данных распределения.

В SSMS мы можем выполнить запрос ниже для получения той же информации.

Статьи

Выполните правый щелчок на Publication > Publication Properties > Articles. Вы увидите список доступных статей. Свойства отдельных статей можно изменить, также щелкнув на Article Properties.

Публикация

Щелкните правой кнопкой на Publication > Properties:

В SSMS мы можем выполнить запрос ниже для просмотра свойств публикации:

Подписка

Щелкните правой кнопкой на Subscription > Subscription properties:

В SSMS мы можем выполнить скрипт ниже для получения информации о подписке:

Агенты репликации

В ветке SQL Server Agent Jobs можно найти конкретные задания, созданные для всех агентов репликации:

В SSMS мы можем выполнить запрос для выяснения, какое задание является необходимым заданием агента читателя журнала, агента снимка и заданий агента распределения. Помимо этого, мы можем видеть задание очистки агента распределения и несколько других заданий, связанных с репликацией при создании внутренней настройки публикации и подписки.

Как работает агент читателя журнала

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

Как агент распределения доставляет изменения данных в базу данных подписчика

Как только данные записаны в базу данных распределения, мы можем прочитать, как данные хранятся в таблицах распределения. Для этого мы применяем процедуру sp_browsereplcmds — она извлекает записи из таблиц MSrepl_commands и MSrepl_transactions.

С целью изучения, давайте возьмем таблицу с 3 столбцами, которая называется Person.ContactType:

• dbo.sp_MSins_
• dbo.sp_MSupd_
• dbo.sp_MSdel_

• dbo.sp_MSins_PersonContactType — вставляет новые записи, извлекаемые из журналов транзакций базы данных издателя, а затем наполняющие базу данных распределения.
• dbo.sp_MSupd_PersonContactType — обновляет изменения, извлекаемые из журналов транзакций базы данных издателя, а затем копируемые в базу данных распеределения.
• dbo.sp_MSdel_PersonContactType — удаляет записи, извлекаемые из журнала транзакций базы данных издателя, а затем распространяемые на базу данных распределения.

Скрипт процедуры dbo.sp_MSins_PersonContactType

Как видно, это просто оператор INSERT, который выполняется в базе данных распространения:

Скрипт процедуры dbo.sp_MSupd_PersonContactType

Этот скрипт основывается на значениях первичного ключа для идентификации уникальной записи для обновления:

Скрипт процедуры dbo.sp_MSdel_PersonContactType

Этот скрипт опирается на значения первичного ключа для определения уникальной записи для удаления записей из подписчика:

Это объясняет, почему транзакционная репликация требует наличия первичного ключа как основного требования для таблиц, которые могут быть частью репликации.

Теперь давайте посмотрим на транзакционную репликацию в действии. Пусть изменяются некоторые данные в базе данных издателя. Для простоты я возьму ту же таблицу Person.ContactType.

Выполнение оператора SELECT к таблице дает 20 записей:

Далее я вставил тестовую запись в таблицу Person.ContactType:

И обновляю вновь вставленную запись:

Удаляю новую запись из таблицы:

Нам нужно проверить эти транзакции в репликации, используя sp_browsereplcmds