Основи реплікації SQL Server 2008

Реплікація – це один з різновидів систем, що підтримують розподілену обробку даних. В останнє десятиліття напрям розподіленої обробки даних бурхливо розвивалося, і на сьогоднішній день це одне з найбільш динамічно зростаючих напрямів. У доповіді про зміну профілю корпоративних даних, який був озвучений на саміті APAC, присвяченому сховищ даних і відбувся в 2007р. в Хошиміні, Рік Вілларс (Rick Villars, Head of Investment Technical Services HSBC) показав, що обсяг тиражованих даних збільшується щорічно на 43.9% і до 2009 р. зрівняється з обсягом традиційних даних, що розміщуються у сховищах. Призначення цієї книги полягає в тому, щоб надати читачам набір апробованих протягом декількох років рецептів по використанню і настройці реплікації в SQL Server.

У цій статті я розгляну найбільш значущі для реплікації концептуальні моменти, і зроблю невеликий огляд основних напрямків адміністрування та моніторингу внутрішніх підсистем репліка ції SQL Server.

Призначення реплікації полягає в керованому тиражуванні даних між декількома СУБД. Завдання це не нова, і тому в реплікації використовується давно всім відома метафора видавничої справи: видавець, публікація, стаття, розповсюджувач і передплатник. Для SQL Server характерно також наявність спеціалізованих програмних модулів, за допомогою яких організується взаємодія задіяних у реплікації баз даних, і які в документації прийнято називати агентами реплікації.

Ось визначення реплікації, яке було представлено у навчальному посібнику Майкрософт: "Реплікація – це процес автоматичного розподілу копій даних і об'єктів БД між екземплярами SQL Server з одночасною синхронізацією всій поширюваної інформації ". Відомий теоретик реляційної теорії баз даних Кріс Дейт дав реплікації таке визначення:" Система підтримує реплікацію даних, якщо дана таблиця або її фрагмент може бути представлена кількома окремими копіями або репліками, які зберігаються на декількох окремих вузлах ". Однак, жодна з наведених тут визначень мені не здається повним. У професійних інтернет-форумах дуже часто можна зустріти питання, як організувати реплікацію без прямого підключення серверів один до одного, наприклад, за допомогою електронної пошти? Мені бачиться невірної навіть сама постановка питання таким чином. Справа в тому, що потрібно чітко відокремлювати реплікацію від простого тиражування даних. На мою думку, розподілена система може називатися системою з реплікацією, якщо вона не тільки автоматично синхронізує дані за заданими правилами, а й уміє гарантувати їх синхронність. Наприклад, якщо для доставки змін до даних використовується протокол без будь-якої гарантії доставки, таку систему вже не можна назвати реплікацією, хоча це ще не означає, що дані в такій системі будуть не синхронні. З іншого боку, реплікація також є дуже ефективним способом тиражування даних, але вона не є єдиною стратегією тиражування даних. Давайте коротко розглянемо декілька стратегій тиражування даних, які також доступні на платформі Microsoft.

У першу чергу варто згадати розподілені транзакції, які можуть передаватися по мережі з досить низькою затримкою. Для успішного функціонування розподілених транзакцій необхідно мати можливість транспортування їх між вузлами, координації цих транзакцій і всі вузли й учасники транспортної системи розподілених транзакцій в момент проходження такої транзакції повинні бути активні. Зрозуміло, така складна ланцюжок не гарантує автономності вузлів, і відстежування передачі змін на всі вузли покладається на розробника програми. Подібні проблеми притаманні і розподіленим запитам, механізм яких схожий з розподіленими транзакціями, і відрізняється тільки відсутністю компонент координатора розподілених транзакцій.

Для копіювання даних з одного сервера на інший іноді буває досить простого резервного копіювання бази даних з наступним відновленням з резервної копії на іншому сервері. Існує навіть методика доставки журналів, яка дозволяє коштами резервного копіювання і відновлення підтримувати актуальну копію бази даних на іншому сервері. Така технологія добре підходить для дублювання всієї бази даних без можливості внесення змін до копію, крім того, є відомі проблеми з доступністю бази даних під час відновлення з копій. Дуже близькою за змістом до технології доставки журналів є дзеркальне відображення бази даних. В останньому випадку дублювання бази даних призначено для забезпечення гарячого або теплого резерву бази даних на випадок апаратних або програмних збоїв. Переключення запитів користувачів на дзеркальну копію може виконуватися автоматично.

Служби інтеграції даних у складі SQL Server також надають багатий набір засобів тиражування інформації. За допомогою пакетів Data Transformation Services (DTS) можна не тільки импортироватьэкспортировать схему і дані між вузлами з SQL Server або будь-яких найрізноманітніша трансформація переданих між вузлами даних. Пакети DTS можуть передаватися також як і резервні копії і навіть використовуватися для передачі змін до стандартної реплікації. Бурхливий розвиток мобільних пристроїв призвело до появи, наприклад, такої нової технології синхронізації даних як Microsoft Synchronization Services для ADO.NET. Ця нова служба дозволяє синхронізувати дані з різних джерел, використовуючи дворівневу або багаторівневу архітектуру взаємодії спеціалізованих служб. Замість копіювання даних і схеми бази, прикладний програмний інтерфейс служби синхронізації надає в розпорядження розробника набір компонентів, з допомогою яких можна синхронізувати дані між службами надання даних і локальним сховищем даних користувача. Така архітектура орієнтована в першу чергу на тих мобільних клієнтів, які не мають гарантованого і надійного підключення по мережі до центрального сервера, і які можуть працювати якийсь час з локальною копією даних автономно. У даному випадку причиною тиражування даних є необхідність тимчасового кешування інформації у пристрої клієнта-передплатника.

Перераховані способи тиражування інформації без реплікації призначені для вирішення окремих, часто, дуже спеціалізованих завдань. Це можуть бути завдання забезпечення високої доступності, мобільності, підвищення надійності, наповнення сховища, реакції на відмову і т.п. На відміну від цих завдань, або на додаток до них, впровадження розподіленої системи з реплікацією викликано такими причинами, як необхідність зниження трафіку між вузлами через зовнішні комунікаційні з'єднання, для балансування навантаження між вузлами, для консолідації даних, для резервування даних, для масштабування і підвищення доступності додатків баз даних, а також для локального кешування даних користувачем.

Основною складністю при організації реплікації є поширення оновлень. Якщо один з беруть участь у реплікації об'єктів був змінений, це зміна потрібно коректно виконати на всіх що беруть участь у реплікації вузлах.

Фундаментальним принципом розподілених баз даних, за визначенням Дейта, є те, що для кінцевого користувача розподілена система повинна виглядати так само, як нерозподілений. Дейт, у своїй книзі "Введення в системи баз даних", сформулював дванадцять основних цілей, які повинна вирішувати розподілена система, щоб вважатися ідеальною з точки зору реплікації:

1. Локальна незалежність.
2. Відсутність опори на центральний вузол.
3. Безперервне функціонування.
4. Незалежність від розташування.
5. Незалежність від секціонування.
6. Незалежність від реплікації.
7. Обробка розподілених запитів.
8. Управління розподіленими транзакціями.
9. Апаратна незалежність.
10. Незалежність від операційної системи.
11. Незалежність від мережі.
12. Незалежність від типу СУБД.


