Некоторые проблемы администрирования баз данных

Размещено на http://www.allbest.ru/

Курсовая работа

Некоторые проблемы администрирования баз данных



Содержание

1. Оптимизация запросов

2. Параллельная обработка данных

3. Технические аспекты администрирования базы данных

4. Распределенные системы баз данных

5. Нераспределенные мультибазовые СУБД

Литература



1. Оптимизация запросов

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

В реляционных системах процесс реоптимизации - это просто повторная обработка исходного запроса системным оптимизатором. В-третьих, оптимизатор - это программа, поэтому он более "настойчив" по сравнению с человеком. Оптимизатор вполне способен рассматривать буквально сотни различных стратегий реализации данного запроса, в то время как программист вряд ли изучает более трех-четырех стратегий.

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



(((Поставки JOIN (Детали WHERE Имя_Д='Тестер'))JOIN Поставщики))[Имя_П].

SELECT Поставщики.Имя_ПFROM Поставщики, Детали,

ПоставкиWHERE Поставщики.ПN=Поставки.ПNAND Поставки.ДN=Детали.ДNAND Детали.Имя_Д='Тестер';

Предположим, что существует порядка 100 строк поставщиков, 50 000 строк поставок и 200 строк деталей. Примерно 1% поставок приходится на деталь «Тестер». Будем полагать, что за одно считывание в оперативную память передается одна запись.

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

1. Выполнить соединение ПОСТАВЩИКИ и ПОСТАВКИ по атрибуту ПN. В худшем случае (при отсутствии индексов и кластеров) для этого потребуется считать 100 записей о поставщиках и для каждой из них считать все 50 000 записей поставок, чтобы создать возможные соединения, т.е. потребуется произвести 100Ч50 000 (5 миллионов) считываний. В результате будет получено временное отношение Temp1, состоящее из 50 000 строк поставок, соединенных с соответствующими строками поставщиков.

2. Выполнить соединение Temp1 с ДЕТАЛИ по атрибуту ДN. Для этого потребуется считать 50 000 строк отношения Temp1 и каждую из них сравнить с 200 строками ДЕТАЛИ. Потребуется произвести 50 000Ч200 (10 миллионов) считываний.

3. Результатом этого соединения будет временное отношение Temp2, состоящее из всех данных о поставках и поставщиках отношения Temp1, к которым добавлены данные о деталях. Отношение по-прежнему будет состоять из 50 000 строк, но сами строки будут очень длинными, так как они теперь содержат атрибуты всех трех отношений.

4. Произвести выборку всех строк отношения Temp2, в которых название детали имеет значение «Тестер». Для этого требуется считать 50000 строк отношения Temp2 и отобрать только те строки, атрибут ДЕТАЛИ которых имеет значение «Тестер». В результате получится временное отношение Temp3, состоящее из 500 строк.

5. Выполнить проекцию Temp3 по Имя_П, чтобы получить окончательный результат. Для этого требуется считать 500 строк отношения Temp3, выполнить проекцию и возвратить результат.

Итак, суммарное количество считываний при такой последовательности выполнения запроса составит 5 000 000 + 10 000 000 + 50 000 + 500, т.е. 15 050 500 считываний.

Такой же результат можно получить, выполнив первые три шага в обратном порядке:

6. Выполнить выборку строк отношения ДЕТАЛИ, в которых Имя_Д = 'Тестер'. Для этого требуется считать 200 строк отношения ДЕТАЛИ, в результате получится временное отношение T1, состоящее из 1 строки.

7. Выполнить соединение T1 с ПОСТАВКИ. Для одной строки T1 считывается 50 000 строк поставок, в результате соединения получается временное отношение T2, состоящее из 500 строк.

8. Выполнить соединение T2 с ПОСТАВЩИКИ. Для каждой из 500 строк отношения T2 считывается 100 строк клиентов, т.е. производится 50 000 считываний и в результате получается временное отношение T3 из 500 строк, содержащее всю информацию о поставщиках, поставках и детали.

9. Выполнить проекцию T3 по атрибуту Имя_П и получить требуемый результат. Для этого считывается 500 строк отношения T3 и выполняется проекция.

