Реплікація злиттям на практиці

1. Створюємо високонадійне і стійке до збоїв рішення, яке легко налаштовувати і підтримувати Я працюю...
2. Віддати чи перевагу реплікації злиттям?
3. Підготовка до реплікації злиттям
4. Розробка реплікації злиттям
5. Налаштування дистрибуції і публікації
6. Підготовка вихідної синхронізації даних (моментального знімка)
7. Налаштування публікацій и создание початкових моментального знімка
8. Створення нового профілю агента злиття і настройка підписки
9. Перевірте реплікацію злиттям перед початком роботи
10. Послідовність дій при налаштуванні публікацій
11. Таблиця 1. Розподіл даних в базі ClientDB
12. Таблиця 2. Змінені значення для екрану деталей профілю агента реплікації
13. Таблиця 3. Значення параметрів профілю агента реплікації

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

Я працюю старшим консультантом в групі 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" на http://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 http://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 http://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 http://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

1,000,000 7 100,000-1,000,000 7 10,000-99,999 32 1000-9999 22 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)