Реплікація програмованих об'єктів БД в SQL Server 2005

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

Налаштування реплікації програмованих об'єктів.

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


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



Рис.1.

Щоб вибрати опції для кожної додається в публікацію статей, потрібно натиснути кнопку Article Properties. Можна вибрати кілька опцій для кожного типу реплицируемой програмованих об'єктів. Також можна реплікувати схему уявлень, індексованих уявлень і призначених для користувача функцій. Для збережених процедур передбачена додаткова гнучкість – крім їхнього визначення ви можете реплікувати і їх виконання. У таблицю нижче зведені опції, доступні для настройки при реплікації програмованих об'єктів.


Запам'ятайте: Деякі опції для статті не можна змінити після створення публікації. Наприклад, опція Procedure Replicate не може бути змінена на Stored Procedure Definition, змінити її можна тільки на Execution Of The Stored Procedure. Щоб змінити цю опцію, можна видалити статтю і додати її заново, а потім вже змінити опцію. Так що перед налаштуванням реплікації, визначте заздалегідь які опції вам потрібно буде встановити.

Як тільки Ви встановили властивості для кожної статті, можна створити знімок для публікації негайно і / або створити розклад для запуску Snapshot Agent. Наступним кроком необхідно визначити параметри налаштування безпеки для Snapshot Agent і Log Reader agent, проаналізуйте те, що повинен зробити майстер, і натисніть кнопку Finish, щоб створити публікацію.

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

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



Рис.2.

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

Наступний сценарій створює публікацію, в яку входять збережена процедура, подання, индексированное уявлення і призначена для користувача функція:

Зміна схеми реплікації

Згадайте, у попередній версії SQL Server для того, щоб визначення програмованих об'єктів передалися передплатнику, потрібно було запустити агента створення знімка. У SQL Server 2005 це вже не так: реплікація передає оператори ALTER VIEW, ALTER FUNCTION, ALTER PROCEDURE і ALTER TRIGGER передплатнику в реальному часі. Опція реплікації тригерів вже не є єдиною можливістю для статей відповідних типів, але вона як і раніше дозволяє копіювати тригери, визначені на таблиці або поданні в опублікованій базі даних. Запам'ятайте, що не можна реплікувати DDL тригери (тригери мови визначення даних).

Давайте розглянемо реплікацію зміни індексуємого подання. Я створив дуже простий приклад індексуємого подання на видавця за допомогою наступних команд:


Це уявлення повертає декілька стовпців таблиці DimCustomer для записів клієнтів, які народилися після 1 січня 1980 року. Я додав це подання в публікацію реплікації транзакцій і створив для неї підписку на іншому сервері.

Тепер давайте змінимо уявлення, щоб воно повертало клієнтів, які народилися після 1 січня 1978 року. Для цього я виконав наступний код:


Тепер, якщо я в контексті бази даних розповсюджувача виконую системну збережену процедуру sp_browserplcmds, я знайду там команду ALTER VIEW, яка призначена для передачі передплатнику.

Реплікація програмованих модулів особливо корисна, якщо Ви працюєте в мультисерверної середовищі і розподіляєте прикладну навантаження на кілька серверів з ідентичними уявленнями, призначеними для користувача функціями і збереженими процедурами. Замість того, щоб застосувати зміни схеми на кількох серверах, можна просто виконати ці зміни на одному сервері-видавця, після чого ці зміни будуть розтиражовані для всіх абонентів. У попередніх версіях SQL Server потрібно було запустити Snapshot агента, який би створив моментальний знімок, за допомогою якого зміни схеми доставляються передплатникам. У версії SQL Server 2005 зміни схеми будуть доставлятися також як зміни даних. Це дозволяє значно спростити і прискорити завдання розгортання додатків.

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



Рис.3.

Реплікація індексованих уявлень як таблиць

Реплікація індексованих уявлень здійснюється також як реплікація таблиць; в цьому випадку, SQL Server створює таблицю на передплатника, яка містить ті ж дані, що і индексированное уявлення на видавця. Дані змінюються в індексованих подання на видавця і передаються до таблиці на передплатника. Зверніть увагу, що таблиця, на якій засновано индексированное подання, не зобов'язана існувати на передплатника.

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

Для того щоб виконувати реплікацію індексованого уявлення як таблиці, потрібно змінити параметр @ type системної процедури sp_addarticle. За умовчанням цей параметр встановлений в значення N "indexed view logbased ". Наприклад, наступний код додасть индексированное подання View_DimCustomer_Young в існуючу публікацію як таблицю.


