Конфигуриране на репликация на хетерогенна база данни – SQL Server към Oracle

Въведение

Репликацията на SQL Server е функция на SQL Server, която ни позволява да прехвърляме данни от един екземпляр на друг за такива цели като консолидиране на данни в среда за отчитане или миграции. Аз лично не бих считал репликацията на SQL Server като технология с висока достъпност, въпреки че някои хора го смятат за такава.

Репликацията на SQL Server използва термини, подобни на тези в издателската индустрия, за да опише начина, по който данните се обработват от източник до местоназначение. Основните термини са както следва:

• Publisher – екземпляр на SQL Server, който предоставя данни за репликиране в други екземпляри (опаковани като публикации).
• Публикация – единица, готова за предаване на получаващия екземпляр, съставена от колекция от статии, които всъщност са обекти на базата данни.
• Дистрибутор – екземпляр на SQL Server, отговорен за съхраняването на данни, свързани с един или повече издатели в база данни, наречена разпространителна база данни . Местен дистрибутор се съхранява в същия екземпляр като издателя, докато отдалечен дистрибутор се намира в друг екземпляр.
• Абонат – екземпляр, който получава репликирана база данни. Абонаментът за абонамент е заявка за копие на публикация, която очаква да получи от Издателя.
• Моментна снимка.

В статията ще споделя няколко точки, които научих от конфигурирането на репликацията на SQL Server за поддръжка на хетерогенен абонат. Ще създам публикация и впоследствие абонамент за Oracle, който ще зависи от тази публикация. Ще демонстрирам също няколко точки заедно с потока на процеса, които са много важни за отстраняването на проблеми.

Стъпките за конфигуриране на сесия за репликация на моментна снимка са както следва:

1. Конфигуриране на дистрибутор
2. Конфигуриране на издател (заедно с публикацията, включително публикуваните статии)
3. Конфигуриране на абонат

Ще дам кратко обяснение на всяка стъпка.

Конфигуриране на дистрибутор

Дистрибуторът е инстанция, отговорна за съхраняването на информация, използвана по време на репликацията. Когато се опитате да създадете публикация в екземпляра за първи път, SQL Server ще ви предложи да конфигурирате дистрибутор. В тази статия нашият дистрибутор е местен дистрибутор .

Създаване на публикация

Нека идентифицираме базата данни, която съдържа обектите, които бихме искали да репликираме. Това ще бъде База данни за публикации .

За да създадете база данни за публикации, следвайте инструкциите на екранните снимки по-долу.

Тази стъпка ви позволява да изберете тип публикация, която искате да конфигурирате. Всеки тип публикация е описан в долния панел. От съображения за простота и съвместимост, ние избираме публикация за моментна снимка. Моля, имайте предвид, че възнамеряваме да репликираме обекти в екземпляр на Oracle. В този случай Транзакционен и Публикации на моментни снимки се поддържат. Има и други добри случаи на използване за peer-to-peer репликация и сливане.

На тази стъпка избираме статиите, които искаме да публикуваме. SQL Server ни позволява да публикуваме четири основни типа обекти като:

1. Таблици
2. Съхранени процедури
3. Прегледи
4. Дефинирани от потребителя функции

Както можете да видите, ние ще публикуваме две таблици:Orders и OrderLines. С цел да демонстрираме гъвкавостта на репликацията на SQL Server, ще филтрираме записите, както е показано по-долу.
Забележка: Интересуваме се броят на идентификаторите на поръчка да е по-голям от 1000.

За да изключите нежелани редове от публикувани таблици, щракнете върху Добавяне... и след товаНапред .

Екранните снимки по-долу показват как да филтрирате колони за таблицата OrderLines.

След това конфигурирайте свойствата на Snapshot Agent. Дефинираме първоначална моментна снимка и интервала, през който се генерира нова моментна снимка. Данните, извлечени на тази стъпка, се съхраняват в директория, посочена при първоначалното конфигуриране на дистрибутора.

Първо, настройте график за стартиране на агент за моментни снимки. Кликнете върху Напред .

За всеки агент за моментни снимки посочете акаунта, под който ще се изпълнява.

