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

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

Прежде чем устанавливать публикуемые базы данных, вы должны установить распределяющий сервер и сконфигурировать распределяемые базы данных. Вы можете настроить распределяющий сервер, используя мастер Configure Distribution Wizard. Этот мастер позволяет сконфигурировать распространитель и распределяемую базу данных и сделать доступным издателя (издателей). При помощи этого мастера вы можете: ♦ сконфигурировать ваш сервер в качестве распространителя так, чтобы его могли использовать другие издатели; ♦ сконфигурировать ваш сервер в качестве издателя так, чтобы он мог работать и как собственный распространитель; ♦ сконфигурировать ваш сервер в качестве издателя, чтобы он использовал другой сервер как распространителя. В этом разделе показан сценарий репликации данных базы данных sample…

Вы можете использовать мастер New Publication Wizard для: ♦ выбора данных и объектов базы данных, для которых вы хотите выполнять репликацию; ♦ фильтрации опубликованных данных таким образом, что подписчики будут получать только те данные, которые им требуются. Предположим, что вы хотите опубликовать данные таблицы employee с сервера NTB01112 на экземпляр NTB01112MNSTANCE1, используя тип репликации «мгновенный снимок». В этом случае единицей публикации является вся таблица employee. Для создания публикации разверните узел сервера в публикующем сервере (NTB01112), разверните папку Replication, щелкните правой кнопкой мыши по папке Local Publications и выберите пункт New Publication. Запустится мастер New Publication Wizard. На первых двух страницах…

Это задача, которая связана с подписчиками, но должна быть выполнена на издателе, имеющем возможность подписки. Используйте SQL Server Management Studio для включения подписчика на сервере издателя. Во-первых, разверните публикующий сервер, разверните узел Replication, щелкните правой кнопкой мыши по узлу Local Subscriptions и выберите пункт New Subscriptions. Появится мастер New Subscription Wizard. Вы можете использовать этот мастер для: ♦ создания для публикации одного или более подписчиков; ♦ указания, где и когда будут запускаться агенты для синхронизации подписки. На первой странице выберите публикацию, для которой вы собираетесь создать одного или более подписчиков, и щелкните по кнопке Next. (В этом примере выберите публикацию…

Репликация данных является предпочтительным методом распределения данных, потому что она дешевле, чем использование распределенных транзакций. Database Engine позволяет выбрать один из четырех возможных типов репликации (репликация мгновенного снимка, репликация транзакции, слияние и одноранговая репликация), в зависимости от используемой вами физической модели. Теоретически в любой модели репликации можно использовать любой тип репликации, хотя каждая (базовая) модель имеет соответствующий тип, который используется в большинстве случаев. Публикация является наименьшей единицей репликации. Одна база данных может иметь множество публикаций с различными типами репликации. Однако каждая публикация соответствует только одной базе данных. Для конфигурирования процесса репликации вы должны в первую очередь настроить распределяющий сервер и…

Задачей оптимизатора является разработка наиболее эффективного плана выполнения для заданного запроса. Эта задача решается с использованием следующих четырех фаз (рис. 20.1).   1. Синтаксический разбор (parsing). Проверяется синтаксис запроса, сам запрос преобразуется в дерево. После этого выполняется проверка всех объектов базы данных, на которые в запросе приводятся ссылки. (Например, проверяется существование всех столбцов, на которые ссылается запрос, и определяются их идентификаторы.) После процесса проверки формируется окончательное дерево запроса. 2. Компиляция запроса (query compilation). Дерево запроса компилируются оптимизатором запросов. 3. Оптимизация запроса (query optimization). В качестве входных данных оптимизатор запросов получает скомпилированное дерево запроса, которое было сгенерировано на предыдущем шаге, и…

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

В процессе анализа запроса оптимизатор проверяет запрос на аргументы поиска, использование оператора or и существование критериев соединения - именно в этом порядке. Поскольку использование оператора or и существование критериев соединения не требуют объяснения, здесь обсуждаются только аргументы поиска. Аргумент поиска является частью запроса, которая ограничивает промежуточный результирующий набор запроса. Основным назначением аргументов поиска является то, что они позволяют использовать существующие индексы применительно к конкретному выражению. Вот примеры аргументов поиска: ♦ emp_fname = 'Moser'; ♦ salary >= 50000; ♦ emp_fname = 'Moser' and salary >= 50000. Существует несколько форм выражений, которые не могут быть использованы оптимизатором в качестве аргументов поиска. К…

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