|
Фильтрация реплицируемых данных
Введение
Фильтры строк
Фильтры столбцов
Динамические фильтры
Динамические снимки
Некоторые соображения по поводу 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()), которые
выдают разные значения на каждом подписчике публикации. Разные разделы данных копируются разным
подписчикам, в зависимости от значений, возвращаемых функцией.
Определяемые пользователем функции расширяют возможности фильтрации, за счёт использования функций
в динамическом фильтре. Это позволяет определять бизнес-правила, скалярные или табличные значения,
используемые при выделении разделов издаваемых данных в динамическом фильтре.
|
|