При выполнении запроса в такой последовательности потребуется 200 + 50 000 + 50 000 +500 = 100 700 считываний, что в 150 раз меньше, чем при использовании первой стратегии отбора. Приведенный пример показывает, что даже простая база данных может функционировать в 150 раз быстрее, используя правильную стратегию обработки запроса.

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

Рассмотрим три отношения А, В и С с атрибутами - А.Х, A.Y, A.Z, B.I, B.J, В.Н, C.L, С.М и C.N соответственно. Для последовательностей реляционных операций существуют следующие правила эквивалентности.

1. Join (A,B) where A.X=B.IR1

Restrict (R1) on R1.Y

Restrict A on A.YR1

Join (R1,B) where R1.X = B.I

То есть, соединение (Join) двух отношений, за которым следует выборка (Restrict) в результирующем отношении, дает тот же результат, что и первоначальное выполнение выборки в соответствующем отношении (A) и последующее соединение полученного отношения (R1) со вторым отношением (B).

Join (A,B) where A.X=B.IR1

Project (R1) on R1.Y

Project (A) on A.Y, A.XR1

Project (B) on B.IR2

Join (R1.R2) where R1.X = R2.lR3

Project (R3) on R3.Y

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

Restrict (A) on A.XR1

Restrict (R1) on R1.Y

Restrict (A) on A.X and A.Y

То есть, последовательные выборки (Restrict), использующие значения атрибутов одного отношения, можно сгруппировать в одну выборку.

2. Restrict (A) on A.XR1

Project (R1) on R1.Y

Project (A) on A.X, A.YR1

Restrict (R1) on A.XR2

Project (R2) on R2.Y



Согласно этому правилу, если в отношении за выборкой (Restrict) следует проекция (Project), того же результата можно достичь с помощью проекции, за которой следует выборка. Если атрибут, по которому выполнялась выборка (А.Х), не является частью конечного результата, его нужно включить в первую проекцию, а затем исключить с помощью последней операции проекции.

Join (A,B) where A.X=B.I

Join (B,A) where B.I=A.X

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

Join (A,B) where A.X=B.IR1

Join (R1,С) where R1.I=C.L

Join (B,C) where B.I=C.LR1

Join (R1,A) where R1.I=A.X

Это правило гласит, что при соединении трех и более отношений соединения можно выполнять в произвольной последовательности.

Правила эквивалентности дают множество путей выполнения заданного запроса. Желательно, чтобы соединения выполнялись как можно позже, так как для выполнения соединений требуется много повторных считываний одного и того же отношения, чтобы найти совпадающие значения атрибутов. Чем меньше соединяемые отношения, тем быстрее удастся выполнить соединение. В рассмотренном примере второй способ эффективнее первого, потому что выборка в отношении ДЕТАЛИ была выполнена раньше, чем выполнялись соединения. Поскольку только одна строка из 200 удовлетворяла условию, удалось сократить соединение ДЕТАЛИ с ПОСТАВКАМИ на 99,5%. Также предпочтительней выполнять проекции перед соединением, поскольку это позволяет уменьшить ширину промежуточных отношений и для их хранения может потребоваться меньше страниц памяти. В нашем примере, вероятно, можно добиться дальнейшего сокращения числа операций ввода-вывода, если выполнить в самом начале проекции по ПОСТАВЩИКИ.ПN, ПОСТАВЩИКИ. Имя_П, ПОСТАВКИ.ПN, ПОСТАВКИ.ДN, ДЕТАЛИ.ДN, ДЕТАЛИ. Имя_Д. Благодаря этому промежуточные отношения станут намного меньше, возможно, они даже полностью разместятся в оперативной памяти, что позволит вовсе избежать операций ввода-вывода.

Чтобы по-настоящему оптимизировать базу данных, нужно обладать статистической информацией о ней. Предположим, имеются три отношения А, В и С, причем А содержит 1000 строк, В - 1000, а С - 10. Каждую из 1000 строк отношения А нужно проверить на возможность соединения с одной из 1000 строк отношения В, а 10 строк отношения С нужно сравнить с 1000 строками отношения В. Используя правило эквивалентности 6, можно выполнить соединение этих трех отношений двумя способами.

