Реплікація злиттям на практиці, Резервне копіювання, Різне, статті

Створюємо високонадійне і стійке до збоїв рішення, яке легко налаштовувати і підтримувати


Я працюю старшим консультантом в групі Financial Services Group підрозділу Microsoft Consulting Services. Моє завдання – допомагати клієнтам, що працюють у фінансовій сфері, ефективно використовувати технології баз даних Microsoft. Нещодавно одному замовнику потрібно високонадійне і відновлюване після збою рішення. Адміністратор баз даних в його компанії не мав практичного досвіду підтримки рішень з високим коефіцієнтом надійності (включаючи реплікацію), тому клієнт хотів отримати рішення, яке буде нескладно налаштовувати і підтримувати. Я розповім про цей випадок і перерахую кроки, виконані мною при розробці рішення, яке не вимагає глибоких знань в області написання сценаріїв. Якщо потрібна проста у використанні рішення з хорошою продуктивністю і можливістю відновлення після збою, вивчіть цей приклад. Можливо, він допоможе зрозуміти, чи є реплікація злиттям правильним вибором в тій чи іншій ситуації.


Вимоги замовника


У користувача, з яким я працював, було два процесингових центру, віддалених один від одного на велику відстань і пов’язаних каналом T2. Замовнику потрібно було гнучке високопродуктивне рішення, яке дозволило б у майбутньому з мінімальними зусиллями додати третій сайт. Кожен наявний сайт грав роль ведучого вузла бази даних SQL Server 2000 на сервері Windows 2000. Обидва сервера Windows мали два процесори і 2 Гбайт оперативної пам’яті. База даних замовника мала обсяг близько 25 Гбайт і росла повільно (від 200 Мбайт до 500 Мбайт в місяць). Завантаження бази даних була відносно низькою (від 10 до 50 транзакцій на хвилину). Додаток замовника знаходилося в роботі в основному з 7 до 9 години вечора, 5 днів на тиждень, і база даних повинна була бути доступною на обох сайтах у робочий час.


Замовнику хотілося виконувати обробку даних на одному сайті і отримувати звіти на іншому. У випадку аварії на одному обчислювальному центрі він хотів мати систему, перехоплюють управління, так, щоб залишився обчислювальний центр міг швидко поєднати всі функції без будь-якої перебудови структури. Замовник планував розділення операцій завантаження даних між центрами, але усвідомлював, що оператори даних можуть змінити або видалити разом одну і ту ж запис на обох сайтах. Для усунення цих можливих конфліктів між двома сайтами клієнт хотів поєднати зміни, зроблені користувачами на різних сайтах в різних стовпцях, якщо це можливо. Наприклад, якщо користувач на сайті А змінює стовпець 1 і користувач на сайті В змінює стовпець 2, потрібно об’єднати обидва зміни в результуючій таблиці. Багато таблиці мають одну або більше текстових полів. Деякі таблиці мають поля IDENTITY.


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


Віддати чи перевагу реплікації злиттям?


SQL Server пропонує кілька додаткових програмних засобів, які підтримують стан бази даних близько до реального часу, включаючи двофазну фіксацію, транзакционную реплікацію при безперервному потоці передплатників на зміну, реплікацію моментального знімка з негайною обробкою передплатників, транзакционную реплікацію (включаючи двосторонню реплікацію), реплікацію моментального знімка, транзакционную реплікацію з почергової обробкою передплатників, і реплікацію злиттям. Виходячи з вимог замовника, я запропонував застосувати реплікацію злиттям SQL Server 2000 з кількох причин. По-перше, злиття дублюючих один одного записів має надійний, вбудований алгоритм вирішення конфліктів, який може бути легко налаштований за допомогою Enterprise Manager. У простих випадках написання сценаріїв не потрібно. Реплікація злиттям забезпечує позаблоковий алгоритм вирішення конфліктів на рівні стовпця і високу транзакционную сумісність операцій в ситуаціях на кшталт тієї, яку описав мій замовник, коли конфлікти трапляються рідко і в обробку даних включені тільки два сайти. До того ж реплікація злиттям дозволяє дублювати текстові дані. Це мало значення для клієнта, тому що в його компанії використовувалося 10 таблиць баз даних, що містять текстові стовпці. Реплікація злиттям включає в себе безперервно виконуються агенти Merge Agents, які забезпечують передачу даних з допустимою затримкою. Також реплікація злиттям легко виконує приєднання іншого сервера до існуючої топологічної схемою.