След това конфигурирайте настройките за защита на Snapshot Agent. Таблицата с настройки за сигурност отваря друг прозорец, в който определяме кой изпълнява процеса на Snapshot Agent, както и определяме данните за вход в SQL Server, които да бъдат свързани с издателя. Има определени разрешения, които се изискват от тези директори, които могат да бъдат малко хитри в производството. Използването на акаунта на SQL Server Agent Service е заобиколно решение за избягване на усложнения, но всъщност НЕ се препоръчва от Microsoft.

Близо до края ще трябва да решите дали искате да запазите конфигурацията като скрипт за по-късна употреба или незабавно да създадете публикацията.

Следващата стъпка (фиг. 16) обобщава всички опции, които сте избрали. Препоръчително е да направите бърз преглед, преди да щракнете върху Край бутон.

Започва процесът на създаване на публикация. Можете да щракнете върху Стоп за да прекъснете процеса.

След като процесът приключи, публикацията ви става видима в панела на Object Explorer на SQL Server Management Studio.

Добавяне на абонат

Абонатът получава публикации, предоставени от Издателя . Копието на публикацията, което трябва да се достави на абонат, се нарича Абонамент . Един издател може да има много абонати. Всеки
абонат получава статиите, публикувани от този издател, като единица, наречена публикация, що се отнася до издателя, и се счита за абонамент за абоната.

Създавайки абонамент, ние просто казваме на Издателя:„Искам да имам копия от тази публикация“. Доколкото един издател може да има много публикации, може да има и много абонати за една
публикация. По този начин връзката между издатели и абонати е връзка един към много.

Съветникът за нов абонамент ни позволява да решим за коя публикация бихме искали да се абонираме. Можем да избираме от списък с предварително създадени публикации, както е показано на Фиг. 20.

След това решаваме дали искаме да стартираме Push Subscription вместо Pull Subscription. Въпреки че Pull Subscription е по-добър за производителност, когато предвиждате няколко абонати, той няма
да работи за хетерогенна репликация на база данни. Абонатите, които не са на SQL сървър, трябва да използват абонамент за изтегляне. Струва си да се спомене, че статиите, публикувани в този сценарий, също са ограничени до таблици и индексирани изгледи.

Добавете абонат на Oracle, като използвате име на източник на данни (DSN). Този DSN трябва вече да е създаден, тестван и е установено, че работи по отношение на възможността да се свърже с екземпляра на Oracle чрез Oracle Net. Това означава, че имате нужда от клиент на Oracle, инсталиран на хоста на SQL Server с вход във файл, наречен tnsnames.ora определяне на дестинацията на връзката. Този TNS запис от своя страна се използва за конфигуриране на името на източника на данни, което съветникът за нов абонамент иска на този етап.

Записът, който създадох в моя файл tnsnames.ora, изглежда така:

ORCL10G =
 (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = IGIRI-LP)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl10g)
    )
 )

Маркираната част е псевдонимът, докато другите детайли определят дестинацията на връзката. Можем да потвърдим дали този запис работи правилно и дали моите променливи на средата на Oracle са конфигурирани правилно, като използваме tnsping помощна програма, както е показано по-долу.

След като бъде потвърдено, този TNS запис се използва за конфигуриране на DSN, който възнамеряваме да използваме. Името на нашата TNS услуга се нарича ORCL10G докато DSN се нарича ORCLDC . Това е DSN, който използваме в съветника за нов абонамент.

Имайте предвид, че сме използвали 64-битовата версия на ODBC за конфигуриране на DSN и това е системен DSN, а не потребителски DSN. Конфигурацията не зависи от това кой е влязъл в компютъра.

Изберете тип абонат за добавяне и въведете името на източника на данни. Щракнете върху OK .

Изберете един или няколко абонати, както и посочете база данни за всеки абонамент.

След като се добави DSN, можем да продължим с конфигурирането на сигурността на агента за разпространение. Откриваме, че това е подобно на случая, когато конфигурирахме Snapshot Agent Security в съветника за нова публикация.

