Транзакционната репликация на SQL Server е една от най-често срещаните техники за репликация, използвани за споделяне, копиране или разпространение на данни до множество дестинации. В тази статия ще обсъдим репликацията, различните типове репликация и ще обърнем специално внимание на работата по репликация на транзакции.
Какво е SQL транзакционна репликация?
Репликацията е технологията на SQL Server за копиране или разпространение на данни от една база данни в друга, като същевременно се поддържа последователност на данните.
Репликацията може да се използва за прехвърляне на данни от една база данни в друга
- на същия екземпляр или друг екземпляр на същия сървър;
- или на сървъри в едно или няколко местоположения.
Първо, трябва да преминем през архитектурата на репликация и да разберем терминологиите за репликация.
Архитектура и терминология за репликация на SQL сървър
- Издателят е екземплярът на изходната база данни, който публикува промените в данните, които могат да бъдат разпределени в друга база данни. Данни от единичен издател може да бъде изпратен до единичен абонат или няколко Абонати .
- Абонат е екземпляр на целевата база данни, където разпространяваме промените в данните, заснети от базата данни на издателя. Абонатът може да бъде или екземпляр на издател, или друг екземпляр в Publisher Server/друг сървър на същото местоположение/отдалечено местоположение. Преди промените в данните да бъдат разпространени в екземпляра на базата данни на абонатите, тези данни се съхраняват в дистрибутора .
- Дистрибутор е база данни, която съхранява регистрационни файлове за промени, заснети от базите данни на издателя. Когато сървърът е активиран като дистрибутор, той ще създаде системна база данни с име разпространителна база данни .
Според местоположението на базите данни за разпространение те могат да бъдат класифицирани като локални или отдалечени дистрибутори.
– Местен дистрибутор е база данни за разпространение, намираща се в екземпляра на базата данни Publisher.
– Отдалечен дистрибутор е база данни за разпространение, намираща се или в екземпляра на базата данни Subscriber, или във всеки друг екземпляр на SQL Server, освен екземпляра на базата данни Publisher.
Решаващият фактор е къде да поставите базата данни за разпространение в екземпляра на издателя (друг екземпляр). зависи от наличните ресурси на сървъра за справяне с натоварването на разпространението на данни.
Според начина, по който данните ще бъдат изпратени от базата данни за разпространение до екземпляра на абоната, те могат да бъдат класифицирани в Push или Изтеглете абонаменти .
– Натиснете абонамент означава, че базата данни за разпространение поема отговорността да изпрати данните към екземпляра на базата данни на абоната.
– Изтеглете абонамент означава, че екземплярът на базата данни за абонати поема отговорността да извлече наличните данни от базата данни за разпространение и да ги приложи към базата данни за абонати.
- Статии са основната единица на репликацията. Той указва всякакви промени в данните за този обект на база данни или статия, които ще бъдат репликирани от издател към абонат. Статията може да бъде таблица, изглед, индексиран изглед, съхранена процедура или функция, дефинирана от потребителя.
- Публикации са колекция от една или повече статии от базата данни в Publisher.
- Абонамент определя каква публикация ще бъде получена. Освен това той определя от коя публикация и по какъв график се репликират данните. Абонаментът може да бъде или Push или Pull (от публикация до абонамент).
- Агенти за репликация са самостоятелни програми, отговорни за проследяване на промените и разпространение на данни от издателя до дистрибутора и абоната. Всички агенти за репликация се изпълняват като задачи под SQL Server Agent. По този начин той може да се администрира чрез SSMS под задания на агент на SQL Server или монитор за репликация. Налични са следните типове агенти за репликация:
- Агент за моментни снимки – Използва се от почти всички видове репликация. Snapshot Agent работи от сървър, който държи базата данни за разпространение. Той подготвя схемата и първоначалните данни на всички статии, включени в публикация на издател. Освен това той създава файловете за моментни снимки в папка за моментни снимки и записва подробности за синхронизирането в базата данни за разпространение.
- Агент за четене на журнали – Използва се от транзакционна репликация. Целта е да се прочетат промените в данните на статии, активирани за репликация от регистрационните файлове на транзакциите на базата данни на издателя и съхранени в базата данни за разпространение. агентът за четене на журнали се изпълнява от сървъра на дистрибутора.
- Агент по разпространение – Използва се от репликация на транзакции и моментна снимка. Той прилага първоначалните файлове за моментни снимки и инкременталните или наличните чакащи транзакции от базата данни за разпространение към базата данни на абонатите. Агентът за разпространение се изпълнява от дистрибуторския сървър за Push абонаменти и сървъра за абонати за изтегляне на абонаменти.
- Агент за сливане – Използва се само от Merge Replication. Той прилага първоначалните файлове за моментни снимки и съгласуване на диференциални или постепенни промени в издателя или абоната. Агентът за сливане работи на дистрибуторския сървър за Push репликация и от абонатния сървър за изтегляне на абонаменти.
- Агент за четене на опашка – Агентът за четене на опашка се използва от транзакционна репликация с опция за актуализиране на опашка. Той премества промените от Абонат към Издател. Агентът за четене на опашка се изпълнява от сървъра на дистрибутора.
- Работа за поддръжка на репликация – Както беше обяснено по-рано, всички агенти за репликация са самостоятелни програми, настроени по време на конфигурирането на репликацията. Те се изпълняват като задачи под задания на агент на SQL Server. Няколко значими задачи, които трябва да се отбележат, са Почистване на разпространението:Разпространение, Почистване на историята на агента:Разпространение и Почистване на изтекъл абонамент.
Типове репликация в SQL Server
Сега, когато знаем терминологията, нека се потопим в типовете репликация.
- Репликация на транзакции . Както подсказва името, всяка транзакция или промяна на данни в рамките на транзакционния обхват на Publisher ще бъде изпратена до абоната в почти реално време с малки закъснения в зависимост от мрежовата честотна лента и ресурсите на сървъра. Транзакционната репликация използва агента за четене на журнали, за да чете промените в данните от регистрационните файлове на транзакциите на базата данни на издателя. Той също така използва агента за разпространение, за да приложи промени към абоната. Понякога може да използва Snapshot Agent, за да вземе първоначални данни за моментни снимки на всички репликирани статии. Публикацията за репликация на транзакции може да попадне в следните категории:
- Стандартна репликация на транзакции – Абонатът е база данни само за четене от гледна точка на репликацията на транзакции. Всички промени, извършени от някой в базата данни на абонатите, няма да бъдат проследявани и актуализирани в базата данни на издателя. Стандартната репликация на транзакции често се нарича репликация на транзакция.
- Репликация на транзакции с абонаменти за актуализиране е подобрение на стандартната репликация на транзакции, което проследява промените в данните, извършвани при абонатите. Всеки път, когато се инициират промени в данните в абонамент с възможност за актуализиране, те първо ще бъдат разпространени до издателя, а след това и до други абонати.
- Репликация от равноправни партньори е подобрение на стандартната репликация на транзакции. Той разпространява транзакционно последователни промени в почти реално време в множество сървърни инстанции.
- Двупосочна репликация е подобрение на стандартната транзакционна репликация, което позволява на два сървъра (ограничени до само 2 сървъра и следователно наречени двупосочни) да обменят промените в данните помежду си с всеки сървър, действащ като издател (за изпращане на промени към друг сървър) или като абонат (за получаване на промени от друг сървър).
- Репликация при сливане – Поддържа улавяне на промени в данните, които се извършват както в издателя, така и в абоната, и ги разпространява до другия сървър. Репликацията за сливане изисква ROWGUID колона в Таблицата Статии, участващи в репликация на сливане. Той използва тригери за улавяне на промените в данните между издател и абонат. Също така, той доставя промените в сървърите, когато и издателят, и абонатът са свързани към мрежата. Репликацията за сливане използва агента за сливане, за да репликира промените в данните между издател и абонат.
- Репликация на моментна снимка – Както показва името, репликацията на моментна снимка не разчита нито на транзакционни регистрационни файлове, нито на тригери, за да улови промените. Той прави моментна снимка на статии, включени в публикацията, и я прилага към абоната с наличните записи към момента на моментната снимка. Репликацията на моментна снимка използва агента за моментна снимка, за да направи моментна снимка на издателя и използва агента за разпространение, за да приложи тези записи към абоната.
Транзакционна репликация на SQL сървър
Транзакционната репликация обикновено се предпочита в сценарии, при които базата данни на OLTP Publisher има тежки дейности по вмъкване/актуализиране на данни и/или изтриване.
Тъй като екземплярът на сървъра на издателя има огромно DISK IO, генерирането на отчети може да причини сериозни блокирания. Това също може да повлияе на производителността на сървъра. Следователно друг сървър с данни почти в реално време е добър за разтоварване на изискванията за отчитане.
Едно от основните изисквания за репликация на транзакции е репликираните таблици да имат наличен първичен ключ.
Можем да обобщим как работи транзакционната репликация. Разгледайте диаграмата на архитектурата на транзакционната репликация по-долу, взета от официалната документация на Microsoft.
Публикацията се създава в базата данни на издателя, която включва списък със статии за репликиране в базата данни за абонати.
Транзакционната репликация обикновено се инициализира от издателя към дистрибутора чрез агента за моментни снимки или пълните архиви. Агентът за моментна снимка се поддържа чрез съветника за конфигуриране на репликация. Пълното архивиране се поддържа чрез TSQL изявления за инициализиране на транзакционната репликация.
Агентът за четене на журнали сканира дневника на транзакциите на базата данни на издателя за проследявани статии. След това копира промените в данните от дневника на транзакциите в базата данни за разпространение.
Базата данни за разпространение може да бъде в Издател или Абонат; може също да бъде или друг независим екземпляр на SQL Server.
Обърнете внимание и на следните неща:
- Агентът за четене на журнали работи непрекъснато от сървъра на дистрибутора, за да сканира за нови команди, маркирани за репликация. Ако обаче не искате да работите непрекъснато и вместо това искате да работите по график, можем да променим SQL заданието на агента за четене на журнали, което ще бъде създадено.
- Агентът за четене на журнали взема всички записи, маркирани за репликация, от партидите на транзакционния регистър и ги изпраща в базата данни за разпространение.
- Агентът за четене на журнали улавя само ангажименти транзакции от регистрационния файл на транзакциите на базата данни на издателя. Така че всички продължителни заявки в базата данни на издателя могат директно да повлияят на репликацията, тъй като тя чака активната транзакция да завърши.
Агентът за разпространение взема всички неразпределени нови команди от базата данни за разпространение и ги прилага към базата данни за абонамент чрез Push или Pull механизъм. Както бе споменато по-рано, ако Push Subscription Distributor поеме собствеността да приложи промените от базата данни за разпространение към абоната, докато в Pull Subscription Subscriber базата данни поема собственост, за да извлече промените от базата данни за разпространение към абоната.
След като записите бъдат разпространени успешно от базата данни за разпространение към абонати, те ще бъдат маркирани като разпределени и маркирани за изтриване от базата данни за разпространение. Една от основните задачи за поддръжка на репликация, наречена Почистване на разпространението:заданието за разпространение се изпълнява веднъж на всеки 10 минути, за да изтрие разпределените записи от базата данни за разпространение, за да поддържа размера на базата данни за разпространение под контрол.
С подробното обяснение на концепциите за репликация и репликация на транзакции можем да се сдобием с него, като конфигурираме репликация за AdventureWorks база данни и проверка на репликацията за всеки компонент, обсъждан теоретично.
Конфигуриране на репликация на транзакции стъпка по стъпка (чрез SSMS GUI)
Конфигурацията на репликация на транзакции включва 3 основни стъпки:
- Конфигуриране на база данни за разпространение
- Създаване на публикация
- Създаване на абонамент
Преди да опитате да конфигурирате репликация, уверете се, че компонентите за репликация са инсталирани като част от инсталацията на SQL Server или използвайте носител на SQL Server за инсталиране на компоненти за репликация, тъй като те са необходими за задачата.
В SSMS се свържете с екземпляр на базата данни на издател и щракнете с десния бутон върху Репликация :
Разпределението не е конфигурирано в момента. Следователно имаме опцията Конфигуриране на разпространение. Можем да конфигурираме базата данни за разпространение с помощта на съветника за конфигуриране на разпространение или чрез съветника за създаване на публикация.
За да конфигурирате базата данни за разпространение и публикация, следвайте стъпките по-долу:
Разгъване Репликация и щракнете с десния бутон върху Нова публикация .
Съветник за нова публикация ще стартира. Щракнете върху Напред за да видите Дистрибутора опции за конфигурация.
По подразбиране той избира сървъра на издателя да държи базата данни за разпространение. Ако желаете да използвате база данни за отдалечено разпространение, изберете втората опция. Щракнете върху Напред .
Следващата опция е за конфигуриране на Папката за моментни снимки . Променете го в необходимата папка. В противен случай той ще бъде създаден в пътя на инсталационната папка на SQL Server по подразбиране. Щракнете върху Напред .
Изберете База данни за публикации (ето го AdventureWorks ) и щракнете върху Напред .
Изберете Тип публикация – Репликация на транзакции . Щракнете върху Напред .
Изберете Статии за тази публикация. За целите на тестване изберете всички Таблици и Изгледи :
Преди да кликнете върху Напред , разгънете таблиците още веднъж, за да проверите някои проблеми.
Някои таблици са маркирани с червени икони. Когато щракнем върху тези таблици, виждаме предупреждението, което показва, че дадена таблица не може да бъде репликирана, защото няма първичен ключ, едно от основните изисквания за репликация на транзакции. По-късно ще разгледаме по-подробно. Сега кликнете върху Напред .
Страница с Проблеми със статии ще се появят свързани със зависимости. Щракнете върху Напред .
Следващата опция е Филтриране на редове на таблица – тъй като тестваме основната репликация, можем да я игнорираме. Щракнете върху Напред .
Конфигуриране на агент за моментни снимки – игнорирайте и щракнете върху Напред .
Агент Настройки – щракнете върху Настройки за сигурност за да конфигурирате акаунта за изпълнение на агента за моментни снимки и агента за четене на журнали под него.
След това променете Процеса на агента за моментна снимка да се изпълнява под акаунт за услуга на агент на SQL Server.
Задайте Агента за четене на журнали за Свържете се с издател> Като се представяте за акаунт за обработка . Щракнете върху OK .
Защитата на агента ще бъде актуализирана.
Така конфигурирахме Дистрибутора и всички елементи на Публикацията като Статии , Агент за моментни снимки , Агент за четене на журнали , и Агентски ценни книжа . Почти завършихме създаването на публикация чрез съветника.
Ако трябва да проучите допълнително TSQL скриптове, използвани за създаване на публикация, можем да проверим Генериране на скриптов файл за създаване на публикация опция. В противен случай щракнете върху Напред .
Тъй като избрах да запазя файла, съветникът ми позволява да задам пътя на скриптовия файл и име . Предоставете тези подробности и кликнете върху Напред .
Най-накрая съветникът иска Име на публикация , кръстих го AdventureWorks_pub с името на базата данни и ключовите думи, за да я посочите като публикация за по-лесно идентифициране.
Проверете всички предоставени данни в Резюме страница и щракнете върху Край .
Съветникът ще покаже напредъка в Създаване на публикация . Когато приключи, ще видим потвърждението. Кликнете върху Затваряне .
За да проверите успешното създаване на Дистрибутора (База данни за разпространение), разширете системните бази данни:
За да проверите успешното създаване на Публикация , разгънете Местна публикация :
Ние конфигурирахме базата данни за разпространение и създадохме базата данни за публикации в базата данни AdventureWorks успешно. Сега можем да продължим с Абонамента създаване
Щракнете с десния бутон върху новата Публикация току-що създадохме и избрахме Нови абонаменти :
Съветникът за нови абонаменти ще се появи. За да започнете процеса, щракнете върху Напред .
Публикацията страницата иска да се уверите, че и двете Публикация и Издател бази от данни са избрани. Щракнете върху Напред .
Задайте Агента за разпространение за Натиснете или Издърпайте Абонамент. Ще използваме сървъра на издателя като абонат и този тип няма да има никакво влияние. Следователно оставяме по подразбиране Push Абонамент. Щракнете върху Напред .
Изберете Абонати (база данни). Избирам AdventureWorks_REPL възстановено от същия архив на базата данни на AdventureWorks. Щракнете върху Напред .
Задайте Сигурност на агента :
Тъй като ще правя всичко в рамките на един сървър, използвам профила за услуги на агент .
Следващият прозорец представя Сигурността на агента за разпространение вече конфигурирани стойности. Щракнете върху Напред .
График за синхронизиране – оставете го по подразбиране. Щракнете върху Напред .
Инициализирайте абонаментите – оставете го със стойностите по подразбиране. Щракнете върху Напред .
След като предоставите всички необходими данни, ще можете да завършите процеса на създаване на абонамента. Проверете Генериране на скриптов файл... опция за изучаване на скриптовете по-късно и щракнете върху Напред .
Посочете пътя за запазване на файловете, щракнете върху Напред .
Разгледайте обобщението и проверете всички конфигурирани стойности. След като потвърдите, щракнете върху Край .
Създаването на абонамента е завършено. Кликнете върху Затваряне .
Сега можем да видим Абонамент показани под нашата Публикация .
Конфигуриране на агента за моментни снимки
Следващата ни стъпка е да работим върху Снимката Агент за да изпратите първоначалните данни от Publisher до Абонат .
Преди да влезем в него, трябва да забележим Монитора за репликация . Този критичен инструмент е наличен в SSMS за преглед на състоянието на репликация на различни нива, ниво на сървър, ниво база данни на издател, ниво на абонамент и ниво на агенти за репликация.
Щракнете с десния бутон върху Репликация /Местна публикация /Местен абонамент /Публикация или Абонамент създадохме, за да стартираме Монитора за репликация както е показано по-долу:
В Монитор за репликация , разгънете Сървър на издател (RRJ)> Публикация ([AdventureWorks]:AdventureWorks_pub) за да се покажат подробностите за абонамента. Щракнете с десния бутон върху Абонамент и изберете Преглед на подробности .
Както виждаме, информацията за Първоначалната снимка за нашата публикация AdventureWorks_pub все още не е наличен. Ще трябва да изпълним задачата на агента за моментна снимка, за да изпратим първоначални данни към базата данни на абонатите .
Дръжте този прозорец отворен, за да видите напредъка на Snapshot след стартиране на задачата Snapshot Agent .
Щракнете с десния бутон върху Публикация > Преглед на състоянието на агента за моментна снимка :
Агентът никога не е бил управляван съобщението гласи, че никога не сме изпълнявали Snapshot Agent. Щракнете върху Старт .
Докато Snapshot Agent се изпълнява, можете да наблюдавате напредъка:
Когато всички моментни снимки бъдат създадени, той ще изведе съобщение за потвърждение:
Можем да видим файловете за моментни снимки, създадени наскоро, в папката Snapshot, за която сме предоставили пътя по-рано.
След като всички моментни снимки бъдат приложени от Агента за разпространение към базата данни за абонати , той ще покаже състоянието по-долу в отворения Монитор за репликация прозорец:
Поздравления! Успешно конфигурирахме репликация на транзакции с помощта на агент за моментни снимки.
Забележка :Ако имаме огромна база данни за издатели, създаването на моментна снимка може да отнеме много време. Затова се препоръчва да използвате пълното архивиране на базата данни на издателя, вместо да изпълнявате Snapshot Agent – ще разгледаме този проблем в следващите статии.
Проверка на компоненти за репликация
Всеки компонент за репликация може да бъде проверен както от SSMS GUI, така и от TSQL заявки. Ще го обсъдим в допълнителни статии и тук бързо ще обясним как да видите свойствата на компонентите по-долу.
Издател
В SSMS щракнете с десния бутон върху Репликация > Свойства на издателя > Бази данни за публикации :
За да видите подробности за издателя , изпълнете заявките по-долу към базата данни за разпространение.
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 щракнете с десния бутон върху Репликация > Дистрибутор Свойства :
Кликнете върху Издатели за да се покаже списъкът на всички издатели, използващи тази база данни за разпространение.
В SSMS можем да изпълним заявката по-долу, за да получим същите подробности.
USE distribution
GO
exec sp_helpdistributor
GO
exec sp_helpdistributiondb
GO
Статии
Щракнете с десния бутон върху Публикация > Свойства на публикацията > Статии . Ще видите списъка с всички налични статии. Свойствата на отделни статии могат да се променят, като щракнете върху Свойства на статия също.
USE AdventureWorks
GO
-- To View all articles available under a Publication
exec sp_helparticle @publication = 'Adventureworks_pub'
GO
-- To View all article columns for a particular article available under a Publication
exec sp_helparticlecolumns @publication = 'Adventureworks_pub', @article = 'Address'
GO
USE distribution
GO
SELECT * from MSArticles
Публикация
Щракнете с десния бутон върху Публикация > Свойства :
В SSMS можем да изпълним заявката по-долу, за да прегледаме Свойствата на публикацията :
USE AdventureWorks
GO
exec sp_helppublication
GO
USE distribution
GO
SELECT * FROM MSPublications
Абонамент
Щракнете с десния бутон върху Абонамент > Свойства на абонамента :
В SSMS можем да изпълним следния скрипт, за да получим информацията за абонамента:
USE AdventureWorks
GO
exec sp_helpsubscription
GO
USE distribution
GO
SELECT * FROM MSsubscriptions
GO
Агенти за репликация
Под Задачи за агент на SQL сървър , можем да намерим конкретните Работни места създадено за всички агенти за репликация:
В 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 Table можем да видим следните процедури, създадени в базата данни за абонати:
- dbo.sp_MSins_PersonContactType – ВЪВЕТЕ нови записи, заснети от регистрационните файлове на транзакциите на базата данни на издателя и след това разпространени в базата данни за разпространение.
- dbo.sp_MSupd_PersonContactType – АКТУАЛИЗИРАНЕ промените, заснети от регистрационните файлове на транзакциите на базата данни на издателя и след това разпространени в базата данни за разпространение.
- dbo.sp_MSdel_PersonContactType – ИЗТРИВАНЕ records captured from Transaction Logs of Publisher database and then propagated to the distribution database.
Script of the dbo.sp_MSins_PersonContactType Procedure
As you can see, it’s a straightforward INSERT statement that comes out of the distribution database:
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
Script of the dbo.sp_MSupd_PersonContactType Procedure
The script relies on the Primary Key values to identify the unique record for updating:
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]', @[email protected]_text, @param3=13233
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
Script of the dbo.sp_MSdel_PersonContactType Procedure
This script relies on the Primary Key values to identify a unique record for deleting records from the Subscriber :
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]', @[email protected]_text, @param3=13234
End
Else
exec sp_MSreplraiserror @errorid=20598
End
end
GO
This clearly explains why Transactional Replication enforces the Primary Key as a key requirement for tables to be added as part of Replication .
Now, let’s see the Transactional Replication in action. Let’s change some data in the Publisher database. For simplicity, I’ll take the same Person.ContactType таблица.
Executing the SELECT statement on the table yields 20 records:
Next, I INSERTed a sample record into the Person.ContactType таблица:
And, I UPDATE the newly inserted record:
DELETE the newly inserted record from the table:
We need to verify these transactions in Replication using sp_browsereplcmds
Changes from Person.ContactType were captured from the Transactional Logs of Publisher Database (AdventureWorks ) and sent to the Distribution database in the same order. Later, it was propagated to the Subscriber Database (AdventureWorks_REPL ).
Заключение
Thanks for reading this long power-packed article! We have gone through a variety of topics, such as:
- Replication Architecture and Terminologies
- SQL Server Replication Types
- SQL Server Transactional Replication in Detail
- SQL Server Transactional Replication Configuration (Default approach)
- SQL Server Transactional Replication Verification
- SQL Server Transactional Replication in action
I hope that you’ve found lots of helpful information in this article. In subsequent parts, we’ll explore troubleshooting various issues that are frequently encountered in Replication, and learn how to handle them more efficiently.