1. Join (A,B) R1 (10001000 считываний, предположим, что получится 1000 строк)Join (R1,C) Result (100010 считываний)

2. Join (В,С) R1 (100010 считываний, может получиться 10 строк)Join (R1,A) Result (101000 считываний)

В первом случае понадобится 1 010 000 считываний, во втором - 20 000; экономия составит до 98%. Таким образом, соединения нужно выполнять в таком порядке, который позволит как можно быстрее уменьшить количество строк. Система базы данных сможет это сделать только в том случае, если она обладает статистической информацией о размерах файлов, строк и доле совпадений внешних ключей различных отношений. Тогда можно приблизительно оценить вероятное количество необходимых операций ввода-вывода для различных последовательностей выполнения операций.

При оптимизации запросов СУБД должна также принимать во внимание существование таких объектов базы данных, как индексы, хеш-индексы и кластеры.

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

На соединения по внешним ключам большое влияние оказывают индексы. Рассмотрим соединение двух отношений А и В, где X - первичный ключ А и внешний ключ В.

Join (A,B) where A.X = В.Х

Если в отношении В существует индекс по атрибуту X, то скорость соединения существенно возрастает: для каждой строки А производится поиск в индексе В.Х и соединяются извлеченные строки. Если индекс В.Х отсутствует, для нахождения в отношении В множества строк, соответствующих каждой определенной строке А, придется полностью его сканировать. Правило эквивалентности 5 гласит, что порядок вхождения отношений в оператор Join не влияет на его результат. Если в отношении А существует индекс по первичному ключу, а в отношении В индекса по внешнему ключу нет, то, вероятно, лучше взять отношение В и для каждой его строки находить соответствующую строку отношения А с помощью индекса А.Х.

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

2. Параллельная обработка данных

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

Однако при несоблюдении определенных правил, параллельная обработка может приводить к нарушению целостности базы данных. Рассмотрим некоторые характерные проблемы, возникающие при параллельном выполнении транзакций.

Потеря обновления

Предположим, что выполняются две транзакции, Т1 и Т2, состоящие из следующих команд.

Т1:UPDATE ACCOUNTSSET BALANCE = BALANCE +100 WHERE ACCNO =1234;

Т2:UPDATE ACCOUNTSSET BALANCE = BALANCE + 200 WHERE ACCNO = 1234;



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

1. Т1 считывает запись счета 1234. Значение баланса равно 150.

2. Т2 считывает запись счета 1234. Значение баланса равно 150.

3. Т1 увеличивает баланс счета до 250 (150 + 100).

4. Т2 увеличивает баланс счета до 350 (150 + 200).

5. Т1 заносит на диск запись с балансом 250.

6. Т2 заносит на диск запись с балансом 350.

Итоговое значение баланса должно равняться 450, а не 350! Обновление, выполненное транзакцией Т1, оказалось потерянным.

Зависимость от незафиксированных обновлений

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

Т1: UPDATE ACCOUNTSSET BALANCE = BALANCE - 100WHERE ACCNO =1234;IF BALANCE<0.00 THEN ROLLBACK ELSE COMMIT;

Т2:DELETE FROM ACCOUNTS WHERE BALANCE<0.00;

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

1. Т1 извлекает счет 1234. Значение баланса 50.

2. Т1 уменьшает значение баланса на 100, он становится равным -50.

3. Т1 заносит в базу данных запись со значением -50.

4. Т2 извлекает счет 1234. Баланс равен -50.

5. Т2 удаляет счет 1234, так как он имеет отрицательный баланс.

6. Т1 выполняет отмену обновления, но уже поздно - счет уже удален!

Эта ситуация называется зависимостью от незафиксированного обновления. Действия транзакции Т2 были основаны на данных, которые еще не были зафиксированы и это послужило потерей данных.

Несогласованный анализ

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

Т1:SELECT SUM(BALANCE) FROM ACCOUNTS;

Т2:UPDATE ACCOUNTSSET BALANCE = BALANCE - 100 WHERE ACCNO = 3;UPDATE ACCOUNTSSET BALANCE = BALANCE + 100 WHERE ACCNO = 1;

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

