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

Кроме того, могут возникнуть проблемы при использовании параметра max text repl size, который задает максимальный размер данных типа text или image, которые могут участвовать в репликации. Убедитесь в том, что этому параметру, задаваемому на уровне сервера, присвоено достаточно высокое значение, соответствующее требованиям системы репликации.

Репликация с непосредственным обновлением баз данных подписчиков

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

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

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

Должны быть предусмотрены высокоскоростные, надежные соединения между издателем и всеми подписчиками, допускающими непосредственное обновление, та-

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

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

Совместное применение различных типов репликации

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

В качестве примера приложения, в ходе эксплуатации которого может потребоваться применение нескольких типов репликации, рассмотрим склад оборудования, состоящий из нескольких участков, на которых оборудование передается пользователям по накладным; перед разработчиками системы стоит задача вести актуальную информацию о состоянии запасов и сохранять копии накладных, поступающих на все участки. На каждом участке установлена отдельная локальная СУБД SQL Server, в которой хранится информация о запасах и на всем складе, и на данном участке. Информация, представленная в накладных, передается с отдельных участков в центральную диспетчерскую по сети. Затем полученная информация распространяется по всем остальным участкам с помощью системы транзакционной репликации в целях обновления сведений о запасах. Кроме того, с помощью системы репликации необходимо обеспечить еженедельное обновление информации о накладных и запасах еще в одной базе данных. Информация, хранящаяся в этой базе данных, используется для делового анализа и подготовки еженедельных отчетов. Передача информации об обновлениях в последнюю указаньг) базу данных происходит каждую неделю с помощью отдельной системы публикации снимков, которая охватывает те же таблицы, которые используются в системе репликации с непосредственным обновлением баз данных подписчиков.

Топология репликации

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

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

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

Простые модели репликации

Вначале рассмотрим более простые модели. После ознакомления с этими моделями мы сможем перейти к рассмотрению некоторых вариантов их применения и способов комбинирования.

Централизованный издатель/распределитель

Эта модель используется в СУБД SQL Server по умолчанию. Как показано на рис. 20.8, в системе репликации один и тот же узел действует и как издатель, и как распределитель. Этот издатель/распределитель поддерживает любое число подписчиков. В распоряжении издателя находятся все данные, подлежащие репликации, и он является единственным источником данных, распространяемых с помощью средств репликации.

Издатель/ распределитель!

Подписчик

Издатель

Рис. 20.8. Модель репликации с централизованным издателем/ распределителем