Фільтрація реплицируемой даних

Введення
Фільтри рядків
Фільтри стовпців
Динамічні фільтри
Динамічні знімки
Деякі думки з приводу 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>

*

*