авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 19 ] --

Рис. 14.55. Окно Default Article Type Рис. 14.56. Окно Default View Article Properties Свойства статьи Мы не будем рассматривать работу с окном свойств по умолчанию, а обратимся к рассмотрению работы со свойствами отдельной статьи. При этом следует заме тить, что для уже созданных статей некоторые свойства будут доступны только в режиме чтения. Поэтому, для полноты картины рассмотрим окно свойств новой статьи. Для этого следует установить флажок Show unpublished objects на вкладке Articles окна свойств публикации (см. рис. 14.54), чтобы иметь возможность выбо Глава 14. Репликация данных pa нового объекта. В качестве примера рассмотрим свойства статьи, созданной на основе таблицы Orders. Установив флажок в самом левом столбце » строке, соот ветствующей таблице orders, мы тем самым предписываем создать статью на ос нове этой таблицы. При этом в самом правом столбце появляется кнопка с мно готочием, нажатие которой и приводит к открытию окна статьи.

Окно свойств статьи имеет название Table Article Properties (рис, j4.57) и, как видно из рисунка, имеет пять вкладок. Однако такое количество вкладок й.ми.т не каждая статья. Для управления статьями, основанными не на таблице ис пользуется всего две вкладки — General и Snapshot, работа о киторчми не имеет принципиальных отличий от соответствующих вкладок, применяемых при рабо те со статьями, основанными на таблицах. Поэтому мы ;

с будем отдельно рае сматривать свойства статей каждого типа, а ограничимся обзорсее епопеп;

статей на основе таблицы.

Рис. 14.57. Окно Table Article Properties, вкладка Genera!

Рассмотрим элементы управления, имеющиеся на вкладке General (рис. 14.57):

П Name —- имя статьи. Для новой статьи значение в этом поле доступно для редактирования, тогда как при работе с созданными ранее статьями поле бу дет доступно только для чтения.

• Description — краткое описание статьи. Поле всегда доступно для редактиро вания (как для новых, так и для старых статей).

• Source table owner. В этом поле, доступном только для чтения, указывается имя владельца таблицы, на основе которой создана статья.

674 Часть III. Администрирование О Source table name. Выводится владелец таблицы, на основе которой создана статья. Значение в поле также доступно только для чтения и в совокупности с предыдущим полем позволяет однозначно идентифицировать исходный объект в пределах базы данных.