Не всі ці цілі є неодмінно обов'язковими для системи, що претендує на назву системи з реплікацією, але їх досягнення може принести такі переваги, які будуть надзвичайно корисні для розподіленої системи. Давайте коротко розглянемо кожну з цих цілей і ті вигоди, які вони дають. Більш докладний їх визначення і пояснення можна знайти у зазначеній вище книзі Кріса Дейта.

Локальна незалежність означає, що всі вузли розподіленої системи повинні бути незалежні один від одного і легко переводитися в автономний режим роботи. Крім того, всі операції в рамках вузла повинні бути підконтрольні із сайтом та не залежати від стану чи іншим чином від інших вузлів розподіленої системи. При цьому локальні дані повинні зберігатися та обслуговуватися на своєму сайті в локальній базі даних, підкорятися діючим на цьому сайті правилам і обмеженням, бути доступними в рамках політики безпеки, що діє на локальному вузлі і в локальній базі даних, мати локальне управління, аудит і адміністрування. При зверненні до даних з інших вузлів розподіленої системи, дані повинні зберігати свою локальну приналежність. На практиці, в багатьох сучасних СУБД, кожна використовувана в розподілених системах база даних, управляється окремо і незалежно від інших баз даних, як ніби-то кожна така база ніяк не пов'язана через мережу з іншими базами даних. Хоча кожна база даних може працювати з іншими, вони являють собою відмінні, окремі системи, кожна з яких вимагає індивідуального підходу.

Оскільки дані реплицируются в місце локальної обробки, то збої в роботі мережі і віддалених систем мають незначний вплив на користувача. Дані можуть оброблятися локально, поки зв'язок з джерелом даних не буде відновлена.

Кожен вузол системи з реплікацією практично незалежний від інших при виборі конфігурації і способу обробки даних. Можна довільно вибирати тип і підмножина даних, яке буде передаватися або прийматися кожним з вузлів. Допускається навіть змінювати оригінальні імена таблиць і стовпців видавця на свої, діючі локально на передплатника. Крім того, оптимізація структури і доступу до даних кожного вузла може виконуватися індивідуально, виходячи з його потреб та конфігурації.

Дейт вважає, що відсутність опори на центральний вузол, у загальному випадку означає, що локальний вузол не повинен залежати від служб, що працюють на іншому, можливо єдиному для всіх вузлів розподіленої системи, "Центральному" або "головне" вузлі. Тут не маються на увазі служби, відповідальні за тиражування даних, не повинно бути служб централізованої обробки запитів або управління транзакціями, як і будь-яких інших служб, через які система в цілому може стати залежною від центрального вузла. В ідеальному випадку, кожен вузол може бути самодостатній, а розподілена система реалізує схему однорангової реплікації з суміщенням на кожному вузлі ролей видавця і передплатника. Однак, це не виключає можливості побудови схем з централізованим тиражування або накопиченням даних. Часто потрібно якраз централізована схема управління розподіленою системою, а опора на центральний вузол задається як одне з бізнес-вимог. До таких систем можна віднести сховища баз даних, які поповнюються інформацією з безлічі джерел розподіленої мережі вузлів, або навпаки, коли одна і та ж інформація тиражується по вузлах філіальної мережі. Часто, єдину точку входу створюють з метою балансування навантаження на систему розподілених вузлів, що теж не вкладається в позначену Дейтом мета – відсутність опори на центральний вузол. Відсутність опори на центральний вузол важливо в тих випадках, коли всі вузли повинні бути рівноправні і втрата будь-якого не повинна призводити до втрати працездатності інших. Зазвичай, реплікація виконується окремими від ядра СУБД модулями, спеціально призначеним для реплікації даних.

У своїй книзі Дейт під безперервним функціонуванням розуміє такі показники СУБД як надійність і доступність. Часто, реплікація використовується не тільки для наближення даних до споживача (підвищення доступності), але і для підвищення надійності зберігання інформації (за рахунок її тиражування). Під надійністю, зокрема, розуміється високий ступінь ймовірності того, що система буде працювати в будь- момент часу. Для розподілених систем з реплікацією характерно збереження працездатності навіть у випадках відмов частини їх компонентів, таких як окремий вузол. Під доступністю розуміється ймовірність безперервного функціонування системи протягом заданого часу. Оскільки реплікація дозволяє дублювати дані, можна непомітно перемикати користувачів між вузлами, підвищуючи тим самим доступність розподілених систем за рахунок дублювання.

Важливо також відзначити, що безперервність функціонування важлива з точки зору одного вузла. У великій розподіленій системі може постійно існувати кілька відключених або непрацюючих з яких-небудь причин вузлів, і це може бути звичайним явищем. Тому, однією з найважливіших характеристик розподіленої системи є можливість відновлення працездатності відключеного сайту або групи вузлів, причому, незалежно від того, які функції в розподіленій системі ці вузли виконують. Повинні передбачатися такі процедури, як відновлення тиражування з обміном накопичених змін або з повторною, повної ініціалізації даних вузла.

На безперервність функціонування локального вузла розподіленої системи можуть впливати не лише фактори реплікації, а й інші властиві СУБД фактори, такі як необхідність періодичного обслуговуванні, профілактика і т.п. Можливості розподіленої системи можна використовувати і для того, щоб зберегти для користувача доступ до даних навіть під час технологічних вікон обслуговування вузла, переключивши їх на інший, рівнозначний вузол.

Основна ідея незалежності від розташування полягає в тому, що з точки зору користувача будь-які доступні йому в розподіленій системі дані повинні виглядати як зберігаються на локальному вузлі. Користувач нічого не повинен знати про місце фізичного зберігання даних, а додатки зможуть звертатися до таких даних уніфіковано і однаково працювати на будь-якому з вузлів розподіленої системи, навіть якщо дані будуть переміщені на інший вузол. Незалежність від розташування дозволяє розміщувати дані там, де вони потрібні. Це зменшує залежність від відмов мереж передачі даних і скорочує загальні витрати на обмін інформацією.

Система, за словами Дейта, незалежна від секціонування, якщо секціонування (тобто фізичне розділення таблиць на частини чи фрагменти) виконується прозоро для кінцевого користувача, тобто логіка роботи повинна бути такою ж, як і з несекціонірованнимі даними. Секціонування використовується для підвищення продуктивності вилучення даних за рахунок скорочення обсягу оперованих даних. Також, за допомогою розподіленого секціонування дані можуть фізично зберігатися у тому місці, де вони найчастіше використовуються. Це дозволяє локалізувати великі запити і скоротити обсяг зовнішнього мережевого трафіку. Застосування розподіленого секціонування дозволяє домогтися спільного використання віддаленими вузлами тільки тих даних розподіленої системи, в яких вони потребують, і не більше. Незалежність від секціонування – Це гарантія того, що секції даних у будь-який момент можуть бути наново зібрані в одну таблицю, причому це не вплине на працездатність і правильність відображення даних в додатках користувача.

