Контрольная работа: Разработка и эксплуатация удаленных баз данных

Централизованный контроль в данной модели выполняется с использованием механизма триггеров, которые являются частью БД.

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

Достоинства: Хранимые процедуры и триггеры хранятся в словаре БД и могут быть использованы несколькими клиентами => уменьшается дублирование алгоритмов обработки данных в разных клиентских приложениях.

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

Для разгрузки сервера была предложена 3-уровневая модель сервера: Эта модель является расширением двухуровневой модели, т.е. вводится дополнительный промежуточный уровень между клиентом и сервером. В этой модели компоненты приложения делятся между тремя исполнителями:

Клиент - обеспечивает логику представления, включая графический пользовательский интерфейс, локальные редакторы.

Серверы приложений - составляют новый, промежуточный уровень архитектуры.

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

удаленная файловый сервер триггер

3. Модели серверов баз данных

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

Вышеперечисленные недостатки устраняются в модели (архитектуре) "систем с выделенным сервером", который способен обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (tread), или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой односерверной.

Достоинства: Уменьшается нагрузка на ОС, возникающая при работе большого числа пользователей.

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

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

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

4. Типы параллелизма

Рассмотрим несколько путей распараллеливания запросов.

Горизонтальный параллелизм возникает, когда хранимая в БД информация распределяется по нескольким физическим устройствам хранения - нескольким дискам. При этом информация из одного отношения разбивается на части по горизонтали. Этот вид параллелизма иногда называют распараллеливанием или сегментацией данных. Параллельность здесь достигается путем выполнения одинаковых операций (например, фильтрации). Результат выполнения целого запроса складывается из результатов выполнения отдельных операций.

Достоинства: Сокращается время выполнения запроса.

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

Достоинства: Сокращается время выполнения запроса.

Гибридный параллелизм. Эти методы позволяют существенно сократить время выполнения сложных запросов над очень большими объемами данных.

5. Модели транзакций

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

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

С точки зрения работника - это единая последовательность операций. Если она будет прервана, то БД потеряет свое целостное состояние.

Свойства транзакций. Способы их завершения

Модели транзакций классифицируются на основании различных свойств: