Как и можно ожидать, экспортирование занимает гораздо больше времени, чем создание образа базы данных. Когда мы говорим гораздо больше , мы имеем в виду именно это. Так, утилиту EXPort нельзя использовать с очень большими базами данных, потому что время экспортирования неприемлемо велико. Эта утилита также требует, чтобы база данных продолжала работать, и пользователь должен сделать так, чтобы в процессе экспортирования никто не изменял данные. Утилита EXPort может выполняться в режиме согласованности по чтению, чтобы к базе данных одновременно имели доступ и другие пользователи, но при обновлении это может привести к остановке экспорта спустя несколько часов из-за нарушения согласованности по чтению (snapshot too old). Ни один метод не позволяет предотвратить эту ошибку.

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

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

Режим архивации журналов

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

Нет, не потеряем, если работаем в режиме архивации журналов и сумели сохранить все файлы журналов, сгенерированные с момента предыдущего резервного копирования файлов. Этот режим устанавливается в файле инициализации Oracle (INIT.ORA) и при правильном использовании позволяет восстанавливать или повторно применять транзакции путем восстановления с повтором транзакций. Мы можем, таким образом, восстановить данные с резервной копии образа базы данных, а затем с помощью журналов (заархивированных) прокатать эту базу-копию либо до конца журналов, либо до заданного момента времени. (Подробное описание этого механизма можно найти в документе Oracle? Server Administrators Guide.)

Когда пользователь выдает SQL-команду COMMIT, все сделанные им изменения, вероятнее всего, еще находятся в памяти (в измененных или грязных буферах базы данных в системной глобальной области, SGA). Поскольку память энергозависима, то эти изменения необходимо записать на диск, иначе операцию фиксации нельзя будет считать завершенной. Поскольку запись потенциально большого количества блоков в базу данных

может быть дорогостоящей (относительно) операцией, то в последовательный файл, называемый журналом, записываются изменения (и только изменения). После того как записаны все изменения, фиксация считается завер-щенной. Блоки базы данных записываются (в конце концов) обратно в нее фоновым процессом, который называется программой записи в базу данных (DBWR), но эта запись не синхронизирована с транзакцией.

Сам журнал представляет собой ряд файлов, запись в которые осуществляется циклически. Запись в первый файл производится до тех пор, пока он не заполнится, затем так же производится запись во второй файл - и так до заполнения последнего файла, после чего перезаписывается первый файл, и все начинается сначала. Режим архивации журналов означает, что ни один файл журнала не перезаписывается до тех пор, пока он не будет скопирован (заархивирован). В случае серьезной аварии данные можно восстановить, смонтировав последнюю резервную копию. При запуске Oracle? подсказывает, что нужно применить журналы в правильном порядке, и восстанавливает все данные вплоть до последней фиксации в последнем имеющемся журнале. В случае полного выхода из строя мащины это будет последний журнал, заархивированный с нее на какой-нибудь съемный носитель, например на ленту.

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

ALTER TABLESPACE...BEGIN BACKUP

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

ALTER TABLESPACE...END BACKUP

Администраторы БД обычно довольно успещно работают с горячими резервными копиями, а вот для остальных членов группы проектировщиков они часто остаются тайной за семью печатями. Важно помнить, что в промежутке между ALTER TABLESPACE...BEGIN BACKUP и соответствующим ALTER TABLESPACE...END BACKUP экземпляр Oracle запишет данные в ряд журналов, и каждый из этих журналов необходимо применить После восстановления с горячей резервной копии.

к свсдетио

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

Резервные узлы

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

Примечание

Не думайте, что это легко. Перед тем как платгровать такой подход, необходимо точно выяснить, как пользователи переключаются, сколько работы л№Шо они должны сделать (включая повторный вход в систему) и сколько времени на все это уйдет. Если обращать внимание на маркетинговую шумиху, которая все это окружает, то можно подумать, что решить эту задачу так же легко, как, скажем, позавтракать. На самом деле вас ждет здесь множество подводных камней.

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

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

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

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

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