В лекции 26 был дан обзор репликации в Microsoft SQL Server 2000, включая краткое описание репликации транзакций. В данной лекции приводится уже подробное описание этой темы. Здесь описывается, как действует этот метод репликации, когда его следует использовать, а также как его конфигурировать, как выполнять его мониторинг и как настраивать системы, участвующие в репликации транзакций.
Репликация транзакций, видимо, является наиболее распространенным методом репликации. Она позволяет достаточно быстро передавать подписчикам изменения после того, как они применены к издателям, и это происходит без особого увеличения нагрузки на издателей.
Введение в репликацию транзакций
Как следует из названия, репликация транзакций используется для репликации того, что происходит в транзакциях. При использовании этого метода репликации база данных подписчика создается первоначально с помощью моментального снимка (snapshot) – мы будем называть его просто снимком, – а последующие изменения, которые вносятся в базу данных издателя, реплицируются подписчику в соответствии с транзакциями. Все обновления, вставки и удаления, выполняемые в базе данных, распространяются именно таким образом.
Транзакции считываются из журнала транзакций агентом чтения журнала Log Reader Agent, который запускается на дистрибьюторе и подсоединяется к издателю. Эти транзакции обрабатываются и помещаются в дистрибутивную базу данных на дистрибьюторе. Позже агенты распространения (Distribution Agents) считывают эту информацию из дистрибутивной базы данных и применяют транзакции к базе данных подписчика.
Каждая база данных, которая использует репликацию транзакций, имеет собственного агента Log Reader Agent, который запускается на дистрибьюторе и следит за журналом транзакций этой базы данных на издателе. На каждую базу данных используется только один агент Log Reader Agent – независимо от количества публикаций, определенных по соответствующей базе данных.
Log Reader Agent запускается на дистрибьюторе в соответствии с расписанием, которое определяется при создании публикации. В зависимости от вашего выбора Log Reader Agent работает в соответствии с регулярным расписанием или непрерывно. При работе Log Reader Agent происходит следующая последовательность событий.
Log Reader Agent читает журнал транзакций системы с данной публикацией и создает список операторов INSERT, UPDATE, DELETE и других модификаций данных, которые были выбраны для репликации, включая удаления таблиц, изменения в определениях колонок и т.д.
Log Reader Agent обрабатывает данные из журнала транзакций и выполняет фильтрации, определенные по статьям. Сюда относятся все горизонтальные и вертикальные фильтрации.
Эти модификации объединяются в пакет и отправляются в дистрибутивную базу данных на дистрибьюторе. Внутри дистрибутивной базы данных имеется несколько таблиц, в которых отслеживаются изменения репликации и задачи. Выполняемые на издателе модификации, которые должны распространяться подписчикам, сохраняются в таблице с именем MSRepl_commands. Эта таблица содержит реальные команды репликации в сжатом формате. Таблица MSRepl_commands содержит по одной строке для каждой операции INSERT, UPDATE и DELETE по каждой определенной ранее статье. Если модификация, которая вносится в таблицу базы данных издателя, относится к нескольким статьям, то это изменение будет дублировано в дистрибутивной базе данных. Например, если таблица A содержится в трех статьях, то изменение в таблице A приведет к появлению трех строк в дистрибутивной базе данных.
После успешной передачи каждого пакета в дистрибутивную базу данных происходит фиксирование транзакций этого пакета. При отказе фиксирования в журнал ошибок агента записывается сообщение об ошибке.
После успешного фиксирования этих изменений в дистрибутивной базе данных Log Reader Agent помечает последнее изменение, включенное в последнюю операцию репликации, чтобы не было повторения этих изменений.
После того как транзакция прочитана из журнала транзакций и фиксирована в дистрибутивной базе данных, Log Reader Agent помечает те строки журнала транзакций, которые подходят для усечения (eligible to be truncated).
Для каждой модификации базы данных публикации создается хотя бы одна запись в дистрибутивной базе данных. В некоторых случаях модификация в базе данных публикации приводит к созданию нескольких записей в дистрибутивной базе данных. Вот эти случаи.
Вставка в таблицу приводит к вставке в дистрибутивную базу данных для каждой статьи, в которую входит данная таблица. Если таблица входит в две различные публикации, то она определена в двух отдельных статьях. Каждая из двух статей получит свою строку в дистрибутивной базе данных для каждой операции вставки, обновления и удаления, выполняемой в базе данных соответствующей публикации.
Для каждого обновления или удаления, влияющего на несколько строк, создается соответствующее количество строк в дистрибутивной базе данных. Для оператора SQL, который выполняет операцию обновления или удаления для нескольких строк, агент Log Reader Agent создает по отдельной команде в дистрибутивной базе данных для каждой из этих строк. Предложение WHERE в операторе SQL преобразуется в предложение WHERE, которое указывает строку в базе данных в соответствии со значение первичного ключа. Например, операция обновления, которая влияет на все строки в 10-строчной таблице, приведет к созданию 10 записей в дистрибутивной базе данных, для каждой из которых в предложении WHERE указывается значение первичного ключа.
Применение репликации
транзакций
Репликация транзакций может применяться, когда подписчикам требуется поддерживать информацию на уровне текущего состояния данных издателя. Репликацию транзакций можно сконфигурировать таким образом, чтобы обновление подписчика происходило вскоре после обновления издателя. Даже в непрерывном режиме работы агент Log Reader Agent вместо непрерывного чтения обращается к журналу транзакций через определенное количество секунд, чтобы снизить нагрузку на журнал транзакций издателя.
Репликацию транзакций можно сконфигурировать таким образом, чтобы подписчики тоже могли модифицировать базу данных. Это свойство придает репликации транзакций высокую степень гибкости и находит применение в ряде случаев.
Передача сообщений. Репликацию транзакций можно использовать для передачи сообщений между системами, когда важно следить за тем, что подписчик получил эти сообщения. Если происходит разъединение в сети, то данные будут переданы, как только соединение в сети будет восстановлено.
Поддержка текущего состояния информации в магазинах. Многие компании используют репликацию транзакций для передачи данных между главным офисом и магазинами розничной торговли. При каждом обновлении цен в главном офисе они также обновляются в системах розничной торговли.
Распределение нагрузки. Репликацию транзакций можно использовать для снятия части нагрузки с баз данных с помощью отчетных систем, которые могут обрабатывать длительные требующие интенсивного использования ресурсов запросы, освобождая тем самым главные серверы.
Существует много применений для репликации транзакций. В зависимости от конфигурации вашей системы и ваших приложений репликация транзакций может оказаться для вас очень полезным средством.
Конфигурирование системы
репликации транзакций
Конфигурирование репликации транзакций выполняется аналогично конфигурированию репликации моментального снимка. Сначала вы должны сконфигурировать публикацию и затем задать, чтобы она принудительно передавалась подписчику (push-подписка) или запрашивалась подписчиком (pull-подписка).
Примечание. Прежде чем конфигурировать любой тип репликации SQL Server, вы должны сначала сконфигурировать публикование и распространение. Инструкции см. в лекции 26.
Конфигурирование публикаций
Процесс создания публикации для репликации транзакций почти идентичен процессу создания публикации для репликации моментальных снимков. Для конфигурирования публикации транзакций выполните следующие шаги.
В окне Enterprise Manager щелкните на меню Tools. Далее укажите пункт Replication (Репликация) и выберите команду Create аnd Manage Publications (Создание и управление публикациями); или выберите пункт Wizards (Мастера), раскройте папку Replication в появившемся в диалоговом окне Select Wizard (Выбор мастера) и выберите Create Publication Wizard (Мастер создания публикации). При любом способе появится диалоговое окно Create and Manage Publications
(рис. 27.1). В этом диалоговом окне вы можете выбрать базу данных или таблицу, содержащую данные, которые вы хотите публиковать.Если публикации уже существуют, то в дополнение к кнопке Create Publication (Создать публикацию) будут доступны следующие кнопки:
(рис 27.1) Диалоговое окно Create and Manage Publications
Properties and Subscriptions (Свойства и подписки). Позволяет вам модифицировать свойства как публикаций, так и подписок.
Script Publication (Сценарий создания публикации). Позволяет вам создать сценарий, который можно использовать для создания других публикаций.
Delete Publication (Удалить публикацию). Позволяет вам удалить уже сконфигурированную публикацию.
Выберите базу данных, которую хотите использовать для данной публикации (на рис 27.1(рис 27.2) Начальное окно мастера Create Publication Wizard
Щелкните на кнопке Next, чтобы появилось окно Choose Publication Database (Выбор базы данных для публикации) (рис 27.3(рис 27.3) Окно Choose Publication Database (Выбор баз данных для публикаций)Примечание. Если для системы, выбранной вами на шаге 1, еще не определен дистрибьютор, то вы получите запрос выбора дистрибьютора в окне Select Distributor (Выбор дистрибьютора). Напомним, что издатель может иметь только одного дистрибьютора – независимо от количества публикаций. Если у вас уже определен дистрибьютор, то появится окно Choose Publication Database, как это описано выше.
Щелкните на кнопке Next, чтобы появилось окно Select Publication Type (Выбор типа публикации) (рис 27.4(рис 27.4) Окно Select Publication Type (Выбор типа публикации)В этом окне вы можете выбрать один из трех типов репликации. Будут представлены следующие варианты выбора:Snapshot publication (Публикация для репликации снимков). Создает публикацию для репликации снимка соответствующей статьи, который периодически копируется на подписчик. Такую публикацию можно создавать из любой таблицы.
Transactional publication (Публикация для репликации транзакций). Создает публикацию для репликации транзакций, в соответствии с которыми происходит обновление подписки изменениями, выполненными на издателе. Статьи могут создаваться только из таблиц с первичным ключом.
Merge publication (Публикация для репликации слиянием).Создает публикацию для репликации слиянием, которая позволяет выполнять двустороннюю репликацию между издателем и подписчиком. Статьи могут создаваться из любых таблиц.
Щелкните на кнопке выбора Transactional Publication и щелкните на кнопке Next, чтобы появилось окно Updatable Subscriptions (Модифицируемые подписки) (рис 27.5(рис 27.5) Окно Updatable Subscriptions (Модифицируемые подписки)В этом окне вы можете указывать, какие изменения, внесенные на подписчиках, реплицируются издателям. Ниже описаны флажки этого окна.Immediate updating (Немедленное обновление).Активизируются подписки с немедленным обновлением. Это означает, что агенты репликации будут использовать Microsoft Distributed Transaction Coordinator (MS DTC – координатор распределенных транзакций) для выполнения двухфазного фиксирования по транзакциям, которые модифицируют данные подписчиков, чтобы можно было вносить изменения на подписчике и немедленно реплицировать их на издателе. (О MS DTC и двухфазном фиксировании см. лекцию 25.) По умолчанию флажок подписок с немедленным обновлением не установлен.
Queued updating (Отложенное обновление). Активизирует подписки с отложенным обновлением. Это означает, что модификации, которые выполняются на подписчике, будут помещаться в очередь до того момента, когда их можно будет применить на издателе. Это позволяет подписчику модифицировать базу данных, но не требует двухфазного фиксирования с издателем.
Примечание. Репликация с немедленным обновлением полезна в тех случаях, когда идентичность систем является требованием, но учтите, что при двухфазном фиксировании возникает большая дополнительная нагрузка. Если у вас нет немедленного доступа к обеим системам, то соответствующая транзакция не может быть фиксирована. Репликацию с немедленным обновлением следует использовать только при абсолютной необходимости.
Щелкните на кнопке Next, чтобы появилось окно Transform Published Data (Преобразование опубликованных данных) (рис. 27.6). Преобразование данных является новой возможностью SQL Server. Для преобразования реплицированных данных используется набор Microsoft Data Transformation Services (DTS – службы преобразования данных). DTS позволяет выполнять следующие преобразования данных:преобразование значений или типов данных;
изменение регистра букв;
слияние данных;
разделение данных.
(рис 27.6) Окно Transform Published Data (Преобразование опубликованных данных)
Щелкните на кнопке Next, чтобы появилось окно Specify Subscriber Types (Указание типов подписчиков) (рис 27.7(рис 27.7) Окно Specify Subscriber Types (Указание типов подписчиков)
Щелкните на кнопке Next, чтобы появилось окно Specify Articles (Указание статей) (рис 27.8(рис 27.8) Окно Specify Articles (Указание статей)Примечание.Если на подписчике имеются хранимые процедуры, то репликацию можно сконфигурировать таким образом, чтобы реплицировать вызовы этих хранимых процедур, а не результаты вызовов хранимых процедур.
Щелкните на кнопке Next. На этом этапе SQL Server проверяет данную публикацию, и если он найдет ошибки, то вы увидите окно (рис 27.9(рис 27.9) Окно Article Issues (Вопросы по статьям)
После завершения анализа данной публикации (и после щелчка на кнопке OK для возврата в окно мастера, если появилось информационное диалоговое окно) щелкните на кнопке Next, чтобы появилось окно Select Publication Name and Description (Выбор имени и описания публикации) (рис 27.10(рис 27.10) Окно Select Publication Name аnd Description (Выбор имени и описания публикации)
Щелкните на кнопке Next, чтобы появилось окно Customize the Properties of the Publication (Настройка свойств данной публикации) (рис 27.11(рис 27.11) Окно Customize the Properties of the Publication (Настройка свойств данной публикации)
Щелкните на кнопке Next, чтобы появилось окно Filter Data (Фильтрация данных) (рис 27.12(рис 27.12) Окно Filter Data (Фильтрация данных)
Появится окно Filter Table Columns (Фильтрация колонок таблицы) (рис 27.13(рис 27.13) Окно Filter Table Columns (Фильтрация колонок таблицы)Примечание.Колонки с первичными ключами нельзя включить в фильтрацию, поскольку колонки с первичными ключами используются в репликации транзакций, как это описано выше в этой лекции.
Щелкните на кнопке Next, чтобы появилось окно Filter Table Rows (Фильтрация строк таблицы) (рис 27.14(рис 27.14) Окно Filter Table Rows (Фильтрация строк таблицы)
Появится диалоговое окно Specify Filter (Задать фильтр) (рис. 27.15). В этом диалоговом окне вы можете добавлять к SQL-оператору предложение (рис 27.15) Диалоговое окно Specify Filter (Задать фильтр)
Щелкните на кнопке Next, чтобы появилось окно Allow Anonymous Subscriptions (Разрешить доступ анонимным подписчикам) (рис 27.16(рис 27.16) Окно Allow Anonymous Subscriptions (Разрешить доступ анонимным подписчикам)
Щелкните на кнопке Next, чтобы появилось окно Set Snapshot Agent Schedule (Задать расписание для агента снимков Snapshot Agent). (Об использовании этого окна см. шаги 15 и 16 подраздела "Конфигурирование репликации моментальных снимков" лекции 26.) Поскольку в репликации транзакций снимок используется только для первоначального создания базы данных подписчика, то вам, видимо, не нужно задавать регулярное расписание для создания снимка; вместо этого вы можете создать снимок вручную.
После того, как вы зададите расписание, щелкните на кнопке Next, чтобы появилось окно мастера Completing the Create Publication Wizard (Завершение работы мастера создания публикации), просмотрите сводку по данной публикации и щелкните на кнопке Finish (Готово). Когда создание вашей публикации будет завершено, появится соответствующее информационное диалоговое окно.
Конфигурирование Log Reader Agent
После создания публикации вам, возможно, потребуется модифицировать поведение агента чтения журнала Log Reader Agent. Например, вы можете задать, как происходит вызов Log Reader Agent, выбрав режим, в котором он будет работать. В непрерывном режиме (это режим по умолчанию) запуск Log Reader Agent происходит при запуске SQL Server Agent. Затем он подсоединяется к журналу транзакций на издателе и выполняет непрерывное чтение этого журнала. В режиме расписания Log Reader Agent запускается в соответствии с заданным вами расписанием и переходит в неактивное состояние после того, как прочитает все реплицируемые транзакции из журнала транзакций. Изменяя режим и другие свойства, вы можете повышать производительность и снижать объем нагрузки на издатель. Чтобы сконфигурировать Log Reader Agent, выполните следующие шаги.
В окне Enterprise Manager раскройте сервер, раскройте папку Replication Monitor, раскройте папку Agents и затем щелкните на папке Log Reader Agents.
В правой панели Enterprise Manager щелкните правой кнопкой мыши на публикации. Появится контекстное меню (рис 27.17(рис 27.17) Контекстное меню для публикации
Выберите пункт Agent Properties (Свойства агента). Появится окно свойств данного агента Log Reader Agent (рис. 27.18).
Щелкните на вкладке Steps (Шаги) (рис 27.19(рис 27.19) Окно свойств Log Reader Agent(рис 27.18) Вкладка Steps (Шаги) окна свойств Log Reader Agent
Run agent (Запуск агента).Запуск данного агента в соответствии с заданным расписанием. При работе в непрерывном режиме этот агент работает, пока не будет отключена система.
Detect nonlogged agent shutdown (Обнаружено незарегистрированное отключение агента). В таблицу журнала работы агента Log Reader Agent помещается сообщение в случае отключения агента.
Выделите шаг Run agent и щелкните на кнопке Edit (Редактировать), чтобы появилось диалоговое окно Edit Job Step (Редактирование шага) (рис. 27.20). В этом диалоговом окне вы можете конфигурировать способ вызова Log Reader Agent.Для агента Log Reader Agent можно сконфигурировать много параметров. Параметры по умолчанию этого агента можно модифицировать в окне Command (Команда) диалогового окна Edit Job Step и в диалоговом окне Replication Agent Profile Details (Детали профиля агента репликации) (рис. 27.22). Здесь описаны два параметра, которые вы можете модифицировать в диалоговом окне Edit Job Step.
(рис 27.20) Вкладка General диалогового окна Edit Job Step (Редактирование шага)
DistributorSecurityMode (Режим безопасности дистрибьютора).Указывает, какой режим аутентификации использует Log Reader Agent: SQL Server или Microsoft Windows 2000.
Кроме того, вы можете задать в диалоговом окне Edit Job Step другие параметры, такие как AsynchLogging, Buffers, DefinitionFile, информацию о дистрибьюторе и подписчиках и MessageInterval.
Закончив модифицирование свойств Log Reader Agent, щелкните на кнопке OK, чтобы сохранить ваши изменения.
Вы можете модифицировать другие параметры в профиле Log Reader Agent. Чтобы модифицировать профиль, выполните следующие шаги.
В правой панели Enterprise Manager щелкните правой кнопкой мыши на Log Reader Agent и выберите из появившегося контекстного меню пункт Agent Profiles (Профили агента). Появится диалоговое окно Log Reader Agent Profiles(рис. 27.21).
Щелкните на кнопке New Profile (Создать профиль), чтобы создать новый профиль. Текущий профиль нельзя модифицировать. В результате появится диалоговое окно Replication Agent Profile Details (Детали профиля агента репликации) (рис. 27.22).
В этом диалоговом окне вы можете модифицировать следующие параметры:HistoryVerboseLevel. Указывает, сколько информации будет протоколироваться в журнале. Обычно хватает принятого по умолчанию уровня, если только у вас не возникают проблемы.
LoginTimeout. Указывает допустимое время ожидания в секундах для Log Reader Agent.
PollingInterval. Указывает, насколько часто опрашивается журнал транзакций на издателе (для получения новых транзакций).
QueryTimeout.Указывает допустимое время ожидания в секундах для запроса.
ReadBatchSize.Указывает количество транзакций, которое считывается из журнала транзакций в одном пакете.
(рис 27.22) Диалоговое окно Log Reader Agent Profiles (рис 27.21) Диалоговое окно Replication Agent Profile Details (Детали профиля агента репликации)Примечание. Как уже говорилось, если Log Reader Agent используется в режиме расписания, а не в непрерывном режиме, то он вызывается агентом SQL Server Agent и выполняет чтение из журнала транзакций всех транзакций, которые были помечены для репликации. Log Reader Agent считывает из журнала транзакций определенное количество транзакций или команд, указанное параметром ReadBatchSize, и выполняет их вставку в дистрибутивную базу данных. После считывания всех транзакций, помеченных для репликации, Log Reader Agent переходит в неактивное состояние, пока не наступит момент следующего запуска в соответствии с расписанием.
Конфигурирование pull-подписок
Управление и конфигурирование pull-подписок осуществляется со стороны подписчика. Тем самым вы должны конфигурировать pull-подписку с помощью Enterprise Manager в системе подписчика. Чтобы сконфигурировать pull-подписку, выполните следующие шаги.
В окне Enterprise Manager щелкните на меню Tools. Далее укажите пункт Replication, выберите пункт Pull Subscription To (Pull-подписка) и затем щелкните на Pull New Subscription (Новая pull-подписка) в появившемся диалоговом окне Pull Subscription To; или выберите из меню Tools пункт Wizards, раскройте папку Replication в появившемся диалоговом окне Select Wizard, затем выберите Create Pull Subscription Wizard (Мастер создания pull-подписки) и щелкните на кнопке OK. При обоих методах появится начальное окно мастера Pull Subscription Wizard (рис 27.23(рис 27.23) Начальное окно Pull Subscription Wizard
Щелкните на кнопке Next, чтобы появилось окно Look for Publications (Поиск публикаций) (рис 27.24(рис 27.24) Окно Look for Publications (Поиск публикаций)
Щелкните на кнопке Next, чтобы появилось окно Choose Publication (Выбор публикации) (рис 27.25(рис 27.25) Окно Choose Publication (Выбор публикации)
Щелкните на кнопке Next, чтобы появилось окно Specify Synchronization Agent Login (Задать login-запись для агента синхронизации) (рис. 27.26). В этом окне вы можете задать login-запись и пароль для дистрибьютора.
Щелкните на кнопке Next, чтобы появилось окно Choose Destination Database (Выбор целевой базы данных) (рис 27.27
(рис 27.27) Окно Specify Synchronization Agent Login (Задать login-запись для агента синхронизации)(рис 27.26) Окно Choose Destination Database (Выбор целевой базы данных)
Щелкните на кнопке Next, чтобы появилось окно Initialize Subscription (Инициализация подписки) (рис. 27.28). Щелкните на кнопке выбора Yes, чтобы инициализировать схему базы данных и данные у подписчика. Если у вас уже есть ранее созданная схема, щелкните на кнопке выбора No.
Щелкните на кнопке Next, чтобы появилось окно Snapshot Delivery (Доставка снимка) (рис. 27.29). В этом окне вы можете указать папку для снимка, отличную от принятой по умолчанию папки. Если вы не хотите изменять папку для снимка, используйте вариант по умолчанию (первая кнопка выбора).
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Schedule (Задать расписание для агента распространения) (рис 27.30
(рис 27.29) Окно Initialize Subscription (Инициализация подписки)(рис 27.28) Окно Snapshot Delivery (Доставка снимка)
(рис 27.30) Окно Set Distribution Agent Schedule (Задать расписание для агента распространения)Принимая решение о том, как работать с обновлениями в вашей системе, помните, что более частые запуски агента Distribution Agent приводят к увеличению нагрузки и на дистрибьюторе, и на подписчике. Запускайте этот агент, сколько вам требуется, но не допускайте излишнего использования.
Чтобы изменить расписание для агента Distribution Agent, щелкните на кнопке Change и модифицируйте расписание в появившемся диалоговом окне Edit Recurring Job Schedule (Редактировать расписание повторяющихся заданий).
Примечание.Если у вас выбрано преобразование данных публикации, то появится окно Specify DTS Package (Задать пакет DTS). Для продолжения работы у вас уже должен быть создан пакет DTS. Если у вас еще нет такого пакета, создайте его и затем снова запустите мастер. В данном примере мы не задаем преобразование данных.
Щелкните на кнопке Next, чтобы появилось окно Start Required Services (Запуск требуемых служб) (рис 27.31(рис 27.31) Окно Start Required Services (Запуск требуемых служб)
Щелкните на кнопке Next, чтобы появилось окно Completing the Pull Subscription Wizard (Завершение работы мастера pull-подписки) (рис. 27.32). Щелкните на кнопке Finish, чтобы завершить задание параметров подписчика.
Теперь статьи будут реплицироваться на подписчик и будут регулярно обновляться в соответствии с заданным вами расписанием. Возможно, что прежде чем можно будет начать репликацию, вам потребуется проверить расписание, в соответствии с которым будут запускаться агенты публикации. Агент Snapshot Agent запускается по своему собственному расписанию, и если вы не сконфигурировали его для немедленного распространения снимка на дистрибьютор, то для поступления данных на дистрибьютор может потребоваться некоторое время. Несмотря на то, что репликация действует, реальные данные не поступят подписчику, пока не выполнит свою работу Snapshot Agent.
(рис 27.32) Окно Completing the Pull Subscription Wizard
Конфигурирование push-подписок
Push-подписка (принудительная подписка) инициируется на издателе. Push-подписка конфигурируется с помощью мастера Push Subscription Wizard. При использовании push-подписки расписание репликаций определяется на дистрибьюторе. Для запуска мастера Push Subscription Wizard выполните следующие шаги:
Вызовите Push Subscription Wizard, используя один из двух методов. Для использования первого метода укажите пункт Replication в меню Tools окна Enterprise Manager и затем выберите пункт Push Subscription to Others (Push-подписка для других). Появится диалоговое окно Create and Manage Publications (Создание и управление публикациями) (рис 27.33Выделите публикацию в списке Databases and Publications (Базы данных и публикации) и затем щелкните на кнопке Push New Subscription (Создать push-подписку). Чтобы использовать второй метод, выберите из меню Tools пункт Wizards, раскройте папку Replication в появившемся диалоговом окне Select Wizards, выберите Create Push Subscription Wizard и щелкните на кнопке ОК. Выделите публикацию в появившемся диалоговом окне Create and Manage Publications и затем щелкните на кнопке Push New Subscription. Появится начальное окно мастера Push Subscription Wizard (рис 27.34(рис 27.34) Публикация, выбранная в диалоговом окне Create and Manage Publications(рис 27.33) Начальное окно мастера Push Subscription Wizard
Щелкните на кнопке Next, чтобы появилось окно Choose Subscribers (Выбор подписчиков) (рис 27.35(рис 27.35) Окно Choose Subscribers (Выбор подписчиков)
Щелкните на кнопке Next, чтобы появилось окно Choose Destination Database (рис 27.36(рис 27.36) Окно Choose Destination Database
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Location (Задать местоположение для агента распространения) (рис 27.37(рис 27.37) Окно Set Distribution Agent Location (Задать местоположение для агента распространения)
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Schedule (рис 27.38(рис 27.38) Окно Set Distribution Agent Schedule
Щелкните на кнопке Next, чтобы появилось окно Initialize Subscription (рис 27.39(рис 27.39) Окно Initialize Subscription В этом окне вы указываете, нужно ли инициализировать данную подписку. По умолчанию выбран вариант инициализации схемы и набора данных на подписчике. В этом окне вы можете также запустить Snapshot Agent, если он еще не запущен. Имеет смысл запускать Snapshot Agent, когда вы инициализируете снимок; в противном случае вам придется запускать этот агент вручную. После того как снимок инициализирован и начинается репликация, вам не нужно использовать снимок, пока не потребуется создать новую подписку. Каждый раз, как вы создаете подписку, создавайте новый снимок, и вам больше не нужно создавать снимки в соответствии с каким-либо расписанием, если только вам не потребуется ресинхронизация базы данных подписчика с использованием снимков.
Щелкните на кнопке Next, чтобы появилось окно Start Required Services (рис 27.40(рис 27.40) Окно Start Required Services
Щелкните на кнопке Next, чтобы появилось окно Completing the Push Subscription Wizard (Завершение работы мастера push-подписки) (рис 27.41(рис 27.41) Окно Comple-ting the Push Subscription Wizard (Завершение работы мастера push-подписки)
Дополнительная информация.Обратитесь к разделу "Управление репликацией" лекции 26 для получения информации по управлению и устранению проблем репликации, мониторингу и управлению агентами репликации, отключению репликации, а также удалению подписок, распространения и публикования.
Конфигурирование, мониторинг
и настройка дистрибьютора
для репликации транзакций
В этом разделе вы узнаете, как осуществлять конфигурирование, мониторинг и настройку дистрибьютора для репликации транзакций Как уже говорилось в предыдущей лекции, дистрибьютор – это сервер, содержащий базу данных SQL Server, которая называется дистрибутивной базой данных и используется как хранилище данных репликации. Эти данные хранятся в базе данных SQL Server, обеспечивая ряд преимуществ, включая следующие:
Высокая производительность. SQL Server обеспечивает высокую производительность, которая требуется дистрибьютору для получения, хранения и распространения данных.
Надежность. Поскольку SQL Server поддерживает высокий уровень восстанавливаемости, то база данных SQL Server идеально подходит для данных репликации. Используя журнал транзакций, SQL Server может выполнять восстановление после аварий системы без потери каких-либо данных.
Простота использования. Поскольку процесс репликации SQL Server непосредственно взаимодействует с дистрибьютором через протоколы передачи данных, это позволяет легко устанавливать и конфигурировать дистрибьютор.
Конфигурирование дистрибьютора
В зависимости от того, как часто вносятся модификации в вашу базу данных, интенсивность операций на дистрибьюторе может оказаться довольно высокой. Поскольку дистрибьютор использует базу данных SQL Server, все модификации, выполняемые на дистрибьюторе, должны протоколироваться в журнале транзакций. Вам следует конфигурировать дистрибутивную базу данных и этот журнал достаточно большими, чтобы можно было выполнять необходимую работу, и достаточно быстрыми, чтобы выполнять эту работу эффективно. Хотя принятая по умолчанию конфигурация распространения подходит для небольших систем репликации, она не соответствует многим системам, поскольку мастера репликации SQL Server не размещают журнал транзакций и файлы данных SQL Server оптимальным образом. Они обычно размещаются на принятом по умолчанию томе SQL Server, причем журнал транзакций и файлы базы данных оказываются на одном томе.
Конфигурируя должным образом дистрибутивную базу данных, вы можете избежать дорогостоящих проблем производительности. Вот некоторые рекомендации по конфигурированию дистрибутивной базы данных.
Используйте RAID-контроллер для системы с дистрибутивной базой данных. Использование аппаратного RAID-контроллера более эффективно, чем использование программных RAID.
Конфигурируйте журнал транзакций дистрибутивной базы данных на томе RAID 1. Журнал транзакций должен быть изолирован, чтобы иметь более высокую производительность при последовательных операциях ввода-вывода.
Конфигурируйте журнал транзакций достаточно большим, чтобы не возникала необходимость частого резервного копирования журнала транзакций. В зависимости от ваших потребностей у вас должна быть возможность обходиться всего лишь одним резервным копированием журнала транзакций в сутки (предпочтительно вечером).
Конфигурируйте дистрибутивную базу данных на томе RAID 1 или RAID 10. RAID 5 не подходит в связи с большим количеством операций записи в дистрибутивную базу данных.
Конфигурируйте дистрибутивную базу данных достаточно большой, чтобы у нее был запас для дополнительных данных репликации. В случае отказа сервера подписчика в этой базе данных могут накопиться данные репликации за несколько дней.
Выполняйте настройку базы данных репликации, как и любой другой базы данных SQL Server.
Конфигурирование дистрибьютора с помощью Enterprise Manager
Для конфигурирования дистрибутивной базы данных, как это показано в предыдущем списке, вам нужно задать, где находится эта база данных. Чтобы сделать это с помощью Enterprise Manager, сначала вызовите мастер Configure Publishing and Distribution Wizard. Используйте этот мастер, чтобы задать публикование и распространение, указывая в окне Customize the Configuration (Настройка конфигурации), что вы хотите настроить параметры распространения (щелкнув на кнопке Yes). Это позволяет вам задать местоположение дистрибутивной базы данных вручную. (Это также позволяет вам выбирать имя для базы данных, активизировать публикование и создавать как публикации, так и подписчиков.)
К сожалению, используя этот мастер, вы не можете задавать размер дистрибутивной базы данных. Вы можете увеличить размер дистрибутивной базы данных, вызвав окно свойств этой базы данных в Enterprise Manager и изменив размер базы данных или файлов журнала транзакций. Если вы хотите одновременно задать местоположение базы данных и ее размер, то вы можете использовать хранимую процедуру sp_adddistributiondb.
Конфигурирование дистрибьютора с помощью sp_adddistributiondb
С помощью системной хранимой процедуры sp_adddistributiondb вы можете использовать сценарий создания дистрибутивной базы данных. Это полезно, когда вы хотите задать размер и местоположение этой базы данных и ее журнала транзакций. И написав сценарий, с помощью которого создается дистрибутивная база данных, вы можете использовать его для различных систем или для повторного создания дистрибутивной базы данных в случае реконфигурирования системы.
Примечание.Прежде чем создавать дистрибутивную базу данных, вы должны активизировать дистрибьютор. Это можно сделать с помощью хранимой процедуры sp_adddistributor, после которой указывается имя системы дистрибьютора.
Синтаксис хранимой процедуры sp_adddistributiondb приводится в SQL Server Books Online. Ниже показан пример использования этой хранимой процедуры:
sp_adddistributor Dash
Следующий оператор SQL инициализирует систему с именем Dash как дистрибьютора.
sp_adddistributiondb @database=dist,
@data_folder=’C:\mssql2000\data’,
@data_file=’dist.mdf’,
@data_file_size=10,
@log_folder=’C:\mssql2000\data’,
@log_file=’dist.ldf’,
@log_file_size=2,
@min_distretention=0,
@max_distretention=72,
@history_retention=96,
@security_mode=0,
@login=’sa’,
@password=’’,
@createmode=0
Мониторинг дистрибьютора
Мониторинг дистрибьютора осуществляется с помощью монитора производительности Microsoft Windows 2000 Performance Monitor (perfmon). В этом мониторе имеется ряд объектов, которые добавляются при использовании репликации SQL Server. Это следующие объекты:
SQLServer:Replication Agents. Указывает количество работающих агентов репликации каждого типа.
SQLServer:Replication Dist. Предоставляет информацию о задержке при распространении.
SQLServer:Replication Logreader. Предоставляет данные об активности и задержке агента Log Reader Agent
SQLServer:Replication Merge. Предоставляет данные о частоте операций слияния
SQLServer:Replication Snapshot. Предоставляет информацию о производительности репликации снимков.
Используя Performance Monitor для мониторинга этих значений, вы можете иногда определять наличие проблем производительности на дистрибьюторе. Данные perfmon дают массу полезной информации, но она не всегда идентифицирует проблемы. В случае мониторинга дистрибьютора нас больше всего интересует объект SQLServer:Replication Dist. Этот объект предоставляет следующие счетчики:
Dist:Delivered Cmds/sec.Следит за количеством команд в секунду, переданных подписчику. Это дает вам хорошее представление об интенсивности операций на данном подписчике.
Dist:Delivered Trans/sec. Следит за количеством транзакций в секунду, переданных подписчику. Этот счетчик также дает вам хорошее представление об интенсивности операций на данном подписчике.
Dist:Delivery Latency. Следит за количеством времени, которое требуется для применения транзакций к подписчику после того, как они были доставлены на дистрибьютор. Это может дать вам некоторое представление о том, насколько перегружен дистрибьютор. (backed up).
Хотя эти счетчики являются в некотором смысле индикаторами того, как работает процесс распространения в целом, они недостаточно полезны, когда вы определяете, нужна ли вам настройка дистрибьютора, поскольку наиболее важным аспектом настройки дистрибьютора является настройка базы данных SQL Server. Вам следует на самом деле следить в основном за следующими проблемами:
Высокий процент использования ЦП. Не слишком ли высока интенсивность использования одного или нескольких ЦП в течение длительных периодов (больше 75 процентов от их мощности)?
Узкие места подсистемы ввода-вывода. Не слишком ли высока интенсивность использования ввода-вывода? Следите за количеством операций ввода-вывода в секунду и длительностью одной операции ввода-вывода.
Время отклика.Не слишком ли велики значения времени отклика в SQL Server?
Настройка дистрибьютора
Как уже говорилось выше, дистрибьютор – это сервер, содержащий дистрибутивную базу данных, и эта база данных должна быть настроена таким же образом, как и любая другая база данных SQL Server. Вы можете повысить производительность дистрибьютора путем выбора состава системы, хотя, как вы знаете из лекции 6, в некоторых случаях это сложная задача. Дистрибьютор должен обладать достаточной мощностью, чтобы выполнять дополнительную работу. Дистрибьютор является "посредником" между издателями и подписчиками, и его следует сконфигурировать так, чтобы он не был узким местом. Ниже приводятся некоторые советы по конфигурированию и настройке дистрибьютора:
Настройка подсистемы ввода-вывода. Обеспечьте, чтобы дистрибьютор, как и любая другая система SQL Server, имел достаточную мощность системы ввода-вывода.
Используйте многопроцессорную систему.Мощность ЦП обычно не является проблемой, поскольку в большинстве случаев операции, выполняемые на дистрибьюторе, не требуют интенсивного использования ЦП. Однако вам следует использовать хотя бы два ЦП, чтобы можно было выполнять параллельные операции.
Настраивайте операционную систему. Конфигурируйте службу Server , чтобы получать максимальную производительность для сетевых приложений. Это приведет к конфигурированию системы памяти в пользу приложений по сравнению с файловыми службами. Для этого нужно использовать значок Network в панели управления. Кроме того, удалите все службы, которые не будут использоваться, такие как IIS и FTP.
Следите за дистрибьютором во время репликации моментальных снимков.При репликации снимков, которая используется, когда происходит копирование начального снимка в репликации транзакций и репликации слиянием, одновременно выполняется большое число операций ввода-вывода. Поскольку на дистрибьютор записывается такое количество данных, может возникнуть перегрузка подсистемы ввода-вывода дистрибьютора. В этой ситуации возрастает время, которое требуется для применения снимка. Поэтому вам нужно следить за дистрибьютором во время передачи снимка.
Настраивайте SQL Server. Используя методы и рекомендации, полученные в этой книге, выполняйте настройку системы SQL Server.
Настройка репликации транзакций
В этом разделе вы узнаете, как конфигурировать и настраивать систему репликации транзакций для получения высокой производительности. Раздел начинается с обзора атрибутов репликации транзакций, после чего даются рекомендации по конфигурированию, мониторингу и настройке.
Атрибуты репликации транзакций
Репликация транзакций начинается с копирования снимка на дистрибьютор и затем на подписчик. После копирования снимка на дистрибьюторе начинает работать агент Log Reader Agent, который выполняет чтение журнала транзакций издателя в непрерывном режиме или в соответствии с регулярным расписанием. Периодичность чтения журнала транзакций определяется тем, как вы сконфигурировали Log Reader Agent. (Нагрузка, налагаемая на издатель при чтении журнала транзакций, – это единственная нагрузка на издатель, относящаяся к репликации.)
Транзакции, которые считываются агентом Log Reader Agent из журнала транзакций на издателе, помещаются в дистрибутивную базу данных. Затем эти транзакции передаются подписчикам. Имеются следующие факторы, которые могут ограничить производительность репликации транзакций.
Производительность подсистемы ввода-вывода для журнала транзакций на издателе. Чтение журнала транзакций выполняется для того, чтобы определить, какие изменения были выполнены в базе данных. А поскольку во время репликации происходит не только чтение, но и запись в журнал транзакций, это может препятствовать последовательному доступу к журналу транзакций. При этом может возникать эффект узкого места. Чтобы избежать этого, журнал должен быть тщательно сконфигурирован.
Производительность дистрибьютора.В зависимости от количества операций репликации и числа издателей, которые используют дистрибьютор, на этом дистрибьюторе могут возникать проблемы производительности. Ранее в этой лекции вы узнали, как конфигурировать и настраивать дистрибьютор.
Производительность подписчика. В зависимости от выполняемых на подписчике операций на нем могут возникать проблемы производительности. Чтобы воспрепятствовать этим проблемам, выполните стандартную настройку в базе данных SQL Server этого подписчика.
Как видите, имеется ряд факторов, которые могут ограничивать производительность. Путем правильного выбора состава и конфигурирования используемых систем вы можете снизить влияние этих факторов и обеспечить высокую производительность.
Конфигурирование репликации транзакций
Конфигурирование системы репликации транзакций состоит из нескольких задач. Как уже говорилось в предыдущем разделе, вы должны правильно сконфигурировать журнал транзакций на издателе, поскольку он испытывает дополнительную нагрузку при использовании репликации. В этом разделе мы рассмотрим несколько других рекомендаций, о которых вы должны помнить при конфигурировании вашей системы репликации транзакций. Ниже приводится список этих рекомендаций.
Сконфигурируйте достаточную мощность подсистем ввода-вывода на всех системах, участвующих в репликации в соответствии с общими рекомендациями по конфигурированию мощности подсистем ввода-вывода. (Возможно, вам потребуется сконфигурировать более высокую мощность ввода-вывода для журнала транзакций на издателе, чем это обычно требуется.)
Увеличьте размер пакета фиксирования на дистрибьюторе.
Настройте Log Reader Agent.
Конфигурирование достаточной мощности
ввода-вывода
Конфигурируя достаточную мощность подсистем ввода-вывода, вы можете повысить производительность всего процесса репликации. Как и в любой системе SQL Server, журнал транзакций системы, участвующей в репликации, должен находиться для защиты данных на своем томе RAID 1. Файлы данных должны находиться на одном или нескольких томах RAID 10 или RAID 5. В отличие от репликации снимков для репликации транзакций требуются лишь небольшие изменения в стандартных конфигурациях ввода-вывода. Эти требования описаны в данном разделе.
Конфигурирование подсистемы ввода-вывода на издателе. В общем случае при конфигурировании подсистемы ввода-вывода издателя вы должны следовать стандартным рекомендациям по конфигурированию SQL Server, описанным на протяжении этой книги. Однако для журнала транзакций издателя может потребоваться более высокая мощность ввода-вывода, чем это обычно требуется. Обычно журнал транзакций следует конфигурировать на томе RAID 1. При необходимости (это зависит от степени занятости вашей системы) вам следует сконфигурировать его на томе RAID 10, используя большее количество дисков. RAID 5 не подходит для журнала транзакций.
Конфигурирование подсистемы ввода-вывода на дистрибьюторе. Дистрибьютор следует конфигурировать таким образом, чтобы дистрибутивная база данных имела собственный журнал транзакций на выделенном томе RAID 1. Это позволит получить максимальную производительность для журнала дистрибутивной базы данных, что повысит производительность самого дистрибьютора.
Конфигурирование подсистемы ввода-вывода на подписчике. При репликации транзакций не требуется какого-либо особого конфигурирования ввода-вывода на подписчике. Просто следуйте общим рекомендациям по определению состава и конфигурации систем, описанным на протяжении этой книги.
Конфигурирование размера пакета фиксирования на дистрибьюторе. Размер пакета фиксирования на дистрибьюторе определяет, сколько транзакций репликации фиксируются на дистрибьюторе в одном пакете. Если увеличить размер пакета, то за один раз будет фиксироваться больше строк, что увеличит время, в течение которого таблицы дистрибутивной базы данных будут недоступны для других процессов. (Во время модификации базы данных происходит захват блокировок по таблицам.) Если снизить размер пакета, то за один раз будет фиксироваться меньше строк, что дает возможность более быстрого доступа других процессов к дистрибутивной базе данных.
При большом количестве операций, применяемых к дистрибутивной базе данных другими источниками (то есть издателем и несколькими подписчиками) попытайтесь снизить размер пакета. Если Log Reader Agent запускается в соответствии с периодическим расписанием и получает много транзакций для единовременной вставки в дистрибутивную базу данных, то вам, видимо, поможет увеличение размера пакета. Может быть, вам не потребуется изменять размер пакета; но если вы будете делать это, сравните отличия в производительности при увеличении и уменьшении этого размера, чтобы определить, какой вариант лучше.
Вы можете конфигурировать размер пакета фиксирования в Enterprise Manager, вызвав окно свойств агента распространения Distribution Agent. (См. раздел "Мониторинг и управление агентами репликации" в лекции 26.)
Настройка Log Reader Agent
Как уже говорилось, операции чтения журнала транзакций издателя, выполняемые агентом Log Reader Agent, могут приводить к прерыванию операций ввода-вывода, которые обычно выполняются последовательным образом. Конфигурируя Log Reader Agent, вы можете снизить его влияние на этот журнал. Существует несколько способов сделать операции Log Reader Agent более эффективными. Один из способов – это использование дискового контроллера с кэшем для дискового тома с этим журналом. Поскольку Log Reader Agent выполняет чтение с диска журнала, то кэш на контроллере позволит осуществлять чтение из этого кэша вместо применения операций ввода-вывода с произвольным доступом.
Еще один способ настройки Log Reader Agent – это его конфигурирование для менее частого запуска. Log Reader Agent может работать в непрерывном режиме или периодически. Если в вашей системе не происходит большого количества модификаций, то, возможно, Log Reader Agent может работать непрерывно без нарушения доступа к журналу транзакций. Но при высоком уровне занятости журнала транзакций вашей системы вы можете увеличить производительность издателя, задав менее частые запуски Log Reader Agent. Тогда Log Reader Agent будет выполнять чтение из журнала транзакций реже, что позволит сохранить последовательный доступ для операций ввода-вывода этого журнала.
И еще одним способом повышения эффективности Log Reader Agent в системах с высокой нагрузкой является увеличение размера пакета чтения. Этот размер определяет, сколько транзакций считывается из журнала транзакций и копируется на дистрибьютор за один раз. Использование этого параметра в системах с высокой нагрузкой может повысить производительность. Кроме того, увеличение размера пакета чтения может оказаться полезным при увеличении интервала опроса. Увеличивая размер пакета чтения для Log Reader Agent, вам следует также увеличить размер пакета фиксирования транзакций на дистрибьюторе, чтобы привести его в соответствие с новым размером пакета чтения.
Вы можете конфигурировать агент Log Reader Agent путем вызова окна его свойств в Enterprise Manager. (См. раздел "Мониторинг и управление агентами репликации" в лекции 26.)
Мониторинг системы репликации транзакций
Мониторинг операций репликации транзакций выполняется так же, как и мониторинг других типов репликации, т.е. через Performance Monitor (perfmon). В perfmon имеется ряд объектов, которые добавляются при использовании репликации SQL Server. Это следующие объекты:
SQLServer:Replication Agents. Указывает количество работающих агентов репликации каждого типа.
SQLServer:Replication Dist. Предоставляет информацию о задержке при распространении. Длительные задержки могут быть признаком того, что дистрибьютор перегружен.
SQLServer:Replication Logreader. Предоставляет данные об активности и задержке агента Log Reader Agent. Следите за длительными задержками. Это может быть признаком того, что имеется проблема, касающаяся чтения журнала транзакций на издателе агентом Log Reader Agent. Кроме того, следите за количеством переданных транзакций в секунду. При большом количестве вам, возможно, требуется более мощная подсистема ввода-вывода на дисковых томах журнала транзакций.
Используя Performance Monitor для мониторинга этих значений, вы можете определить наличие проблем производительности Log Reader Agent или дистрибьютора. Данные perfmon дают массу полезной информации, но она не всегда идентифицирует проблемы.
Настройка системы репликации транзакций
Основные шагами в настройке системы репликации транзакций являются надлежащее конфигурирование и мониторинг системы, как это описано в предыдущих разделах. Кроме того, после ввода системы в эксплуатацию, когда вы можете выполнять ее мониторинг, вам, возможно, потребуется изменение интервала опроса. Обычно вполне подходит значение по умолчанию, равное 10 секундам. При увеличении частоты опроса (т.e. уменьшении интервала опроса) транзакции реплицируются быстрее, но увеличивается нагрузка на журнал транзакций. При уменьшении частоты опроса (т.e. увеличении интервала опроса) вы снижаете нагрузку на журнал транзакций, но время репликации транзакций увеличивается.
Кроме того, если в вашей системе происходят частые обновления, вам может потребоваться увеличение размера пакета чтения. Как уже говорилось, это позволит агенту Log Reader Agent считывать за один раз больше транзакций. Если увеличить это значение и оставить интервал опроса в 10 секунд, то будет реплицироваться больше транзакций и станет меньше дополнительная нагрузка.
Вам может также потребоваться мониторинг производительности сети и (при необходимости) ее увеличение, как и в случае репликации снимков. Если ваша система работает неадекватным образом, например, если центральные процессоры и подсистемы ввода-вывода достигли предела своих возможностей, а процесс репликации занимает слишком много времени, то у вас, возможно, имеются сетевые проблемы. К сожалению, сетевые проблемы нельзя диагностировать с помощью perfmon. Следует использовать продукт для мониторинга сети, такой как Microsoft Systems Management Server (SMS). Выполните мониторинг сетевой платы, чтобы определить, не достигла ли она предела своих возможностей.
И, наконец, помните, что издатель, дистрибьютор и подписчики – это системы SQL Server. Поэтому вам следует настраивать эти системы точно так же, как и любую другую систему SQL Server. Рекомендации по настройке систем SQL Server приводятся на протяжении всей этой книги.
Реализация репликации транзакций
В этом разделе вы узнаете о методах реализации репликации транзакций. Она может быть реализована по схеме "один-к-многим" или "многие-к-одному". Репликация транзакций часто реализуется через глобальную сеть (WAN).
Репликация типа "один-к-многим"
В большинстве реализаций репликации транзакций используется схема "один-к-многим". При этом типе реализации одна таблица публикуется для одного или нескольких подписчиков.
Репликация типа "многие-к-одному"
В схеме репликации "многие-к-одному" одна база данных подписывается на более чем одну подписку. Это не самая распространенная схема репликации, но тем не менее она широко используется. Поскольку репликация транзакций выполняется путем чтения журнала транзакций на издателе и применения операций вставки, обновления и удаления на подписчике, то она прекрасно подходит для этой схемы репликации. Единственным потенциальным недостатком является то, что подписывающаяся таблица должна иметь определенный в ней первичный ключ. И если источники ваших данных не портят этот первичный ключ, то схема репликации "многие-к-одному" работает должным образом.
Репликация через глобальную сеть (WAN)
Репликация через глобальную сеть не только возможна, но и довольно широко распространена. Если вы реплицируете данные через глобальную сеть, то вам следует непрерывно следить за операциями распространения и выявлять случаи слишком длительной репликации, связанные с ограничениями пропускной способности сети. Кроме того, если возможно, конфигурируйте репликацию таким образом, чтобы взаимодействие через глобальную сеть выполнялось только агентом Distribution Agent. Это означает конфигурирование системы таким образом, чтобы дистрибьютор и издатель находились по одну сторону глобальной сети.
Заключение
В этой лекции вы ознакомились с основами репликации транзакций. Вы узнали, что такое репликация транзакций, как она выполняется, как осуществлять ее мониторинг и как ее настраивать. Понимание механизма действия репликации транзакций и результатов ее работы поможет вам в ее эффективном использовании и конфигурировании. В следующей лекции вы узнаете о репликации слиянием.
В лекции 26 был дан обзор репликации в Microsoft SQL Server 2000, включая краткое описание репликации транзакций. В данной лекции приводится уже подробное описание этой темы. Здесь описывается, как действует этот метод репликации, когда его следует использовать, а также как его конфигурировать, как выполнять его мониторинг и как настраивать системы, участвующие в репликации транзакций.
Репликация транзакций, видимо, является наиболее распространенным методом репликации. Она позволяет достаточно быстро передавать подписчикам изменения после того, как они применены к издателям, и это происходит без особого увеличения нагрузки на издателей.
Введение в репликацию транзакций
Как следует из названия, репликация транзакций используется для репликации того, что происходит в транзакциях. При использовании этого метода репликации база данных подписчика создается первоначально с помощью моментального снимка (snapshot) – мы будем называть его просто снимком, – а последующие изменения, которые вносятся в базу данных издателя, реплицируются подписчику в соответствии с транзакциями. Все обновления, вставки и удаления, выполняемые в базе данных, распространяются именно таким образом.
Транзакции считываются из журнала транзакций агентом чтения журнала Log Reader Agent, который запускается на дистрибьюторе и подсоединяется к издателю. Эти транзакции обрабатываются и помещаются в дистрибутивную базу данных на дистрибьюторе. Позже агенты распространения (Distribution Agents) считывают эту информацию из дистрибутивной базы данных и применяют транзакции к базе данных подписчика.
Каждая база данных, которая использует репликацию транзакций, имеет собственного агента Log Reader Agent, который запускается на дистрибьюторе и следит за журналом транзакций этой базы данных на издателе. На каждую базу данных используется только один агент Log Reader Agent – независимо от количества публикаций, определенных по соответствующей базе данных.
Log Reader Agent запускается на дистрибьюторе в соответствии с расписанием, которое определяется при создании публикации. В зависимости от вашего выбора Log Reader Agent работает в соответствии с регулярным расписанием или непрерывно. При работе Log Reader Agent происходит следующая последовательность событий.
Log Reader Agent читает журнал транзакций системы с данной публикацией и создает список операторов INSERT, UPDATE, DELETE и других модификаций данных, которые были выбраны для репликации, включая удаления таблиц, изменения в определениях колонок и т.д.
Log Reader Agent обрабатывает данные из журнала транзакций и выполняет фильтрации, определенные по статьям. Сюда относятся все горизонтальные и вертикальные фильтрации.
Эти модификации объединяются в пакет и отправляются в дистрибутивную базу данных на дистрибьюторе. Внутри дистрибутивной базы данных имеется несколько таблиц, в которых отслеживаются изменения репликации и задачи. Выполняемые на издателе модификации, которые должны распространяться подписчикам, сохраняются в таблице с именем MSRepl_commands. Эта таблица содержит реальные команды репликации в сжатом формате. Таблица MSRepl_commands содержит по одной строке для каждой операции INSERT, UPDATE и DELETE по каждой определенной ранее статье. Если модификация, которая вносится в таблицу базы данных издателя, относится к нескольким статьям, то это изменение будет дублировано в дистрибутивной базе данных. Например, если таблица A содержится в трех статьях, то изменение в таблице A приведет к появлению трех строк в дистрибутивной базе данных.
После успешной передачи каждого пакета в дистрибутивную базу данных происходит фиксирование транзакций этого пакета. При отказе фиксирования в журнал ошибок агента записывается сообщение об ошибке.
После успешного фиксирования этих изменений в дистрибутивной базе данных Log Reader Agent помечает последнее изменение, включенное в последнюю операцию репликации, чтобы не было повторения этих изменений.
После того как транзакция прочитана из журнала транзакций и фиксирована в дистрибутивной базе данных, Log Reader Agent помечает те строки журнала транзакций, которые подходят для усечения (eligible to be truncated).
Для каждой модификации базы данных публикации создается хотя бы одна запись в дистрибутивной базе данных. В некоторых случаях модификация в базе данных публикации приводит к созданию нескольких записей в дистрибутивной базе данных. Вот эти случаи.
Вставка в таблицу приводит к вставке в дистрибутивную базу данных для каждой статьи, в которую входит данная таблица. Если таблица входит в две различные публикации, то она определена в двух отдельных статьях. Каждая из двух статей получит свою строку в дистрибутивной базе данных для каждой операции вставки, обновления и удаления, выполняемой в базе данных соответствующей публикации.
Для каждого обновления или удаления, влияющего на несколько строк, создается соответствующее количество строк в дистрибутивной базе данных. Для оператора SQL, который выполняет операцию обновления или удаления для нескольких строк, агент Log Reader Agent создает по отдельной команде в дистрибутивной базе данных для каждой из этих строк. Предложение WHERE в операторе SQL преобразуется в предложение WHERE, которое указывает строку в базе данных в соответствии со значение первичного ключа. Например, операция обновления, которая влияет на все строки в 10-строчной таблице, приведет к созданию 10 записей в дистрибутивной базе данных, для каждой из которых в предложении WHERE указывается значение первичного ключа.
Применение репликации
транзакций
Репликация транзакций может применяться, когда подписчикам требуется поддерживать информацию на уровне текущего состояния данных издателя. Репликацию транзакций можно сконфигурировать таким образом, чтобы обновление подписчика происходило вскоре после обновления издателя. Даже в непрерывном режиме работы агент Log Reader Agent вместо непрерывного чтения обращается к журналу транзакций через определенное количество секунд, чтобы снизить нагрузку на журнал транзакций издателя.
Репликацию транзакций можно сконфигурировать таким образом, чтобы подписчики тоже могли модифицировать базу данных. Это свойство придает репликации транзакций высокую степень гибкости и находит применение в ряде случаев.
Передача сообщений. Репликацию транзакций можно использовать для передачи сообщений между системами, когда важно следить за тем, что подписчик получил эти сообщения. Если происходит разъединение в сети, то данные будут переданы, как только соединение в сети будет восстановлено.
Поддержка текущего состояния информации в магазинах. Многие компании используют репликацию транзакций для передачи данных между главным офисом и магазинами розничной торговли. При каждом обновлении цен в главном офисе они также обновляются в системах розничной торговли.
Распределение нагрузки. Репликацию транзакций можно использовать для снятия части нагрузки с баз данных с помощью отчетных систем, которые могут обрабатывать длительные требующие интенсивного использования ресурсов запросы, освобождая тем самым главные серверы.
Существует много применений для репликации транзакций. В зависимости от конфигурации вашей системы и ваших приложений репликация транзакций может оказаться для вас очень полезным средством.
Конфигурирование системы
репликации транзакций
Конфигурирование репликации транзакций выполняется аналогично конфигурированию репликации моментального снимка. Сначала вы должны сконфигурировать публикацию и затем задать, чтобы она принудительно передавалась подписчику (push-подписка) или запрашивалась подписчиком (pull-подписка).
Примечание. Прежде чем конфигурировать любой тип репликации SQL Server, вы должны сначала сконфигурировать публикование и распространение. Инструкции см. в лекции 26.
Конфигурирование публикаций
Процесс создания публикации для репликации транзакций почти идентичен процессу создания публикации для репликации моментальных снимков. Для конфигурирования публикации транзакций выполните следующие шаги.
В окне Enterprise Manager щелкните на меню Tools. Далее укажите пункт Replication (Репликация) и выберите команду Create аnd Manage Publications (Создание и управление публикациями); или выберите пункт Wizards (Мастера), раскройте папку Replication в появившемся в диалоговом окне Select Wizard (Выбор мастера) и выберите Create Publication Wizard (Мастер создания публикации). При любом способе появится диалоговое окно Create and Manage Publications
(рис. 27.1). В этом диалоговом окне вы можете выбрать базу данных или таблицу, содержащую данные, которые вы хотите публиковать.Если публикации уже существуют, то в дополнение к кнопке Create Publication (Создать публикацию) будут доступны следующие кнопки:
(рис 27.1) Диалоговое окно Create and Manage Publications
Properties and Subscriptions (Свойства и подписки). Позволяет вам модифицировать свойства как публикаций, так и подписок.
Script Publication (Сценарий создания публикации). Позволяет вам создать сценарий, который можно использовать для создания других публикаций.
Delete Publication (Удалить публикацию). Позволяет вам удалить уже сконфигурированную публикацию.
Выберите базу данных, которую хотите использовать для данной публикации (на рис 27.1(рис 27.2) Начальное окно мастера Create Publication Wizard
Щелкните на кнопке Next, чтобы появилось окно Choose Publication Database (Выбор базы данных для публикации) (рис 27.3(рис 27.3) Окно Choose Publication Database (Выбор баз данных для публикаций)Примечание. Если для системы, выбранной вами на шаге 1, еще не определен дистрибьютор, то вы получите запрос выбора дистрибьютора в окне Select Distributor (Выбор дистрибьютора). Напомним, что издатель может иметь только одного дистрибьютора – независимо от количества публикаций. Если у вас уже определен дистрибьютор, то появится окно Choose Publication Database, как это описано выше.
Щелкните на кнопке Next, чтобы появилось окно Select Publication Type (Выбор типа публикации) (рис 27.4(рис 27.4) Окно Select Publication Type (Выбор типа публикации)В этом окне вы можете выбрать один из трех типов репликации. Будут представлены следующие варианты выбора:Snapshot publication (Публикация для репликации снимков). Создает публикацию для репликации снимка соответствующей статьи, который периодически копируется на подписчик. Такую публикацию можно создавать из любой таблицы.
Transactional publication (Публикация для репликации транзакций). Создает публикацию для репликации транзакций, в соответствии с которыми происходит обновление подписки изменениями, выполненными на издателе. Статьи могут создаваться только из таблиц с первичным ключом.
Merge publication (Публикация для репликации слиянием).Создает публикацию для репликации слиянием, которая позволяет выполнять двустороннюю репликацию между издателем и подписчиком. Статьи могут создаваться из любых таблиц.
Щелкните на кнопке выбора Transactional Publication и щелкните на кнопке Next, чтобы появилось окно Updatable Subscriptions (Модифицируемые подписки) (рис 27.5(рис 27.5) Окно Updatable Subscriptions (Модифицируемые подписки)В этом окне вы можете указывать, какие изменения, внесенные на подписчиках, реплицируются издателям. Ниже описаны флажки этого окна.Immediate updating (Немедленное обновление).Активизируются подписки с немедленным обновлением. Это означает, что агенты репликации будут использовать Microsoft Distributed Transaction Coordinator (MS DTC – координатор распределенных транзакций) для выполнения двухфазного фиксирования по транзакциям, которые модифицируют данные подписчиков, чтобы можно было вносить изменения на подписчике и немедленно реплицировать их на издателе. (О MS DTC и двухфазном фиксировании см. лекцию 25.) По умолчанию флажок подписок с немедленным обновлением не установлен.
Queued updating (Отложенное обновление). Активизирует подписки с отложенным обновлением. Это означает, что модификации, которые выполняются на подписчике, будут помещаться в очередь до того момента, когда их можно будет применить на издателе. Это позволяет подписчику модифицировать базу данных, но не требует двухфазного фиксирования с издателем.
Примечание. Репликация с немедленным обновлением полезна в тех случаях, когда идентичность систем является требованием, но учтите, что при двухфазном фиксировании возникает большая дополнительная нагрузка. Если у вас нет немедленного доступа к обеим системам, то соответствующая транзакция не может быть фиксирована. Репликацию с немедленным обновлением следует использовать только при абсолютной необходимости.
Щелкните на кнопке Next, чтобы появилось окно Transform Published Data (Преобразование опубликованных данных) (рис. 27.6). Преобразование данных является новой возможностью SQL Server. Для преобразования реплицированных данных используется набор Microsoft Data Transformation Services (DTS – службы преобразования данных). DTS позволяет выполнять следующие преобразования данных:преобразование значений или типов данных;
изменение регистра букв;
слияние данных;
разделение данных.
(рис 27.6) Окно Transform Published Data (Преобразование опубликованных данных)
Щелкните на кнопке Next, чтобы появилось окно Specify Subscriber Types (Указание типов подписчиков) (рис 27.7(рис 27.7) Окно Specify Subscriber Types (Указание типов подписчиков)
Щелкните на кнопке Next, чтобы появилось окно Specify Articles (Указание статей) (рис 27.8(рис 27.8) Окно Specify Articles (Указание статей)Примечание.Если на подписчике имеются хранимые процедуры, то репликацию можно сконфигурировать таким образом, чтобы реплицировать вызовы этих хранимых процедур, а не результаты вызовов хранимых процедур.
Щелкните на кнопке Next. На этом этапе SQL Server проверяет данную публикацию, и если он найдет ошибки, то вы увидите окно (рис 27.9(рис 27.9) Окно Article Issues (Вопросы по статьям)
После завершения анализа данной публикации (и после щелчка на кнопке OK для возврата в окно мастера, если появилось информационное диалоговое окно) щелкните на кнопке Next, чтобы появилось окно Select Publication Name and Description (Выбор имени и описания публикации) (рис 27.10(рис 27.10) Окно Select Publication Name аnd Description (Выбор имени и описания публикации)
Щелкните на кнопке Next, чтобы появилось окно Customize the Properties of the Publication (Настройка свойств данной публикации) (рис 27.11(рис 27.11) Окно Customize the Properties of the Publication (Настройка свойств данной публикации)
Щелкните на кнопке Next, чтобы появилось окно Filter Data (Фильтрация данных) (рис 27.12(рис 27.12) Окно Filter Data (Фильтрация данных)
Появится окно Filter Table Columns (Фильтрация колонок таблицы) (рис 27.13(рис 27.13) Окно Filter Table Columns (Фильтрация колонок таблицы)Примечание.Колонки с первичными ключами нельзя включить в фильтрацию, поскольку колонки с первичными ключами используются в репликации транзакций, как это описано выше в этой лекции.
Щелкните на кнопке Next, чтобы появилось окно Filter Table Rows (Фильтрация строк таблицы) (рис 27.14(рис 27.14) Окно Filter Table Rows (Фильтрация строк таблицы)
Появится диалоговое окно Specify Filter (Задать фильтр) (рис. 27.15). В этом диалоговом окне вы можете добавлять к SQL-оператору предложение (рис 27.15) Диалоговое окно Specify Filter (Задать фильтр)
Щелкните на кнопке Next, чтобы появилось окно Allow Anonymous Subscriptions (Разрешить доступ анонимным подписчикам) (рис 27.16(рис 27.16) Окно Allow Anonymous Subscriptions (Разрешить доступ анонимным подписчикам)
Щелкните на кнопке Next, чтобы появилось окно Set Snapshot Agent Schedule (Задать расписание для агента снимков Snapshot Agent). (Об использовании этого окна см. шаги 15 и 16 подраздела "Конфигурирование репликации моментальных снимков" лекции 26.) Поскольку в репликации транзакций снимок используется только для первоначального создания базы данных подписчика, то вам, видимо, не нужно задавать регулярное расписание для создания снимка; вместо этого вы можете создать снимок вручную.
После того, как вы зададите расписание, щелкните на кнопке Next, чтобы появилось окно мастера Completing the Create Publication Wizard (Завершение работы мастера создания публикации), просмотрите сводку по данной публикации и щелкните на кнопке Finish (Готово). Когда создание вашей публикации будет завершено, появится соответствующее информационное диалоговое окно.
Конфигурирование Log Reader Agent
После создания публикации вам, возможно, потребуется модифицировать поведение агента чтения журнала Log Reader Agent. Например, вы можете задать, как происходит вызов Log Reader Agent, выбрав режим, в котором он будет работать. В непрерывном режиме (это режим по умолчанию) запуск Log Reader Agent происходит при запуске SQL Server Agent. Затем он подсоединяется к журналу транзакций на издателе и выполняет непрерывное чтение этого журнала. В режиме расписания Log Reader Agent запускается в соответствии с заданным вами расписанием и переходит в неактивное состояние после того, как прочитает все реплицируемые транзакции из журнала транзакций. Изменяя режим и другие свойства, вы можете повышать производительность и снижать объем нагрузки на издатель. Чтобы сконфигурировать Log Reader Agent, выполните следующие шаги.
В окне Enterprise Manager раскройте сервер, раскройте папку Replication Monitor, раскройте папку Agents и затем щелкните на папке Log Reader Agents.
В правой панели Enterprise Manager щелкните правой кнопкой мыши на публикации. Появится контекстное меню (рис 27.17(рис 27.17) Контекстное меню для публикации
Выберите пункт Agent Properties (Свойства агента). Появится окно свойств данного агента Log Reader Agent (рис. 27.18).
Щелкните на вкладке Steps (Шаги) (рис 27.19(рис 27.19) Окно свойств Log Reader Agent(рис 27.18) Вкладка Steps (Шаги) окна свойств Log Reader Agent
Run agent (Запуск агента).Запуск данного агента в соответствии с заданным расписанием. При работе в непрерывном режиме этот агент работает, пока не будет отключена система.
Detect nonlogged agent shutdown (Обнаружено незарегистрированное отключение агента). В таблицу журнала работы агента Log Reader Agent помещается сообщение в случае отключения агента.
Выделите шаг Run agent и щелкните на кнопке Edit (Редактировать), чтобы появилось диалоговое окно Edit Job Step (Редактирование шага) (рис. 27.20). В этом диалоговом окне вы можете конфигурировать способ вызова Log Reader Agent.Для агента Log Reader Agent можно сконфигурировать много параметров. Параметры по умолчанию этого агента можно модифицировать в окне Command (Команда) диалогового окна Edit Job Step и в диалоговом окне Replication Agent Profile Details (Детали профиля агента репликации) (рис. 27.22). Здесь описаны два параметра, которые вы можете модифицировать в диалоговом окне Edit Job Step.
(рис 27.20) Вкладка General диалогового окна Edit Job Step (Редактирование шага)
DistributorSecurityMode (Режим безопасности дистрибьютора).Указывает, какой режим аутентификации использует Log Reader Agent: SQL Server или Microsoft Windows 2000.
Кроме того, вы можете задать в диалоговом окне Edit Job Step другие параметры, такие как AsynchLogging, Buffers, DefinitionFile, информацию о дистрибьюторе и подписчиках и MessageInterval.
Закончив модифицирование свойств Log Reader Agent, щелкните на кнопке OK, чтобы сохранить ваши изменения.
Вы можете модифицировать другие параметры в профиле Log Reader Agent. Чтобы модифицировать профиль, выполните следующие шаги.
В правой панели Enterprise Manager щелкните правой кнопкой мыши на Log Reader Agent и выберите из появившегося контекстного меню пункт Agent Profiles (Профили агента). Появится диалоговое окно Log Reader Agent Profiles(рис. 27.21).
Щелкните на кнопке New Profile (Создать профиль), чтобы создать новый профиль. Текущий профиль нельзя модифицировать. В результате появится диалоговое окно Replication Agent Profile Details (Детали профиля агента репликации) (рис. 27.22).
В этом диалоговом окне вы можете модифицировать следующие параметры:HistoryVerboseLevel. Указывает, сколько информации будет протоколироваться в журнале. Обычно хватает принятого по умолчанию уровня, если только у вас не возникают проблемы.
LoginTimeout. Указывает допустимое время ожидания в секундах для Log Reader Agent.
PollingInterval. Указывает, насколько часто опрашивается журнал транзакций на издателе (для получения новых транзакций).
QueryTimeout.Указывает допустимое время ожидания в секундах для запроса.
ReadBatchSize.Указывает количество транзакций, которое считывается из журнала транзакций в одном пакете.
(рис 27.22) Диалоговое окно Log Reader Agent Profiles (рис 27.21) Диалоговое окно Replication Agent Profile Details (Детали профиля агента репликации)Примечание. Как уже говорилось, если Log Reader Agent используется в режиме расписания, а не в непрерывном режиме, то он вызывается агентом SQL Server Agent и выполняет чтение из журнала транзакций всех транзакций, которые были помечены для репликации. Log Reader Agent считывает из журнала транзакций определенное количество транзакций или команд, указанное параметром ReadBatchSize, и выполняет их вставку в дистрибутивную базу данных. После считывания всех транзакций, помеченных для репликации, Log Reader Agent переходит в неактивное состояние, пока не наступит момент следующего запуска в соответствии с расписанием.
Конфигурирование pull-подписок
Управление и конфигурирование pull-подписок осуществляется со стороны подписчика. Тем самым вы должны конфигурировать pull-подписку с помощью Enterprise Manager в системе подписчика. Чтобы сконфигурировать pull-подписку, выполните следующие шаги.
В окне Enterprise Manager щелкните на меню Tools. Далее укажите пункт Replication, выберите пункт Pull Subscription To (Pull-подписка) и затем щелкните на Pull New Subscription (Новая pull-подписка) в появившемся диалоговом окне Pull Subscription To; или выберите из меню Tools пункт Wizards, раскройте папку Replication в появившемся диалоговом окне Select Wizard, затем выберите Create Pull Subscription Wizard (Мастер создания pull-подписки) и щелкните на кнопке OK. При обоих методах появится начальное окно мастера Pull Subscription Wizard (рис 27.23(рис 27.23) Начальное окно Pull Subscription Wizard
Щелкните на кнопке Next, чтобы появилось окно Look for Publications (Поиск публикаций) (рис 27.24(рис 27.24) Окно Look for Publications (Поиск публикаций)
Щелкните на кнопке Next, чтобы появилось окно Choose Publication (Выбор публикации) (рис 27.25(рис 27.25) Окно Choose Publication (Выбор публикации)
Щелкните на кнопке Next, чтобы появилось окно Specify Synchronization Agent Login (Задать login-запись для агента синхронизации) (рис. 27.26). В этом окне вы можете задать login-запись и пароль для дистрибьютора.
Щелкните на кнопке Next, чтобы появилось окно Choose Destination Database (Выбор целевой базы данных) (рис 27.27(рис 27.27) Окно Specify Synchronization Agent Login (Задать login-запись для агента синхронизации)(рис 27.26) Окно Choose Destination Database (Выбор целевой базы данных)
Щелкните на кнопке Next, чтобы появилось окно Initialize Subscription (Инициализация подписки) (рис. 27.28). Щелкните на кнопке выбора Yes, чтобы инициализировать схему базы данных и данные у подписчика. Если у вас уже есть ранее созданная схема, щелкните на кнопке выбора No.
Щелкните на кнопке Next, чтобы появилось окно Snapshot Delivery (Доставка снимка) (рис. 27.29). В этом окне вы можете указать папку для снимка, отличную от принятой по умолчанию папки. Если вы не хотите изменять папку для снимка, используйте вариант по умолчанию (первая кнопка выбора).
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Schedule (Задать расписание для агента распространения) (рис 27.30(рис 27.29) Окно Initialize Subscription (Инициализация подписки)(рис 27.28) Окно Snapshot Delivery (Доставка снимка)(рис 27.30) Окно Set Distribution Agent Schedule (Задать расписание для агента распространения)Принимая решение о том, как работать с обновлениями в вашей системе, помните, что более частые запуски агента Distribution Agent приводят к увеличению нагрузки и на дистрибьюторе, и на подписчике. Запускайте этот агент, сколько вам требуется, но не допускайте излишнего использования.
Чтобы изменить расписание для агента Distribution Agent, щелкните на кнопке Change и модифицируйте расписание в появившемся диалоговом окне Edit Recurring Job Schedule (Редактировать расписание повторяющихся заданий).
Примечание.Если у вас выбрано преобразование данных публикации, то появится окно Specify DTS Package (Задать пакет DTS). Для продолжения работы у вас уже должен быть создан пакет DTS. Если у вас еще нет такого пакета, создайте его и затем снова запустите мастер. В данном примере мы не задаем преобразование данных.
Щелкните на кнопке Next, чтобы появилось окно Start Required Services (Запуск требуемых служб) (рис 27.31(рис 27.31) Окно Start Required Services (Запуск требуемых служб)
Щелкните на кнопке Next, чтобы появилось окно Completing the Pull Subscription Wizard (Завершение работы мастера pull-подписки) (рис. 27.32). Щелкните на кнопке Finish, чтобы завершить задание параметров подписчика.
Теперь статьи будут реплицироваться на подписчик и будут регулярно обновляться в соответствии с заданным вами расписанием. Возможно, что прежде чем можно будет начать репликацию, вам потребуется проверить расписание, в соответствии с которым будут запускаться агенты публикации. Агент Snapshot Agent запускается по своему собственному расписанию, и если вы не сконфигурировали его для немедленного распространения снимка на дистрибьютор, то для поступления данных на дистрибьютор может потребоваться некоторое время. Несмотря на то, что репликация действует, реальные данные не поступят подписчику, пока не выполнит свою работу Snapshot Agent.
(рис 27.32) Окно Completing the Pull Subscription Wizard
Конфигурирование push-подписок
Push-подписка (принудительная подписка) инициируется на издателе. Push-подписка конфигурируется с помощью мастера Push Subscription Wizard. При использовании push-подписки расписание репликаций определяется на дистрибьюторе. Для запуска мастера Push Subscription Wizard выполните следующие шаги:
Вызовите Push Subscription Wizard, используя один из двух методов. Для использования первого метода укажите пункт Replication в меню Tools окна Enterprise Manager и затем выберите пункт Push Subscription to Others (Push-подписка для других). Появится диалоговое окно Create and Manage Publications (Создание и управление публикациями) (рис 27.33Выделите публикацию в списке Databases and Publications (Базы данных и публикации) и затем щелкните на кнопке Push New Subscription (Создать push-подписку). Чтобы использовать второй метод, выберите из меню Tools пункт Wizards, раскройте папку Replication в появившемся диалоговом окне Select Wizards, выберите Create Push Subscription Wizard и щелкните на кнопке ОК. Выделите публикацию в появившемся диалоговом окне Create and Manage Publications и затем щелкните на кнопке Push New Subscription. Появится начальное окно мастера Push Subscription Wizard (рис 27.34(рис 27.34) Публикация, выбранная в диалоговом окне Create and Manage Publications(рис 27.33) Начальное окно мастера Push Subscription Wizard
Щелкните на кнопке Next, чтобы появилось окно Choose Subscribers (Выбор подписчиков) (рис 27.35(рис 27.35) Окно Choose Subscribers (Выбор подписчиков)
Щелкните на кнопке Next, чтобы появилось окно Choose Destination Database (рис 27.36(рис 27.36) Окно Choose Destination Database
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Location (Задать местоположение для агента распространения) (рис 27.37(рис 27.37) Окно Set Distribution Agent Location (Задать местоположение для агента распространения)
Щелкните на кнопке Next, чтобы появилось окно Set Distribution Agent Schedule (рис 27.38(рис 27.38) Окно Set Distribution Agent Schedule
Щелкните на кнопке Next, чтобы появилось окно Initialize Subscription (рис 27.39(рис 27.39) Окно Initialize Subscription В этом окне вы указываете, нужно ли инициализировать данную подписку. По умолчанию выбран вариант инициализации схемы и набора данных на подписчике. В этом окне вы можете также запустить Snapshot Agent, если он еще не запущен. Имеет смысл запускать Snapshot Agent, когда вы инициализируете снимок; в противном случае вам придется запускать этот агент вручную. После того как снимок инициализирован и начинается репликация, вам не нужно использовать снимок, пока не потребуется создать новую подписку. Каждый раз, как вы создаете подписку, создавайте новый снимок, и вам больше не нужно создавать снимки в соответствии с каким-либо расписанием, если только вам не потребуется ресинхронизация базы данных подписчика с использованием снимков.
Щелкните на кнопке Next, чтобы появилось окно Start Required Services (рис 27.40(рис 27.40) Окно Start Required Services
Щелкните на кнопке Next, чтобы появилось окно Completing the Push Subscription Wizard (Завершение работы мастера push-подписки) (рис 27.41(рис 27.41) Окно Comple-ting the Push Subscription Wizard (Завершение работы мастера push-подписки)
Дополнительная информация.Обратитесь к разделу "Управление репликацией" лекции 26 для получения информации по управлению и устранению проблем репликации, мониторингу и управлению агентами репликации, отключению репликации, а также удалению подписок, распространения и публикования.
Конфигурирование, мониторинг
и настройка дистрибьютора
для репликации транзакций
В этом разделе вы узнаете, как осуществлять конфигурирование, мониторинг и настройку дистрибьютора для репликации транзакций Как уже говорилось в предыдущей лекции, дистрибьютор – это сервер, содержащий базу данных SQL Server, которая называется дистрибутивной базой данных и используется как хранилище данных репликации. Эти данные хранятся в базе данных SQL Server, обеспечивая ряд преимуществ, включая следующие:
Высокая производительность. SQL Server обеспечивает высокую производительность, которая требуется дистрибьютору для получения, хранения и распространения данных.
Надежность. Поскольку SQL Server поддерживает высокий уровень восстанавливаемости, то база данных SQL Server идеально подходит для данных репликации. Используя журнал транзакций, SQL Server может выполнять восстановление после аварий системы без потери каких-либо данных.
Простота использования. Поскольку процесс репликации SQL Server непосредственно взаимодействует с дистрибьютором через протоколы передачи данных, это позволяет легко устанавливать и конфигурировать дистрибьютор.
Конфигурирование дистрибьютора
В зависимости от того, как часто вносятся модификации в вашу базу данных, интенсивность операций на дистрибьюторе может оказаться довольно высокой. Поскольку дистрибьютор использует базу данных SQL Server, все модификации, выполняемые на дистрибьюторе, должны протоколироваться в журнале транзакций. Вам следует конфигурировать дистрибутивную базу данных и этот журнал достаточно большими, чтобы можно было выполнять необходимую работу, и достаточно быстрыми, чтобы выполнять эту работу эффективно. Хотя принятая по умолчанию конфигурация распространения подходит для небольших систем репликации, она не соответствует многим системам, поскольку мастера репликации SQL Server не размещают журнал транзакций и файлы данных SQL Server оптимальным образом. Они обычно размещаются на принятом по умолчанию томе SQL Server, причем журнал транзакций и файлы базы данных оказываются на одном томе.
Конфигурируя должным образом дистрибутивную базу данных, вы можете избежать дорогостоящих проблем производительности. Вот некоторые рекомендации по конфигурированию дистрибутивной базы данных.
Используйте RAID-контроллер для системы с дистрибутивной базой данных. Использование аппаратного RAID-контроллера более эффективно, чем использование программных RAID.
Конфигурируйте журнал транзакций дистрибутивной базы данных на томе RAID 1. Журнал транзакций должен быть изолирован, чтобы иметь более высокую производительность при последовательных операциях ввода-вывода.
Конфигурируйте журнал транзакций достаточно большим, чтобы не возникала необходимость частого резервного копирования журнала транзакций. В зависимости от ваших потребностей у вас должна быть возможность обходиться всего лишь одним резервным копированием журнала транзакций в сутки (предпочтительно вечером).
Конфигурируйте дистрибутивную базу данных на томе RAID 1 или RAID 10. RAID 5 не подходит в связи с большим количеством операций записи в дистрибутивную базу данных.
Конфигурируйте дистрибутивную базу данных достаточно большой, чтобы у нее был запас для дополнительных данных репликации. В случае отказа сервера подписчика в этой базе данных могут накопиться данные репликации за несколько дней.
Выполняйте настройку базы данных репликации, как и любой другой базы данных SQL Server.
Конфигурирование дистрибьютора с помощью Enterprise Manager
Для конфигурирования дистрибутивной базы данных, как это показано в предыдущем списке, вам нужно задать, где находится эта база данных. Чтобы сделать это с помощью Enterprise Manager, сначала вызовите мастер Configure Publishing and Distribution Wizard. Используйте этот мастер, чтобы задать публикование и распространение, указывая в окне Customize the Configuration (Настройка конфигурации), что вы хотите настроить параметры распространения (щелкнув на кнопке Yes). Это позволяет вам задать местоположение дистрибутивной базы данных вручную. (Это также позволяет вам выбирать имя для базы данных, активизировать публикование и создавать как публикации, так и подписчиков.)
К сожалению, используя этот мастер, вы не можете задавать размер дистрибутивной базы данных. Вы можете увеличить размер дистрибутивной базы данных, вызвав окно свойств этой базы данных в Enterprise Manager и изменив размер базы данных или файлов журнала транзакций. Если вы хотите одновременно задать местоположение базы данных и ее размер, то вы можете использовать хранимую процедуру sp_adddistributiondb.
Конфигурирование дистрибьютора с помощью sp_adddistributiondb
С помощью системной хранимой процедуры sp_adddistributiondb вы можете использовать сценарий создания дистрибутивной базы данных. Это полезно, когда вы хотите задать размер и местоположение этой базы данных и ее журнала транзакций. И написав сценарий, с помощью которого создается дистрибутивная база данных, вы можете использовать его для различных систем или для повторного создания дистрибутивной базы данных в случае реконфигурирования системы.
Примечание.Прежде чем создавать дистрибутивную базу данных, вы должны активизировать дистрибьютор. Это можно сделать с помощью хранимой процедуры sp_adddistributor, после которой указывается имя системы дистрибьютора.
Синтаксис хранимой процедуры sp_adddistributiondb приводится в SQL Server Books Online. Ниже показан пример использования этой хранимой процедуры:
sp_adddistributor Dash
Следующий оператор SQL инициализирует систему с именем Dash как дистрибьютора.
sp_adddistributiondb @database=dist,
@data_folder=’C:\mssql2000\data’,
@data_file=’dist.mdf’,
@data_file_size=10,
@log_folder=’C:\mssql2000\data’,
@log_file=’dist.ldf’,
@log_file_size=2,
@min_distretention=0,
@max_distretention=72,
@history_retention=96,
@security_mode=0,
@login=’sa’,
@password=’’,
@createmode=0
Мониторинг дистрибьютора
Мониторинг дистрибьютора осуществляется с помощью монитора производительности Microsoft Windows 2000 Performance Monitor (perfmon). В этом мониторе имеется ряд объектов, которые добавляются при использовании репликации SQL Server. Это следующие объекты:
SQLServer:Replication Agents. Указывает количество работающих агентов репликации каждого типа.
SQLServer:Replication Dist. Предоставляет информацию о задержке при распространении.
SQLServer:Replication Logreader. Предоставляет данные об активности и задержке агента Log Reader Agent
SQLServer:Replication Merge. Предоставляет данные о частоте операций слияния
SQLServer:Replication Snapshot. Предоставляет информацию о производительности репликации снимков.
Используя Performance Monitor для мониторинга этих значений, вы можете иногда определять наличие проблем производительности на дистрибьюторе. Данные perfmon дают массу полезной информации, но она не всегда идентифицирует проблемы. В случае мониторинга дистрибьютора нас больше всего интересует объект SQLServer:Replication Dist. Этот объект предоставляет следующие счетчики:
Dist:Delivered Cmds/sec.Следит за количеством команд в секунду, переданных подписчику. Это дает вам хорошее представление об интенсивности операций на данном подписчике.
Dist:Delivered Trans/sec. Следит за количеством транзакций в секунду, переданных подписчику. Этот счетчик также дает вам хорошее представление об интенсивности операций на данном подписчике.
Dist:Delivery Latency. Следит за количеством времени, которое требуется для применения транзакций к подписчику после того, как они были доставлены на дистрибьютор. Это может дать вам некоторое представление о том, насколько перегружен дистрибьютор. (backed up).
Хотя эти счетчики являются в некотором смысле индикаторами того, как работает процесс распространения в целом, они недостаточно полезны, когда вы определяете, нужна ли вам настройка дистрибьютора, поскольку наиболее важным аспектом настройки дистрибьютора является настройка базы данных SQL Server. Вам следует на самом деле следить в основном за следующими проблемами:
Высокий процент использования ЦП. Не слишком ли высока интенсивность использования одного или нескольких ЦП в течение длительных периодов (больше 75 процентов от их мощности)?
Узкие места подсистемы ввода-вывода. Не слишком ли высока интенсивность использования ввода-вывода? Следите за количеством операций ввода-вывода в секунду и длительностью одной операции ввода-вывода.
Время отклика.Не слишком ли велики значения времени отклика в SQL Server?
Настройка дистрибьютора
Как уже говорилось выше, дистрибьютор – это сервер, содержащий дистрибутивную базу данных, и эта база данных должна быть настроена таким же образом, как и любая другая база данных SQL Server. Вы можете повысить производительность дистрибьютора путем выбора состава системы, хотя, как вы знаете из лекции 6, в некоторых случаях это сложная задача. Дистрибьютор должен обладать достаточной мощностью, чтобы выполнять дополнительную работу. Дистрибьютор является "посредником" между издателями и подписчиками, и его следует сконфигурировать так, чтобы он не был узким местом. Ниже приводятся некоторые советы по конфигурированию и настройке дистрибьютора:
Настройка подсистемы ввода-вывода. Обеспечьте, чтобы дистрибьютор, как и любая другая система SQL Server, имел достаточную мощность системы ввода-вывода.
Используйте многопроцессорную систему.Мощность ЦП обычно не является проблемой, поскольку в большинстве случаев операции, выполняемые на дистрибьюторе, не требуют интенсивного использования ЦП. Однако вам следует использовать хотя бы два ЦП, чтобы можно было выполнять параллельные операции.
Настраивайте операционную систему. Конфигурируйте службу Server , чтобы получать максимальную производительность для сетевых приложений. Это приведет к конфигурированию системы памяти в пользу приложений по сравнению с файловыми службами. Для этого нужно использовать значок Network в панели управления. Кроме того, удалите все службы, которые не будут использоваться, такие как IIS и FTP.
Следите за дистрибьютором во время репликации моментальных снимков.При репликации снимков, которая используется, когда происходит копирование начального снимка в репликации транзакций и репликации слиянием, одновременно выполняется большое число операций ввода-вывода. Поскольку на дистрибьютор записывается такое количество данных, может возникнуть перегрузка подсистемы ввода-вывода дистрибьютора. В этой ситуации возрастает время, которое требуется для применения снимка. Поэтому вам нужно следить за дистрибьютором во время передачи снимка.
Настраивайте SQL Server. Используя методы и рекомендации, полученные в этой книге, выполняйте настройку системы SQL Server.
Настройка репликации транзакций
В этом разделе вы узнаете, как конфигурировать и настраивать систему репликации транзакций для получения высокой производительности. Раздел начинается с обзора атрибутов репликации транзакций, после чего даются рекомендации по конфигурированию, мониторингу и настройке.
Атрибуты репликации транзакций
Репликация транзакций начинается с копирования снимка на дистрибьютор и затем на подписчик. После копирования снимка на дистрибьюторе начинает работать агент Log Reader Agent, который выполняет чтение журнала транзакций издателя в непрерывном режиме или в соответствии с регулярным расписанием. Периодичность чтения журнала транзакций определяется тем, как вы сконфигурировали Log Reader Agent. (Нагрузка, налагаемая на издатель при чтении журнала транзакций, – это единственная нагрузка на издатель, относящаяся к репликации.)
Транзакции, которые считываются агентом Log Reader Agent из журнала транзакций на издателе, помещаются в дистрибутивную базу данных. Затем эти транзакции передаются подписчикам. Имеются следующие факторы, которые могут ограничить производительность репликации транзакций.
Производительность подсистемы ввода-вывода для журнала транзакций на издателе. Чтение журнала транзакций выполняется для того, чтобы определить, какие изменения были выполнены в базе данных. А поскольку во время репликации происходит не только чтение, но и запись в журнал транзакций, это может препятствовать последовательному доступу к журналу транзакций. При этом может возникать эффект узкого места. Чтобы избежать этого, журнал должен быть тщательно сконфигурирован.
Производительность дистрибьютора.В зависимости от количества операций репликации и числа издателей, которые используют дистрибьютор, на этом дистрибьюторе могут возникать проблемы производительности. Ранее в этой лекции вы узнали, как конфигурировать и настраивать дистрибьютор.
Производительность подписчика. В зависимости от выполняемых на подписчике операций на нем могут возникать проблемы производительности. Чтобы воспрепятствовать этим проблемам, выполните стандартную настройку в базе данных SQL Server этого подписчика.
Как видите, имеется ряд факторов, которые могут ограничивать производительность. Путем правильного выбора состава и конфигурирования используемых систем вы можете снизить влияние этих факторов и обеспечить высокую производительность.
Конфигурирование репликации транзакций
Конфигурирование системы репликации транзакций состоит из нескольких задач. Как уже говорилось в предыдущем разделе, вы должны правильно сконфигурировать журнал транзакций на издателе, поскольку он испытывает дополнительную нагрузку при использовании репликации. В этом разделе мы рассмотрим несколько других рекомендаций, о которых вы должны помнить при конфигурировании вашей системы репликации транзакций. Ниже приводится список этих рекомендаций.
Сконфигурируйте достаточную мощность подсистем ввода-вывода на всех системах, участвующих в репликации в соответствии с общими рекомендациями по конфигурированию мощности подсистем ввода-вывода. (Возможно, вам потребуется сконфигурировать более высокую мощность ввода-вывода для журнала транзакций на издателе, чем это обычно требуется.)
Увеличьте размер пакета фиксирования на дистрибьюторе.
Настройте Log Reader Agent.
Конфигурирование достаточной мощности
ввода-вывода
Конфигурируя достаточную мощность подсистем ввода-вывода, вы можете повысить производительность всего процесса репликации. Как и в любой системе SQL Server, журнал транзакций системы, участвующей в репликации, должен находиться для защиты данных на своем томе RAID 1. Файлы данных должны находиться на одном или нескольких томах RAID 10 или RAID 5. В отличие от репликации снимков для репликации транзакций требуются лишь небольшие изменения в стандартных конфигурациях ввода-вывода. Эти требования описаны в данном разделе.
Конфигурирование подсистемы ввода-вывода на издателе. В общем случае при конфигурировании подсистемы ввода-вывода издателя вы должны следовать стандартным рекомендациям по конфигурированию SQL Server, описанным на протяжении этой книги. Однако для журнала транзакций издателя может потребоваться более высокая мощность ввода-вывода, чем это обычно требуется. Обычно журнал транзакций следует конфигурировать на томе RAID 1. При необходимости (это зависит от степени занятости вашей системы) вам следует сконфигурировать его на томе RAID 10, используя большее количество дисков. RAID 5 не подходит для журнала транзакций.
Конфигурирование подсистемы ввода-вывода на дистрибьюторе. Дистрибьютор следует конфигурировать таким образом, чтобы дистрибутивная база данных имела собственный журнал транзакций на выделенном томе RAID 1. Это позволит получить максимальную производительность для журнала дистрибутивной базы данных, что повысит производительность самого дистрибьютора.
Конфигурирование подсистемы ввода-вывода на подписчике. При репликации транзакций не требуется какого-либо особого конфигурирования ввода-вывода на подписчике. Просто следуйте общим рекомендациям по определению состава и конфигурации систем, описанным на протяжении этой книги.
Конфигурирование размера пакета фиксирования на дистрибьюторе. Размер пакета фиксирования на дистрибьюторе определяет, сколько транзакций репликации фиксируются на дистрибьюторе в одном пакете. Если увеличить размер пакета, то за один раз будет фиксироваться больше строк, что увеличит время, в течение которого таблицы дистрибутивной базы данных будут недоступны для других процессов. (Во время модификации базы данных происходит захват блокировок по таблицам.) Если снизить размер пакета, то за один раз будет фиксироваться меньше строк, что дает возможность более быстрого доступа других процессов к дистрибутивной базе данных.
При большом количестве операций, применяемых к дистрибутивной базе данных другими источниками (то есть издателем и несколькими подписчиками) попытайтесь снизить размер пакета. Если Log Reader Agent запускается в соответствии с периодическим расписанием и получает много транзакций для единовременной вставки в дистрибутивную базу данных, то вам, видимо, поможет увеличение размера пакета. Может быть, вам не потребуется изменять размер пакета; но если вы будете делать это, сравните отличия в производительности при увеличении и уменьшении этого размера, чтобы определить, какой вариант лучше.
Вы можете конфигурировать размер пакета фиксирования в Enterprise Manager, вызвав окно свойств агента распространения Distribution Agent. (См. раздел "Мониторинг и управление агентами репликации" в лекции 26.)
Настройка Log Reader Agent
Как уже говорилось, операции чтения журнала транзакций издателя, выполняемые агентом Log Reader Agent, могут приводить к прерыванию операций ввода-вывода, которые обычно выполняются последовательным образом. Конфигурируя Log Reader Agent, вы можете снизить его влияние на этот журнал. Существует несколько способов сделать операции Log Reader Agent более эффективными. Один из способов – это использование дискового контроллера с кэшем для дискового тома с этим журналом. Поскольку Log Reader Agent выполняет чтение с диска журнала, то кэш на контроллере позволит осуществлять чтение из этого кэша вместо применения операций ввода-вывода с произвольным доступом.
Еще один способ настройки Log Reader Agent – это его конфигурирование для менее частого запуска. Log Reader Agent может работать в непрерывном режиме или периодически. Если в вашей системе не происходит большого количества модификаций, то, возможно, Log Reader Agent может работать непрерывно без нарушения доступа к журналу транзакций. Но при высоком уровне занятости журнала транзакций вашей системы вы можете увеличить производительность издателя, задав менее частые запуски Log Reader Agent. Тогда Log Reader Agent будет выполнять чтение из журнала транзакций реже, что позволит сохранить последовательный доступ для операций ввода-вывода этого журнала.
И еще одним способом повышения эффективности Log Reader Agent в системах с высокой нагрузкой является увеличение размера пакета чтения. Этот размер определяет, сколько транзакций считывается из журнала транзакций и копируется на дистрибьютор за один раз. Использование этого параметра в системах с высокой нагрузкой может повысить производительность. Кроме того, увеличение размера пакета чтения может оказаться полезным при увеличении интервала опроса. Увеличивая размер пакета чтения для Log Reader Agent, вам следует также увеличить размер пакета фиксирования транзакций на дистрибьюторе, чтобы привести его в соответствие с новым размером пакета чтения.
Вы можете конфигурировать агент Log Reader Agent путем вызова окна его свойств в Enterprise Manager. (См. раздел "Мониторинг и управление агентами репликации" в лекции 26.)
Мониторинг системы репликации транзакций
Мониторинг операций репликации транзакций выполняется так же, как и мониторинг других типов репликации, т.е. через Performance Monitor (perfmon). В perfmon имеется ряд объектов, которые добавляются при использовании репликации SQL Server. Это следующие объекты:
SQLServer:Replication Agents. Указывает количество работающих агентов репликации каждого типа.
SQLServer:Replication Dist. Предоставляет информацию о задержке при распространении. Длительные задержки могут быть признаком того, что дистрибьютор перегружен.
SQLServer:Replication Logreader. Предоставляет данные об активности и задержке агента Log Reader Agent. Следите за длительными задержками. Это может быть признаком того, что имеется проблема, касающаяся чтения журнала транзакций на издателе агентом Log Reader Agent. Кроме того, следите за количеством переданных транзакций в секунду. При большом количестве вам, возможно, требуется более мощная подсистема ввода-вывода на дисковых томах журнала транзакций.
Используя Performance Monitor для мониторинга этих значений, вы можете определить наличие проблем производительности Log Reader Agent или дистрибьютора. Данные perfmon дают массу полезной информации, но она не всегда идентифицирует проблемы.
Настройка системы репликации транзакций
Основные шагами в настройке системы репликации транзакций являются надлежащее конфигурирование и мониторинг системы, как это описано в предыдущих разделах. Кроме того, после ввода системы в эксплуатацию, когда вы можете выполнять ее мониторинг, вам, возможно, потребуется изменение интервала опроса. Обычно вполне подходит значение по умолчанию, равное 10 секундам. При увеличении частоты опроса (т.e. уменьшении интервала опроса) транзакции реплицируются быстрее, но увеличивается нагрузка на журнал транзакций. При уменьшении частоты опроса (т.e. увеличении интервала опроса) вы снижаете нагрузку на журнал транзакций, но время репликации транзакций увеличивается.
Кроме того, если в вашей системе происходят частые обновления, вам может потребоваться увеличение размера пакета чтения. Как уже говорилось, это позволит агенту Log Reader Agent считывать за один раз больше транзакций. Если увеличить это значение и оставить интервал опроса в 10 секунд, то будет реплицироваться больше транзакций и станет меньше дополнительная нагрузка.
Вам может также потребоваться мониторинг производительности сети и (при необходимости) ее увеличение, как и в случае репликации снимков. Если ваша система работает неадекватным образом, например, если центральные процессоры и подсистемы ввода-вывода достигли предела своих возможностей, а процесс репликации занимает слишком много времени, то у вас, возможно, имеются сетевые проблемы. К сожалению, сетевые проблемы нельзя диагностировать с помощью perfmon. Следует использовать продукт для мониторинга сети, такой как Microsoft Systems Management Server (SMS). Выполните мониторинг сетевой платы, чтобы определить, не достигла ли она предела своих возможностей.
И, наконец, помните, что издатель, дистрибьютор и подписчики – это системы SQL Server. Поэтому вам следует настраивать эти системы точно так же, как и любую другую систему SQL Server. Рекомендации по настройке систем SQL Server приводятся на протяжении всей этой книги.
Реализация репликации транзакций
В этом разделе вы узнаете о методах реализации репликации транзакций. Она может быть реализована по схеме "один-к-многим" или "многие-к-одному". Репликация транзакций часто реализуется через глобальную сеть (WAN).
Репликация типа "один-к-многим"
В большинстве реализаций репликации транзакций используется схема "один-к-многим". При этом типе реализации одна таблица публикуется для одного или нескольких подписчиков.
Репликация типа "многие-к-одному"
В схеме репликации "многие-к-одному" одна база данных подписывается на более чем одну подписку. Это не самая распространенная схема репликации, но тем не менее она широко используется. Поскольку репликация транзакций выполняется путем чтения журнала транзакций на издателе и применения операций вставки, обновления и удаления на подписчике, то она прекрасно подходит для этой схемы репликации. Единственным потенциальным недостатком является то, что подписывающаяся таблица должна иметь определенный в ней первичный ключ. И если источники ваших данных не портят этот первичный ключ, то схема репликации "многие-к-одному" работает должным образом.
Репликация через глобальную сеть (WAN)
Репликация через глобальную сеть не только возможна, но и довольно широко распространена. Если вы реплицируете данные через глобальную сеть, то вам следует непрерывно следить за операциями распространения и выявлять случаи слишком длительной репликации, связанные с ограничениями пропускной способности сети. Кроме того, если возможно, конфигурируйте репликацию таким образом, чтобы взаимодействие через глобальную сеть выполнялось только агентом Distribution Agent. Это означает конфигурирование системы таким образом, чтобы дистрибьютор и издатель находились по одну сторону глобальной сети.
Заключение
В этой лекции вы ознакомились с основами репликации транзакций. Вы узнали, что такое репликация транзакций, как она выполняется, как осуществлять ее мониторинг и как ее настраивать. Понимание механизма действия репликации транзакций и результатов ее работы поможет вам в ее эффективном использовании и конфигурировании. В следующей лекции вы узнаете о репликации слиянием.