1. Т1 извлекает счет 1. Баланс равен 100. Вычисляемая сумма 100.

2. Т2 извлекает счет 3. Баланс равен 100.

3. Т1 извлекает счет 2. Баланс равен 100. Вычисляемая сумма 200.

4. Т2 обновляет значение баланса счета 3. Оно становится равным 0.

5. Т1 извлекает счет 3. Баланс равен 0. Сумма 200.

6. Т2 извлекает счет 1. Баланс равен 100.

7. Т1 извлекает счет 4. Баланс 100. Сумма 300.

8. Т2 обновляет баланс счета 1, он становится равным 200.

Транзакция Т1 сообщит, что сумма балансов всех счетов равна 300, в то время как на самом деле она равна 400. Эта ситуация называется несогласованным анализом.

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

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

Это означает, что, когда две транзакции используют один и тот же объект, одной из них придется ожидать, пока транзакция, которая первой успела заблокировать объект, освободит его. Таким образом, могут создаваться "очереди блокировок" к объектам, которые используются множеством транзакций.

Блокировки могут быть неполными. Если две транзакции просто считывают одно и то же множество данных, не производя никаких обновлений, им не нужно блокировать данные друг от друга. Поэтому существует два типа блокировок: совместная (shared, S) и исключающая (exclusive, X).

Если доступ к объекту осуществляется только для чтения, то на него налагается совместная S-блокировка. Исключающая X-блокировка налагается на объект, который подвергается изменениям (обновляется или удаляется). Таким образом, действует следующий протокол:

– Если на объект наложен S-блок, на него можно налагать другие S-блоки. Транзакция, которой требуется Х-блок, должна ожидать, пока будут сняты все S-блоки.

– Если на объект наложен Х-блок, никакие другие блоки на него налагать нельзя. Все транзакции, которым требуется блок (X или S), должны ожидать, пока этот Х-блок будет снят.

Данный протокол означает, что при выполнении операции, включающей только чтение (например, SQL-оператор SELECT), по отношению к этому объекту могут параллельно выполняться и другие подобные операции. При выполнении операции обновления другие операции выполняться не могут. Этот протокол позволяет избежать перечисленных выше проблем параллельной обработки. Потеря обновления исключается, поскольку транзакция Т1 заблокирует счет 1234, прежде чем приступить к обновлению, и транзакция Т2 не сможет начать выполнение своих обновлений до тех пор, пока Т1 не закончит свои. Удается также избежать зависимости от незафиксированных значений, так как до тех пор, пока Т1 не завершит откат, она будет блокировать счет 1234 (т.е. Т2 не сможет получить к нему доступ). Что касается несогласованного анализа, Т1 наложит на все считываемые записи счетов S-блок. Таким образом, Х-блок, запрашиваемый Т2, не будет предоставлен ей до тех пор, пока Т1 не завершит свой анализ.

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

Обе транзакции собираются запросить Х-блок на объект 1. Если Т1 - логически первая транзакция, тогда важно гарантировать, что она получит этот блок раньше, чем Т2. Предположим, что блокировки снимаются сразу же после того, как закончена соответствующая обработка объекта. Тогда при одновременной работе транзакций возможна такая последовательность событий:

1. Т1 налагает S-блок на объект 1.

2. Т2 налагает S-блок на объект 1.

3. Т1 снимает S-блок с объекта 1 и налагает S-блок на объект 2.

4. Т2 налагает Х-блок на объект 1 (она может это сделать, поскольку Т1 сняла свою S-блокировку с данного объекта).

5. Т1 снимает S-блок с объекта 2. Теперь она должна ожидать предоставления Х-блока на объект 1.

6. Т2 снимает Х-блок с объекта 1 и налагает S-блок на объект 2.

7. Т1 налагает Х-блок на объект 1.

8. Т2 снимает S-блок с объекта 2.

9. Т1 снимает Х-блок с объекта 1.

В результате транзакция Т2 обновила объект 1 прежде, чем это сделала транзакция Т1. Такая последовательность действий ошибочна, поскольку Т1 - логически первая транзакция, т.е. ее результат должен быть зафиксирован в базе данных прежде, чем результат транзакции Т2. Рассматриваемое расписание событий противоречит принципу сериализации.