Незалежність від реплікації означає, що реплікація повинна бути "прозорою для користувача", тобто логіка роботи з даними повинна бути такою ж, як і без реплікації. Іншими словами, таблиці або секції таблиць бази даних, з якими працює користувач, можуть включатися в реплікацію без переробки програм і, часто, непомітно для користувача. Ця мета не така проста, як здається на перший погляд, оскільки "прозорість" реплікації залежить не тільки від реалізації реплікації виробником СУБД, а також від того, як була реалізована топологія і схема реплікації об'єктів бази даних розробником програму або адміністратором баз даних. Крім того, що відповідають за реплікацію компоненти можуть впливати на роботу вузла і опосередковано впливати на операції користувачів, що теж ускладнює вирішення поставленої мети. Непросто забезпечити незалежність від реплікації в умовах гетерогенних вузлів.

Розподілені системи повинні бути реляційними, тому що такі системи дозволяють оптимізувати обробку запитів. По продуктивності розподілена реляційна система може істотно перевершує не реляційну систему.

Для розподілених запитів характерне використання протоколу двофазної фіксації, включаючи гетерогенні джерела, а також можливий асинхронний режим роботи за допомогою черг. Підключення гетерогенних джерел через свого провайдера дозволяє використовувати оптимізатор гетерогенного джерела.

Дейт наголошує на двох основних аспекти управління транзакціями: управління відновленням і керування паралельністю роботи. У реплікації обидва ці аспекти отримують додатковий сенс і значення. Коли ми маємо справу з розподіленою системою, в рамках однієї транзакції можуть бути виконані DML або DDL-операції з об'єктами на декількох вузлах, причому, розподілена система повинна вміти керувати ходом виконання всіх таких операцій і не допускати блокування одних і тих же ресурсів при виконанні операцій в рамках розподіленої транзакції. Точно також, реплікація повинна гарантувати атомарность розподілених транзакцій і надавати можливість відкоту таких транзакцій, як це передбачено протоколом двофазної фіксації.

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

У сучасних СУБД передача транзакцій може здійснюватися асинхронно, коли вузол-одержувач знаходиться в офлайні або в режимі відкладених команд, і коли агенти реплікації зв'язуються асинхронно, поміщаючи запити в черзі і потім продовжуючи їх роботу. У деяких СУБД поряд з двофазної фіксацією, використовується механізм реплікації подій, який забезпечує оповіщення віддалених вузлів про події, дозволяючи кожному такому вузлу реагувати на події у відповідності з його потребами.

Під апаратної незалежністю мається на увазі можливість запуску однієї і тієї ж СУБД на різних апаратних платформах. Бажано, щоб працюють на різних платформах вузли в рамках розподіленої системи з реплікацією були рівноправні.

Вже давно затребувана можливість запуску однієї і тієї ж СУБД під управлінням різних операційних систем. Сьогоднішні можливості віртуалізації багато в чому знижують складність вирішення цього завдання. Мається на увазі, що розподілена система з реплікацією повинна вміти підтримувати використовуються для зв'язку між вузлами комунікаційні мережі і не залежати від заміни мережі або комунікаційного каналу, а також маршруту передачі даних.

Під незалежністю від типу СУБД мається на увазі, що системи управління базами даних, які можуть працювати на різних платформах і під управлінням різних операційних систем, при включенні в розподілену систему зможуть використовувати для організації реплікації даних один і той же інтерфейс.

Вибір типу реплікації

Одними з основних чинників при виборі типу реплікації для тиражування даних є ступінь автономності передплатників і величина допустимої затримки передачі змін від породив їх вузла на всі беруть участь у реплікації вузли. У SQL Server існує три різновиди реплікації: реплікація моментальних знімків, реплікація транзакцій і реплікація злиттям. У всіх цих типів є підтипи, зі своїми характеристиками автономності та затримки. Під автономністю прийнято розуміти можливість використання бази даних без забезпечують реплікацію механізмів, і без підключення до інших систем баз даних. Наприклад, база даних на портативному комп'ютері може використовуватися і тоді, коли комп'ютер не підключений до мережі. Затримка ж визначається періодом часу, протягом якого розташовані на різних вузлах копії даних можуть бути не ідентичні через незавершеність процесу тиражування змін. Це можуть бути секунди, хвилини, години, дні і навіть місяці, максимальний час можливої затримки визначає вимогами бізнес-правил.

Крім реплікації, у SQL Server є ще декілька технологій, придатних для тиражування даних, для яких теж застосовні характеристики автономності та затримки. До таких технологій можна віднести: розподілені запити, техніку резервування з подальшим відновленням на іншому сайті, доставку журналів, дзеркальне відображення, копіювання DTS-пакетів засобами служби Integration Services, експорт / імпорт через BCP, а також нову технологію в Visual Studio 2008 – служби синхронізації для ADO.NET. Багато з цих технологій застосовуються на різних стадіях реплікації.

З точки зору автономності, багато технологій близькі за показниками і легко об'єднуються в групи. Так, наприклад, всі способи передачі даних за допомогою файлів імпорту-експорту показують хорошу автономність, оскільки в перервах між передачами і завантаженням-вивантаженням дані доступні для локального використання. Однак, при передачі великих обсягів даних за допомогою транспортних файлів може сильно зрости час, що витрачається на їх транспортування та завантаження-вивантаження. При цьому затримка тиражування може бути досить значною. У реплікації аналогічні показники автономності спостерігаються у двох типів реплікації. По-перше, це реплікація злиттям, яка має в своїй основі критичний механізм, не використовує розподілених транзакцій і потребує метаданих інших вузлів тільки під час сеансів обміну змінами з видавцем. Все це робить беруть участь у реплікації вузли автономними і ступінь автономності висока. Цей тип реплікації відрізняється невеликими значеннями затримки тиражування. Крім того, типи реплікації, що допускають передачу змін з передплатника на видавця (а реплікація злиттям є за своєю природою двобічної з точки зору передачі таких змін) мають спеціальні параметри запуску своїх агентів реплікації, що дозволяють регулювати число змін в рамках одного сеансу. Таким чином, можна диференційовано впливати на затримку тиражування змін, переданих з видавця кожному передплатнику.

Будь-які додавання і зміни даних записуються в спеціальні локальні таблиці метаданих реплікації злиттям. Під час сеансів синхронізації агент реплікації злиттям звіряє метадані абонентів і видавця, виконуючи передбачені метаданими дії щодо синхронізації інформації обох джерел. Оскільки одні і ті ж дані можуть змінюватися одночасно на різних вузлах і цілісність ключів повинна забезпечуватися у всій розподіленої топології реплікації, в реплікації злиттям можливе виникнення конфліктів змін даних, і для вирішення цих конфліктів передбачені спеціальні заходи та механізми.

