
- •Определение базы данных и субд. Функции субд.
- •2 Модели данных и их классификация.
- •3 Функциональные зависимости.
- •4 Реляционная модель данных.
- •5 Реляционная алгебра.
- •6 Этапы разработки базы данных.
- •7 Концептуальное проектирование базы данных.
- •8 Целостность данных.
- •9 Критерии согласованности.
- •15 Нормальная форма Бойса-Кодда.
- •16 Транзакции и свойства транзакций.
- •17 Индивидуальный откат транзакций.
- •18 Метод временных меток.
- •19 Блокировки и решение проблем параллелизма.
- •20 Проблемы параллельной работы транзакций.
- •21 Преднамеренные блокировки.
- •22 Виды восстановления данных.
- •23 Восстановление после мягкого и жесткого сбоев.
- •24 Основные команды языка запросов sql.
- •25 Sql. Группировка и вычисления в запросах, соединения.
- •26 Sql. Представления. Хранимые процедуры и функции. Курсоры.
- •27 Способы организации архитектуры баз данных.
- •28 Физические модели хранения данных в субд.
- •29 Защита информации в базах данных.
- •30 Индексирование. Триггеры.
19 Блокировки и решение проблем параллелизма.
Термин параллелизм означает возможность одновременной обработки СУБД нескольких транзакций, запрашивающих одни и те же данные, причем в одно и то же время.
Основная идея блокировки заключается в том, что если для выполнения некоторой транзакции необходимо, чтобы какой-либо объект (как правило, это строка таблицы) не изменился без ведома этой транзакции, то этот объект блокируется. Доступ к заблокированному объекту со стороны других транзакций ограничивается. Следовательно, вызвавшая блокировку транзакция в состоянии выполнить необходимую обработку с учетом того, что обрабатываемый объект не будет самопроизвольно изменяться (с точки зрения данной транзакции) столько времени, сколько потребуется. Блокировки по-другому называют синхронизационными захватами.
Таким образом, использование протокола доступа к данным на основе блокировок разрешает часть проблем параллелизма, но возникает новая проблема – тупики.
20 Проблемы параллельной работы транзакций.
Каким образом транзакции различных пользователей могут мешать друг другу? Различают три основные проблемы параллелизма:
Проблема потери результатов обновления.
Проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное считывание).
Проблема несовместимого анализа.
Рассмотрим подробно эти проблемы.
Рассмотрим
две транзакции, A и B, запускающиеся в
соответствии с некоторыми графиками.
Пусть транзакции работают с некоторыми
объектами базы данных, например со
строками таблицы. Операцию чтение
строки
будем
обозначать
,
где
-
прочитанное значение. Операцию записи
значения
в
строку
будем
обозначать
.
21 Преднамеренные блокировки.
Как видно из анализа поведения транзакций, при использовании протокола доступа к данным не решается проблема фантомов. Это происходит оттого, что были рассмотрены только блокировки на уровне строк. Можно рассматривать блокировки и других объектов базы данных:
Блокировка самой базы данных.
Блокировка файлов базы данных.
Блокировка таблиц базы данных.
Блокировка страниц (Единиц обмена с диском, обычно 2-16 Кб. На одной странице содержится несколько строк одной или нескольких таблиц).
Блокировка отдельных строк таблиц.
Блокировка отдельных полей.
Кроме того, можно блокировать индексы, заголовки таблиц или другие объекты.
Чем крупнее объект блокировки, тем меньше возможностей для параллельной работы. Достоинством блокировок крупных объектов является уменьшение накладных расходов системы и решение проблем, не решаемых с использованием блокировок менее крупных объектов. Например, использование монопольной блокировки на уровне таблицы, очевидно, решает проблему фантомов.
Современные СУБД, как правило, поддерживают минимальный уровень блокировки на уровне строк или страниц. (В старых версиях настольной СУБД Paradox поддерживалась блокировка на уровне отдельных полей.).
22 Виды восстановления данных.
Данные должны храниться в базе данных с избыточностью, позволяющей иметь информацию, по которой восстанавливается состояние базы данных на момент начала неудачной транзакции. Такую избыточность обычно обеспечивает журнал транзакций. Журнал транзакций содержит детали всех операций модификации данных в базе данных, в частности, старое и новое значение модифицированного объекта, системный номер транзакции, модифицировавшей объект и другая информация.
Восстановление базы данных может производиться в следующих случаях:
Индивидуальный откат транзакции. Откат индивидуальной транзакции может быть инициирован либо самой транзакцией путем подачи команды ROLLBACK, либо системой. СУБД может инициировать откат транзакции в случае возникновения какой-либо ошибки в работе транзакции (например, деление на нуль) или если эта транзакция выбрана в качестве жертвы при разрешении тупика.
Мягкий сбой системы (аварийный отказ программного обеспечения). Мягкий сбой характеризуется утратой оперативной памяти системы. При этом поражаются все выполняющиеся в момент сбоя транзакции, теряется содержимое всех буферов базы данных. Данные, хранящиеся на диске, остаются неповрежденными. Мягкий сбой может произойти, например, в результате аварийного отключения электрического питания или в результате неустранимого сбоя процессора.
Жесткий сбой системы (аварийный отказ аппаратуры). Жесткий сбой характеризуется повреждением внешних носителей памяти. Жесткий сбой может произойти, например, в результате поломки головок дисковых накопителей.
Во всех трех случаях основой восстановления является избыточность данных, обеспечиваемая журналом транзакций.