Принцип сериализации требует, чтобы при параллельном выполнении двух транзакций их результаты были такими же, как и в том случае, когда они выполняются строго последовательно, т.е. следующая транзакция не начинается до тех пор, пока предыдущая не завершится полностью. Таким образом, сериализация занимается рассмотрением конфликтующих запросов. В нашем примере конфликтующими запросами были запросы обеих транзакций на Х-блок объекта 1. График событий для определенного множества транзакций называется сериализуемым в случае, когда конфликтующие запросы в нем представлены в том же порядке, как если бы транзакции выполнялись последовательно. Другими словами, Х-блок на объект 1 должен запрашиваться транзакцией Т1 до того, как он запрашивается Т2.

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

В нашем сценарии Т1 не получит Х-блок на объект 1, если она к тому времени снимет S-блокировку с этого объекта, поэтому она ее не снимает. Следовательно, график событий будет таким.

1. Т1 налагает S-блок на объект 1.

2. Т2 налагает S-блок на объект 1.

3. Т1 налагает S-блок на объект 2.

4. Т2 запрашивает Х-блок на объект 1. Запрос отклоняется. Т2 ожидает.

5. Т1 налагает Х-блок на объект 1.

6. Т1 снимает все блоки.

7. Т2 налагает Х-блок на объект 1.

8. Т2 налагает S-блок на объект 2.

9. Т2 снимает все блоки.

Протокол называется двухфазным потому, что все транзакции проходят две фазы: фазу получения и фазу снятия блокировок. В большинстве систем вторая фаза откладывается до самого конца транзакции, когда транзакция готова выполнить фиксацию или откат, и блокировки снимаются только в этот момент (как и в рассмотренном примере), хотя такие действия не всегда обязательны. В нашем сценарии, например, Т1 может снять S-блок с объекта 2 перед тем, как наложить Х-блокировку на объект 1. Однако, откладывая снятие блокировок до окончания транзакции, система избегает необходимости анализировать будущие требования блокировок.



3.Технические аспекты администрирования базы данных

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

Восстановление базы данных

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

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

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

· записывать в архив все находящиеся в данный момент в оперативной памяти исходные записи и записи преобразований;

· записывать все модифицированные значения в базу данных;

· заносить в архив дату и время создания этой контрольной точки.

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

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

Безопасность баз данных

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

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

Между ними есть и некоторое сходство - как при обеспечении безопасности, так и при обеспечении целостности система вынуждена проверить, не нарушают ли выполняемые пользователем действия некоторых правил.

Среди многочисленных аспектов проблемы безопасности необходимо отметить следующие:

- Правовые, общественные и этические аспекты (имеет ли право некоторое лицо получить запрашиваемую информацию, например о кредите клиента).

- Физические условия (например, закрыт ли данный компьютер или терминальная комната или защищен каким-либо другим образом).

- Организационные вопросы (например, как в рамках предприятия, обладающего некой системой, организован доступ к данным).

- Вопросы реализации управления (например, если используется метод доступа по паролю, то как организована реализация управления и как часто меняются пароли).

- Аппаратное обеспечение (обеспечиваются ли меры безопасности на аппаратном уровне, например, с помощью защитных ключей или привилегированного режима управления).

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

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

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

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

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

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

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

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

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

В общем случае, при избирательном управлении доступом правила безопасности обладают пятью компонентами.

1. Имя (правило будет зарегистрировано в системном каталоге под этим именем; это имя появится в любом системном сообщении или сообщении о состоянии системы в ответ на нарушение этого правила).

2. Одна или несколько привилегий (например, RETRIVE или DELETE).

3. Диапазон, к которому это правило применяется (например, в качестве диапазона могут рассматриваться все кортежи поставщиков из Минска).

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

5. Реакция на нарушение правил сообщает системе, что делать, если пользователь нарушил правила безопасности.

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

Для обязательного управления доступом действуют два правила безопасности:

1. Пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.

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

Шифрование данных

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

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

Более надежным считается метод шифрования на основе открытого ключа, когда доступны как алгоритм шифрования, так и ключ шифрования, а в секрете хранится только ключ расшифровки. Ключ расшифровки не может быть выведен из ключа шифрования.