Тук обаче имаме раздел, в който установяваме връзка с Абоната а не на Издателя (припомнете си, че това е насочен абонамент). Този потребителски акаунт трябва да е създаден в екземпляра на Oracle и трябва да има привилегии за създаване на таблици и квота в неговото пространство за таблици по подразбиране (тук може да се нуждаете от Oracle DBA).

Добавете параметри към сигурността на агента за разпространение и щракнете върху OK .

Посочете акаунта и опциите за връзка за всеки агент за разпространение и щракнете върху Напред .

Определете графика за синхронизиране за всеки агент. В нашия случай избрахме да синхронизираме непрекъснато. Кликнете върху Напред .

Изберете опцията за незабавно инициализиране на абонамента, което означава повторно копиране на ВСИЧКИ налични данни в папката Snapshot. Препоръчително е абонатите на NoSQL Server да инициализират повторно абонамента, когато към публикацията се добавят нови статии. Кликнете върху Напред .

Изберете опциите, които да бъдат изпълнени, след като процесът приключи успешно. Кликнете върху Напред .

Проверете информацията, която сте добавили, и кликнете върху Край .

Изпълнява се процесът на създаване на абонамент.

Абонаментът, който току-що създадохме, показва запис в Object Explorer (на издателя), съпоставен с неговата родителска публикация. Имайте предвид, че той не се показва в възела „Локални абонаменти“, който ви предоставя списък с абонаменти, създадени в текущия екземпляр, който не е в този случай.

Наблюдение и отстраняване на неизправности

SQL Server предоставя монитора за репликация за преглед и наблюдение на подробности за всички сесии на репликация на потребителския модел. Мониторът за репликация може да информира администратора, когато агентът за моментни снимки стартира и завърши. Може също да ни покаже дали абонаментите са инициализирани и дали агентът за разпространение работи гладко.

Има осем задачи на SQL Server Agent, свързани с текущата ни конфигурация. Прегледът на хронологията на тези работни места също дава подробности за това дали всичко е наред.

Действителните грешки на Oracle са изброени в монитора за репликация и в регистъра за грешки на SQL Server, когато се срещнат. Това ниво на подробности прави репликацията на SQL Server интересна за отстраняване на неизправности. Познаването на Oracle (за SQL Server DBA) ще отнеме дълъг път в разбирането на грешките, които могат да възникнат.

Обърнете внимание на примера за грешката на фиг. 34. Тази грешка е възникнала преди средата на Oracle Net и ODBC да бъдат конфигурирани правилно. Грешките дават много ясна индикация къде е проблемът.

Изгледът „Монитор на дейността по работа“ също ни информира кои работни места са успешни и коя работа трябва да отстраним подробно, като разгледаме историята на заданията.

След като всички предишни грешки бъдат разрешени, отварянето на абонамент чрез двукратно щракване ни дава подробен преглед на всички сесии, грешки и резултат, който очакваме да видим, когато всичко е наред. Обърнете внимание, че Agent Bulk копира данни от издателя към абоната на партиди. Можем също да направим заявка за таблиците, които са създадени в екземпляра на Oracle, и да сравним записите. (Фиг. 37).

Както можете да видите, SQL Server подготвя таблицата, изключвайки изходната схема (Продажби), преди да създаде таблицата в Oracle и да копира данните.

Броят на записите в екземпляра на Oracle съвпада с този в таблицата източник и взема предвид факта, че филтрираме таблицата OrderLines за идентификатори на поръчки, по-големи от 1000.

Заключение

Накратко преминахме през процеса на конфигуриране на хетерогенна репликация на база данни с екземпляр на Oracle като абонат. Въпреки че тази опция постепенно се оттегля от Microsoft, има случаи на използване, които все още могат да се възползват от възможностите, предоставени от тази стара функция на SQL Server. Разделът „Препратки“ предоставя по-широко четене по темата, което смятам, че ще бъде полезно за тези, които искат да практикуват повече.

Препратки

Конфигуриране на репликация за винаги активни групи за наличност
Абонати, които не са на Oracle
Репликация на хетерогенна база данни
Абонати на Oracle