О Destination table owner. В этом поле, доступном для редактирования, указыва ется владелец, которому будет принадлежать таблица при копировании ее на подписчика. При выборе имени владельца следует предварительно убедиться, что указываемый пользователь существует на каждом подписчике. Если на одном из подписчиков не будет существовать указанного пользователя, то создать таблицу не удастся. Отметим, что указание пользователя dbo позво ляет избежать подобных проблем, т. к. этот пользователь имеется в каждой базе данных.

) ( Замечание При работе с репликацией транзакций или репликацией моментальных снимков в окне будет еще иметься поле Destination table name, с помощью которого можно будет определить имя, присвоенное реплицируемой таблице на подписчике. При работе с репликацией сведением такой возможности нет.

• When merging changes from different sources. Данный переключатель предна значен для определения ситуации, при которой будет считаться, что произо шел конфликт изменения данных:

• Treat changes to the same row as a conflict — конфликтом будет считаться изменение данных в одной и той же строке более чем одним участником репликации. При этом не важно, были данные изменены в одном и том же или в разных столбцах. Подобный подход позволяет обеспечить бы строе обнаружение конфликтов и их разрешение, что является несомнен ным достоинством. Однако явный недостаток заключается в низкой дета лизации отслеживаемых изменений. Если в одной и той же строке были изменены данные в разных столбцах, то часть изменений будет потеряна.

• Treat changes to the same column as a conflict (changes to different columns in the same row will be merged) — в этом случае конфликтом будут считаться только изменения, затрагивающие данные одного и того же столбца од ной и той же строки. Это позволяет максимально детализировать отсле живание изменений и избавиться от ненужных потерь информации. Од нако платой за это является более высокое требование агента Merge Agent как к используемой памяти, так и к процессорному времени.

Перейдем к рассмотрению следующей вкладки, имеющей имя Snapshot.

Вкладка Snapshot (рис. 14.58), как несложно догадаться из названия, предназна чена для управления созданием моментального снимка и последующим его применением на подписчике. Окно разделено на три части. Вверху расположен переключатель, с помощью которого указывается метод поведения подсистемы репликации при обнаружении на подписчике объекта с тем же именем, что и реплицируемый. Допускаются следующие варианты поведения:

Глава 14. Репликация данных • Keep the existing table unchanged. Никаких действий предприниматься не будет.

• DROP the existing table and re-create it. На подписчике будет автоматически удалена одноименная таблица, после чего подсистема репликации создаст новую, основываясь на информации моментального снимка. Подобный под ход позволяет гарантировать, что структура таблицы, имеющейся на подпис чике, будет полностью отвечать структуре соответствующей статьи.

П Delete data in the existing table that matches the row filter statement. В этом слу чае из таблицы подписчика будут удалены все строки, относящиеся к опре деленному для статьи горизонтальному фильтру. Это позволяет гарантиро вать, что при использовании соответствующего логического условия будет осуществляться работа с теми же данными, что имеются на издателе. Если горизонтальный фильтр для статьи не был определен, то из таблицы подпис чика будут удалены все строки.

• Delete all data in the existing table. Предусматривает удаление из таблицы под писчика всех имеющихся в ней строк.

Рис. 14.58. Окно Table Article Properties, вкладка Snapshot По умолчанию выбран второй метод разрешения конфликта. Это самый резуль тативный, но в то же время и самый разрушительный метод, действующий на пролом, но избавляющий пользователя от всяческих неожиданностей, связан ных с присутствием в таблице подписчика посторонних строк или несоот ветствием структур объектов. Более того, удаление, а затем повторное создание таблицы позволяет также гарантировать, что с ней не будет связано никаких Часть III. Администрирование непредусмотренных объектов — ограничений целостности, триггеров, индексов и т. д.

В центральной части окна расположен набор флажков, с помошью которых можно управлять включением в моментальный снимок команд, обеспечиваю щих создание на подписчике дополнительных объектов, связанных с реплипи руемым объектом:

П Include declared referential integrity. Включение команд, обеспечивающих соз дание в таблице подписчика ограничений целостности FOREIGN KEY (внешний ключ). При этом необходимо убедиться, что в публикацию также включена и таблица, с которой выполняется связывание.

• Clustered indexes. Для реплицированной таблицы на подписчике будет создан кластерный индекс, включающий те же столбцы, что и на издателе.

О Nonclustered indexes. Будут созданы все некластерные индексы.

П User triggers. На подписчике будут созданы все триггеры, организованные пользователями на издателе для соответствующей таблицы.

• Extended properties. Конфигурирование на подписчике тех же свойств для таблицы, что она имела на издателе. Это позволяет гарантировать, что вы полнение различных операций как на издателе, так и на подписчике будет выполняться одинаково.

• Collation. Предписывает использовать для таблицы на подписчике то же со поставление, что таблица имела на издателе.' С Замечание ^ При создании в таблице подписчика дополнительных объектов следует вниматель но относиться с конфигурированию вертикального фильтра. Некоторые из столбцов, не включенных в публикацию, могут использоваться для индексов, ограничений це лостности или триггеров.

Помимо рассмотренных флажков, в нижней части вкладки имеется еще один флажок — Convert aser-defmed to base data types. Посредством его можно пред писать агенту Snapshot Agent при создании сценариев, с помощью которого бу дет выполняться создание таблицы на подписчике, применять не определяемые пользователем типы данных (LJDDT, user-defined data types), а использовать вместо них соответствующие системные типы данных. Это позволяет избежать проблем при создании таблиц на подписчиках, связанные с отсутствием в базе данных подписчика нужного пользовательского типа данных, а также проблем с несоответствием этих типов данных на издателе и подписчике.

Когда работа с вкладкой Snapshot будет завершена, можно переходить к вкладке Resolver (рис. 14.59), которая предназначена для конфигурирования механизма разрешения конфликтов изменения. Сразу можно заметить, что центральную роль в окне играет переключатель. С его помощью определяется тип механизма, который будет использован для разрешения конфликтов:

Глава 14. Репликация данных • Use the default resolver. При установке переключателя в это положение будет использоваться стандартный механизм разрешения конфликтов, основанный на приоритетах. Этот же механизм применялся для разрешения конфликтов и в SQL Server 7.0.

• Use this custom resolver (registred at the Distributor). Установка переключателя в данное положение позволяет выбрать один из дополнительных механизмов разрешения конфликтов. В этом случае становится доступным список в цен тральной части вкладки, с помощью которого и выбирается нужный механизм разрешения конфликтов. Подробное описание посташшемых в составе SQL Server 2000 дополнительных механизмов разрешения конфликтов было дано в разд. "Репликация сведением"ранее в этой главе. Однако, помимо выбора встро енных механизмов, также разрешается запуск своих собственных механизмов.

реализуемых в виде хранимой процедуры. Для этого в списке следует выбрать пункт Microsoft SQL Server Stored Procedure Resolver и в поле Enter information needed by the resolver ввести имя нужной хранимой процедуры.

Рис. 14.59. Окно Table Article Properties, вкладка Resolver Помимо использования автоматического разрешения конфликтов с помощью конкретного механизма, также имеется возможность ручного (или интерактив ного) разрешения конфликтов. Устанавливая флажок в нижней части вкладки, можно предписать подсистеме репликации при выполнении ручной синхрони зации выводить пользователю специальное диалоговое окно, в котором будут перечислены обнаруженные конфликты изменения. Пользователь обязан будет Часть III. Администрирование сам решить, какое изменение должно победить. Подробно интерактивное раз решение конфликтов будет рассмотрено далее в этой главе.

Сейчас же обратимся к рассмотрению вкладки Identity Range (рис. 14.60), с помо щью которой можно управлять диапазонами значений для столбцов-счетчиков (с установленным свойством IDENTITY) на серверах — участниках репликации. По добная возможность является довольно полезной. Если не контролировать про цесс генерирования значений в столбцах-счетчиках, то вполне может получиться ситуация, когда на разных серверах будут созданы строки, имеющие одинаковые значения в столбце-счетчике для одной и той же таблицы. Не стоит и говорить, что необходимо всеми силами избегать подобных ситуаций. Наличие двух строк с одинаковыми идентификационными номерами недопустимо. Поэтому необходи мо каким-то образом обеспечить уникальность значений в столбце-счетчике не только в пределах подписчика (что реализуется стандартными средствами SQL Server 2000), но и в пределах всех участников репликации.

Рис. 14.60. Окно Table Article Properties, вкладка Identity Range с Замечание Подробно использование столбцов-счетчиков будет рассмотрено в главе 21.

Это реализуется путем выделения каждому серверу — участнику репликации определенного диапазона идентификационных номеров, что вполне возможно, т. к. при создании столбца-счетчика можно указать, с какого номера следует начинать генерацию значений. Вкладка Identity Range предназначена для указа Глава 14. Репликация данных ния ширины диапазона, который будет выделяться участникам репликации для генерации значений в столбце-счетчике.

(~ Замечание ) Необходимо отметить, что вкладка Identity Range будет присутствовать в окне свойств статьи только в том случае, если в исходной таблице был определен стол бец-счетчик.

В верхней части вкладки (см. рис. 14.60) имеется флажок, устанавливая который можно разрешить автоматический контроль подсистемой репликации уникаль ности значений в столбцах-счетчиках. Если флажок сброшен, то пользователи должны будут сами заботиться об уникальности значений в этих столбцах.

После установки флажка на вкладке становятся доступными дополнительные элементы управления:

• Maximum identity value. Указывается максимально возможное значение для идентификатора в столбце-счетчике. Зависит от типа данных, используемого для столбца счетчика.

( Замечание ^ Для столбца-счетчика могут применяться только целочисленные типы данных — t i n y i n t (диапазон возможных значений от 0 до 255), s m a l l i n t (диапазон от -32 768 до 32 767), int (диапазон от -2 147 483 648 до 2 147 483 647) и b i g i n t (диапазон от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 807).

О Next range starting value. Указывается число, с которого будет начинаться следующий диапазон значений издателя или одного из подписчиков. При создании новой статьи ничего в этом поле указано не будет.

• Identity increment — шаг приращения значений в столбце-счетчике. По умол чанию равен 1 и не может быть изменен.

• Range size at Publisher — ширина диапазона, выделяемого для столбца счетчика на издателе.

П Range size at Subscribers — ширина диапазона, выделяемого для столбца счетчика на подписчиках.

• Assign a new range when this percentage of values is used. Задается, на сколько процентов должен быть исчерпан существующий диапазон, прежде чем соот ветствующему серверу будет выделен новый диапазон.

На этом работа со вкладкой Identity Range заканчивается. Необходимо заметить, что для созданной публикации не поддерживается возможность разрешения или запрещения автоматического контроля значений в столбце-счетчике. Поэтому следует нужным образом сконфигурировать статью во время создания.

Теперь же обратимся к последней вкладке окна свойств статьи — вкладке Merging Changes (рис. 14.61). В верхней части вкладки имеется группа фдажков Check permissions, с помощью которых можно разрешить проверку прав доступа Часть III. Администрирование агента Merge Agent к соответствующей таблице подписчика. По умолчанию предполагается, что агенту предоставлены все необходимые права. Однако, если агент не имеет прав на выполнение тех или иных действий, то он будет генери ровать сообщение об ошибке каждый раз при неудачном выполнении той или иной команды. Это может привести к лавине ошибок и множеству безуспешных попыток изменения данных. Чтобы избежать загрузки агента ненужными по пытками, можно сначала проверить, имеет ли агент необходимые права. Для этого и используются флажки:

• INSERT — проверка возможности вставки данных;

• UPDATE — проверка возможности изменения данных;

П DELETE — проверка возможности удаления данных.

Рис. 14.61. Окно Table Article Properties, вкладка Merging Changes Помимо трех указанных флажков, в нижней части вкладки присутствует еще один флажок, с помощью которого можно определить стратегию изменения данных в различных столбцах одной и той же строки. При установленном флажке указанные изменения будут выполняться как одна команда, даже если изменения в столбцы были внесены различными участниками репликации. При сброшенном флажке для каждого столбца станет генерироваться отдельная ко манда UPDATE, что потребует дополнительньюфесурсов., На этом конфигурирование свойств статьи можно считать оконченным. Теперь же настало время вернуться к окну свойств публикации.

Глава 14. Репликация данных Вертикальные фильтры Итак, в предыдущем разделе была описана работа с вкладкой Articles окна свойств публикации. В этом же разделе будет описано конфигурирование вер тикальных фильтров для статей, основанных на таблицах. Для этого предназна чена вкладка Filter Columns Вкладка Filter Columns (рис. 14.62) служит для управления столбцами, которые будут включены в ту или иную статью, основанную на таблице. Как видно, вклад ка разделена на две области. В левой части перечислены все таблицы, которые публикуются в конфигурируемой публикации в качестве статей. В правой же час ти вкладки выводится список столбцов, имеющихся в таблице, выбранной слева в окне. Как видно, каждый Столбец описывается именем и типом данных. Установ ленный флажок слева от имени столбца свидетельствует о том, что этот столбец включен в статью. По умолчанию в статью включаются все столбцы.

Рис. 14.62. Вкладка Filter Columns окна свойств публикации Сбрасывая тот или иной флажок, можно исключить из статьи соответствующий столбец, что и называется установкой вертикального фильтра. Отметим, что нельзя исключить из статьи столбцы, на основе которых построен первичный ключ, а также на которые ссылаются реплицируемые объекты и столбец ROWGUIDCOL.

В нижней части вкладки находятся две кнопки — Add Column to Table и Drop Selected Column, с помощью которых, соответственно, можно добавить в табли 682 Часть III. Администрирование цу новый столбец или удалить один из существующих. Если удаление столбца не вызывает особых трудностей (достаточно выбрать его в правой таблице), то создание нового столбца требует пояснений.

После нажатия кнопки Add Column to Table откроется окно Add Column to Repli cated Table (рис. 14.63), с помощью которого необходимо указать параметры столбца. В верхней части окна имеется поле Table, где указывается имя табли цы, в которую будет добавлен столбец. Имя столбца необходимо ввести в поле Column name, тогда как собственно описание столбца приводится в текстовом поле Column definition (excliding the column name). Как минимум необходимо ука зать тип данных (параметр data_type), который должен иметь столбец. Все остальные параметры являются дополнительными и могут быть опущены. Под робно конфигурирование столбцов будет рассмотрено в главе 21.

Рис. 14.63. Окно Add Column to Replicated Table В нижней части окна имеется таблица Include this column in the following publica tions, с помощью которой можно сразу же включить создаваемый столбец в лю бую из публикаций, включающих соответствующую таблицу.

Горизонтальные фильтры Помимо вертикальных фильтров, определяющих какие столбцы должны быть реплицированы подписчикам, имеется возможность управлять и горизонталь ными фильтрами, определяющими список строк, предлагаемых к копированию подписчикам. Таким образом, использование горизонтальных фильтров позво ляет реплицировать только часть строк, имеющихся в таблице.

Глава 14. Репликация данных Для управления горизонтальными фильтрами служит вкладка Filter Rows (рис. 14.64). В верхней части вкладки перечислены все таблицы, выбранные для публикации. Собственно условие фильтрации указывается в столбце Filter Clause. Для его редактирования предназначено окно Specify Filter (см. рис. 14.46), работа с которым, а также и другими имеющимися на вкладке Filter Rows элементами управления, была представлена в разд. "Создание публи кации" ранее в этой главе. Поэтому мы не будем повторяться и сразу же перей дем к следующей вкладке.

Рис. 14.64. Вкладка Filter Rows окна свойств публикации Управление подписками Следующей вкладкой, которую мы рассмотрим, будет вкладка Subscriptions (рис. 14.65), с помощью которой можно управлять подписками, созданными на конфигурируемую публикацию. К данному моменту еще не было создано ни одной подписки, поэтому основная часть элементов управления вкладки недоступна.

Активной является только кнопка Push New, позволяющая запустить мастер создания принудительной подписки Push Subscription Wizard, работа с которым будет рассмотрена позже в одном из следующих разделов этой главы.

Часть III. Администрирование Рис. 14.65. Вкладка Subscriptions окна свойств публикации Помимо указанной кнопки, на вкладке еше имеются перечисленные ниже кнопки:

П Properties открывает окно свойств подписки, работа с которым будет рас смотрена в одном из следующих разделов;

О Delete предназначена для удаления подписки;

О Reinitialize предписывает выполнить повторную инициализацию соответст вующего подписчика, применив на нем моментальный снимок;

Я Reinitialize АН предоставляет возможность выполнить повторную инициали зацию всех подписчиков;

П View Conflicts открывает окно просмотра конфликтов изменения. Работа с этим окном также будет рассмотрена в одном из следующих разделов данной главы.

Кроме кнопок существует таблица Subscriptions, в которой выводится список подписок. Рассмотрим, какие же столбцы имеются в этой таблице:

• Subscription Name — имя подписки;

О Туре — тип подписки: принудительный (Push) или по требованию (Pull);

• Priority — приоритет соответствующего подписчика.

Глава 14. Репликация данных Управление свойствами подписок Если предыдущая вкладка использовалась для управления конкретными под писками, то вкладка Subscription Options (рис. 14.66) предназначена для управ ления общими свойствами публикаций.

Рис. 14.66. Вкладка Subscription Options окна свойств публикации Рассмотрим элементы управления, имеющиеся на вкладке:

• Allow pull subscriptions. Установка этого флажка разрешает создание для пуб ликации подписки по требованию. При этом становится доступным допол нительный флажок:

• Allow anonymous subscriptions — разрешает подписку на публикацию ано нимным подписчикам.

• Allow new subscriptions to be created by attaching a copy of a subscription data base. С помощью этого флажка можно контролировать автоматическое соз дание новой подписки для присоединяемой (attaching) базы данных если она имеет поддержку репликации сведением. Это позволяет автоматизировать создание подписок при рассылке отсоединенной базы данных множеству пользователей.

П Centralize conflicting reporting at the Publisher предписывает централизованно хранить информацию о конфликтах изменения.

Часть III. Администрирование • Allow partitioning through dynamic filters. В этом поле указывается, была ли публикация сконфигурирована для поддержки динамических фильтров. Та ким образом, разрешить или запретить поддержку этих фильтров после соз дания публикации невозможно.

• Before merging, validate Subscribers with this expression. В этом текстовом поле можно указать код раздела WHERE, С ПОМОЩЬЮ которого будет выполняться проверка данных на подписчике на соответствие установленному динамиче скому фильтру. Эта проверка осуществляется при синхронизации подписчи ка и позволяет гарантировать, что подписчик содержит данные, соответст вующие горизонтальному фильтру. При обнаружении несоответствия будет автоматически применен моментальный снимок, что должно устранить не согласованность.

• Minimize network traffic by increasing the storage requirements at the Publisher. В данном поле указывается, разрешено ли для публикации сведением к мини муму объема передаваемых по сети данных. Эта возможность конфигуриру ется при создании публикации и позже не может быть изменена.

Управление моментальным снимком Следующая вкладка, которую мы рассмотрим, — это вкладка Snapshot (рис. 14.67). С ее помощью можно управлять параметрами создания и размеще ния моментального снимка, который будет использоваться агентом Merge Agent при выполнении первоначальной синхронизации подписчика.

Рис. 14.67. Вкладка Snapshot окна свойств публикации Глава 14. Репликация данных Первое, с чем сталкиваешься на этой вкладке — это переключатель Snapshot format, предназначенный для выбора формата, который будет использоваться для генерирования файлов с данными моментального снимка:

О Native SQL Server format — all Subscribers must be servers running SQL Server.

Будет использоваться так называемый исконный (native) формат, обеспечиваю щий более компактное хранение данных и более высокую скорость последую щей закачки данных в таблицы подписчика. Однако этот формат может быть использован только для серверов SQL Server 2000 или SQL Server 7.0.

• Character mode format — supports heterogeneous Subscribers and data transfor mations using DTS. Данные в файлах моментального снимка будут храниться в текстовом виде, что обеспечивает возможность их использования подпис чиками любых типов (Oracle, SQL Server 6.x, SQL Server 2000 и т. д.).

Помимо указанного переключателя, в нижней части вкладки имеется два тек стовых поля, где можно указать путь к файлу с набором команд Transact-SQL, которые должны быть выполнены на подписчике до (верхнее поле) и после (нижнее поле) применения на подписчике моментального снимка.

Размещение моментального снимка С помощью вкладки Snapshot Location (рис. 14.68) можно определить место, в котором следует сохранить файлы моментального снимка.

Рис. 14.68. Вкладка Snapshot Location окна свойств публикации 23 Зшс. в88 Часть III. Администрирование ) ( Замечание При работе с предыдущими версиями SQL Server пользователи не могли явно ука зать каталог, в который будут сохраняться файлы моментального снимка. В SQL Server 2000 это стало возможным. Более того, подписчики могут выкачивать момен тальный снимок не только стандартными средствами, но и с использованием прото кола FTP.

Рассмотрим элементы управления, находящиеся на вкладке Snapshot Location:

• Generate snapshots in the normal snapshot folder. Когда для публикации установ лен этот флажок, файлы моментального снимка будут располагаться в стан дартном месте — в каталоге дистрибьютора Program Files\Micsoroft SQL Server\MSSQL\ReplData. Для каждой публикации в этом каталоге автоматиче ски создается отдельный каталог, в котором и сохраняются файлы. Преимуще ства стандартного каталога в том, что его местоположение известно всегда.

( Замечание ) К счастью, не приходится выбирать между стандартным хранилищем и произволь ным — можно использовать оба типа хранилищ независимо друг от друга. По умол чанию на вкладке установлен только первый флажок.

П Generate snapshots in the following location. Если необходимо сохранить файлы моментального снимка в ином каталоге, чем предлагаемый по умолчанию, то требуется установить данный флажок. После этого станут доступными сле дующие элементы управления:

Folder — указывается каталог, в котором следует сохранить файлы момен • тального снимка. Можно задать как локальный каталог, так и сетевой ре сурс;

• Compress the snapshot files in this location — устанавливая этот флажок, можно выполнить сжатие файлов моментального снимка. Это позволит уменьшить нагрузку на каналы связи;

• Subscribers can access this folder using FTP (File Transfer Protocol) — уста навливая этот флажок, можно разрешить доступ к файлам моментального снимка с помощью протокола FTP.

При установке последнего флажка становятся доступными дополнительные элементы управления, с помощью которых определяются параметры использо вания подписчиками протокола FTP:

• FTP server name — имя сервера FTP, на котором расположены данные.

Предполагается, что к каталогу, указанному в поле Folder, можно обратиться с помощью протокола FTP.

• Port — номер порта, используемого на сервере для работы протокола FTP;

П Client path to this folder from the FTP root — относительный путь к каталогу сервера FTP, в котором расположены файлы моментального снимка. При указании пути не нужно указывать имени сервера;

Глава 14. Репликация данных П Login — имя учетной записи, которая имеет доступ к указанному каталогу сервера и которая будет применяться подписчиками для установления со единения с сервером;

• Password — пароль учетной записи, указанной в предыдущем поле;

• Confirm Password — повторение пароля для избежания ошибок при вводе.

Мы рассмотрели все элементы управления, имеющиеся на вкладке Snapshot Lo cation. Варианты использования предоставленных возможностей уже зависят от конкретной ситуации.

Доступ к публикации Перейдем к рассмотрению вкладки Publication Access List (рис. 14.69). Она предназначена для управления правами доступа к публикации.

Рис. 14.69. Вкладка Publication Access List окна свойств публикации Как видно, центральную часть вкладки занимает таблица, в которой перечисля ются учетные записи. Любая учетная запись, указанная в таблице, имеет право подписываться на публикацию, и изменения, выполненные на соответствующем подписчике, начнут отображаться на всех участниках репликации.

Для предоставления доступа новой учетной записи следует нажать кнопку Add, что приведет к открытию окна SQL Server Enterprise Manager, в котором будут 23* Часть III. Администрирование перечислены все учетные записи, сконфигурированные на текущем сервере.

Достаточно выбрать в окне необходимую учетную запись и нажать кнопку ОК.

Выбор партнеров для синхронизации Следующая вкладка — Sync Partners (рис. 14.70) — предназначена для выбора партнеров для синхронизации. Однако непонятно, что кроется за этой фразой.

При работе по стандартной схеме данные публикуются издателем и реплициру ются подписчикам. Однако по тем или иным причинам использование издателя может оказаться нерациональным. Более того, неплохо было бы обезопасить участников репликации от выхода из строя издателя, что приведет к останову работы публикации.

В SQL Server 2000 имеется возможность разрешить использование в качестве издателя иного сервера, чем тот, на котором была создана публикация. Для этого и предназначена вкладка Sync Partners.

Рис. 14.70. Вкладка Sync Partners окна свойств публикации По умолчанию взаимоотношения между участниками репликации осуществля ются по стандартной схеме. Если же необходимо сконфигурировать один из серверов в качестве дополнительного издателя, то сначала следует установить флажок в верхней части вкладки. После этого станет доступной таблица в цен тральной части вкладки. В этой таблице перечислены все участники реплика Глава 14. Репликация данных ции. Устанавливая флажок слева от имени сервера, можно разрешить использо вать его в качестве дополнительного издателя.

Просмотр статуса Последняя вкладка, которую нам осталось рассмотреть, — это вкладка Status (рис. 14.71). Она предназначена для управления работой агента Snapshot Agent и запуском службы SQLServerAgent.

Рис. 14.71. Вкладка Status окна свойств публикации В полях Last run и Next run указывается дата последнего и следующего запуска агента Snapshot Agent. Если необходимо запустить агент Snapshot Agent немед ленно, то следует нажать кнопку Run Agent Now. С помощью кнопки Agent Pro files можно открыть окно свойств задания, которое позволяет запустить агент Agent Profiles. После нажатия кнопки Explore Snapshot открывается каталог с файлами моментального снимка (рис. 14.72). Эта операция также может быть выполнена из контекстного меню публикации, если в нем выбрать команду Ex plore The Last Snapshot Folder.

с Замечание Нетрудно заметить, что сохранение стандартного моментального снимка происхо дит иначе, чем запись динамического моментального снимка. Если файлы послед него записываются непосредственно в указанный каталог, то при работе со стан Часть III. Администрирование дартным моментальным снимком в указанном каталоге образуется несколько до полнительных каталогов, что позволяет указывать один и тот же каталог для записи моментальных снимков различных публикаций.

Рис. 14.72. Окно просмотра каталога моментального снимка Нижняя часть вкладки предназначена для управления запуском служб, необхо димых для работы подсистемы репликации. Так как работа подсистемы репли кации обеспечивается службой SQLServerAgent, то ее имя и будет выведено. Для службы в столбце Status указывается ее текущее состояние, которое также ото бражается в самом левом столбце в виде значка, символизирующего службу.

Из операций управления службой в распоряжении пользователей имеется лишь кнопка Start Service, с помощью которой можно запустить выбранную службу.

Кнопка Refresh Status предназначена для обновления информации о состоянии службы.

Удаление публикации Удаление публикации является, наверное, для нее самой простой операцией.

Действительно, ломать — не строить. Итак, чтобы удалить публикацию, необхо Глава 14. Репликация данных димо открыть папку Publications нужной базы данных и найти в ней требуемую.публикацию. Затем в контекстном меню публикации необходимо выбрать ко манду Delete. Вот и все.

При удалении публикации будут автоматически удалены все подписки, сделан ные на нее. При удалении публикации не происходит удаления опубликованных данных ни на издателе, ни на подписчиках. После изъятия подписки просто перестает выполняться синхронизация изменений, выполненных участниками репликации. Таким образом, на издателе и подписчиках будут содержаться дан ные. Но с течением времени разница между ними будет становиться все более и более заметной.

Управление подпиской Предыдущие разделы были посвящены рассмотрению хотя и необходимой, но все же предварительной подготовке к репликации данных. К настоящему времени читатель должен уже уметь конфигурировать издателя и дистрибьютора, а также создавать публикации. После выполнения этих операций можно приступать к собственно репликации данных. Это подразумевает инициализацию подписчика и подписку его на одну из созданных публикаций. До тех пор, пока в сети не будет иметься хотя бы одного подписчика, никакой репликации данных выполняться не будет. Конечно, опубликованная база данных издателя будет иметь все механизмы для обеспечения репликации данных, на дистрибьюторе будут запущены необхо димые агенты поддержки репликации, создана база данных распределения, и нач нет осуществляться отслеживание изменения данных на издателе. Однако все это ни к чему, если никто не станет получать эту информацию.

Итак, настоящий раздел посвящен инициализации подписчика и созданию под писки на существующую публикацию. Для целостности излагаемого в главе ма териала в качестве примера рассмотрим подписку на публикацию репликации сведением, созданную в одном из предыдущих разделов с помощью мастера Create Publication Wizard. Мы обсудим как создание принудительной подписки (Push Subscription), так и подписки по требованию (Pull Subscription).

Создание принудительной подписки Особенностью подписки этого типа является то, что она направлена от дист рибьютора к подписчику, т. е. подписчик играет пассивную роль, а все действия выполняются дистрибьютором. Все агенты репликации в этом случае работают на издателе и дистрибьюторе, но не на подписчике. Конкретные детали зависят от типа используемой репликации. Если говорить о репликации сведением, то во время применения принудительной подписки агент Merge Agent запускается на дистрибьюторе и устанавливает соединение с подписчиком, выкачивает у него информацию о выполненных изменениях, объединяет ее с имеющейся ин формацией на дистрибьюторе, при необходимости решая конфликты изменения данных, после чего закачивает подписчику окончательныйвариант данных.

Часть III. Администрирование Создание принудительной подписки выполняется с помощью мастера Push Subscription Wizard, который можно запустить различными способами. Самый простой из них — использование окна Select Wizard, которое можно открыть с помощью кнопки Run a wizard, расположенной в панели инструментов Enter prise Manager. Мастер также может быть запущен из окна свойств публикации.

Эту возможность предоставляет вкладка Subscriptions (см. рис. 14.84), в которой необходимо нажать кнопку Push New. Мастер также может быть запушен из контекстного меню публикации, если в нем выбрать команду Push New Sub scriptions. Эта же команда доступна в меню Action окна Enterprise Manager после предварительного указания нужной публикации.

Заметим, что при запуске мастера с помощью окна Select Wizard сначала откро ется окно менеджера публикаций Create and Manage Publications (рис. 14.73). В этом окне необходимо открыть базу данных, в контексте которой была создана нужная публикация, после чего выбрать имя самой публикации. Затем остается только нажать кнопку Push New Subscription.

с Замечание Как видно, в окне Create and Manage Publications в распоряжении пользователей имеется кнопка Properties, с помощью которой можно открыть окно свойств публи кации. Для открытия окна Create and Manage Publications можно также воспользо ваться меню Tools, выбрав в нем команду Replication, а потом команду Create and Manage Publications.

Рис. 14.73. Окно Create and Manage Publications Что ж, предположим, что мастер удалось запустить (неважно каким способом).

Первое окно мастера содержит общую информацию о шагах, которые будут вы полнены при создании подписки. В нижней части окна имеется флажок, уста новка которого предписывает мастеру выводить расширенные свойства подпис Глава 14. Репликация данных ки. Мы будем работать с мастером именно в этом режиме, поэтому следует ус тановить флажок, который по умолчанию сброшен.

Таким образом, работа с первым окном мастера не должна вызывать затрудне ний, поэтому можно смело переходить ко второму окну мастера, которое назы вается Choose Subscribers (рис. 14.74). — Рис. 14.74. Окно Choose Subscribers мастера Push Subscription Wizard Это окно предназначено для выбора подписчиков, для которых будет создана принудительная подписка. Для выбора более одного сервера необходимо указать в окне первый сервер, и, нажав клавишу Ctrl или Shift, выбрать дополни тельные серверы. Мы рассмотрим создание подписки для одного сервера.

После того, как будут выбраны все подписчики, можно переходить к следую щему окну мастера, имеющему имя Choose Destination Database (рис. 14.75). В нем необходимо определить имя базы данных, в которую будут реплицироваться данные. В распоряжении пользователя имеется единственное текстовое поле, в котором и необходимо ввести имя базы данных. Указанная база данных должна существовать на всех выбранных подписчиках. Если вы не помните имени нуж ной базы данных, то можно воспользоваться окном Browse Databases (рис. 14.76), в котором перечислены все имеющиеся на подписчике базы дан ных. Для открытия этого окна достаточно нажать кнопку Browse or Create.

С Замечание Если во втором окне мастера было выбрано более одного сервера, то кнопка Browse or Create будет недоступна. Таким образом, можно будет указать имя базы данных только вручную. Нельзя также будет создать и новую базу данных. Однако 696 Часть III. Администрирование можно выбрать во втором окне один из подписчиков, перейтиь к окну мастера Choose Destination Database, создать новую базу данных и возвратиться ко второ му окну для выбора другого подписчика, повторяя указанную операцию.

Рис. 14.75. Окно Choose Destination Database мастера Push Subscription Wizard Рис. 14.76. Окно Browse Databases Помимо прочего, из окна Browse Databases можно открыть окно создания но вой базы данных Database Properties (рис. 14.77), нажав для этого кнопку Create New. Мы не будем сейчас рассматривать работу с окном создания новой базы данных, отложив это до главы 20.

Глава 14. Репликация данных Рис. 14.77. Окно Database Properties Сейчас же вернемся к окну мастера Choose Destination Database (см. рис. 14.75).

Итак, при создании подписки для более чем одного сервера в окне необходимо указать имя базы данных, существующей на всех серверах. Если необходимо реплицировать данные в базы данных с разными именами, то следует запускать мастер Push Subscription Wizard персонально для каждой группы баз данных.

Так как мы рассматриваем создание подписки для одного подписчика, то доста точно выбрать имя любой из существующих баз данных. Остановим свой выбор на базе данных Northwind, хотя, в принципе, можно задать любую другую.

Следующее окно мастера имеет имя Set Merge Agent Location (рис. 14.78) и по зволяет назначить место запуска агента Merge Agent. Хотя в обычной ситуации при использовании принудительной репликации агент Merge Agent стартует на дистрибьюторе, в SQL Server 2000 допускается управление местом запуска этого агента, что открывает дополнительные возможности. Выбор местоположения запуска агента осуществляется с помощью переключателя, который установли вается в одно из перечисленных ниже положений:

• Run the agent at the Distributor — стандартный вариант запуска агента на ди стрибьюторе, который был единственным в SQL Server 7.0.

О Run the agent at the Subscribers (administration will still be performed at the Pub lisher and Distributor). В этом случае агент будет запускаться на подписчике и Часть III. Администрирование устанавливать соединение с дистрибьютором для синхронизации изменений.

Запуск агента на подписчике вовсе не означает, что подписка станет вести себя так же, как и подписка по запросу. Независимо от места старта агента Merge Agent инициатором синхронизации изменений всегда будет дистрибь ютор. Администрирование агента также будет выполняться со стороны изда теля или дистрибьютора. При установке переключателя в рассматриваемое положение становится доступным текстовое поле: Network computer name of Subscriber — в этом поле указывается сетевое имя NetBIOS сервера подписчика. При работе с инсталляцией по умолчанию сетевое имя совпада ет с именем SQL Server 2000.

Рис. 14.78. Окно Set Merge Agent Location мастера Push Subscription Wizard Рассмотрим стандартный вариант расположения агента Merge Agent — на дист рибьюторе, установив переключатель в верхнее положение. После этого можно переходить к следующему окну мастера.

Если предыдущее окно использовалось для управления местом запуска агента Merge Agent, то окно мастера Set Merge Agent Schedule (рис. 14.79) предназна чено для указания времени запуска того же агента. Как видно, в распоряжении пользователя имеется переключатель, с помощью которого необходимо выбрать стратегию запуска агента:

П Continuously — provides minimal latency between when an action occurs at the Publisher and is propagated to the Subscriber. В этом случае агент будет запу щен постоянно. Подобный подход позволяет обеспечить минимальную за держку между выполнением изменения и отображением его на дистрибьюто ре, а также отображение накопленных на дистрибьюторе изменений на Глава 14. Репликация данных подписчике. Однако при этом нужно быть готовым к тому, что часть систем ных ресурсов будет использоваться для работы агента Merge Agent.

О Using the following schedule. Предыдущий метод запуска агента оправдывает себя только при наличии постоянного соединения между издателем и дистрибьюто ром и необходимостью оперативного отображения изменений. Если же соеди нение устанавливается лишь периодически, то лучше будет сконфигурировать запуск агента в соответствии с определенным расписанием. Для этого необхо димо установить переключатель в рассматриваемое положение. При этом необ ходимо будет сконфигурировать и расписание запуска агента. По умолчанию предлагается запускать агента один раз в час. Если это расписание вас не уст раивает, то его можно легко изменить с помощью окна Edit Recurring Job Schedule, открыть которое можно нажатием кнопки Change.

Рис. 14.79. Окно Set Merge Agent Schedule мастера Push Subscription Wizard (~ Замечание ^ Как было сказано в начале главы, запуск агентов репликации осуществляется с по мощью заданий службы SQLServerAgent. Таким образом, вы можете определить до полнительные расписания запуска любого агента репликации, в том числе и Merge Agent. Более того, можно также сконфигурировать запуск агентов при наступлении оповещений, что открывает дополнительные возможности по управлению подсис темой репликации. Подробно конфигурирование запуска заданий было рассмотрено в главе 12.

Когда будет выбрана стратегия запуска агента Merge Agent, можно переходить к следующему окну мастера — окну Initialize Subscription (рис. 14.80), которое Часть III. Адк позволяет указать, нужно ли выполнять первоначальную синхронизацию под писчика:

П Yes, initialize the schema and data. Установка переключателя в это положение свидетельствует о необходимости выполнения первоначальной синхрониза ции, которая включает в себя подготовку объектов и закачку данных. Естест венно, прежде чем станет возможным выполнение первоначальной синхро низации, предварительно необходимо создать моментальный снимок:

• Start the Merge Agent to initialize the subscription immediately — если этот флажок установлен, то первоначальная инициализация подписчика будет осуществлена непосредственно сразу же после завершения работы масте ра. В противном случае эта операция выполнится при следующем запуске агента Merge Agent.

П No, the Subscriber already has the schema and data. В этом случае предполага ется, что подписчик уже содержит необходимые объекты и данные, т. е. пер воначальная синхронизация уже была выполнена (вручную или каким-то иным способом).

Рис. 14.80. Окно Initialize Subscription мастера Push Subscription Wizard По умолчанию мастер предлагает выполнить первоначальную синхронизацию.

Рекомендуется запускать эту операцию даже в том случае, когда подписчик со держит необходимые объекты и данные, т. к. это позволит гарантировать, что подписчик полностью соответствует требованиям репликации. Возможность невыполнения синхронизации используется в случаях, если соединение между подписчиком и хранилищем файлов моментальных снимков (обычно это дист рибьютор) имеет низкую пропускную способность.

Глава 14. Репликация данных Хотя в базе данных Northwind подписчика и содержится та же информация, что и на издателе (конечно, если вы не вносили изменений), тем не менее, мы все же выполним первоначальную синхронизацию, причем сразу же после заверше ния работы мастера.

Далее переходим к работе с очередным окном, называющимся Set Subscription Priority (рис. 14.81), которое предназначено для указания приоритета подписчи ка. Этот приоритет будет использоваться при разрешении конфликтов измене ния данных. Приоритет может либо устанавливаться издателем (положение пе реключателя Use the priority setting of the Publisher to resolve the conflict), либо задаваться вручную (положение переключателя Use the following priority, between zero (lost) and 99.99 (highest), to resolve the conflict). В последнем случае пользо ватель должен в текстовом поле явно указать приоритет, который будет иметь подписчик. По умолчанию предлагается значение 75, однако можно указать лю бое другое в диапазоне от 0 до 99.

С Замечание Хотя шкала приоритетов лежит в диапазоне от 0 до 100, значение 100 всегда заре зервировано за издателем.

Рис. 1 4. 8 1. Окно Set Subscription Priority мастера Push Subscription Wizard Отметим, что каждый подписчик должен иметь свое собственное значение при оритета. Напомним, что при разрешении конфликтов изменения во время рабо ты со стандартным механизмом разрешения конфликтов победителем будет счи таться сервер, имеющий наивысший приоритет.

702 Часть III. Администрирование В нижней части окна имеется таблица, в которой приводится список имеющих ся подписчиков с указанием их приоритета. Эта таблица весьма полезна при выборе приоритета.

Следующее окно мастера Start Required Services (рис. 14.82) предоставляет поль зователю возможность запускать или останавливать службу SQLServerAgent, ко торая, как уже не раз говорилось, необходима для работы подсистемы реплика ции. Устанавливая флажок в самом левом столбце, вы тем самым предписываете запустить службу SQLServerAgent (если конечно она еще не запущена) после нажатия кнопки Finish в последнем окне мастера. Текущее состояние службы указывается в столбце Status.

( Замечание ) Если в окне Initialize Subscription было предписано выполнить первоначальную синхронизацию подписчика сразу же после завершения работы мастера, то служба SQLServerAgent должна быть запущена.

Рис. 14.82. Окно Start Required Services мастера Push Subscription Wizard На этом конфигурирование принудительной подписки заканчивается. Сле дующее окно мастера будет последним. В нем перечислены сконфигурирован ные свойства создаваемой подписки. После нажатия кнопки Finish мастер приступит к собственно созданию подписки с указанными параметрами. При этом также будут внесены все необходимые изменения в базу данных подпис чика — создание триггеров, таблиц поддержки репликации и всех других тре буемых объектов.

Глава 14. Репликация данных Создание подписки по требованию Напомним, что этот тип подписки характеризуется тем, что инициатором син хронизации изменений является подписчик. Таким образом, при работе с реп ликацией по требованию от пользователя понадобится больше внимания, одна ко при этом имеются и свои преимущества. В частности, пользователь может выбрать время, наиболее удобное для выполнения синхронизации изменений.

Более того, при использовании подписки по требованию пользователи могут получать файлы моментального снимка не только из стандартного каталога, но и любого другого.

Создание подписки по требованию осуществляется с помощью мастера Pull Subscription Wizard, первое окно которого содержит вводную информацию о выполняемых шагах. В нижней части окна имеется флажок, установка которого предписывает мастеру отображать элементы управления для конфигурирования расширенных свойств подписки. Рассмотрим работу с мастером именно в этом режиме.


С Замечание ^ Мастер Pull Subscription Wizard должен быть запущен в контексте того сервера, для которого необходимо создать подписку по требованию.

Второе окно мастера называется Look for Publications (рис. 14.83) и определяет источник, в котором будет осуществляться поиск публикаций, предназначенных для подписки:

• Look at publications from registered servers. В этом случае поиск публикации будет осуществляться в пределах зарегистрированных серверов.

П Look at publications in the Active Directory or specify publication information, this option is for Publisher running SQL Server 2000 or later. Этот вариант предпо лагает получение информации о доступных публикациях из каталога Active Directory. Однако, чтобы публикация могла быть найдена с использованием этого метода, необходимо разрешить сохранение информации о ней в Active Directory. Заметим, что использование Active Directory доступно только для SQL Server 2000, работающих под управлением операционной системы Win dows 2000 и при установленной поддержке в сети Active Directory.

Мы рассмотрим первый метод поиска публикаций, который работает независи мо от используемой операционной системы. В этом случае следующее окно мастера будет называться Choose Publication и иметь вид, подобный приведен ному на рис. 14.84.

Как видно, в окне приведен список зарегистрированных серверов и созданных на них публикаций. Если публикация располагается на незарегистрированном сервере, то, чтобы подписаться на нее, необходимо предварительно зарегистри ровать соответствующий сервер. Это можно выполнить, не выходя из мастера.

Регистрация сервера производится с помощью стандартного окна регистрации, открыть который можно с помощью кнопки Register Server.

Часть III. Администрирование Рис. 14.83. Окно Look for Publications мастера Pull Subscription Wizard Рис. 14.84. Окно Choose Publication мастера Pull Subscription Wizard В нашем случае нужный сервер уже зарегистрирован и остается только выбрать интересующую нас публикацию, после чего можно переходить к очередному окну мастера, которое будет называться Specify Synchronization Agent Login (рис. 14.85). Данное окно предназначено для указания учетной записи, которая 70S Глава 14. Репликация данных будет использоваться агентом Merge Agent при установлении соединения с ди стрибьютором для синхронизации изменений данных. Можно использовать ли бо учетную запись, предназначенную для запуска службы SQLServerAgent (положение переключателя Impersonated the SQL Server Agent account), либо произвольную учетную запись SQL Server, имеющуюся на дистрибьюторе (положение переключателя Use SQL Server Authentication). В последнем случае необходимо будет указать имя (поле Login) и пароль (поля Password и Confirm password) учетной записи.

Рис. 14.85. Окно Specify Synchronization Agent Login мастера Pull Subscription Wizard Следующее окно мастера имеет имя Choose Destination Database и предназначе но для выбора базы данных, в которую будут реплицироваться данные. В пре дыдущем разделе мы создали принудительную подписку, которая связана с ба зой данных Northwind, поэтому новую подписку мы свяжем с другой базой данных, например chair. Скорее всего, такой базы данных на подписчике не окажется, поэтому можно предварительно создать ее. Для открытия окна созда ния новой базы данных достаточно нажать кнопку New.

С помощью окна Allow Anonymous Subscription (рис. 14.86) определяется, будет ли подписка на публикацию осуществляться анонимно или с указанием имени подписывающегося пользователя. Отметим, что мастер не станет выводить дан ное окно, если для публикации запрещена анонимная подписка.

Так как нам нечего скрывать, то мы подпишемся на публикацию с указанием своего имени. Для этого необходимо установить переключатель в положение No, this a named subscription.

Часть III. Администрирование Рис. 14.86. Окно Allow Anonymous Subscription мастера Pull Subscription Wizard Рис. 14.87. Окно Initialize Subscription мастера Pull Subscription Wizard ' Окно мастера Initialize Subscription (рис. 14.87) позволяет определить, нужно ли выполнять первоначальную синхронизацию подписчика. Так как база данных, в которую будут реплицироваться данные, только что создана, то необходимо обя зательно синхронизировать ее с издателем. Для этого переключатель должен Глава 14. Репликация данных быть установлен в положение Yes, initialize the schema and data. Дополнительно можно отметить флажок в центральной части окна, что предписывает выпол нить синхронизацию непосредственно при завершении работы мастера, а не откладывать это до следующего запуска агента Merge Agent.

Перейдем к очередному окну, которое называется Snapshot Delivery (рис. 14.88).

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

• Use snapshot files from the default snapshot folder for this publication. При уста новке переключателя в это положение файлы моментального снимка станут выкачиваться из каталога дистрибьютора ReplData, являющегося стандарт ным для хранения моментальных снимков.

• Use snapshot files from the following folder. В этом случае можно указать любой произвольный каталог, из которого необходимо получить файлы моменталь ного снимка. Это может быть как локальный каталог, так и сетевой. Файлы в указанный каталог могут быть помещены как автоматически агентом Snap shot Agent при создании для публикации моментального снимка, так и ско пированы пользователем вручную. Если для первоначальной синхронизации будет использован динамический моментальный снимок, то необходимо ус тановить флажок This snapshot is for a dynamically filtered subscription.

Рис. 14.88. Окно Snapshot Delivery мастера Pull Subscription Wizard В качестве примера рассмотрим применение динамического моментального снимка, который был создан в разд. "Создание динамического моментального Часть III. Администрирование снимка" ранее в этой главе. Напомним, что этот снимок был сохранен в каталоге C:\Tmp\DynSnap5.

Далее переходим к окну Set Merge Agent Schedule (рис. 14.89), предназначенно му для выбора метода запуска агента Merge Agent, который для подписки по требованию всегда запускается на подписчике. Можно утановить переключатель в одно из положений:

• Continuously — provides minimal latency between when an action occurs at the Publisher and is propagated to the Subscriber. Агент Merge Agent будет постоян но находиться в памяти. То есть соединение с дистрибьютором будет посто янно установлено и обнаружение и применение изменений станет происхо дить с минимальными задержками.

О Using the following schedule. Агент начнет автоматически запускаться в соот ветствии с установленным расписанием.

• On demand only -- you can synchronize this subscription using SQL Server Enter prise Manager or the Windows Synchronization Manager. В этом случае агента можно будет запустить только вручную. То есть пользователь обязан запус кать агента каждый раз, когда нужно будет выполнить синхронизацию под писчика с дистрибьютором.

Первые два варианта запуска агента Merge Agent не представляют особого инте реса, поэтому сконфигурируем ручной запуск.

Рис. 14.89. Окно Set Merge Agent Schedule мастера Pull Subscription Wizard Как и при создании принудительной подписки, в процессе конфигурирования подписки по требованию необходимо указать приоритет, который будет иметь Глава 14. Репликация данных подписчик. Для этого и используется окно мастера Set Subscription Priority (рис. 14.90). Работа с этим окном уже была описана в предыдущем разделе (см.

рис. 14.81). Как видно, в нижней части окна в таблице приведена принудитель ная подписка, созданная в предыдущем разделе и имеющая приоритет 75.

Р и с. 1 4. 9 0. Окно S e t S u b s c r i p t i o n P r i o r i t y мастера Pull Subscription Wizard Рис. 14.91. Окно Start Required Services мастера Pull Subscription Wizard Часть III. Администрирование Следующее окно мастера Start Required Services (рис. 14.91) предоставляет поль зователю возможность запускать или останавливать службу SQLServerAgent. Ус танавливая флажок в самом левом столбце, вы тем самым предписываете запус тить службу SQLServerAgent после нажатия кнопки Finish в последнем окне мастера. В столбце Status указывается текущее состояние службы.

Если служба SQLServerAgent не сконфигурирована для автоматического запуска и была остановлена в момент создания публикации, то следующим окном мас тера является окно Configure SQL Server Agent (рис. 14.92). С его помощью можно будет предписать мастеру сконфигурировать службу SQLServerAgent для автоматического запуска при старте операционной системы. Для этого доста точно установить переключатель в верхнее положение. В ином случае необхо димо будет запускать службу SQLServerAgent вручную каждый раз, когда потре буется синхронизировать изменения.

Рис. 14.92. Окно Configure SQL Server Agent мастера Pull Subscription Wizard На этом работа с мастером создания подписки по требованию заканчивается.

Следующее окно будет последним. После нажатия кнопки Finish в этом окне мастер приступит к непосредственному созданию публикации на основе указан ных параметров.

Конфигурирование подписки В двух предыдущих разделах было рассмотрено создание подписок по требова нию и по запросу. В этом же разделе рассмотрим управление свойствами уже созданной подписки. Сразу необходимо отметить, что некоторые свойства под писки не могут быть изменены после ее создания.

Глава 14. Репликация данных Для начала рассмотрим управление принудительной подпиской. Для этого мож но использовать вкладку Subscriptions (рис. 14.93) окна свойств публикации.


При описании свойств публикации мы уже рассматривали эту вкладку. Однако тогда у нас не существовало еще ни одной подписки, поэтому продемонстриро вать управление свойствами подписки не было возможности, да и тема была несколько другой. В этом же разделе мы наверстаем упущенное.

Рис. 14.93. Вкладка Subscriptions окна свойств публикации Итак, у нас в таблице приведено две подписки, которые мы создали в предыду щих разделах. Как видно, для каждой из них указывается тип и приоритет. Что бы управлять свойствами подписки, необходимо выбрать ее имя в таблице Sub scriptions и нажать кнопку Properties. В ответ появится окно свойств подписки.

Рассмотрим сначала окно свойств подписки по требованию (Pull). Для подписки по требованию не допускается изменения никаких свойств. Однако корректнее сказать, что для подписки по требованию не допускается изменения свойств со стороны дистрибьютора. Ниже в этом разделе мы рассмотрим управление свой ствами подписки со стороны подписчика.

Откроем же теперь окно свойств принудительной подписки (рис. 14.94). Оно имеет две вкладки. Первая из них — General — весьма напоминает окно свойств подписки по требованию и также не допускает внесения никаких изменений в свойства подписки.

712 Часть III. Администрирова ние Рис. 14.94. Окно свойств принудительной подписки, вкладка General Рис. 14.95. Окно свойств принудительной подписки, вкладка Synchronization Глава 14. Репликация данных Обратимся же ко второй вкладке — Synchronization (рис. 14.95). Как видно, вкладка содержит переключатель, который позволяет для созданной подписки изменять место запуска агента Merge Agen и может быть установлен в следую щие положения:

П At the Distributor — на дистрибьюторе;

О At the Subscriber — на подписчике. При установке переключателя в это по ложение необходимо указать имя компьютера, на котором запущен SQL Server 2000-подписчик. С помощью кнопки Verify Agent можно проверить успешность запуска агента на указанном сервере.

На этом работа со свойствами принудительной подписки заканчивается. Однако, помимо рассмотренного окна свойств подписки по запросу, имеется еще и воз можность управления подпиской со стороны подписчика. Для этого необходимо на сервере-подписчике открыть папку Replications\Subscriptions (рис. 14.96) и вы брать в ней нужную подписку по запросу (значение Pull в столбце Туре).

Рис. 14.96. Папка Replications\Subscriptions Для открытия окна свойств подписки Pull Subscription Properties (рис. 14.97) нужно в ее контекстном меню выбрать команду Properties или просто дважды щелкнуть на имени подписки. Окно свойств имеет четыре вкладки.

714 Часть III. Администрирование Рис. 14.97. Окно свойств подписки по запросу, вкладка General Содержимое вкладки General практически ничем не отличается от содержимого окна свойств подписки, когда работа с ней осуществляется со стороны дист рибьютора. Внесение изменений не допускается, поэтому сразу перейдем к рас смотрению вкладки Synchronization (рис. 14.98).

Вкладка Synchronization служит для управления процессом синхронизации под писчика с дистрибьютором, а также местом запуска агента Merge Agent. В верх ней части окна имеется две кнопки — Agent Properties и View Conflicts. С помо щью первой из них можно открыть окно свойств агента Merge Agent. Точнее говоря, будет открыто окно свойств задания службы SQLServerAgent, с помо щью которого осуществляется запуск агента Merge Agent. Подробно принципы работы с этим окном были рассмотрена в разд. "Запуск агентов" ранее в этой главе.

Нажатие второй кнопки — View Conflicts — приводит к открытию окна Micro soft Replication Conflict Viewer. С его помощью можно просмотреть имеющиеся в публикации конфликты изменения. Также это окно помогает вручную решить имеющиеся конфликты.

Продолжим рассмотрение элементов управления, имеющихся на вкладке Syn chronization. Ниже двух описанных кнопок расположен флажок Enable synchroni zation using Windows Synchronization Manager. Устанавливая этот флажок, можно разрешить выполнение синхронизации подписчика с дистрибьютором средства ми менеджера синхронизации операционной системы, а не только средствами Enterprise Manager. По умолчанию флажок сброшен.

Глава 14. Репликация данных Рис. 14.98. Окно свойств подписки по запросу, вкладка Synchronization j ( Замечание Запустить менеджер синхронизации операционной системы можно из главного меню Programs (Программы), выбрав затем в группе Accessories команду Syncronize.

В центральной части вкладки расположен переключатель On-demand synchroniza tion, с помощью которого можно контролировать возможность разрешения кон фликтов обновления пользователями при выполнении ручной синхронизации:

• Resolve conflicts automatically. Разрешение конфликтов будет осуществляться автоматически независимо от пользователей.

О Resolve conflicts interactively (articles must support interactive resolution). В этом случае пользователи будут иметь возможность вручную решать конфликты изменения с помощью окна Microsoft Replication Conflict Viewer.

с Замечание Напомним, что возможность интерактивного разрешения конфликтов контролирует ся на уровне отдельной статьи. Таким образом, помимо ручного разрешения кон фликтов на уровне подписчика, необходимо позволить выполнение этой операции и на уровне конкретной статьи.

На вкладке Synchronization также имеется переключатель Merge Agent Location, с помощью которого контролируется место запуска агента Merge Agent:

• Run the agent at the Subscriber — агент будет запускаться на подписчике;

Часть III. Администрирование • Run the agent at the Distributor — агент будет запускаться на дистрибьюторе.

При этом в текстовом поле Network machine name of Distributor необходимо будет указать имя сервера-дистрибьютора.

На этом рассмотрение вкладки Synchronization можно закончить и переходить к сле дующей вкладке — Security (рис. 14.99). Она используется для конфигурирования контекста подсистемы безопасности, в котором будет работать подписка. Точнее, на этой вкладке указывается, какая учетная запись будет использоваться агентом Merge Agent при установлении соединения с дистрибьютором и издателем.

Рис. 14.99. Окно свойств подписки по запросу, вкладка Security Как видно из рисунка, вкладка разделена на две части — Distributor login и Pub lisher login, которые, соответственно, используются для конфигурирования свойств соединения с дистрибьютором и издателем. В распоряжении пользователя име ется переключатель, который может быть установлен в одно из перечисленных ниже положений:

• Impersonate the SQL Server Agent account on 'ServerName' (trusted connection).

При установке переключателя в это положение соединение будет осуществ ляться с использованием аутентификации Windows NT. При этом агент Merge Agent будет иметь те же права, что предоставлены учетной записи, ко торая применяется для запуска службы SQLServerAgent. При выборе этого варианта необходимо убедиться, что служба SQLServerAgent запускается под учетной записью пользователя домена.

Глава 14. Репликация данных П Use SQL Server Authentication. В этом случае соединение может быть уста новлено с использованием любой учетной записи SQL Server. Имя и пароль учетной записи должны быть указаны в соответствующих полях.

Рассмотренные положения переключателя являются общими для свойств уста новления соединения как с издателем, так и с дистрибьютором. Однако, для издателя также имеется положение Use the same login as for the Distributor. Уста новка переключателя в это положение предписывает использовать для установ ления соединения с издателем те же настройки, что и при установлении соеди нения с дистрибьютором.

Теперь же перейдем к последней вкладке — Snapshot File Location (рис. 14.100).

Она позволяет управлять получением файлов моментальных снимков.

Рис. 14.100. Окно свойств подписки по запросу, вкладка Snapshot File Location Ведущую роль на вкладке играет переключатель, определяющий тип источника, с которого необходимо получить файлы моментального снимка:

• Get the snapshot from the Publisher's normal snapshot folder. Файлы моменталь ного снимка будут получаться из стандартного каталога ReplData, располо женного на дистрибьюторе.

• Get the snapshot from the following folder. Можно указать произвольный ката лог, из которого и будут копироваться файлы моментального снимка. Собст венно каталог указывается в поле Folder. Подобный вариант позволяет ис пользовать динамические моментальные снимки, которые записываются не в стандартный каталог. Если необходимо получить динамический моменталь 718 Часть III. Администрирование ный снимок, то следует установить флажок This is a snapshot for a dynamically filtered subscription.

П Download the snapshot using FTP (File Transfer Protocol). В этом случае под писчик будет выкачивать файлы с сервера FTP. Предварительно файлы должны быть положены на сервер либо вручную, либо автоматически аген том Snapshot Agent при генерировании моментального снимка. Имя сервера FTP, каталога и номер порта получаются от дистрибьютора. Напомним, что эти параметры конфигурируются с помощью вкладки Snapshot Location окна свойств публикации (см. рис. 14.68).

В нижней части вкладки имеется поле Folder. В нем указывается каталог, кото рый будет служить для временного хранения выкачанных файлов моменталь ного снимка. Не рекомендуется указывать временный каталог, используемый операционной системой, т. к. файлы оттуда могут быть автоматически удалены.

Удаление подписки В предыдущих разделах были рассмотрены самые сложные операции работы с подписками — создание новой и конфигурирование существующей подписки, а также синхронизация изменений. Логическим завершением работы с подпиской является ее удаление. Эта операция не представляет ничего сложного и не тре бует особых знаний. Чтобы удалить подписку, достаточно найти ее в панели Enterprise Manager и в контекстном меню выбрать команду Delete.

При удалении подписки не происходит удаления реплицированных данных.

Удаление подписки представляет собой деактивизацию механизмов отображения на подписчике изменений, выполненных другими участниками репликации.

Полученные в процессе репликации данные могут продолжать использоваться и далее. Однако, если же реплицированные данные необходимо удалить, то эту операцию придется осуществлять вручную. Глава Мониторинг и аудит Как бы хорошо вы не настроили систему при установке, рано или поздно в ее работе появятся проблемы. Это связано не с ошибками при администрирова нии, а в большей степени с последствиями добавления в базы данных новой информации, создания новых объектов, написания неоптимизированных запро сов, использования новых приложений и т. д. Со временем эти проблемы могут привести к серьезным неприятностям в работе сервера и даже к его краху. По следнее случается достаточно редко, но все же вероятность остается. Чем боль ше сеть предприятия и чем больше объем обрабатываемой информации, тем выше вероятность возникновения проблем.

Одной из обязанностей администратора является контроль работы сервера. Ад министратор должен периодически измерять нагрузку, которая ложится на под системы сервера. Это позволит выявить проблемы на стадии их появления и предпринять необходимые меры для устранения их причин. В противном случае придется смириться с убытками, понесенными вашей компанией, и объяснять начальству, что, мол, техника износилась и пора бы ее заменить, а вашей вины здесь нет.

Мониторинг работы сервера может выполняться также для оптимизации работы пользователей. Обычно пользователям не разрешается работать с данными на прямую. Все алгоритмы обработки данных реализуются в виде хранимых проце дур. Такой подход позволяет также реализовать при обработке данных бизнес логику, специфичную для конкретной организации. Разработчик может реали зовать правила контроля достоверности данных, которые выполняются при по пытке пользователя изменить или удалить данные.

Однако не всегда процедуры пишутся наиболее оптимальным образом. Непра вильно написанная процедура может заметно снизить производительность выпол нения обработки данных. Если хранимая процедура слишком долго блокирует информацию, то это может снизить производительность работы других хранимых процедур. Проблема не так страшна, когда таких процедур одна-две. Однако если количество неоптимизированных процедур значительно, то проблема растет в геометрической прогрессии. Процедуры мешают друг другу, блокируя ресурсы и загружая систему. В этом случае ваши пользователи наверняка отметят, что систе ма работает нестабильно и часто выполнение запросов прерывается.

Мониторинг работы SQL Server 2000 позволяет найти хранимые процедуры, ко торые не лучшим образом используют системные ресурсы и снижают произво дительность системы в целом. Администратор может проанализировать каждый шаг процедуры в отдельности и определить, какую операцию необходимо опти 24 3*1207 ' 720 Часть III. Администрирование мизировать. Это лишь один из примеров оптимизации работы пользователей.

Можно легко продолжить этот список.

В описанном примере узким местом (bottlenecks) системы является неправильно написанная хранимая процедура. Однако неудовлетворительная производитель ность сервера может быть связана и с его аппаратной частью. Если пользователи жалуются на низкую производительность выполнения запросов, то прежде всего необходимо локализовать проблему. Будет обидно потратить полдня на поиск. неоптимизированной хранимой процедуры, а потом выяснить, что проблема связана с нехваткой оперативной памяти.

При выборе компьютера, который будет работать в качестве сервера баз данных предприятия, необходимо оценить объем нагрузки, который ожидается как на компьютер в целом, так и на каждую из подсистем в отдельности. Неудовлетво рительная работа одной подсистемы может отрицательно сказаться на произво дительности всего сервера. Если для реализации крупной системы обработки информации вы приобретаете компьютер с мощной дисковой системой, пред ставленной RAID массивом дисков SCSI, общим объемом 130 Гбайт, но объем оперативной памяти составляет всего 128 Мбайт, то вряд ли работа система бу дет удовлетворительной. Из-за нехватки оперативной памяти операционная сис тема будет активно использовать виртуальную память, что существенно снижает производительность выполнения запросов пользователей.

Приведенный пример является лишь верхушкой айсберга. Все аппаратные части сервера должны по производительности соответствовать друг другу. Медленный процессор может свести на нет производительность дисковой системы, но при использовании медленного винчестера процессор будет простаивать, ожидая завершения дисковых операций ввода/вывода. Если вы затрудняетесь оценить производительность аппаратных подсистем сервера, то можете приобрести гото вый сервер. Многие фирмы — производители компьютеров предлагают серверы, оптимизированные под выполнение определенных операций. В крайнем случае обратитесь к специалистам. Профессиональный подход к выбору конфигурации сервера избавит вас от множества проблем в будущем.

Из всего вышесказанного следует, что оптимизация работы сервера должна вы полняться в комплексе. Простейшим путем увеличения производительности явля ется простое наращивание аппаратных ресурсов сервера — добавление памяти, увеличение объема жестких дисков, установка более мощного или дополнитель ного процессора и т. д. Однако в некоторых случаях увеличения производительно сти можно добиться и другими способами. Например, вы можете разнести файлы базы данных, журнала транзакций и "тяжелые" индексы на разные жесткие диски.

Это позволит добиться значительного увеличения производительности при вы полнении запросов, активно использующих индексы и журнал транзакций.

Выбор инструмента мониторинга Мониторинг производительности системы может осуществляться с помощью различных инструментов. Как было сказано выше, мониторинг можно разделить на две категории:

Глава 15. Мониторинг и аудит [ 721_ О Мониторинг операционной системы и аппаратной части компьютера. В этом случае администратор получит количественную информацию о работе систе мы. Этот тип мониторинга операционной системы предполагает применение следующих инструментов:

• утилита Performance Monitor;

• утилита Task Manager;

• утилита Event Viewer;

• протокол Simple Network Management Protocol, SNMP.

П Мониторинг работы SQL Server 2000 и его подсистем. При использовании этого типа мониторинга вы сможете проанализировать работу отдельных за просов и хранимых процедур. Для получения качественной информации о работе SQL Server 2000 могут применяться следующие инструменты:

• утилита SQL Server Profiler;

• утилита Enterprise Manager;

• средства Transact-SQL.

Каждый из упомянутых инструментов мониторинга отличается своей специфи кой. Выбор конкретного инструмента, прежде всего, зависит от типа анализи руемых объектов. Например, если пользователи жалуются, что выполнение их запросов прерывается, и сервер часто выдает сообщение об ошибке 1205, то это говорит о том, что на сервере часто возникают мертвые блокировки (deadlocks).

Вы желаете решить эту проблему. Нетрудно догадаться, что увеличение произ водительности аппаратной части сервера не приведет к решению вопроса. Необ ходимо определить, какие запросы образуют мертвые блокировки и переписать их таким образом, чтобы этого больше не возникало.

Замечание Мертвые блокировки — это взаимное блокирование ресурсов разными процессами таким образом, что каждый из них ждет, пока другой процесс освободит ресурсы, необходимые для завершения транзакции. Так как ресурсы, требуемые каждому из процессов, заблокированы, то завершение операций невозможно. Процессы могут бесконечно ожидать разблокирования ресурсов. Мертвая блокировка может состо ять более чем из двух процессов. Со временем ситуация может только ухудшиться, когда пользователи запустят запросы, обращающиеся к блокированным ресурсам.

Следует решить, какой инструмент должен быть использован для поиска запро сов, приводящих к образованию мертвых блокировок. С помощью утилиты Performance Monitor, поставляемой в составе операционной системы, удастся лишь определить общее число мертвых блокировок, выполняемых на сервере, 'а также частоту их возникновения. |ЗГо есть вы будете иметь количественную ин формацию. Для получения качественной информации, с помощью которой можно определить, какие именназапросы вызывают образование мертвых бло кировок, должна быть использована утилита SQL Server Profiler.

24* 722 Часть III. Администрирование Утилита Performance Monitor Начнем рассмотрение методов мониторинга сервера с описания утилиты Per formance. Эта программа является стандартной утилитой операционной системы Windows 2000 и предназначена для сбора количественной информации о работе операционной системы и приложений, запущенных в ней. Кроме того, утилита Performance позволяет проводить мониторинг удаленных компьютеров. Это дает возможность централизованно контролировать работу множества серверов сети.

Администратору не нужно физически присутствовать при работе за анализируе мым компьютером. Конечно, платой за это является увеличение нагрузки на сеть. Необходимо выбрать частоту обновления информации таким образом, что бы мониторинг не мешал обычной работе пользователей.

(~ ) Замечание Утилита Performance в операционной системе Windows NT 4.0 имеет несколько иное название — Performance Monitor. Несмотря на значительные различия в интерфейсе возможности утилиты Performance для Windows 2000 практически те же, что и у ути литы Performance Monitor для Windows NT 4.0. При описании утилиты мы будем ис пользовать название Performance Monitor.



Pages:     | 1 |   ...   | 17 | 18 || 20 | 21 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.