SQL-Ex blog

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

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

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

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


• или по серверам в одном или нескольких местах.

Сначала мы должны познакомиться с архитектурой и методами репликации.

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

• Издатель (Publisher) - экземпляр базы данных источника, который публикует изменения данных, которые могут распределяться на другие базы данных. Данные от единственного издателя могут посылаться единственному подписчику или множеству подписчиков.


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


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

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

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

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

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

- 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.


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


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

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

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

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

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

Конфигурация транзакционной репликации включает 3 основных шага:

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


2. Создание публикации


3. Создание подписки

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

В 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:



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

USE distribution

GO

exec sp_helpdistpublisher

GO

select * from MSpublisher_databases

GO

Подписчик

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

USE distribution

GO

exec sp_helpsubscriberinfo

GO

select * from MSsubscriber_info

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

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



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



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

USE distribution

GO

exec sp_helpdistributor

GO

exec sp_helpdistributiondb

GO

Статьи

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

USE AdventureWorks

GO

-- Чтобы увидеть все статьи, доступные для публикации

exec sp_helparticle @publication = 'Adventureworks_pub'

GO

-- Чтобы увидеть все столбцы статьи для конкретной статьи публикации

exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'

GO

USE distribution

GO

SELECT * from MSArticles

Публикация

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


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

USE AdventureWorks

GO

exec sp_helppublication

GO

USE distribution

GO

SELECT * FROM MSPublications

Подписка

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



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

USE AdventureWorks

GO

exec sp_helpsubscription

GO

USE distribution

GO

SELECT * FROM MSsubscriptions

GO

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

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



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

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

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

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

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

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



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

• dbo.sp_MSins_<ИмяСхемы><ИмяТаблицы>


• dbo.sp_MSupd_<ИмяСхемы><ИмяТаблицы>


• dbo.sp_MSdel_<ИмяСхемы><ИмяТаблицы>

Для статьи таблицы Person.ContactType мы можем увидеть ниже процедуры, созданные в базе данных подписчика:

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


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


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

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

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

ALTER procedure [dbo].[sp_MSins_PersonContactType]

    @c1 int,

    @c2 nvarchar(50),

    @c3 datetime

as

begin  

	insert into [Person].[ContactType] (

		[ContactTypeID],

		[Name],

		[ModifiedDate]

	) values (

		@c1,

		@c2,

		@c3	) 

end  

GO

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

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

ALTER procedure [dbo].[sp_MSupd_PersonContactType]

		@c1 int = NULL,

		@c2 nvarchar(50) = NULL,

		@c3 datetime = NULL,

		@pkc1 int = NULL,

		@bitmap binary(1)

as

begin  

	declare @primarykey_text nvarchar(100) = ''

update [Person].[ContactType] set

		[Name] = case substring(@bitmap,1,1) & 2 when 2 then @c2 else [Name] end,

		[ModifiedDate] = case substring(@bitmap,1,1) & 4 when 4 then @c3 else [ModifiedDate] end

	where [ContactTypeID] = @pkc1

if @@rowcount = 0

    if @@microsoftversion>0x07320000

		Begin

			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')

			Begin

				

				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)

				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @param2=@primarykey_text, @param3=13233 

			End

			Else

				exec sp_MSreplraiserror @errorid=20598

		End

end 

GO

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

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

ALTER procedure [dbo].[sp_MSdel_PersonContactType]

		@pkc1 int

as

begin  

	declare @primarykey_text nvarchar(100) = ''

	delete [Person].[ContactType] 

	where [ContactTypeID] = @pkc1

if @@rowcount = 0

    if @@microsoftversion>0x07320000

		Begin

			if exists (Select * from sys.all_parameters where object_id = OBJECT_ID('sp_MSreplraiserror') and [name] = '@param3')

			Begin

				

				set @primarykey_text = @primarykey_text + '[ContactTypeID] = ' + convert(nvarchar(100),@pkc1,1)

				exec sp_MSreplraiserror @errorid=20598, @param1=N'[Person].[ContactType]', @param2=@primarykey_text, @param3=13234 

			End

			Else

				exec sp_MSreplraiserror @errorid=20598

		End

end  

GO

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

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

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



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



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



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



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



Изменения из Person.ContactType были захвачены из журнала транзакций базы данных издателя (AdventureWorks) и посланы в базу данных распределения в том же самом порядке. Позже они были перенесены в базу данных подписчика (AdventureWorks_REPL).

Заключение

В этой объемной статье мы рассмотрели разнообразные темы, в частности:

• Технологии и архитектура репликации


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


• Подробно о транзакционной репликации в SQL Sever


• Конфигурирование транзакционной репликации в SQL Sever (подход по умолчанию)


• Проверку транзакционной репликации в SQL Sever


• Репликацию в действии (SQL Sever)