На какую среднюю скорость передачи данных можно рассчитывать при резервном копировании? (Этот вопрос в корне отличается от вопроса о скорости передачи данных, которую может обеспечить устройство, и о полосе пропускания сети.)

Имеется ли защищенное место для хранения резервных носителей?

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

требования и ограничения, а затем предлагать рещения. Какие же варианты имеются в нащем распоряжении?

Создание образа базы данных

База данных Oracle хранится в совокупности файлов операционной системы. С точки зрения резервного копирования и восстановления самыми важными из них являются следующие:

файлы данных;

управляющие файлы;

журнальные файлы.

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

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

Накопитель на ленте

Активные % данные

Резервное копирование при включенной базе данных

Копирование при отключенной базе данных

Копия данных

Рис 10.1 Ускорение процесса резервного копирования с помощью промежуточной копии

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

1. Закрыть экземпляр базы данных.

2. Приостановить процесс создания зеркальной копии.

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

4. Выполнить резервное копирование необновляемой базы.

5. Возобновить процесс создания зеркальной копии.

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

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

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

1. Снять резервную копию с текущей базы данных.

2. Восстановить данные с самой последней резервной копии (предшествующей только что снятой).

3. Сохранить копию таблицы (как правило, с помощью утилиты экспортирования Oracle).

4. Восстановить данные с резервной копии, снятой в операции 1.

5. Воссоздать таблицу, сохраненную в операции 3 (как правило, с помощью утилиты импортирования Oracle).

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

Экспортирование и импортирование

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

экспортировать отдельный объект базы данных, например таблицу;

экспортировать избранные объекты базы данных, принадлежащие указанному пользователю;

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

создавать резервную копию всей базы данных.

Полезной особенностью утилиты импортирования (IMP) является то, что нам не нужно импортировать все, что было экспортировано. Следовательно, если мы экспортировали всю базу данных, то сможем найти одну таблицу для несчастного пользователя, который случайно потерял ее или удалил 1000 крайне необходимых ему строк. Еще одно преимущество утилиты EXPort состоит в том, что она неявно проверяет логическую целостность данных. Поскольку эта утилита читает данные, обращаясь к таблицам построчно, она гарантирует, что все строки остаются целыми и никакие повреждения не возникают. А при создании образа базы данных испорченные блоки просто когшруются, хотя в Oracle? они встречаются редко, что весьма приятно.

Поскольку один из нас работает на фирму ВМС Software, мы не можем удержаться от искушения отметить, что продукт SQL*Trax этой фирмы позволяет устранить повреждения этого типа путем выявления выполненного действия по журналу и отмены его