Другий з найбільш автономних типів реплікації – це реплікація моментальних знімків. У чистому вигляді, реплікації моментальних знімків використовує для тиражування даних їх моментальні знімки, після чого розповсюджувач тиражує ці знімки (набір файлів або архівний файл) передплатникам, які потім їх самостійно застосовують у своїх базах даних. Створення та тиражування моментальних знімків може здійснюватися на періодичній основі або на вимогу. Оскільки в самому простому випадку кожен передплатник отримує одні й ті ж дані і не може вносити в них зміни, конфлікти виключені. Виходить, що кожен передплатник має свою копію публікації видавця, чим забезпечується дуже висока автономність, а можливість тиражування змін даних на стороні абонентів не передбачена зовсім. Час передачі знімка від видавця передплатникам визначається розмірами транспортних файлів, характеристиками каналу передачі даних і можливостями серверного комплексу і може бути досить великим, обумовлюючи високу затримку тиражування. Оскільки у реплікації моментальних знімків використовується передача всіх реплицируемой об'єктів і даних, цей тип реплікації, поряд з відновленням з резервної копії, використовується у всіх інших типах реплікації для початкової синхронізації даних. Існують різновиди реплікації моментальних знімків, які передбачають можливість оновлення реплицируемой даних на передплатника. Наприклад, в SQL Server 2000 таке оновлення здійснювалося за допомогою розподіленої транзакції безпосередньо в базі даних видавця або через механізм обслуговування черг. Потрібно розуміти, що використання розподілених транзакцій або черг впливає на автономність бази даних абонентів і, в разі інтенсивного та сталого використання цих механізмів, може призвести до втрати автономності передплатника.

Реплікація транзакцій дає не більше можливостей автономності для користувачів, ніж реплікація моментальних знімків з оновленням на передплатника. Цей тип реплікації характерний тим, що дані, внесені, змінювані або видаляються на видавця, тиражуються передплатникам у вигляді хронологічно вибудуваних транзакцій. Оскільки кожен передплатник отримує одні й ті ж дані і в простому випадку не вносить у ці дані змін, виникнення конфліктів виключається. Між сеансами синхронізації кожен передплатник має цілісним знімком даних (автономність у деякому роді). Оскільки транзакції доставляються передплатникам не миттєво, зміни в даних доступні на передплатника теж з деякою затримкою тиражування. Можливий варіант реплікації транзакцій з оновленням на передплатника, природа якого дуже схожа на те, як це реалізовувалося в реплікації моментальних знімків з оновленням на передплатника. Цей варіант накладає ще більше обмежень на автономність передплатників.

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

Одну з провідних ролей у реплікації SQL Server грають агенти, які є звичайними програмами, реалізованими у вигляді виконуваних модулів. Найбільш важливу роль у реплікації грають чотири агента реплікації, це програми: distrib.exe – Replication Distribution Agent (агент розповсюджувача); snapshot.exe – Replication Snapshot Agent (агент моментальних знімків); replmerg.exe – Replication Merge Agent (агент злиття); і logread.exe – Replication Log Reader Agent (агент читання журналу транзакцій в реплікації транзакцій).

Для SQL Server 2000 всі ці чотири програми можна знайти в каталозі за замовчуванням: "C: Program FilesMicrosoft SQL Server80COM". Для SQL Server 2005/2008 шлях до програм відрізняється тільки папкою версії, замість "80" буде "90" або "100". Для того щоб подивитися параметри виклику цих програм, необхідно запустити відповідні виконувані файли з ключем "/?". На екрані буде наведено синтаксис їх запуску і перелік можливих ключів. Ця інформація докладно викладена в документації, що поставляється з сервером баз даних.

Зверніть увагу на те, що параметри можуть бути визначені в будь-якому порядку. Коли додаткові параметри не визначені, використовуються значення зумовлених параметрів в системному реєстрі локальної системи. Більшість параметрів визначають метадані, необхідні для підключення програм, проте цілий ряд параметрів застосуємо для тонкої настройки продуктивності реплікації, а також для регулювання і налаштування поведінки алгоритмів, закладених в роботу агентів, на різних етапах логічної послідовності операцій. Оточення беруть участь у реплікації серверів і можливості їхніх комунікацій можуть сильно відрізнятися на різних ділянках топології реплікації. Для врахування можливих відмінностей та обмежень можна використовувати існуючі параметри виклику програм-агентів реплікації.

У табл. 1 представлені параметри виклику агентів реплікації SQL Server 2000, з допомогою яких можна регулювати породжувану реплікацією навантаження на сервери, а також обмежувати трафік реплікації між серверами.

Табл. 1. Управління навантаженням і трафіком




































BcpBatchSize MaxBcpThreads ReadBatchThreshold
Buffers MaxCmdsInTran SrcThreads
CommitBatchSize MaxDeliveredTransactions StartQueueTimeout
CommitBatchThreshold MaxDownloadChanges UploadReadChangesPerBatch
DestThreads MaxUploadChanges UploadReadChangesPerBatch
DownloadGenerationsPerBatch PacketSize UploadWriteChangesPerBatch
DownloadReadChangesPerBatch PollingInterval UseInprocLoader
DownloadWriteChangesPerBatch ReadBatchSize  

Набір параметрів запуску програми агента реплікації може бути унікальним для кожного сервера або єдиним для всіх серверів-передплатників. Задавати параметри можна через стандартний або користувальницький профіль агента, а також безпосередньо в завданні за розкладом, який обслуговується агентом сервера і в якому одним із кроків завдання викликається програма агента реплікації.

Параметри запуску агента розповсюджувача можна змінити, додавши до стандартного набору параметрів додатковий, наприклад, з ім'ям UseInprocLoader і присвоївши йому значення "1". Для довідки зазначу, що це підвищує ефективність використання початкового знімка, наказуючи агенту розповсюджувача використовувати команду BULK INSERT при застосуванні файлів знімка на передплатника.

Профіль агентів реплікації може бути заданий, перевизначений або створений за допомогою спеціалізованого майстра, в SQL Server 2000 він носив назву "Agent Profiles for". Майстер використовує у своїй роботі системні таблиці в базі даних msdb. У таблиці MSagent_profiles зберігатися інформація про існуючі профілях агентів реплікації. Переглянути цю інформацію можна за допомогою наступного запиту:

Для кожного з типів реплікації існує заздалегідь зумовлену набір стандартних системних профілів. Скориставшись вибором відповідного режиму, можна застосувати зазначений профіль до всіх агентам реплікації, зареєстрованим на сервері. Кожен профіль має заданий набір параметрів, які в електронній документації до SQL Server прийнято називати аргументами. За замовчуванням, набір параметрів такої, як це визначено в таблиці MSagent_parameters. Однак, параметрів може бути більше, ніж визначено і повний список можливих аргументів для кожного з типів агентів можна побачити в таблиці MSagentparameterlist.

За допомогою параметрів можна впливати на продуктивність роботи агентів, а, отже, і на реплікацію в цілому. Однак, варто віддавати собі звіт в тому, що публікація тільки необхідної кількості даних може виявитися найефективнішим методом підвищення продуктивності реплікації.

Роботою агентів реплікації управляє служба SQL Server Agent. Це не тільки дозволяє забезпечити простоту запуску агентів реплікації за розкладом, практично, в стандартній реалізації всі агенти реплікації працюють як підсистеми служби SQL Server Agent. Однак, ви можете почати сеанс реплікації, запустивши відповідного агента реплікації з командного рядка, з прикладної програми, з командлетів PowerShell або, наприклад, з командного файлу, що викликається на виконання планувальником операційної системи. У SQL Server 2000 були реалізовані компоненти для контролю роботи агентів реплікації з користувацьких додатків за допомогою Microsoft ActiveX controls. Відповідність бібліотек програмами агентів реплікації показано в табл. 2.

