Защита данных, восстановление РБД

Здесь речь идет о защите данных в БД и приложений, запрашивающих данные.

Для защиты администратор РБД (АРБД) присваивает пропуска [11] для всех зарегистрированных в РБД пользователей и дает им разрешения на выполнение конкретных операций с конкретными данными. Проще всего это можно выполнить, как в СУРБД Oracle, с использованием языка SQL.

В таком случае, как и в централизованной БД, выделяют режимы запрещения и разрешения. К запрещениям относятся пароль, идентификатор пользователя. Они позволяют получить доступ к РБД в целом.

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

Полномочия могут относиться к объектам или системе в целом. Полномочия для отдельных объектов ("внутренность таблицы") предоставляют для какой-либо таблицы конкретным пользователям возможность выполнения операций (INSERT, UPDATE, DELETE). Системные полномочия касаются всей БД: создание, изменение структуры, удаление любой табличной области, опрос любой таблицы (CREATE, ALTER, DROP, SELECT).

Как и в централизованной БД, перечисленные полномочия могут быть отменены (REVOKE).

Для целей защиты АРБД может создавать (использовать) пароли.

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

Если РБД обеспечивает целостные, непротиворечивые данные, говорят об ее корректном состоянии (корректности).

Восстановление (управление восстановлением) связано с приведением системы в корректное состояние после (аппаратного) сбоя. Любой конкретный метод восстановления реагирует на определенный отказ РБД.

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

Система восстановления решает две группы задач:

1) при незначительной неисправности – откат в выполнении текущей транзакции;

2) при существенных отказах – минимизация работы по восстановлению РБД.

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

Копирование изменений возможно после закрытия БД. Однако для РБД с интенсивными обновлениями копирование (архивацию) следует проводить в процессе работы РБД.

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

Процедура восстановления проводится следующим образом.

1. Устраняется аппаратный сбой.

2. Восстанавливаются испорченные файлы данных путем копирования архивных копий и групп регистрации транзакций.

3. Запускается процесс восстановления:

а) с применением транзакций (применение к архивным копиям испорченных данных необходимых групп журнала транзакций);

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

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

Изучим подробнее процесс отказа.

Возможно выделить следующие основные состояния узла: исправный, неисправный (застопоривший, неуправляемый), восстанавливаемый.

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

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

Обсудим два возможных случая работы узлов в надежной сети: без дублирования и с дублированием данных.

При отсутствии дублирования не рассматриваются неуправляемые узлы (узлы с потерей управления).

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

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

одновременного доступа при одновременном упрощении процедуры восстановления.

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

Может быть частичное и полное (в каждом узле находится полная копия РБД) дублирование.

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

Достоинствами метода основной копии являются единственная последовательность корректировки БД и уменьшение вероятности тупика.

В случае чтения во всех доступных узлах и использования активных узлов формируется и вводится список U записей об активных узлах, а основной узел используется для восстановления. "Основная" транзакция при обновлении должна запрашивать обстановку для записи и корректировки данных во всех узлах списка U, включая основной. Удастся избежать некоторых конфликтов (чтение-запись, запись-запись). При наличии отказов и восстановлений список U меняется основным узлом и может возникнуть осложнение.

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

Пример 12.2. Пусть узел 2 восстановился. Он запрашивает информацию о пропущенных транзакциях. Основной узел передает данные по транзакциям Т1, ..., Тn и добавляет узел 2 в список U. Однако транзакция Тn+1, находящаяся в состоянии фиксации, имеет старый список и не будет записывать в узел 2.

Таким образом, надо тщательно продумывать порядок работы, желательно с использованием временны́х диаграмм.

Рис. 12.7. Схема восстановления при потере управления:

t1 – отказ; t2 – выявление отказа; t, – начало восстановления; t4 – конец восстановления

Возможны и другие методы:

1) выбор нового основного узла при отказе прежнего, при этом прежний узел должен быть восстанавливаемым, а новый – "видеть" обстановку, сложившуюся в прежнем узле. Доступ упрощается, но усложняется восстановление;

2) голосование по большинству: если откажут все узлы фрагмента, надо подождать восстановления мажоритарной группы.

Схема восстановления одного из узлов показана на рис. 12.7.

Пусть в момент t1 отказал узел 2 и его БД разрушилась. Если узел 2 не будет исправлен до момента времени t5, то отказ узлов 1 или 2 приведет к серьезному сбою. Узел 2 выявляет свой отказ к моменту t, и начинает восстанавливаться, используя "снимки" других узлов. На интервале t3 – t4 исправные узлы должны продолжать выполнение транзакций, которые должен запоминать узел 2 (и обрабатывать после момента t4). С момента t4 узел 2 присоединяется к остальным и система может выдержать второй отказ.