Фільтрація реплицируемой даних, MS SQL Server, Бази даних, статті

Введення
Фільтри рядків
Фільтри стовпців
Динамічні фільтри
Динамічні знімки
Деякі міркування з приводу Dynamic Snapshot
Створення і застосування динамічних знімків вручну
Звірка інформації на передплатника
Join фільтри
Зумовлені користувачем функції і статичні фільтри
Зумовлені користувачем функції і динамічні фільтри

Введення

Горизонтальні, вертикальні, динамічні та join фільтри дають можливість створити розділи даних, які потім будуть видані. Фільтруючи призначені для видання дані, Ви можете:
– Скоротити кількість даних, переданих по мережі.
– Зменшити розмір баз даних на передплатників (subscriber).
– Налаштувати публікацію і прикладні програми під індивідуальні вимоги передплатника.
– Виключити або зменшити конфлікти, за рахунок того, що різні розділи даних можуть бути реплицирована різним передплатникам (різні передплатники не будуть модифіковані одні й ті ж дані).

Фільтрація рядків і стовпців може застосовуватися для моментальних знімків, транзакційної і merge (Об’єднання) публікацій. Фільтрація рядків використовує пропозицію WHERE в SQL інструкції та обмежує рядки, включені в публікацію, засновану на заданих критеріях. Фільтрація стовпців обмежує стовпці, які включаються в публікацію.
Динамічні та join фільтри розширюють можливості Merge реплікації. Динамічні фільтри – це рядкові фільтри, які використовують функцію для відбору значень на передплатника і реплікації фільтрованих даних, заснованих на цьому значенні. Фільтр для публікації визначається один раз, але результуючий набір може відрізнятися на різних передплатників, що дозволяє на передплатника отримувати тільки те підмножина даних, яке необхідно користувачам цього передплатника. Join фільтри розширюють можливості фільтрації рядків однієї видається таблиці в іншу. Join фільтр визначає відносини між двома таблицями, які будуть запропоновані протягом процесу об’єднання; це схоже на об’єднання (Join) двох таблиць.

Фільтри рядків

Використання фільтрів рядків дозволяє визначити підмножина рядків таблиці для видання на сервери передплатники. Фільтри рядків використовуються в тих випадках, коли тільки певні рядки повинні бути реплицирована передплатникам, при цьому, виключаються рядки, які користувачі не повинні бачити (Наприклад, рядки, які містять конфіденційну інформацію), або коли створюються розділи даних, які реплікуються різним передплатникам. Такі фільтри допомагають запобігти конфлікти, які могли виникнути при одночасній спробі на декількох передплатників модифікації одних і тих же даних.
Фільтри рядків зручні тому, що вони можуть застосовуватися з уже існуючим прикладним програмним забезпеченням, коли присутня визначає атрибут, за яким можна фільтрувати рядки видається таблиці, або однієї з пов’язаних з нею таблиць.
Фільтри рядків застосовні для моментальних знімків, реплікації транзакцій і Merge реплікації. Фільтри рядків в транзакційної публікації можуть істотно вплинути на ефективність, тому що умова фільтрації статті буде застосовуватися для кожної реєстраційної записи в журналі транзакцій, відноситься до видаваної таблиці. Це необхідно, щоб визначити, чи повинна вона бути зазначеної для реплікації. Фільтри рядків в транзакційної публікації бажано уникати в тих випадках, коли допустима повне завантаження даних, і цей повний набір даних не великий, я кількість вставок, оновлень і вилучень не велике.
Фільтри рядків для реплікації моментальних знімків (snapshot) і реплікації транзакцій є статичними і використовують критерій пропозиції WHERE, який можна задати за допомогою Create publication Wizard або за допомогою діалогового вікна властивостей публікації. Якщо є два передплатника, які повинні отримувати різні рядки даних з видаваної таблиці, потрібно створити дві публікації, кожна з яких матиме свій фільтр рядків. Це дозволить відправляти необхідні рядки кожному передплатнику.
Хоча можна використовувати у фільтрі рядків підзапит, це не буде join фільтр. Якщо рядок в таблиці модифікується підзапитом, запит не буде врахований, і рядок не буде врахована як частина реплікації. Реплікація з Join фільтром застосовна тільки для Merge реплікації.
В якості альтернативи для створення декількох публікацій можна розглядати використання динамічних фільтрів в Merge реплікації або створення трансформованою передплати (transformable subscription) з визначеним фільтром для реплікації моментального знімка або реплікації транзакцій, яка буде динамічно створювати розділи даних, засновані на інформації, отриманої від різних передплатників.