Табл. 2. Бібліотеки Microsoft ActiveX controls




























Ім'я агента  Виконуваний файл  Елемент керування ActiveX 
Агент моментальних знімків snapshot.exe sqlinitx.dll
Агент читання журналу logread.exe Ні
Агент читання черг qrdrsvc.exe Ні
Агент розповсюджувача distrib.exe sqldistx.dll
Агент злиття replmerg.exe Sqlmergx.dll

У SQL Server 2005 був зроблений наступний крок до поліпшення можливостей управління роботою агентів реплікації з додатків і вбудовування реплікації в додатки третіх фірм. Одним з нововведень реплікації в цій версії став набір об'єктів управління реплікацією, який називається: "Replication Management Objects" (RMO), і являє собою керований код, що надає доступ до функціональності агентів реплікації. Усі завдання реплікації, які доступні в програмі SQL Server Management Studio, можуть виконуватися програмно за допомогою RMO.

У реплікації та її агентів є свої власні лічильники продуктивності, які можна знайти в оснащенні системного монітора. Наприклад, кількість запущених агентів реплікації показує лічильник: "Microsoft SQL Server: Replication Agents”.

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

Replication Snapshot Agent

Програма агента моментальних знімків (Replication Snapshot Agent) на основі заданої параметрами запуску або профілем конфігурації створює файли моментального знімка. Моментальний знімок містить схему даних і самі дані виданих таблиць і об'єктів бази даних. Файли зберігаються в папці моментальних знімків, а запуск агента виконується за розкладом відповідним завданням на сервері, де розташована база даних розповсюджувача. Крім того, агент моментальних знімків фіксує в базі даних розповсюджувача інформацію про стан синхронізації. Агент моментальних знімків не призначений для розповсюдження створених ним знімків. При реплікації знімками цей агент запускається настільки часто, наскільки необхідно забезпечити прийнятну періодичність забезпечення синхронності підписаних баз даних. Для реплікації транзакцій або реплікації злиттям моментальні знімки необхідні рідше, аж до того, що вони можуть створювати тільки тоді, коли виникне необхідність підключення нового передплатника.

Після того, як запущений на розповсюджувача агент моментальних знімків встановлює підключення до видавця (за умовчанням, це може бути той самий сервер), він встановлює поєднуються (shared lock) блокування на всіх таблицях, включених до публікації. Це йому потрібно для копіювання схеми даних і гарантії несуперечності знімка. Оскільки такий рівень блокування заважає іншим користувачам вносити зміни в таблиці, створення знімка краще планувати на час мінімальної активності. Сценарії схеми таблиць, уявлень і збережених процедур зберігаються у файлах з розширенням "sch". Сценарії створення індексів зберігаються у файлах з розширенням "idx". Сценарії створення тригерів будуть у файлах з розширенням "trg". Обмеження для підтримки декларативної посилальної цілісності будуть знаходитися у файлах з розширенням "dri". Дані будуть знаходитися у файлах з розширенням "bcp". Агент моментальних знімків отримує всю необхідну інформацію в базах даних видавця, вивантажуючи дані з публікованих таблиці у файли моментального знімка. Ці файли є сценарії для створення всіх необхідних об'єктів і синхронізації даних, зберігаючи моментальний знімок даних на момент часу створення знімка. Знімок створюється для тих статей, які входять в публікацію, і все це реєструється в системних таблицях бази даних розповсюджувача: MSrepl_commands і MSrepl_transactions. У таблиці MSrepl_commands зберігаються покажчики на місця розміщення знімків статей, а також посилання на передують синхронізацію сценарії, якщо такі є. У таблиці MSrepl_transactions зберігаються посилання на відповідні завдання синхронізації передплатника. Після того як записи в цих двох таблицях будуть зроблені, поєднується блокування з видаються таблиць знімається.

У SQL Server 2000 майстер створення публікації "Create Publication Wizard" за замовчуванням не включає опцію паралельної роботи зі знімком, яка дозволяє пом'якшити вплив, викликане накладенням совмещаемой блокування на видаються таблиці. У властивостях публікації, на вкладці Snapshot можна включити опцію "Do not lock tables during snapshot generation", яка дозволяє користувачам інформації, що публікується бази даних продовжувати роботу і під час створення моментального знімка. Не рекомендується включати цю опцію, якщо публікується таблиця має унікальний індекс, який не є первинним ключем або кластерним індексом. Крім того, включення цієї опції може істотно збільшити час створення знімка. Для створення знімків даних використовується програма масового копіювання BCP. У профілі агента створення знімків і в числі аргументів виклику програми агента моментальних знімків є параметри, які дозволяють оптимізувати роботу BCP. Зокрема, мова йде про значення аргументу BcpBatchSize, який дозволяє розбивати потік експорту / імпорту даних на блоки. Цей аргумент задає кількість рядків, які використовуються в операціях масового копіювання. При виконанні операцій "BCP IN", вказується розмір блоку – це кількість рядків, які надсилаються сервера як одна транзакція, а також число рядків, які повинні бути послані, щоб агент розповсюджувача зареєстрував у своєму журналі черговий крок у послідовності операцій BCP. При виконанні операцій "BCP OUT" використовується встановлений за умовчанням розмір пакету, який дорівнює 1000. Значення 0 відповідає відсутності реєстрації кроків BCP. Якщо ви сумніваєтеся, який розмір блоку слід вибрати для створення моментального знімка вашої публікації, скористайтеся значенням, запропонованому за умовчанням в системному профілі агента моментальних знімків. Для цього агента в SQL Server 2000 пропонувався тільки один профіль, на підставі якого можна будувати свої, призначені для користувача профілі для всіх публікацій або для кожної публікації окремо.

Табл. 3. Зумовлений в SQL Server 2000 профіль для агента моментальних знімків






















Параметр  Значення за замовчуванням 
BcpBatchSize 100000
HistoryVerboseLevel 2
LoginTimeOut 15
MaxBcpThreads 1
QueryTimeOut 300

Помітний вплив на час створення знімка надає аргумент MaxBcpThreads. Він визначає число потоків операцій масового копіювання, які можуть бути виконані паралельно. Максимальне число потоків і підключень, які існують одночасно, буде не більше, ніж значення MaxBcpThreads або число запитів на масове копіювання, які опиняться при синхронізації транзакцій в базі даних розповсюджувача (Для агента злиттям вони будуть в системній таблиці sysmergeschemachange бази даних видавця). Аргумент MaxBcpThreads повинен бути більше нуля і не має верхньої межі. Значення за замовчуванням дорівнює -1. При застосуванні знімка, який був створений видавцем, використовують опцію паралельного створення знімка, буде використовуватися один потік, незалежно від заданого для аргументу MaxBcpThreads значення. Практика показує, що навіть для однопроцесорних систем є сенс встановлювати значення аргументу MaxBcpThreads більше одиниці. На одному процесорі я віддаю перевагу задавати цього аргументу значення, рівне 3.

