Резервное копирование и восстановление

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

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

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

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

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

• запись на диск всех страниц, измененных к началу кон­трольной точки;

• запись в журнал транзакций списка незавершенных тран­закций;

• запись в журнал транзакций всех измененных страниц;

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

Резервное копирование выполняется для каждой базы индиви­дуально и может производиться несколькими способами.

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

Выборочное (дифференциальное) резервное копирование обеспе­чивает архивирование только тех данных базы, которые были из­менены с момента последнего архивирования.

Резервное копирование журнала транзакций обеспечивает ар­хивирование и усечение журнала.

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

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

Резервное копирование и восстановление можно выполнить с помощью Enterprise Manager, «мастера» или T-SQL. Для раз­мещения архивных копий должно быть создано логическое уст­ройство (которое может быть и отдельным физическим устрой­ством).

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

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

Целостность базы данных

Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.

Короче, под целостностью БД понимают правильность и непротиворечивость ее содержимого.

Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.

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

Рассмотрим два аспекта целостности – на уровне отдельных объектов и операций и на уровне базы данных в целом.

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

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

Часто же база может иметь такие ограничения целостности, которые требуют обязательного выполнения не одной, а нескольких операций. Для иллюстрации примеров рассмотрим функциональные возможности учебной БД «Сессия», добавив в таблицу «Кадровый состав» столбец Нагрузка для решения дополнительной задачи – расчета общей годовой нагрузки преподавателей (в часах учебной работы). Тогда любая операция по внесению изменений или добавления данных в столбец ID_Преподаватель таблицы «Учебный план» должна сопровождаться соответствующим изменением данных в столбце Нагрузка. Если после внесения изменений в столбец ID_преподаватель произойдет сбой, то БД окажется в нецелостном состоянии.

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

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

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

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

Итак, БД может быть целостной, но не достоверной. Возможно и обратное: БД может быть достоверной, но не целостной. Последнее имеет место, если правила (ограничения целостности) заданы неверно.

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

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

NOT NULL

PRIMARY KEY

UNIQUE KEY

FOREIGN KEY ( REFERENCES)

CHECK

INDEX (ИНДЕКСЫ)

TRRIGERS и PROCEDURES

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

PRIMARY KEY (первичный ключ) . Ограничение определяет столбец или группу столбцов, которую можно использовать для уникальной идентификации строки. Никакие две строки в таблице не могут иметь одинаковые значения столбцов первичного ключа. Кроме того, столбцы первичного ключа должны всегда содержать значение. Все эти условия гарантируют то, что в нашем распоряжение будет одна и только одна строка, соответствующая критериям связывания. Первичные ключи могут быть или именованные (пользователем) или неименованные ( Oracle составляет имя сам). В первичных ключах не могут использоваться столбцы типа: raw, long, long raw.

UNIQUE (уникальный). Ограничение UNIQUE используется для определения того, что значения в столбце не должно повторяться в другой строке этой таблицы, определяет вторичный ключ для таблицы. Это столбец или группа столбцов, которые можно использовать как уникальную идентификацию строки. Никакие две строки не могут иметь одинаковые значения для столбца или столбцов ключа UNIQUE. Столбцы для ограничения UNIQUE не обязательно NOT NULL. Можно сформировать ограничение таблицы, указав, что в таблице не должна повторяться комбинация столбцов. К примеру: можно в начале объявить стандартно emp_id number(5), person_id date а под конце объявить что: unique( emp_id, person_id) – и получиться, что сочетание значений этих полей, должно быть уникальным в каждой строке.

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

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

ИНДЕКСЫ (INDEX). Ограничения PRIMARY KEY и UNIQUE автоматически создают индексы на столбцах, для которых они определены, если ограничение активизируется при создании. Если индекс уже существует на столбцах, которые составляют ограничение PRIMARY KEY и UNIQUE, то использует именно этот индекс и Oracle не может создать новый.

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

Таким образом, целостность базы данных может быть рассмотрена на трех уровнях :

На уровне типа данных (т.е. соответствия типов данных)

На уровне ключей (к примеру, соответствие первичных и внешних ключей)

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