Фільтри стовпців

Фільтри стовпців обмежують число стовпців, які будуть включені в моментальний знімок, транзакционную або merge публікацію. Фільтри стовпців можуть зменшити час, який потрібно для тиражування змін даних до передплатників, зменшувати розмір бази на передплатника і обмежити дані в публікації тільки тими, що необхідні різним передплатниками. Ви можете використовувати фільтри рядків і стовпців спільно.
Нижче представлені типи стовпців, до яких не можуть бути застосовані вертикальні фільтри для публікації:
– Стовпці з обмеженнями первинного ключа.
– Non-null стовпці без заданого значення за замовчуванням.
– Стовпці, включені в унікальний індекс.
– Стовпець ROWGUID для merge публікації і стовпець ROWGUID для моментального знімка або транзакційної публікації, яким встановлено негайне оновлення передплатника.

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

Динамічні фільтри

Динамічні фільтри дозволяють створювати merge публікацію і потім фільтрувати дані з видаваної таблиці, забезпечуючи різні розділи даних для різних абонентів. Використання динамічних фільтрів в merge публікації доцільно в наступних випадках:
– На видавця створюється менше публікацій. Це спрощує адміністрування публікацій.
– Використання визначених користувачем функцій (user-defined functions – UDF) в динамічному фільтрі дає можливість фільтрувати по критеріям.
– Передплатник отримує тільки ту інформацію, яка необхідна, тому що фільтрація даних базується на властивостях підключення Merge Agent для підписки.