Створення знімка може призводити до підвищення навантаження на дискову підсистему, де розташовуються файли моментального знімка публікації. При плануванні розміщення файлів і розбитті дискових масивів необхідно враховувати, що викликана створенням знімків додаткове навантаження може негативно позначитися на інших процесах і завданнях, які звертаються до цих же дисків. Доброю практикою є планування створення моментальних знімків у години найменшого навантаження, щоб при необхідності використовувати для передачі агенту розповсюджувача вже заготовлений знімок. Такий підхід можливий, якщо після застосування знімка реплікація не переданих з ним змін буде виконуватися без особливого навантаження апаратних і комунікаційних засобів, і не буде перевищувати допустимі регламентами терміни. Інакше, необхідно резервувати запас продуктивності процесорів і дискової підсистеми для забезпечення необхідного рівня продуктивності під час створення моментальних знімків.

При кожному запуску агента моментальних знімків виконується перевірка на появу нових підписок. Якщо за час, що минув з останнього створення знімка, не з'явилося нових підписок, файли сценаріїв або знімків даних не створюються. Однак, якщо була задана команда негайного створення моментального знімка, агент моментальних знімків створить нові файли схеми і знімків даних.

Для полегшення роботи з уже готовими моментальними знімками рекомендується використовувати опцію стиснення знімка в CAB-файл. Для гарантії доставки файлу знімка краще знімки викладати у каталог сервера FTP. Однак, стиснення файлів знімків вимагає додаткової витрати ресурсів системи при створенні та застосуванні файлу моментального знімка і збільшення часу генерації та застосування знімка.

Запуск програми агента моментальних знімків краще робити тільки тоді, коли це необхідно, і не під час пікового навантаження, щоб уникнути блокувань. Папки моментальних знімків краще розміщувати на диску, не використовується для зберігання файлів бази даних або файлів журналів транзакцій. Також, варто використовувати по одній папці для моментальних знімків кожної публікації, щоб скоротити кількість операцій для підтримки знімків в інших папках.

У разі тривалого переривання сеансів реплікації, може настати момент, коли вигідніше не чекати синхронізації всіх накопичених змін, а застосувати свіжий моментальний знімок. При великому розмірі публікації це може виявитися досить тривалою і дорогою операцією. Щоб уникнути такої ситуації, бажано налаштувати розсилку сповіщень про всі критичних події в системі реплікації. Бажано також створити "оператора останньої надії" (fail-safe operator), щоб гарантувати доставку таких повідомлень.

Застосуванням моментального знімка на передплатника займається агент розповсюджувача. Для цього він спочатку встановлює підключення до сервера, де розташовується база даних розповсюджувача, щоб отримати в таблицях MSrepl_commands і MSrepl_transactions інформацію про те, які знімки необхідно застосувати даному передплатнику. Там же він отримує відомості про розташування теки моментального знімка. Наступним кроком він застосовує у базі даних абонентів сценарії створення / зміни схеми, які створюють всі необхідні об'єкти. При необхідності здійснюється конвертація типів даних, яка буває потрібна для абонентів інших версій або СУБД. Коли схема готова, здійснюється операція масової вставки даних. Після того як всі статті стануть синхронні з публікацією, і для основних таблиць буде забезпечена транзакційна і посилальна цілісність, у підписаній базі даних створюються системні об'єкти реплікації, а також тригери, процедури або подання. Всі ці кроки реєструються в базі даних розповсюджувача.

Для моніторингу продуктивності роботи агентів моментальних знімків можна використовувати лічильники продуктивності об'єкта "SQL Server: Replication Snapshot.", Які показують скільки команд або транзакцій було передано розповсюджувачу. Лічильник: "Snapshot: Delivered Cmds / sec" показує передане розповсюджувачу кількість команд у секунду, а лічильник "Snapshot: Delivered Trans / sec" передане в секунду число транзакцій.

Replication Distribution Agent

Агент розповсюджувача (Replication Distribution Agent) використовується для доставки моментальних знімків передплатникам, а також для тиражування змін до реплікації транзакцій. Свою конфігурацію він отримує з рядка запуску або запитує її із заданого йому профілю. Після цього він переміщує моментальний знімок (для реплікації знімків і реплікації транзакцій), визначений в таблицях бази даних розповсюджувача (Для реплікації транзакцій), у вказані місця призначення на передплатників. Агент розповсюджувача запускається для кожної публікації і виконується на передплатника, при передплаті у режимі "pull", а при передплаті в режимі "push", він працює на розповсюджувача. Агент розповсюджувача вміє передавати дані у вигляді команд або транзакцій не тільки безпосередньо передплатникам, але і на вхід DTS-пакета. Для реплікації моментальних знімків періодичність запуску визначається вимогами до оновлення інформації на передплатників.

Для реплікації транзакцій передача моментального знімка виконується при первісній синхронізації (якщо в налаштуваннях підписки не вказано інше) або для примусової, повторної ініціалізації передплатника. В інший час агент розповсюджувача в реплікації транзакцій займається доставкою передплатникам пакетів команд зміни даних, які він бере зі своєї бази даних, звертаючись до таблиці MSrepl_commands, містить записи про реплікованих командах, і до таблиці MSrepl_transactions, яка містить по одному рядку для кожної реплицируемой транзакції. Крім того, розповсюджувач передає передплатникам хронологію сеансів реплікації і відомості про виниклі помилки.

SQL Server 2005 з'явилися два нових типи первісної синхронізації (один задавався параметром "replication support only", а другий використовував ініціалізацію резервної копією), що спрощують ініціалізацію передплатників, які дозволяють виконати синхронізацію вручну (в англомовній документації така синхронізація називається: "no-sync subscriptions"). Необхідність ручної синхронізації була викликана завданнями автоматизації підготовки бази даних передплатника для реплікації, а також, за допомогою ручної синхронізації можна істотно скоротити час простою, якщо використовувати вже синхронну резервну копію.

У SQL Server 2008 з'явився ще один новий тип синхронізації – ініціалізація по LSN. Цей тип синхронізації використовується для внутрішніх потреб в однорангової реплікації транзакцій. Він схожий на ініціалізацію резервної копією, відрізняючись тим, що ініціалізація буде продовжена починаючи з зазначеного LSN, тобто від Уповноваженої в базу даних абонентів будуть довантажений ті транзакції, які були зареєстровані після вказаного номера віртуального журналу. Такий тип синхронізації дуже зручний для скорочення часу відновлення абонентів після відмови, оскільки довантаженням транзакцій займає, як правило, менше часу, ніж повна ініціалізація, а Агент Уповноваженої продовжить роботу з того місця, де він зупинився через відмову абонентів, або відмови Дзеркального відображення.