Після налаштування реплікації індексованого уявлення як таблиці, оператори INSERT, UPDATE і DELETE, виконані на подання на видавця, будуть реплікувати до таблиці на передплатника.

Реплікація виконання збережених процедур

Таким же чином можна налаштувати реплікацію виконання збережених процедур, що дуже корисно при великих змінах у наявних даних, і за умови, що дані на передплатника і видавця ідентичні. Що станеться, якщо виконання оператора UPDATE зачіпає 1000 рядків реплицируемой таблиці? За замовчуванням SQL Server трансформує одну команду UPDATE у виконання збереженої процедури реплікації 1000 разів. Цей варіант хороший тим що кожне виконання збереженої процедури реплікації зачіпає тільки один рядок що не викликає велику кількість блокувань / підтверджень на передплатника.

Але що станеться, якщо ваша збережена процедура виконує зміни, що зачіпають мільйон рядків у кількох таблицях? Ваша база даних розподілу буде рости експоненціально, і час затримки реплікації може бути неприпустимо великим. Перед тим як передати ці команди передплатнику SQL Server повинен прочитати їх з таблиці msrepl_commands бази даних розподілу; Агент – чистильник розподільника займається видаленням транзакції для цих таблиць, коли вони вже були передані передплатнику. Якщо таблиця msrepl_commands містить кілька мільйонів рядків, читання та видалення даних з цієї таблиці буде виконуватися дуже повільно. Крім того, передача великих змін при використанні табличній статті, надає велике навантаження на мережу.

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

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

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

Наприклад, припустимо що у нас є збережена процедура, яка змінює деяку кількість рядків у таблиці factFinance бази даних AdventureWorksDW:


Створимо публікацію на основі реплікації виконання збереженої процедури. Кожен раз, коли ми виконуємо процедуру на видавця, агент розподілу буде передавати передплатнику команду, подібну до цієї:


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

Реплікація виконання збережених процедур усередині серіалізуємих транзакції.

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


Якщо хоча б одна умова не буде виконана, виконання збереженої процедури не реплікується. Крім цих обов'язкових умов, також необхідно використовувати опцію SET XACT_ABORT ON. Використання цієї опції гарантує, що зміни, внесені транзакцією, всередині якої виконується збережена процедура, будуть автоматично скасовані, якщо виникнуть помилки часу виконання.

Реплікація виконання збережених процедур усередині серіалізуємих транзакції – це рекомендована опція, коли необхідно підтримати цілісність даних на видавця і передплатника. Чому? У кожній збереженій процедурі міститься кілька явних або неявних транзакцій. Ви можете зіткнутися з ситуацією коли деякі транзакції усередині збереженої процедури завершуються успішно, а інші з помилкою. Якщо Ви змушуєте SQL Server реплікувати кожне виконання збереженої процедури, тоді навіть те виконання, в якому транзакції завершуються помилками, буде відправлено передплатнику. Рівень ізоляції транзакцій – SERIALIZABLE, є найжорсткішим рівнем ізоляції, що гарантує, що блокування будуть встановлені на всіх таблицях, які використовує збережена процедура. Блокування будуть утримуватися до тих пір, поки транзакція не буде завершена. Тому, використання в реплікації виконання тільки в межах серіалізуємих транзакції, дає гарантію того, що процедура успішно завершить роботу на видавця, і лише потім буде послана передплатникам.

Давайте скористаємося процедурою update_factFinance щоб продемонструвати як ми можемо реплікувати її виконання всередині серіалізуємих транзакції. Виконаємо наступний код:


Однак, наступна команда не буде реплікувати, тому що вона не включена в явну транзакцію:


Тепер ми завершимо виконання процедури, щоб продемонструвати значення установки XACT_ABORT. Я змінюю тип даних стовпця amount таблиці factFinance на SMALLINT, замість INT, виконуючи таку інструкцію:

Максимальне значення для типу SMALLINT – 32768; множимо максимальне значення стовпця на 1.15 щоб результат перевищив 32768, таким чином, наступне виконання процедури update_factFinance, призведе до помилки:

Результат такий:

Транзакція скасована, і виконання збереженої процедури не передано передплатнику.

Далі, виконаємо той же набір команд, скасувавши установку XACT_ABORT:

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

Виконання процедури передано передплатнику навіть за умови того, що на видавця воно завершилося з помилкою. Це призведе до того, що агент розподілу завершить роботу з помилкою. І що ще більш важливо, може порушити цілісність даних на передплатника і видавця. Тому завжди використовуйте опцію SET XACT_ABORT ON при реплікації виконання збережених процедур.

Висновок

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

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

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


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

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

Ваш отзыв

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

*

*