Альтернативні підходи можуть мати свої переваги, але я не рекомендую використовувати пряму обробку даних і почергову коригування підписок, так як ці варіанти не обробляють текстові дані. Не всі типи транзакционной реплікації можуть об’єднувати одночасні зміни в різних полях на різних сайтах. Миттєва реплікація і DTS просто не здатні працювати в ситуації, коли зміни даних відбуваються на обох сторонах одночасно. І двофазна фіксація – це дуже ненадійне рішення, тому що навіть короткочасна втрата з’єднання між вузлами мережі під час транзакції обов’язково призведе до збою додатка. Вирішивши, що реалізація схеми досить надійна, я приготував базу даних для реплікації злиттям.


Підготовка до реплікації злиттям


Перед налаштуванням реплікації злиттям потрібно спочатку уважно переглянути основні компоненти програми і сформувати спеціальні технічні вимоги для реплікації злиттям. Так як в одній невеликій статті неможливо розповісти про всі деталі планування і підготовки, для їхнього вивчення я рекомендую почитати секцію в SQL Server 2000 Books Online (далі BOL) під назвою “Planning for Merge Replication”. Тут наведено ряд прийомів, які я повинен був застосувати для вирішення проблем мого замовника.


Реплікація злиттям дублює текстові поля, тільки якщо вони були явно оброблені за допомогою пропозиції UPDATE, яке змусило тригер спрацювати і оновити метадані, гарантуючи, що транзакція передана передплатникам. Операції WRITETEXT і UPDATETEXT не передають зміни іншим сайтам. Для вирішення цієї проблеми я модифікував кілька збережених процедур, додавши пусте пропозицію UPDATE після операцій WRITETEXT або UPDATETEXT всередині тієї ж транзакції. У BOL є приклад розробки цього типу модифікації.


Щоб уникнути повторюваних конфліктів під час реплікації злиттям, я налаштував всі конструкції зовнішнього ключа і тригери користувача за допомогою установки NOT FOR REPLICATION. Щоб виконати цю настройку, потрібно вибрати таблицю з Enterprise Manager, клацнути правою кнопкою миші і вибрати Design Table. Натисніть Manage Relationships, потім встановіть в початковий стан Enforce relationship for replication у таблиці Relationships вікна Properties, як показано на Малюнку 1, повторіть цей крок для кожного зовнішнього ключа в “спадному” списку. Далі натисніть Close, потім Save. Клацніть Yes, коли з’явиться вікно підтвердження. Закрийте вікно Design Table і повторіть ці кроки для всіх таблиць, що містять зовнішні ключі.


Щоб змінити установку NOT FOR REPLICATION для наявного тригера, слід вибрати таблицю в Enterprise Manager. Клацніть правою кнопкою миші, виберіть All Tasks, потім виберіть вкладку Manage Triggers. З контекстного меню виберіть визначений користувачем тригер. Як показано на рисунку 2, наберіть NOT FOR REPLICATION в рядку, що передує AS в текстовому вікні. Натисніть Apply, потім повторіть ці кроки для інших тригерів в тій же таблиці. На закінчення натисніть OK. Потім поміняйте варіант NOT FOR REPLICATION для всіх таблиць, які мають тригери.


