в распределенной базе данных используется несколько СУБД, что требует активной совместной работы СУБД, поставляемых конкурирующими компаниями. Но такое маловероятно.

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

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

Практические подходы к управлению распределенными базами данных

Из-за указанных препятствий поставщики СУБД вводят управление распределенными данными последовательно, щаг за шагом. Например, сначала в СУБД может появиться модуль, позволяющий извлекать набор записей из главной базы данных и рассылать его по сети в подчиненные базы данных. Затем этот модуль будет усовершенствован и позволит отслеживать изменения в главной базе данных, произошедшие с момента последней выборки, чтобы можно было загружать только изменения. В следующей версии СУБД модуль уже будет располагать средствами автоматического управления всем процессом. Точно так же СУБД может первоначально позволять пользователю одной системы делать запросы к базе данных, размещенной в другой системе. В новой версии СУБД будет разрешено включать запрос к удаленной базе данных в качестве подчиненного в запрос к локальным таблицам. В последующих версиях возможности управления распределенными данными будут расширяться, приближаясь к поставленной цели: обеспечению универсального и прозрачного доступа к данным.

Доступ к удаленным базам данных

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

Локальный сервер

Удаленный сераер

n-jnarbhM SQL запрос ПК -

Результаты

СУБД

СУБД

Клиент серверный запрос * fipyroi --

Локальная база данных

Удаленная база данных

Ш удал0нмой базе данных

Для сравнения на рис 22 2 изображена схема выполнения обьгшого клиент-серверного запроса к удаленной базе данных, направленного пользователем другого ПК С точки зрения удаленной базы данньгх, разница между обработкой запроса от обычного кли-егггского ПК и запроса, полученного по специальной технологии удаленного доступа, очень невелика В обоих сл>чаях запрос передается по сети, удалегзная СУБД определяет, имеет ли пользователь нужные прггвилегии, и выпо/гняет запрос Информация о гом, чем завершилось вьшолнение запроса, передается обратно по сети

А вот локальная СУБД, участвуюшая в процессе, изображенном на рис 22 2, должна выполнять совершенно иные действия, чем при вьшолнении обычного локального запроса У нее несколько задач

ш она должна определить, к какой удаленной базе данньгх обращается пользователь и как ее найти в сети,

ш она должна установить соединение с этой базой данных для выполнения удаленного запроса,

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

стандартное клиент-серверное подключение к удаленной СУБД, в котором сама

выступает в качестве клиента

Несколько ведуших производителей СУБД предлагают различные реализации

описанной схемы удаленного доступа Они отличаются деталями оргаггизации работы

пользователя и администратора базы данных В одних случаях СУБД поддерживает

специальные расширения языка SQL, в других же механизм установки соединения практически не связан с SQL

Например, Sybase Adaptive Server позволяет очень просто получить доступ к удаленной базе данных с помошью средств Component Integratmn Servюes Подключившись к локальному серверу Sybase, пользователь может направить ему инструкцию connect то, в которой должен указать известное локальному серверу имя удаленного сервера Например, если имеется удаленный сервер с именем central-host, тогда инструкция

CONNECT то CENTRALHOST

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

Когда работа с удаленным сервером окончена, нужно всего лишь выполнить инструкцию disconnect в отвез режим сквозной передачи будет отменен, а локальный сервер снова станет текущим За исключением пары инструкций connect/disconnect весь механизм управления удаленным сервером реализован вне языка SQL Администратор базы данных предоставляет локальному серверу всю необходимую информацию о наличии удаленных серверов, их местоположении и именах посредством системных хранимых процедур spaddserver () и spdropser-ver () По умолчанию для доступа к удаленному серверу используются текущие имя и пароль пользователя, но в качестве альтернативы администратор базы данньгх может задать для удаленного сервера специальные имя и пароль пользователя, опять же посредством системных хранимых процедур Sybase предлагает и другие, более сложные возможности управления распределенными базами данных, но описанный базовый механизм обладает неоценимым преимушеством - предельной простотой

в Oracle используется иная схема организации доступа к удаленным базам данных необходимо, чтобы как на локальном, так и на удаленном сервере помимо СУБД была установлена программа SQL*Net Администратор базы данных отвечает за создание одного или нескольких именованных каналов связи (между локальной и удаленными базами данных) Каждый канал определяет

местоположение удаленного компьютера в сети,

используемый коммуникационный протокол,

имя базы данных Oracle на удаленном сервере,

имя и пароль пользователя для подключения к удаленной базе данных

Весь доступ к удаленным базам данных осуществляется через каналы связи и ограничивается привилегиями, предоставленными пользователю в удаленной системе Можно сказать, что определение канала связи содержит ответы на такие вопросы какая база данных , как с ней взаимодействовать и каковы привилегии пользователя Администратор назначает каждому каналу собственное имя Каналы связи могут быть персональными (созданными для конкретного пользователя локальной Системы) или общими (доступными для многих пользователей локальной системы) Для доступа к удаленной базе данных пользователь локальной системы применяет Стандартные инструкции SQL, только к именам удаленных таблиц и представлений добавляется символ <§>, за которым следует имя канала связи Предположим, напри-ер, что вы работаете с учебной базой данных через канал с именем centralhost Следующая инструкция возвращает информацию из таблицы salesreps