Приложение 2. Журнализация изменений базы данных
Одним из основных требований является надежность хранения баз данных. Это требование предполагает возможность восстановления согласованного состояния базы данных после любого программного или аппаратного сбоя.
Типичная СУБД должна предоставлять такие функции восстановления, как:
механизм резервного копирования, предназначенный для периодического создания копий базы данных;
средства ведения журнала, в котором фиксируются текущее состояние транзакций и вносимые в базы данных изменения;
функция создания контрольных точек, обеспечивающая перенос выполняемых в базе данных изменений во вторичную помять с целью сделать их постоянными;
менеджер восстановления, обеспечивающий восстановление согласованного состояния базы данных, нарушенного в результате отказа.
Указанные механизмы восстановления рассмотрены в учебном пособии [18] в приложении 2 (Журнал транзакций).
Там же рассмотрены ситуации при которых требуется производить восстановление состояния базы данных:
Индивидуальный откат транзакции.
Восстановление после внезапной потери содержимого оперативной памяти (мягкий сбой).
Восстановление после поломки основного внешнего носителя базы данных (жесткий сбой).
Общей целью журнализации изменений базы данных является обеспечение возможности восстановления согласованного состояния базы данных после любого сбоя. Поскольку основой поддержания целостного состояния базы данных является механизм транзакций, журнализация и восстановление тесно связаны с понятием транзакции. Общие принципы восстановления следующие:
результаты зафиксированных транзакций должны быть сохранены в восстановленном состоянии базы данных;
результаты незафиксированных транзакций должны отсутствовать в восстановленном состоянии базы данных.
В файл журнала может помещаться следующая информация: записи о транзакциях (идентификатор транзакции, тип записи журнала, идентификатор элемента данных, вовлеченного в операцию обработки базы данных, копию элемента данных до и после операции) и записи о контрольных точках.
Основой восстановления является избыточное хранение данных; эти данные хранятся в журнале, содержащем последовательность записей об изменении базы данных. Возможно два варианта ведения журнальной информации:
В первом варианте - для каждой транзакции поддерживается отдельный локальный журнал изменений базы данных этой транзакции и может поддерживаться в оперативной (виртуальной) памяти; кроме того, поддерживается общий журнал изменений базы данных. Этот вариант позволяет быстро выполнить индивидуальные откаты транзакций, однако приводит к значительному дублированию информации в локальных и общем журналах;
Второй вариант - поддержание только общего журнала изменений базы данных, который и применяется выполнении индивидуальных откатов.
Индивидуальный откат транзакции.
Для того чтобы можно было выполнить по общему журналу индивидуальный откат транзакции, все записи в журнале о данной транзакции связываются в обратный список. Началом списка для незакончившихся является запись о последнем изменении базы данных, произведенном данной транзакцией. Концом списка всегда служит запись об изменении базы данных, произведенном данной транзакцией. Обычно в каждой записи проставляется идентификационный номер транзакции, чтобы можно было восстановить прямой список записей об изменениях базы данных определенной транзакции.
Индивидуальный откат транзакции выполняется следующим образом:
выбирается очередная запись из списка данной транзакции;
выполняется противоположная по смыслу операция (например, вставка вместо удаления); тем самым восстанавливается предыдущее состояние объекта базы данных;
обратные операции журнализируются;
при успешном завершении отката в журнал заносится запись о конце транзакции; с точки зрения механизма журнализации такая транзакция является зафиксированной.
Восстановление после мягкого сбоя.
К числу проблем, возникающих при мягком сбое, относится тот факт, что одна логическая операция модификации базы данных может изменить несколько физических блоков базы данных. После мягкого сбоя набор страниц внешней памяти базы данных может оказаться несогласованным, т.е. часть страниц внешней памяти соответствует измененному состоянию объекта, а часть - нет. К такому состоянию не применима операция восстановления логического уровня. Если состояние объекта соответствует состоянию объекта до/после его изменения, то состояние внешней памяти базы данных называют физически согласованным.
Контрольные точки.
Контрольная точка – момент синхронизации между базой данных и журналом регистрации транзакций. Все буферы оперативной памяти принудительно записываются во вторичную память системы.
Контрольные точки организуются через установленный временной интервал и включают выполнение следующих действий:
запись всех имеющихся в оперативной памяти записей журнала во вторичную память;
запись всех модифицированных блоков в буферах базы данных во вторичную память;
помещение в файл журнала записи контрольной точки, которая содержит идентификаторы всех транзакций, которые были активны в момент создания этой контрольной точки.
Восстановление после жесткого сбоя, механизм резервного копирования.
Любая СУБД должна предоставлять механизм, позволяющий создавать резервные копии базы данных и ее журнала через установленные промежутки времени и без необходимости останавливать систему.
Для этого типа восстановления недостаточно только восстановление последнего состояния базы данных, поэтому основным инструментом является в этом случае журнал и архивная копия базы данных.
Восстановления начинается с обратного копирования базы данных из архивной копии; затем для всех закончившихся транзакций операции выполняются повторно в прямом смысле. По журналу (в прямом направлении) выполняются все операции, для не закончившихся к моменту сбоя операциям применяется откат. Поскольку жесткий сбой не сопровождается утратой буферов оперативной памяти, можно восстановить базу данных до такого уровня, чтобы можно было продолжить даже выполнение незакончившихся транзакций. Восстановление после жесткого сбоя - процедура достаточно длительная. К сожалению, возможна утрата и журнала изменений, тогда единственным источником данных является архивная копия; недостатком в данном случае является восстановление не к последнему согласованному состоянию базы данных.
Производство архивных копий возможно несколькими путями: при переполнении журнала изменений и архивирование самого журнала изменений.
Приложение 3. Система безопасности в СУБД
Современные информационные приложения опираются, как уже говорилось, в первую очередь, на многопользовательские СУБД. В этой связи пристальное внимание в настоящее время уделяется проблемам обеспечения информационной безопасности, которая определяет степень безопасности организации, учреждения в целом.
В общем случае система безопасности СУБД базируется на трех компонентах:
1. Пользователи. СУБД выполняет любое действия с БД от имени какого-то пользователя. Каждому пользователю присваивается идентификатор (login) - имя, однозначно определяющее пользователя в СУБД. Для подтверждения того, что пользователь может работать с введенным идентификатором используется пароль. Таким образом, с помощью идентификатора и пароля производится идентификация и аутентификация пользователя. Большинство СУБД позволяет объединять пользователей с одинаковыми привилегиями в группы - это позволяет упростить процесс администрирования.
2. Объекты БД. По стандарту SQL2 защищаемыми объектами в БД являются таблицы, представления, домены и определенные пользователем наборы символов. Большинство коммерческих СУБД расширяет список объектов, добавляя в него хранимые процедуры и др. объекты.
3. Привилегии. Привилегии показывают набор действий, которые возможно производить над тем или иным объектом. Например, пользователь имеет привилегию только для просмотра таблицы.
В самом общем виде требования к безопасности реляционных СУБД формулируются так:
данные в любой таблице должны быть доступны не всем пользователям, а лишь некоторым из них
некоторым пользователям должно быть разрешено обновлять данные в таблицах, в то время как для других допускается лишь выбор данных из этих же таблиц
для некоторых таблиц необходимо обеспечить выборочный доступ к ее столбцам
некоторым пользователям должен быть запрещен непосредственный (через запросы) доступ к таблицам, но разрешен доступ к этим же таблицам в диалоге с прикладной программой.
Схема доступа к данным во всех реляционных СУБД выглядит примерно одинаково и базируется на трех принципах:
* Пользователи СУБД рассматриваются как основные действующие лица, желающие получить доступ к данным. СУБД от имени конкретного пользователя выполняет операции над базой данных, то есть добавляет строки в таблицы (INSERT), удаляет строки (DELETE), обновляет данные в строках таблицы (UPDATE). Она делает это в зависимости от того, обладает ли конкретный пользователь правами на выполнение конкретных операций над конкретным объектом базы данных.
* Объекты доступа - это элементы базы данных, доступом к которым можно управлять (разрешать доступ или защищать от доступа). Обычно объектами доступа являются таблицы, однако ими могут быть и другие объекты базы данных - формы, отчеты, прикладные программы и т.д. Конкретный пользователь обладает конкретными правами доступа к конкретному объекту.
* Привилегии (priveleges) - это операции, которые разрешено выполнять пользователю над конкретными объектами.
Таким образом, в СУБД авторизация доступа осуществляется с помощью привилегий. Установление и контроль привилегий - задача администратора базы данных.
Привилегии устанавливаются и отменяются специальными операторами языка SQL - GRANT (ПЕРЕДАТЬ) и REVOKE (ОТОБРАТЬ). Оператор GRANT указывает конкретного пользователя, который получает конкретные привилегии доступа к указанной таблице.
Поддержка мер обеспечения безопасности в языке SQL, средства поддержки доступности, технология тиражирования данных, вопросы защита коммуникаций между клиентом и сервером рассмотрены в приложении 3 (Управление безопасностью в СУБД) учебного пособия [qqq].
Содержание
1. Информация о дисциплине 3
1.1. Предисловие 3
1.2. Содержание дисциплины и виды учебной работы 4
1.2.1. Объем дисциплины и виды учебной работы 4
2. Рабочие учебные материалы 6
2.1. РАБОЧАЯ ПРОГРАММА 6
2.2. Тематические планы дисциплины 11
2.2.1. Тематический план дисциплины для студентов очной формы обучения 11
2.2.2. Тематический план дисциплины для студентов очно-заочной формы обучения 13
2.2.3. Тематический план дисциплины для студентов заочной формы обучения 15
2.3. Структурно-логическая схема дисциплины 17
2.5. Практический блок 19
2.6. Балльно-рейтинговая система 21
3. Информационные ресурсы дисциплины 23
3.1. Библиографический список 23
3.2. Опорный конспект 25
ВВЕДЕНИЕ 25
Схема работы с разделом 1 26
Раздел 1. Назначение и основные компоненты системы баз данных 26
Схема работы с разделом 2 45
Раздел 2. Архитектура банка данных 45
Схема работы с разделом 3 59
Раздел 3. Модели и типы данных в БД 59
Схема работы с разделом 4 72
Раздел 4. Базовые элементы реляционных БД 72
Схема работы с разделом 5 84
Раздел 5. Язык структурированных запросов SQL 84
Схема работы с разделом 6 95
Раздел 6. Использование БД 95
ЗАКЛЮЧЕНИЕ 112
3.3 Глоссарий 113
3.4. Учебное пособие 123
3.5. Методические указания к выполнению лабораторных работ 125
3.5.1. Общие указания 125
3.6. Методические указания к выполнению практических занятий 127
3.6.1. Задания на практические занятия 127
3.6.2. Методические указания к выполнению практических заданий 128
4. Блок контроля освоения дисциплины 144
4.1. Общие указания 144
4.2. Задание на курсовой проект и методические указания к его выполнению 144
4.3. Текущий контроль 150
Тренировочные тесты 150
Тест № 1 (по разделу 1) 150
Тест №2 (по разделу 2) 151
Тест № 3 (по разделу 3) 153
Тест № 4 (по разделу 4) 154
Тест № 5 (по разделу 5) 156
Тест № 6 (по разделу 6) 157
ПРАВИЛЬНЫЕ ОТВЕТЫ НА ТРЕНИРОВОЧНЫЕ ТЕСТЫ 160
4.4. Итоговый контроль 161
Вопросы для подготовки к экзамену 161
Приложение 1. Определение данных в SQL. 164
Приложение 2. Журнализация изменений базы данных 170
Приложение 3. Система безопасности в СУБД 173
Копейкин Михаил Васильевич
Спиридонов Виктор Валентинович
Шумова Елена Олеговна
БАЗЫ ДАННЫХ
Учебно-методический комплекс
Редактор
Сводный темплан 2010 г.
Лицензия ЛР № 020308 от 14.02.97
Санитарно-эпидемиологическое заключение № 78.01.07.953.П.005641.11.03
от 21.11.2003 г.
______________________________________________________________
Подписано в печать Формат 6084 1/16.
Б. кн.-журн. П.л. Б.л. Изд-во СЗТУ
Тираж экз. Заказ
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Северо-Западный государственный заочный технический университет
Издательство СЗТУ, член Издательско-полиграфической ассоциации университетов России
191186, Санкт-Петербург, ул. Миллионная, 5
|