Поля All IDENTITY повинні мати установку NOT FOR REPLICATION (цей варіант налаштовується автоматично при установці реплікації злиттям). Значення IDENTITY потрібно розділити відповідно до місцезнаходженням. При налаштуванні реплікації злиттям для гарантії того, що значення ідентифікації задаються в межах значень, передбачених для діапазону вузла, SQL Server автоматично створює обмежує умова CHECK в кожній таблиці, яка містить поле IDENTITY. При роботі над вирішенням клієнта я ретельно планував амплітуду значень стовпця для кожної порушеної таблиці. Я рекомендую встановити великий діапазон значень для вузла, так щоб неможливо було досягти межі. Через деякі проблеми з його функціональністю не варто покладатися на діапазон автоматичної ідентифікації, обробляючи рядок за допомогою SQL Server. Роз’яснити ці труднощі з ідентифікацією рядка допоможе стаття Microsoft “BUG: Identity Range Not Adjusted on Publisher When Merge Agent Runs Continuously” на support.microsoft.com/?id=304706.


Я вирішив використати алгоритм вирішення конфлікту за замовчуванням. Це найпростіший варіант в подібному випадку, з двома серверами і рідкісними конфліктами. Вибір варіанту за замовчуванням був відповідним. Виконання механізмів вирішення конфліктів у системі, що залежать від часу та дати, зажадає модифікацій в табличній структурі багатьох таблиць. В основному SQL Server дозволяє вибрати з декількох запропонованих типів механізмів вирішення конфліктів у системі. Або можна написати свій механізм вирішення конфліктів. У більшості випадків, я впевнений, читачі будуть задоволені кількома типами запропонованого механізму вирішення конфліктів у системі.


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


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


Розробка реплікації злиттям


На рисунку 3 показана схема реплікації злиттям для мого замовника. Я вибрав SQLServer1 на Site 1 як видавця і дистриб’ютора. А SQLServer2 на Site2 я визначив як передплатника. ClientDB – це база даних, яка повинна бути тиражувана. Агенти по знімках і злиття виконують реплікацію злиттям. Агент знімків готує файли-копії знімків, які містять схему і дані опублікованих таблиць, зберігає файли в папці моментальної копії, а потім вносить завдання щодо синхронізації в базу публікацій. Агент знімку також створює спеціальні процедури, що зберігаються, тригери та системні таблиці. Агент злиття об’єднує зміни даних у вигляді збільшень, які відбуваються у видавця або підписувача після розробки початкового моментального знімка, і це дозволяє залагоджувати конфлікти згідно з установленими правилами.


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


Налаштування дистрибуції та публікації


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


Найлегше встановити дистриб’ютора і налаштовувати видавця, використовуючи Enterprise Manager. Обидва сервера (видавець і передплатник) повинні бути зареєстровані в Enterprise Manager. У лівому вікні Enterprise Manager клацніть Databases для сервера, який треба налаштовувати як дистриб’ютора (SQLServer1 в цьому випадку). На панелі інструментів клацніть Tools, виберіть Replication, потім виберіть Малюнок Publishing, Subscribers , Distribution. Якщо реплікація ще не налаштована, з’являється Replication Wizard. Натисніть Next, після чого з’являється вікно Select Distributor. Якщо реплікація вже налаштована, з’явиться вікно Publisher and Distributor Properties. Виберіть Make SQLServer1 its own Distributor для створення власного дистриб’ютора, потім клацніть Next.


Якщо є підозра, що SQL Server Agent не виконується, виберіть Yes, Малюнок SQL Server Agent to start automatically, потім натисніть Next. Якщо SQL Server Agent працює, пропустіть цей крок налаштування. У діалоговому вікні Specify Snapshot Folder підтвердіть вибір за замовчуванням (або виберіть свій варіант) для папки моментального знімка і клацніть Next. Якщо з’являється повідомлення і потрібно підтвердити вибір папки, зробіть це.


Потім у вікні Customize the Configuration (для настройки конфігурації) виберіть Yes, let me для настройки властивостей бази даних розподілу, потім клацніть Next. Вкажіть місце для даних і системного журналу для бази даних розподілу. Потім натисніть Next. Якщо є можливість, використовуйте різні накопичувачі для даних і системних журналів. Я рекомендую для бази даних розподілу зберегти ім’я за замовчуванням.


