Управление распределенными базами данных

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

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

• Гетерогенные системы. СУБД должна работать с данными, которые хранятся на различных системах с разной архитектурой и производительностью, включая персональные компьютеры, рабочие станции, серверы ЛВС, мини-компьютеры и мэйнфреймы.

• Прозрачность относительно сети. За исключением различий в производительности, СУБД должна работать одинаково в разнородных сетях, от высокоскоростных ЛВС до низкоскоростных телефонных линий.

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

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

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

• Универсальный доступ. СУБД должна обеспечивать единую методику доступа ко всем данным предприятия.

Ни одна из существующих распределенных СУБД по своим возможностям не соответствует этому идеалу. Имеются препятствия, из-за которых с трудом реализуются даже простые формы управления распределенными базами данных. К ним относятся:

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

• Проблема сохранения целостности данных. Чтобы при выполнении распределенных транзакций соблюдался принцип " все или ничего", необходимо активное взаимодействие двух или более независимых СУБД, работающих в различных вычислительных системах. При этом должны использоваться специальные протоколы двухфазного завершения транзакций, которые приводят к повышению сетевого трафика и длительной блокировке тех частей баз данных, которые участвуют в распределенной транзакции.

• Проблема, связанная с планом выполнения статического SQL. Встроенная статическая инструкция SQL компилируется и сохраняется в базе данных в виде плана выполнения. Когда запрос объединяет данные из двух или более баз данных, в какой из них следует хранить план выполнения? Может, необходимо иметь два или более согласованных плана? А если изменяется структура одной базы данных, то как можно изменить план выполнения в другой базе данных? Применение динамического SQL в сетевой среде для решения этой проблемы практически всегда ведет к неприемлемому снижению производительности приложений из-за повышения сетевого трафика и многочисленных задержек.

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

• Проблема совместимости данных. В различных вычислительных системах суще­ствуют разные типы данных, и даже когда в двух системах присутствуют данные одного и того же типа, они могут иметь разные форматы. Например, в компьютерах VAX и Macintosh 16-разрядные целые числа представляются по-разному.

Для представления символов в мэйнфреймах компании IBM используется кодировка EBCDIC, а в персональных компьютерах — кодировка ASCII. В распределенной СУБД эти различия должны быть незаметны.

• Проблема хранения системных каталогов. Во время работы СУБД часто обращается к своим системным каталогам. Где в распределенной базе данных следует хранить каталог? Если он будет храниться в одной системе, то удаленный доступ к каталогу будет медленным, что может парализовать работу СУБД. Если расположить его в нескольких различных системах, то изменения в каталоге придет распространять по сети и синхронизировать.

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

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

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

Контрольные вопросы

1. Перечислите основные функции ODBC для работы с системными каталогами.

2. Какие расширенные возможности(по сравнению с SQL/CLI) предоставляет ODBC?

3. Какие преимущества обеспечивает механизм управления сеансами ODBC?

4. Каким требованиям должна отвечать идеальная система управления распределенными базами данных.