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

— Могут быть созданы некачественные программы, которые разрушают данные или оставляют базу данных в непредсказуемом состоянии
— При параллельной работе пользователей (работа конкурирующих программ) могут возникать ситуации, когда получаются неправильные результаты
— Анонимные пользователи портят данные
— Обновления могут менять содержимое БД непредсказуемым способ

Восстановление

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

1. Транзакции

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

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

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

Ключевые операторы:
Commit – подтвердить изменения. Сигнализирует серверу БД (диспетчеру управления транзакциями), что все операторы успешно выполнены и можно подтвердить изменения.
Roll back – отменить назад. Извещает, что произошел сбой и нужно все, что было сделано, отменить.

Среди операторов, которые можно отменять назад, есть операторы, которые внутри транзакции делать нельзя, поскольку сделать их откат назад нельзя: операторы создания новых объектов (таблиц, домена, индекса), процедур, триггеры (все операторы, начинающиеся на create (создать), alter (изменить), drop (удалить).

Модель транзакции:
В стандарте ANSI\ISO принята модель: транзакция автоматически начинается с выполнения первого оператора обновления от пользователя и продолжается до тех пор, пока не появится Commit или Roll back,которые заканчивают транзакцию.

В некоторых СУБД (SyBase, SQL Server) принята другая модель транзакций: прежде, чем начать транзакцию, надо ввести команду Begin Transaction.Считается, что после этого любой оператор обновления входит в транзакцию. Если есть единичный оператор обновления за рамками команды Begin Transaction,то он считается оператором обновления с авто commit-ом.

Свойства АСИД (ACID):
1. Атомарность (atomicy) – в транзакции выполняются либо все операторы, либо ничего не выполняется — все откатывается назад, БД возвращается в исходное состояние.
2. Согласованность (consistency) – транзакции переводят БД из одного согласованного состояния в другое без обязательной поддержки в промежуточных точках (операторах).
3. Изолированность (isolation) – транзакции отделены друг от друга. Выполнение нескольких конкурирующих транзакций скрыто друг от друга до их окончания.
4. Долговечность (durability) – после выполнения транзакции ее обновление сохраняется даже если после этого произойдет отказ или сбой системы.

Именованные транзакции:
Существует много моделей транзакций от чисто теоретических до практических, используемых в разных СУБД.
— Плоская транзакция: простейшая транзакция. Она может только начаться и только закончиться, ничего другого она не предполагает.
— Вложенная транзакция (предложены в 1981 году Моссом): Внутри одной транзакции начинается другая. Чтобы их отличать, чтобы разобраться, какая началась, какая закончилась, было принято именовать транзакции. Для вложенных транзакций существует 2 правила:
1) Правило отката: откат внешней транзакции приводит к откату внутренней, даже если она уже зафиксирована оператором Commit.
2) Правило видимости: все изменения, подтвержденные во внутренней транзакции, должны быть видны во внешней.

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

Точки сохранения (save points):
Приняты в стандарте и многие СУБД используют их на практике. Во многом похожи на подтранзакцию и предполагают, что внутри транзакции может происходить откат не к началу, а к некоторому промежуточному значению (точке сохранению), которое может отметить разработчик.
Rollback to <имя точки>

Файлы регистрации (журнал транзакций, log-файлы):
Для того, чтобы иметь возможность отменять транзакцию, СУБД должна поддерживать журнал транзакций и запись в него обновлений. Запись в него обычно происходит до начала транзакции (протокол предварительной записи в журнал). Т.е, как только пользователь посылает команду изменения, СУБД автоматически вводит в журнал транзакций 1 запись для каждой изменяемой строки, которая включает в себя идентификатор транзакции, время начала транзакции, 2 копии строки (до и после изменения).

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

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

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

На практике в крупных СУБД журнал регистрации часто состоит из 2-х частей: активной (интерактивной) и архивной (автономной). Интерактивная часть используется в процессе работы, она имеет размер, и пока он не заполнится, архивный специальными методами сжимается. Как только текущий журнал заполняется, он переводится в режим архивации, а заполняется уже чистый. Архивный журнал нужен для того, чтобы восстановить журнал при сбое. Размер журналов нужно рассчитывать так, чтобы не получилось, что активный журнал заполняется быстрее, чем архивируется автономный.

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

Рекомендуемый размер журнала транзакций для реляционной БД 10-25% от основной БД, для БД, работающей в режиме большого числа параллельных транзакций и высокой скорости изменения, 70-75% от БД.

Оперативная обработка транзакций (OLTP – On-Line Transaction Processing):
Первоначально реляционные СУБД не использовались для систем с оперативной обработкой транзакций из-за низкого быстродействия, доминировали иерархические СУБД. В 1986 году фирма SyBase первой представила СУБД для OLTP-систем, которая обрабатывала до 250-ти транзакций в секунду), временные СУБД обрабатывают 1000 транзакций в секунду).
Для тестирования производительности СУБД существуют специальные тесты ТРС-А\В\С.

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

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

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

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

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

Для поддержки зеркального копирования, напр. в SQL Server, есть специальный пользователь, управляющий зеркальным копированием (Mirror Handing User),в списке процессов он имеет имя speed1.

Комментарии запрещены.