У вікні Enable Publishers виберіть лише необхідний сервер (SQLServer1). Закрийте вікно повідомлення, якщо воно з’являється. Якщо з’явиться вікно Publisher Properties, залиште типове встановлення (використовувати наявне з’єднання) і очистіть варіант, що вимагає пароль для з’єднання видавця з дистриб’ютором. Натисніть OK для виходу з вікна і поверніться у вікно Enable Publishers. Якщо повідомлення з’являється, клацніть Yes для підтвердження та натисніть Next.


У вікні Enable Publication Databases виберіть Merge для бази даних (ClientDB в цьому випадку), потім клацніть Next. У вікні Enable Subscribers виберіть базу даних (SQLServer2 в цьому випадку), клацніть Next, натисніть Finish. Закрийте вікно, яке описує функціональність Replication Monitor.


Підготовка вихідної синхронізації даних (моментального знімка)


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


Реплікація злиттям додає поле унікального ідентифікатора з властивістю ROWGUIDCOL і значенням за замовчуванням newid () до кожної опублікованої таблиці і створює індекс по полю. Для великих таблиць процес може бути тривалим. Швидше додати нові поля до вже виданим великим таблиць, а потім виконати початковий знімок для публікації з порушеними таблицями (докладніше про це читайте в статті Microsoft “HOW TO: Manually Synchronize Replication Subscriptions by Using Backup or Restore” at support.microsoft.com/kb/320499/en-us).


У моєму випадку дані в базі даних ClientDB були непропорційно розміщені між майже 200 таблицями, які потрібно було тиражувати. Велика частина (85 відсотків) простору бази даних була сконцентрована у таблиці BatchTrans, в якій було понад 53 мільйонів записів. Наступна найбільша таблиця містила близько 5 мільйонів рядків.


В Таблиці 1 показано, як дані розподілені між таблицями в ClientDB. Для мого замовника я написав пакет DTS, за допомогою якого підготував структурні зміни в семи найбільших таблицях ClientDB (кожна з числом рядків більше мільйона). Я запустив цей пакет тільки один раз. Навіть якщо нові початкові знімки будуть потрібні пізніше, виконання модуля DTS необхідно, так як таблиці вже мають необхідні стовпці з унікальним ім’ям.


Налаштування публікацій і створення початкового знімка


Після настройки сервера-дистриб’ютора і видавця прийшов час створити початковий моментальний знімок. Щоб підвищити продуктивність агента знімків при роботі з великими публікаціями (або публікаціями, мають великі таблиці), я рекомендую створити новий профіль для цього агента і використовувати його замість профілю за замовчуванням. На малюнку 4 показаний процес створення нового профілю агента знімків.


У Enterprise Manger виберіть Replication на сервері видавця (дистриб’ютора), потім клацніть правою кнопкою миші і виберіть Малюнок Publishing, Subscribers, Distribution. На таблиці Distributor натисніть Agent Profiles, виберіть таблицю Snapshot. У вікні Replication Agent Profile Details введіть значення, які показані в Таблиці 2 (Налаштуйте ці значення для наявних умов, як я зробив тут, я перевірив ці зміни в середовищі розробки замовника і вибрав комбінацію, яка дала мені оптимальний час). Коли значення за потрібне чином змінені, натисніть OK. Потім у вікні Agent Profiles виберіть профіль Snapshot_Speed ​​і зробіть його профілем за замовчуванням, вибираючи Change all existing Snapshot Agents для вказівки варіанта вибраного профілю. Натисніть OK два рази, щоб закінчити настройку.


З цього місця я був готовий налаштовувати публікації. Я вирішив створити 12 публікацій: 4 різні публікації, в яких зібрані групи споріднених таблиць і 8 інших, в яких зібрані незв’язані таблиці, засновані на бізнес-функції, частоті змін, розмір та інших факторах. Використовуючи декілька публікацій, можна налаштовувати кожен агент злиття для самостійного виконання, за його власним планом, використовуючи різні підпроцеси, що прискорюють процес дублювання. Якщо потрібно врівноважити число агентів, що працюють за допомогою доступних засобів, прочитайте врізку “Кроки по налаштуванню публікацій”, Де представлений процес налаштовувати кожну створеної публікації.