База даних розповсюджувача поповнюється відомостями про новостворених моментальних знімках, які постачає агент моментальних знімків. Агент читання журналу запускає на видавця системну процедуру sp_replcmds, що повертає команди, з яких складаються помічені для реплікації транзакції. Ці команди зберігаються в базі даних розповсюджувача, який доставляє їх всім передплатникам і відстежує, були Чи є команди доставлені успішно за відведений для цього час. Крім цього, агент читання журналу, за допомогою системної збереженої процедури sp_repldone, оновлює запис у журналі транзакцій видавця, яка ідентифікує останню розподілену транзакцію сервера. Тобто ті транзакції, які були успішно реплікувати всім зареєстрованим учасникам, можуть бути прибрані з журналу в резервну копію, і займане ними місце в журналі реєстрації транзакцій публікується бази даних на видавця може бути вивільнено для інших віртуальних журналів. Інформацію для цього він також бере з бази даних розповсюджувача, де знаходить дані про успішно реплікованих командах.

За допомогою аргументу MaxDeliveredTransactions програми агента розповсюджувача можна задати максимальну кількість "push" або "pull"-транзакцій, застосованих на передплатника в рамках одного сеансу синхронізації. Значення 0 вказує, що буде застосовано максимально можливе число транзакцій. Інші значення можуть використовуватися на передплатника для того, щоб скоротити тривалість синхронізації з видавцем. Це дозволяє управляти трафіком транзакцій по мережі, а також навантаженням, породжуваної агентом розповсюджувача на сервер запуску і на сервер, який обслуговує базу даних абонентів.

Навантаженням на передплатника дозволяють управляти ще два аргументи агента розповсюджувача. Аргумент CommitBatchSize задає число транзакцій, які будуть виконані передплатником перш, ніж буде виконана інструкція COMMIT обрамляє транзакції. Значення за замовчуванням дорівнює: 100. Аргумент CommitBatchThreshold задає число команд реплікації, які будуть виконані передплатником перш, ніж буде виконана інструкція COMMIT. Значення за замовчуванням дорівнює: 1000.

У базі даних розповсюджувача присутні й інші таблиці, які використовуються для деяких режимів реплікації. Таблиця MSrepl_backup_lsns потрібна для синхронізації реплікації транзакцій з резервною копією. Таблиця MSrepl_errors містить інформацію про помилки агентів розповсюджувача і злиття. Таблиця MSrepl_identity_range призначена для управління діапазонами ідентифікаторів. Таблиця MSrepl_originators потрібна оновлюваним передплатникам. Таблиця MSreplication_queuedtraninfo потрібна для організації черг команд. У таблиці MSrepl_version зберігаються дані про поточні версіях реплікації. Таблиця MSreplication_monitordata використовується монітором реплікації, і т.д.

Якщо ви запускаєте службу SQL Server Agent під обліковим записом локальної системи (значення за замовчуванням), а не під обліковим записом користувача домену, служба зможе звертатися тільки до локального комп'ютера. Якщо агент розповсюджувача, робота якого керується службою SQL Server Agent, буде при цьому використовувати для доступу до примірника SQL Server режим аутентифікації Windows, агент розповсюджувач не зможе нормально працювати. У SQL Server 2000, параметр за замовчуванням для режиму аутентифікації – власна аутентифікація SQL Server.

В агента розповсюджувача існує кілька визначених профілів. Для SQL Server 2000 їх було чотири. Один профіль використовувався за замовчуванням і включав значення аргументів запуску агента розповсюджувача для найбільш поширених варіантів реплікації. Цей профіль можна взяти за відправну точку для початку налаштування агентів розповсюджувача.

Існує також профіль для безперервного режиму роботи агента розповсюджувача, який, працюючи в тандемі з агентом читання журналу, може в безперервному режимі відстежувати і тиражувати зміни від видавця передплатникам. Потрібно відзначити, що безперервний режим теж є дискретним, і цю дискретність у секундах визначає ще один аргумент агента розподільника PollingInterval.

Іншим профілем є профіль для розширеної діагностики і хронології сеансів реплікації агента розповсюджувача. Він визначає деталізацію хронології, реєстрованої під час виконання операцій агента дистрибутора, агента злиття або протягом виконання операцій з моментальним знімком. Основна відмінність цього профілю від інших – це значення аргументу HistoryVerboseLevel, який визначає обсяг інформації, протоколіруемой в журналі роботи агента. Збільшення рівня деталізації допомагає швидше локалізувати проблему і прийняти відповідні заходи за рахунок отримання більш детальної хронології сеансу реплікації. Потрібно зауважити, що цей аргумент використовується в усіх агентів реплікації. Можливі три значення для цього аргументу. У профілях за замовчуванням для агента розповсюджувача, агента моментальних знімків і агента читання журналу для цього аргументу задане значення 1. При такому рівні деталізації завжди оновлюються попередні хронологічні записи з таким же як у поточного завдання станом (startup, progress, success і так далі). Якщо не існує жодної попереднього запису з тим же самим станом, у звіт вставляється нова запис. Для агента злиття в профілі за замовчуванням аргументу задане значення "2". При такому рівні деталізації вставляються хронологічні записи, якщо ці записи не є повідомленнями про відсутність активності або повідомленнями про виконуються довго завданнях, для яких відбувається оновлення попередніх записів. Якщо аргументу задати значення "3", це призведе до того, що нові записи в хронологічний журнал будуть вставлятися у всіх випадках, крім тих, коли вони є повідомленнями про відсутність активності. Крім цього аргументу для отримання максимально можливого рівня деталізації хронології роботи агентів реплікації, можна використовувати два аргументи, які дозволяють виводити хронологію у зовнішній файл. Включається такий режим журналірованія додаванням аргументу Output, значення якого задає шлях до файлу звіту роботи агента і його ім'я. Якщо шлях не вказаний, вивід здійснюється на консоль. Якщо вказане ім'я файлу існує, записи додаються в кінець файлу. Ще один аргумент, OutputVerboseLevel, визначає рівень подробиці звіту, що зберігається у файл. Якщо рівень подробиці – 0, записуються тільки повідомлення про помилки. Якщо рівень подробиці – 1, будуть записані всі повідомлення про результати роботи. Якщо рівень подробиці – 2 (значення за замовчуванням), будуть записані всі повідомлення про помилки та про результати роботи, які дуже корисні для налагодження.

Встановлювати рівень подробиці хронології роботи агентів реплікації більше нульового стоїть в тих випадках, коли проводиться тестування реплікації, на час періодичного контролю роботи агентів або з метою налагодження і вирішення проблем. Відмова від ведення хронології сеансів реплікації може дати приріст продуктивності сеансу реплікації до 15%.

Останній профіль досить рідко застосовується на практиці і призначений для тих випадків, коли реплікація використовує службу Windows Synchronization Manager. Слід пам'ятати, що коли агент розповсюджувача застосовує моментальний знімок на передплатника, він блокує вхідні в підписку таблиці бази даних абонентів. Крім того, агент розповсюджувача блокує ці таблиці на час застосування блоку команд, обрамлених транзакцією.

Під час застосування агентом розповсюджувача моментального знімка на передплатника можна задіяти засоби підвищення продуктивності масових операцій, які застосовуються в програмі BCP. Використання при запуску агента розповсюджувача аргументу UseInprocLoader підвищує ефективність використання моментального знімка, наказуючи агенту розповсюджувача при застосуванні файлів знімка на передплатника використовувати команду BULK INSERT. У результаті, продуктивність застосування знімка може отримати приріст до 30% (якщо немає проблем з установками порядку сортування (collation)). Також до 30% підвищення в продуктивності може бути досягнуто при застосуванні аргументу MaxBcpThreads. Цей аргумент визначає число потоків операцій масового копіювання, які можуть бути виконані паралельно. Його сенс точно такий, як і в однойменного аргументу агента моментальних знімків. Спільне застосування аргументів UseInprocLoader і MaxBcpThreads може дати до 50% виграшу в продуктивності.