У динамічному фільтрі можна визначити функцію Microsoft SQL Server 2000 або UDF функцію, яка буде по різному оброблятися для кожного передплатника. Найбільш часто використовувані системні функції, які застосовуються для цих цілей – SUSER_SNAME () і HOST_NAME (). Ви можете використовувати UDF в динамічному фільтрі, але якщо UDF включає SUSER_SNAME (), HOST_NAME () або якщо UDF використовує одну з цих системних функцій в умовах фільтра (наприклад, MyUDF (SUSER_SNAME ()), тоді UDF ставати статичною.
Динамічні фільтри – це фільтри рядків (обмежують число рядків даних) і застосовуються лише для однієї таблиці (не можна використовувати перетину або об’єднання з іншими таблицями). Проте, можна використовувати динамічні фільтри і join фільтри в одній публікації і на тих же самих видаваних таблицях.
Динамічні фільтри застосовні тільки з Merge реплікацією. Крім того, при їх використанні, необхідно розглянути також використання динамічних знімків. За замовчуванням, динамічна фільтрація для публікацій грунтується на операціях INSERT на видавця, щоб застосувати дані на передплатника, як частина початкового знімка. При використанні динамічних фільтрів, динамічні знімки використовують усі переваги ефективності програми масового копіювання (bcp), щоб передати дані певного передплатнику при застосуванні початкового знімка.
Якщо Ви використовуєте реплікацію знімків або реплікацію транзакцій, Ви можете створювати зумовлені фільтри, що використовують трансформовану підписку, які будуть фільтрувати дані, грунтуючись на індивідуальних вимогах передплатників.


Динамічні знімки

Динамічні знімки (Dynamic Snapshots) забезпечують хорошу ефективність при застосуванні знімку merge публікації спільно з динамічними фільтрами. Висока ефективність досягається за рахунок використання Microsoft SQL Server 2000 bulk copy, що дозволяє оптом застосовувати дані на subscriber замість послідовного виконання інструкції INSERT. Створення динамічного знімка для передплати дозволяє також забезпечити кращу гнучкість і економічність при передачі знімка на змінних носіях (наприклад, CD-ROM). Таке застосування знімка на передплатника з використанням носія можна виконати швидше, ніж за допомогою застосування первісного моментального знімка, переданого по повільному комунікаційного каналу.
Коли в merge публікації використовуються динамічні фільтри, дані видається таблиці фільтруються на основі властивостей підключення Merge Agent для поточної протягом процесу об’єднання (merge) публікації. За замовчуванням, публікація з динамічним фільтром грунтується на операціях вставки (INSERT) даних від видавця, що дозволяє застосувати дані на передплатника, як частина первісного знімка. Це може стати довгим і ресурсоємним процесом, тому що Merge Agent повинен буде визначити рядок-к-рядку (row-by-row) дані, які потрібно включити в знімок, грунтуючись на динамічних критеріях фільтра. Застосування динамічних знімків забезпечує більш високу ефективність, за рахунок використання механізму SQL bulk copy (bcp) при застосуванні даних на передплатника, тобто за рахунок застосування початкового знімка з використанням динамічних фільтрів. Коли Ви створюєте динамічний знімок, Ви, фактично, генеруєте моментальний знімок, який буде налаштований для заданого передплатника. Оскільки дані будуть вже витягнуто і скопійовані, застосовуватися знімок буде також швидко, як застосовується знімок без динамічних фільтрів. Однак, є й негативні моменти, це додаткові витрати часу та додатковий дисковий простір, які будуть потрібні при створенні і збереженні динамічного знімка. Хоча для створення динамічного знімка потрібно більше часу (по суті, знімок буде генеруватися двічі), процес застосування знімка на передплатників пройде швидше, ніж застосування стандартного знімка для merge публікації з динамічним фільтром. Спочатку буде згенеровано стандартний знімок, а динамічний знімок створюється шляхом фільтрації стандартного знімка.
Динамічні знімки можна створювати за допомогою Enterprise Manager, за допомогою майстрів: Create Publication і Create Dynamic Snapshot Job, за допомогою системних процедур і Transact-SQL скриптів, а також за допомогою Microsoft ActiveX controls або SQL-DMO.

Деякі міркування з приводу Dynamic Snapshot

При плануванні merge публікації з динамічними фільтрами та динамічними знімками, потрібно враховувати наступні моменти:
1. Динамічні знімки можуть використовуватися зі всіма типами передплати. Ви можете створювати динамічний знімок, використовуючи Create Dynamic Snapshot Job Wizard та / або запустивши Snapshot Agent з відповідними параметрами. Застосування динамічного знімка здійснюється з використанням Merge Agent або Merge ActiveX Control і з установкою властивостей DynamicSnapshotLocation.
2. Ви можете використовувати параметр командного рядка – DynamicSnapshotLocation для Merge Agent або властивість DynamicSnapshotLocation в Merge ActiveX Control, щоб застосувати попередньо згенерований динамічний знімок.
3. Динамічні фільтри і динамічні знімки застосовуються тільки з Merge реплікацією.
4. Щоб створити динамічний знімок, для публікації потрібно включити динамічний фільтр і повинен бути створений стандартний знімок.
5. Файли динамічних знімків також будуть стислі, якщо стиснутий стандартний знімок. Щоб стиснути стандартний знімок, і відповідно динамічний знімок, відкрийте властивості публікації, і для “Snapshot Location tab” виберете “Generate snapshots in the following location”, що б задати в текстовому полі місце розташування знімка, а потім потрібно вибрати “Compress Snapshot files in this
location”.
6. Логін, вказаний для входу в систему видавця, повинен бути зазначений в Publication Access List (PAL) або бути членом ролі sysadmin публікується бази даних або групи DB_owner. Цей логін може бути визначений в Create Dynamic Snapshot Job Wizard або при використанні параметра Snapshot
Agent -DynamicFilterLogin.
7. Оскільки SQL Server додає і видаляє тимчасові логіни в Snapshot Agent, логін Snapshot Agent видавця повинен бути членом серверної ролі securityadmin і бути членом групи DB_owner публікується бази даних, щоб мати можливість створювати динамічні знімки.
8. Логіни динамічного фільтру, вказані для створення динамічного знімка, повинні бути включені у відповідний список доступу публікації (PAL).
9. SQL Server на видавця повинен мати змішаний режим захисту (mixed security mode).
10. Зміна властивостей публікації без пересозданія стандартного знімка для публікації з динамічним фільтром зробить не можливим застосування всіх наступних динамічних знімків, які будуть згенеровані.
11. Не використовуйте параметри в системній функції SUSER_SNAME (), яка використовується з динамічними знімками, наприклад: SUSER_SNAME (SID).
12. Функції, які неявно покладаються на SUSER_SNAME () або поточного користувача, наприклад: USER_NAME (), CURRENT_USER (), System_USER (), USER_id () або SUSER_SID () не будуть правильно працювати і не повинні використовуватися з динамічними знімками (замість них потрібно використовувати SUSER_SNAME () або HOST_NAME ()).
13. У динамічному фільтрі можна використовувати визначені користувачем функції (user-defined functions). Однак, якщо визначений користувачем фільтр видає одні й ті ж значення для всіх передплатників, це – тип статичного фільтру, і немає ніякої необхідності використовувати динамічні знімки, тому що всі передплатники отримають однаковий знімок даних.
14. Ви можете використовувати системну функцію SUSER_SNAME (), вкладену в обумовлену користувачем функцію, в критеріях динамічного фільтру, і можете використовувати динамічний знімок (наприклад, MyUDF (SUSER_SNAME ()), де MyUDF – обумовлена ​​користувачем функція, яка використовує SUSER_SNAME ()). Системна функція повинна бути видима в критеріях динамічного фільтра. Якщо системна функція існує у визначенні визначається користувачем функції, і Ви вводите в динамічний фільтр тільки визначається користувачем функцію, Ви не зможете використовувати динамічний знімок.

Створення і застосування динамічних знімків вручну

Запустите Snapshot Agent, щоб створити стандартну схему знімка і всі інші файли. Використовуйте стандартні властивості (-Publisher,-PublisherDB,-Publication, і т.д.) при запуску Snapshot Agent. Запустите Snapshot Agent, щоб створити файли масових копій (. Bcp) один раз для кожного певного розділу передплатника. При цьому, використовуйте стандартні властивості і наступні властивості:
-DynamicFilterHostName
-DynamicFilter Login
-DynamicSnapshotLocation

Запустіть Merge Agent для кожної підписки, щоб застосувати початковий динамічний знімок на передплатників. Використовуйте стандартні властивості, і додайте наступні властивості:
-Hostname
-DynamicSnapshotLocation


Звірка інформації на передплатника

Merge реплікація з динамічним фільтром має функцію, яка видає інформацію про передплатника. Microsoft SQL Server 2000 перевіряє інформацію передплатника, грунтуючись на цій функції до того, як відбудеться кожне об’єднання. Це гарантує, що інформація буде послідовно розбита на розділи для кожного об’єднання. Наприклад, коли публікація з динамічним фільтром використовує функцію SUSER_SNAME (), Merge Agent застосовує початковий знімок до кожного передплатнику, грунтуючись на даних, які є вірними для вираження SUSER_SNAME ().
Коли передплатник повторно з’єднується з видавцем при наступній синхронізації, Merge Agent звіряє інформацію передплатника і гарантує, що будуть синхронізовані ті розділи, які були надіслані до цього, як частина початкового знімка. Якщо Merge Agent виявляє, що вираз фільтра повертає різні значення, об’єднання закінчується збоєм. Оскільки значення функції, що використовується в динамічному фільтрі, змінилося, підписка для абонентів повинна бути повторно ініціалізований або оригінальний логін або значення host_name повинні використовуватися до того, як буде дозволена синхронізація. Це запобіжить проблеми, які можуть виникати, якщо змінені параметри об’єднання для передплатника.
Ви можете вибирати створення динамічного фільтру, а потім звірку інформації передплатника при створенні публікації, використовуючи Create publication Wizard, або інакше, після того, як публікація створена і визначена для динамічних фільтрів, можна використовувати властивості публікації.


Join фільтри

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


ARTICLE1_TABLE.COLUMN = ARTICLE2_TABLE.COLUMN

Join фільтри звичайно використовуються разом з фільтрами рядків і дозволяють Merge процесу підтримувати посилальну цілісність між цими двома таблицями. Якщо таблиця, що видається з фільтром рядків, посилається на foreign key в інший видається таблиці, стаття foreign key таблиці повинна мати Join фільтр для забезпечення посилальної залежно від статті primary key таблиці.
Enterprise Manager використовує це правило автоматично при створенні публікації для того, щоб запропонувати об'єднання з логікою фільтрації для foreign key таблиці, заснованої на foreign key посиланнях. З цієї причини, а також для простоти використання, рекомендується, щоб Ви попередньо визначили відносини primary key і foreign key, а потім обрали автоматичну генерацію Join фільтра, при створенні публікації засобами
Create Publication Wizard.

Зверніть увагу: Синтаксис створення обмежень FOREIGN KEY в CREATE TABLE або ALTER TABLE передбачає можливість використання опції NOT FOR REPLICATION. Коли ця опція встановлена, Microsoft SQL Server 2000 передбачає, що посилання була перевірена, коли користувач вніс зміни в дані. Тому SQL Server 2000 пропускає додаткові кроки подальшої обробки, в яких перевіряється посилання під час синхронізації даних Merge процесом. Якщо ця опція включена, повинен бути визначений Join фільтр, який дозволить уникнути виникнення недопустимих по foreign key рядків на передплатника.

Join фільтри строго не обмежені відносинами primary key - foreign key. Join фільтр може бути заснований на будь-якій логіці порівняння, яка зіставляє дані в двох таблицях статті, але ця логіка повинна використовувати, якщо можливо, проіндексовані стовпці для забезпечення більш високої ефективності.
Merge процес вміє оптимізувати ефективність в залежності від того, засновано чи умова об'єднання на унікальному стовпці, що має місце, коли Join фільтр foreign key відносини. Якщо умова об'єднання засноване на унікальному стовпці, з метою підвищення ефективності, для цієї статті властивість join_unique_key повинно бути включено.
Хоча в фільтрі рядків можна використовувати підзапит, це не можна ще вважати Join фільтром. Якщо Ви оновлюєте рядок у таблиці згаданим вище підзапитом, запит не буде переоцінений, і рядок не буде включена в реплікацію. Join фільтри існують тільки в Merge реплікації.

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

Зумовлені користувачем функції і статичні фільтри

Зумовлені користувачем функції (UDF), це підпрограми, складені з прихованих від користувача наборів логіки Transact-SQL. Ви можете використовувати їх в статичних або динамічних фільтрах.
Використовуючи визначені користувачем функції, Ви збільшуєте можливості фільтрації, тому що з'являється можливість створення фільтрів на основі часто використовуваної логіки, керованої таблицею бізнес-правил або будь-яким набором складних команд, які повертають обчислені значення.
Ви можете використовувати визначені користувачем функції, які повертають скалярні значення (Int, char або decimal) при горизонтальній фільтрації (фільтрація рядків, що копіює підмножина рядків з таблиці) в реплікації знімків, реплікації транзакцій або Merge реплікації.
Щоб створювати визначається користувачем функцію для використання в фільтрі публікації, використовуйте команду CREATE FUNCTION для бази даних, яка містить видаються дані, і включайте в неї необхідні оператори і команди Transact-SQL. Ви можете використовувати функцію в фільтрі при створенні новий публікації в Create publication Wizard або при конфігуруванні існуючої публікації через діалогове вікно її властивостей. Якщо публікація вже має передплатників, потрібно видалити всі її передплати, і тільки потім створювати або змінювати фільтри рядків. Ви не повинні реплицировать функцію, щоб використовувати її як частину фільтра в публікації.

Зумовлені користувачем функції і динамічні фільтри

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

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


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

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

Ваш отзыв

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

*

*