Після створення моментальних знімків для всіх публікацій я зробив резервну копію бази даних ClientDB на сервері-видавця, потім копіював резервні файли на сервер-абонентів і відновив там базу даних.


Створення нового профілю агента злиття та налаштування підписки


Для збільшення продуктивності агента злиття та мінімізації ефекту, коли SQL Server обробляє запису нащадка і батька, я вирішив створити новий профіль для агента злиття (про можливі проблеми розказано у статті компанії Microsoft “PRB: Non-Convergence When SQL Server Processes Child and Parent Generations in Separate Generation Batches” at support.microsoft.com/default.aspx?scid=kb;en-us;308266). Для створення нового профілю агента злиття почніть з Enterprise Manager і виберіть вузол Replication на сервері-дистриб’ютора. Потім клацніть правою кнопкою миші і виберіть ConРісунок Publishing, потім Subscribers, потім Distribution. На закладці Distributor клацніть Agent Profiles, і на таблиці Merge натисніть New Profile.


Як показано на рисунку 5, введіть значення у вікні Replication Agent Profile Details, які показані в Таблиці 3, Потім натисніть OK і підтвердіть зміни, якщо з’являється повідомлення. У вікні Agent Profiles виберіть профіль Merge_Speed ​​і зробіть його профілем за замовчуванням, вибираючи Change all existing Snapshot Agents to use the selected profile для всіх існуючих агентів моментального знімка, для виконання цього профілю. Натисніть OK два рази для завершення налаштування.


Потім я налаштував передплатників на електронні публікації. Зайдіть в Enterprise Manager, виберіть вузол Replication сервера-користувача, виберіть Publications, клацніть правою кнопкою миші на публікації та виберіть Push New Subscription. Клацніть Next, і в секції Enabled Subscribers вікна Choose Subscribers виберіть сервер-користувача (SQLServer2 в даному випадку) і клацніть Next. У вікні Set Merge Agent Schedule виберіть Continuously (важливо відзначити, що це не варіант за замовчуванням) і натисніть Next.


Коли з’явиться вікно Initialize Subscription, для завдання початкових умов підписки виберіть No, the Subscriber already has the schema and data (знову це не варіант за замовчуванням) і клацніть Next. Не потрібно вибирати цей варіант, тому що копія бази даних на цільовому сервері вже відновлена. На екрані Set Subscription Priority для встановлення пріоритету абонентів виберіть Use the Publisher as a proxy, натисніть Next. Після цього у вікні Start Required Services прийміть всі установки та натисніть Next. Клацніть Finish, щоб закрити вікно майстра, потім натисніть Close. У правій панелі Enterprise Manager ви побачите новий рядок з заново налаштованими даними передплати. Повторіть ці кроки для всіх публікацій.


Перевірте реплікацію злиттям перед початком роботи


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


Для баз даних малого та середнього розміру, які мають рівномірний розподіл і не дуже великий робочий об’єм (як я описав раніше), реплікація злиттям буде працювати добре. Дані користувача, журнал реєстрації, файли TempDB і Distribution повинні бути розміщені на різних накопичувачах. За додатковим поясненням зверніться до статті компанії Microsoft “SQL Server 2000 Merge Replication Performance Tuning and Optimization” at www.microsoft.com/technet/prodtechnol/sql/2000/maintain/mergperf.mspx.


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



Послідовність дій при налаштуванні публікацій