Ще одним корисним аргументом для підвищення продуктивності агента розповсюджувача є аргумет Buffers. Він задає число буферів, доступних для асинхронних транзакцій. Значення за замовчуванням дорівнює 2. Збільшення цього числа може сприяти підвищенню ефективності за рахунок скорочення перегортання (memory paging) пам'яті.

Проте велика кількість встановлених буферів збільшує обсяг пам'яті, виділеної для обслуговування перегортання. Оцінити ефективність змін значень цього параметра можна шляхом оцінки часу підключення передплатників до дистриб'ютору при зміні значень параметра. Особливістю цього аргументу є те, що не у всіх версіях SQL Server його можна додати в системні таблиці профілів реплікації. У SQL Server 2000 його можна було додати тільки у вигляді аргументу виклику програми агента, у спеціалізованому кроці завдання за розкладом агента сервера.

Якщо ви оновлюєте будь-якої стовпець таблиці бази даних, яка обслуговується Microsoft SQL Server 2000 Standard і Enterprise Edition, який є частиною унікального або складеного індексу, SQL Server здійснює оновлення як відкладене зміна. Відкладене зміна означає, що команда UPDATE буде передана передплатнику як пара операцій: DELETE і INSERT. Відкладене зміну більш докладно описано в статті бази знань Microsoft: "Q238254 INF: UPDATE Statements May be Replicated as DELETE / INSERT Pairs". Можливі випадки, коли передача передплатникам змін у вигляді пари команд DELETE і INSERT не відповідає вимогам бізнес-правил, які, наприклад, можуть наказувати передачу передплатнику дій тригерів при оновленнях. Саме для того, щоб допомогти правильно вирішити цю ситуацію, був введений прапор трасування № 8207, який з'явився в SQL Server 2000 Service Pack 1, і при використанні якого в реплікації транзакцій допускаються зміни однією командою. Оновлення унікального стовпця, яке зачіпає тільки один рядок (зміна, яке прийнято називати "singleton"), здійснюється як команда UPDATE, а не як пара операцій DELETE і INSERT. Якщо зміни стосуються кілька рядків, зміна буде виконуватися як пара команд DELETE і INSERT. Ви можете задати ключ трасування 8207 на сервері, виконуючому роль видавця, виконуючи команду DBCC TRACEON (8207, -1) при кожному запуску SQL Server, або додавши до параметрів запуску сервера баз даних ключ-T8207. Ключ трасування 8207 використовується тільки у варіанті реплікації транзакцій без оновлюваних передплатників.

При великій кількості абонентів розгляньте можливі заходи для скорочення частоти копіювання змін на розповсюджувача. У таких випадках може виявитися вигідним запускати агента розповсюджувача рідше (в межах, допустимих бізнес-правил), це може істотно скоротити кількість операцій.

Використання підписок типу "pull" або анонімних підписок дозволяє розвантажити видавця та / або розповсюджувача. Аналогічно діє використання опції віддаленого запуску агента (Remote Agent Activation). Анонімні підписки не зберігають інформацію про передплату в базі даних розповсюджувача.

І нарешті, якщо сервер-видавець перевантажений, але не може бути масштабований до необхідного рівня продуктивності, можна перемістити базу даних розповсюджувача на інший, менш завантажений сервер.

Для моніторингу продуктивності роботи агентів розповсюджувача можна використовувати відповідні лічильники продуктивності об'єкта "SQL Server: Replication Dist.", Які показують скільки команд і транзакцій було передано передплатникам з бази даних розповсюджувача зазначеним агентом розповсюджувача. Таких лічильників три. Перший лічильник: "Dist: Delivered Cmds / sec", він показує число зраджувати передплатнику команд в секунду. Другий лічильник: "Dist: Delivered Trans / sec", показує число переданих в секунду транзакцій передплатнику. І третій лічильник: "Dist: Delivery Latency", показує затримку виконання транзакції на передплатника після її відправки з бази даних розповсюджувача в мілісекундах.

Replication Log Reader Agent

Агент читання журналу транзакцій (Replication Log Reader Agent) є найбільш важливим і вразливим елементом топології реплікації транзакцій. У видається бази даних може бути більше одного агента читання журналу. Щоб зрозуміти його роботу, варто коротко описати схему взаємодії компонент SQL Server в реплікації транзакцій. У цьому типі реплікації окремі транзакції, що обрамляють команди INSERT, UPDATE і / або DELETE, передаються від видавця передплатникам. Після запуску програми агент читання журналів зчитує свою конфігурацію із системних таблиць бази даних розповсюджувача, зокрема, там він дізнається, де знаходяться і як називається видавана база даних. Першим кроком при налаштуванні підписки реплікації транзакцій виконують первісну синхронізацію схеми і даних абонентів з видавцем, для чого на передплатника застосовується моментальний знімок публікації з видавця.

Після синхронізації, єдиний для публікації агент читання журналу за встановленим розкладом або безперервно переглядає журнал транзакцій видається бази даних, вибираючи в ньому записи про транзакції, позначених для реплікації. Про всі виявлені транзакціях, які підлягають реплікації, агент читання журналу робить записи у відповідних системних таблицях бази даних розповсюджувача, і заодно зберігає в цій базі даних запису про хронологію своєї роботи. У таблиці бази даних розповсюджувача MSlogreader_history агент читання журналу робить записи про останніх прочитаних в сеансах реплікації номерах віртуальних журналів (LSN). Це необхідно для того, щоб у наступному сеансі реплікації почати читання з цього номера LSN. Саме читання здійснюється за допомогою системної збереженої процедури sp_replcmds, яка буде переглядати всі записи в журналі з зазначеного їй LSN і до кінця журналу, якщо не заданий обмежує розмір читання аргумент ReadBatchSize. Агент читання журналу відбирає тільки ті транзакції, які відзначені для реплікації і якщо вони задовольняють умовам фільтрації статті (коли публікація використовує фільтри). Знайдені записи буферизуются і копіюються пакетами в системну таблицю MSrepl_commands в базу даних розповсюджувача. На цьому етапі агент читання журналу оцінює ефективність складових транзакцію команд і може внести зміни в їх синтаксис, якщо це призведе до підвищення ефективності. Наприклад, команди можуть бути перетворені в реплицируемой виклики процедур із заданими параметрами агентом, або у синтаксис може бути додано використання первинного ключа (присутнього, але не заданого явно), а також у відомих випадках команда UPDATE може бути перетворена в пару команд DELETE і INSERT. Але, незважаючи на всі можливі зміни, є взаємно однозначна відповідність між транзакціями в журналі і записами команд у базі даних розповсюджувача.

Агент розповсюджувача передає передплатникам на виконання все реплицируемой команди, які були виявлені азі

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*