Производительность баз данных

Как правило, в многопользовательских системах администратору разрешается задавать параметры настройки системы - какая часть базы данных может преобразовываться в оперативной памяти в конкретный момент времени, сколько исходных и преобразованных данных должно быть буферизовано, сколько процессов может одновременно инициировать отдельный пользователь, сколько блокировок может получить отдельная транзакция и т.д. Администратор базы данных должен контролировать возможные блокировки объектов базы данных, так как существует опасность возникновения взаимной блокировки (deadlock). Пусть, например, две транзакции Т1 и Т2 используют объекты О1 и O2 базы данных. Может возникнуть ситуация, когда обеим транзакциям требуются блокировки обоих объектов. Рассмотрим такую последовательность событий:

1. Т1 блокирует объект О1.

2. Т2 блокирует объект О2.

3. Т1 запрашивает блокировку объекта О2. Ей необходимо ожидать.

4. Т2 запрашивает блокировку объекта О1. Ей также приходится ожидать.

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

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

Важный аспект производительности базы данных - ее доступность. Администратор должен следить за тем, чтобы стандартные "внутренние" процедуры, такие как создание архивных копий базы данных и проведение модернизаций, как можно меньше отражались на использовании базы данных.

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

Администрирование данных

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

4. Распределенные системы баз данных

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

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

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

Прозрачность данных и независимость от размещения - две взаимодополняющие технические задачи распределенной системы баз данных. Они должны поддерживать достижение распределенной системой ее операционных целей.

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

1. Необходима большая дополнительная работа по обеспечению коммуникаций. Пересылаются большие объемы данных, а это происходит медленно и приводит к значительным затратам.

2. На перегруженной центральной машине возможны проблемы функционирования.

3. Возникает чрезмерная зависимость от центральной машины. В результате ее сбоя вся корпоративная база данных становится недоступной.

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

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

2. Повышается производительность обработки данных. Вместо одной машины базу данных обслуживает несколько машин.

3. Ликвидируется зависимость от центрального узла. При сбое машины страдает только локальная часть системы баз данных, остальные базы данных сохраняют работоспособность и доступность.

4. База данных становится ближе к ее пользователям. Локальное хранение данных приводит к изменению стиля работы организации, поскольку пользователям больше не нужно обращаться к удаленному центру для получения доступа к необходимым оперативным данным и их использования. В локальных системах пользователи могут принимать непосредственное участие в управлении и функционировании базы данных (что не всегда является преимуществом).

Таким образом, распределенные базы данных призваны решить следующие задачи:

1. Обеспечить прозрачность данных.

2. Обеспечить независимость от размещения.

3. Уменьшить количество работы по обеспечению коммуникаций.

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

5. Ликвидировать чрезмерную зависимость от центра.

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

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

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

Фрагментация

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

В распределенной системе, состоящей из кооперированных реляционных баз данных, возможны два типа фрагментации.

1. Горизонтальная фрагментация. Это процесс разбиения отношения на подмножества кортежей, когда в каждом узле хранится определенное подмножество. Например, в рассмотренной нами базе данных Проекты-Поставщики-Поставки отношение Поставки может быть разбито на подмножества, соответствующие проектам, которые могут храниться в разных узлах.

2. Вертикальная фрагментация. Это процесс разбиения отношения по атрибутам.

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

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

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

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

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

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

Распространение обновлений

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

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

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

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

Один из методов, позволяющий частично решить проблему доступности, - это стратегия первичной копии: для каждого реплицируемого объекта выделяется один узел, который объявляется хранителем первичной копии (primary copy) данного объекта. Когда производится обновление в масштабах системы, хранящий первичную копию узел запрашивает предоставление блоков в рамках всей системы. Если узел, содержащий первичную копию, зафиксировал обновление, операция обновления считается завершенной. Это означает, что все другие узлы, которые пытаются выполнить фиксацию, могут использовать данный объект базы данных так, как если бы он был уже изменен повсюду. В узлах, которые вследствие возникновения локальных проблем не могут завершить фиксацию, просто локально блокируется использование данного конкретного объекта. Это не влияет на функционирование остальных узлов.

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