Для налаштування кожній публікації почніть з Enterprise Manager на сервері-видавця (у цьому випадку SQLServer1) і виконайте наступні кроки:



  1. Виберіть Replication, Publications. Клацніть правою кнопкою миші і виберіть New Publication.
  2. З’являється майстер Create Publication. Натисніть Next.
  3. У вікні Choose Publication Database виберіть базу даних (ClientDB в цьому випадку), потім натисніть Next
  4. Якщо з’являється вікно Use Publication Template, виберіть No, I will define the articles and properties, потім натисніть Next. У вікні Select Publication Type виберіть Merge publication, натисніть Next
  5. У вікні Specify Subscriber Types виберіть лише Servers running SQL Server 2000, натисніть Next.
  6. У вікні Specify Articles переконайтеся, що у стовпці Show на лівій панелі обраний тільки варіант Tables і перевірте, чи вибраний варіант Show unpublished objects.
  7. На правій панелі виберіть таблиці, які потрібно дублювати.
  8. Якщо таблиця містить поле IDENTITY, як показано на Малюнку А, натисніть (…) поруч із полем і вкажіть закладку Identity Range. Потім виберіть Automatically assign and maintain a unique identity range for each subscription .
  9. Введіть досить великі значення в текстові вікна Range Size at Publisher і Range Size at Subscriber. Наприклад, на основі передбачуваного збільшення кількості даних таблиці, яка містить близько 1,500,000 мільйонів рядків я ввів тут 10,000,000.
  10. У текстовому вікні Assign a new range when the percentage of values ​​is used надрукуйте 99, потім натисніть OK.
  11. Після того як вибрані всі статті та модифіковані всі властивості, натисніть Next.
  12. Якщо з’являється вікно Article Issues, переконайтеся в тому, що отриманий тільки один результат, uniqueidentifier columns will be added to tables. Якщо результат пов’язаний з полем IDENTITY однієї або більшої кількості таблиць, поверніться в попереднє вікно і внесіть зміни до властивості статті, як було описано вище. Якщо в таблиці тільки один результат, перегляньте опис у вікні Article Issues, потім натисніть Next.
  13. У вікні Select Publication Name and Description надрукуйте назву публікації. Після цього змінити присвоєне назву публікації вже буде не можна. Введіть зрозумілий опис публікації, потім натисніть Next
  14. У вікні Customize the Properties of the Publication, виберіть Yes, I will define data filters, натисніть Next
  15. У вікні Filter Data (нічого не вибираючи) клацніть Next. Тут можна ввести критерій для фільтрації рядків.
  16. У вікні Allow Anonymous Subscriptions виберіть No, allow only named subscriptions, потім натисніть Next.
  17. У вікні Set Snapshot Agent Schedule прийміть варіанти за замовчуванням. Переконайтеся в тому, що обраний варіант Create the first snapshot immediately, потім натисніть Next. Або можна призначити виконання агента знімків в більш зручне пізній час.
  18. У вікні Completing the Create Publication, натисніть Finish і закрийте ті повідомлення, які з’являються.
  19. У правій панелі Enterprise Manager стежите за розвитком Replication Monitor, Agents і Snapshot Agents в процесі генерації моментального знімка.
  20. Повторіть кроки 1-20 для усіх публікацій.



Таблиця 1. Розподіл даних в базі ClientDB






















Число рядків  Число таблиць в ClientDB 
> 1,000,000 7
100,000-1,000,000 7
10,000-99,999 32
1000-9999 22
< 1000 130

Таблиця 2. Змінені значення для екрану деталей профілю агента реплікації






















Параметр  Змінена значення 
Ім’я Snapshot_Speed
Опис Підвищені BcpBatchSize, MaxBcpThreads, QueryTimeout
BcpBatchSize 200,000 (від 100,000)
MaxBcpThreads 20 (від 1)
QueryTimeout 5000 (від 300)

Таблиця 3. Значення параметрів профілю агента реплікації

























Параметр  Пропоноване значення 
Ім’я Merge_Speed ​​(або інше зрозуміле ім’я)
Опис Підвищені UploadGenerationPerBatch, QueryTimeout, DownloadGenerationsPerBatch, зменшені PollingInterval
UploadGenerationPerBatch 1000 (від 100)
DownloadGenerationsPerBatch 1000 (від 100)
QueryTimeout 3000 (від 300)
PollingInterval 10 (від 60)

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


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

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

Ваш отзыв

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

*

*