Резервное копирование и восстановление базы данных, страница 3

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

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

ALTER DATABASE BACKUP CONTROLFILE TO ‘имя_файла’ [REUSE]

имя_файла – имя файла для резервной копии управляющего файла

REUSE – пересоздать файл, если он уже существует

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

ALTER DATABASE BACKUP CONTROLFILE TO TRACE [AS ‘имя_файла’ [REUSE]]

имя_файла – имя командного файла, если опущено, буден создан стандартный трассировочный файл

REUSE – пересоздать файл, если он уже существует

Достоинства «горячего» физического копирования:

·  база данных доступна во время выполнения резервного копирования;

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

Недостатки «горячего» физического копирования:

·  «горячее копирование» требует более значительного вмешательства администратора, чем «холодное» копирование, поэтому в большей степени подвержено ошибкам;

·  этот способ копирования более сложен, поэтому требует более высокого профессионализма от администратора базы данных.

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

Логическое резервное копирование

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

Логическое резервное копирование позволяет:

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

·  переместить данные между двумя версиями Oracle;

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

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

Экспорт данных

Логическое копирование возможно на различных уровнях:

  • Полное логическое копирование (FULL) – экспорт всех объектов в базе данных. Используется при необходимости перенести базу данных на другую машину или обновить до более высокой версии Oracle.
  • Логическое копирование таблицы (TABLE) – экспорт заданных таблиц пользователя. Используется, если нужно перенести таблицу из одной схемы в другую, или необходимо удалить таблицу, но при этом сохранить ее копию.
  • Логическое копирование данных пользователя (USER) – экспорт всех объектов схемы заданного пользователя. Используется, если нужно удалить пользователя, но есть вероятность, что объекты этого пользователя еще понадобятся, или для обновления версии приложения, использующего объекты одной схемы.
  • Логическое копирование табличного пространства (TABLESPACE) – экспорт всех таблиц, хранящихся в заданном табличном пространств, а также всех индексов, созданных для этих таблиц, независимо от того, в каком табличном пространстве они находятся. Используется, как правило, для перемещения оперативных данных (OLTP) в хранилище данных (Data Warehouse).

Любые пользователи могут выполнять экспорт только собственных объектов и только в режимах TABLE и USER. Экспорт чужих объектов или в других режимах может выполнять только привилегированный пользователь с ролью EXP_FULL_DATABASE.

Импорт данных

При восстановлении данных из логических копий происходит чтение экспортного файла (export dump file). Данные восстанавливаются в следующем порядке:

1.  создаются новые таблицы;

2.  импортируются данные;

3.  строятся обычные индексы;

4.  импортируются триггеры и включаются ограничения целостности;

5.  строятся двоичные, функциональные и прочие индексы.

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

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