Некоторые вопросы администрирования информационных систем, работающих с базой данных Oracle db

Резервное копирование базы данных

Как уже отмечалось в гл. 3, основная обязанность администратора информационной системы — быть готовым оперативно восстановить данные в ней при возникновении аварии, сбоя или повреждении данных. Для того чтобы осуществить восстановление данных, необходимо иметь их резервную копию. Администратором ИС должен быть разработан план резервного копирования данных и порядок действий на случай их повреждения.

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

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

Если БД работает в режиме NOARCHIVELOG, то существует несколько особенностей и ограничений при создании резервных копий и восстановлении данных:

• • нельзя делать резервные копии активных табличных пространств;
• • нельзя использовать для восстановления резервные копии активных табличных пространств, выполнявшихся ранее, когда БД работала в режиме ARCHIVELOG;
• • необходимо делать только полные копии закрытой БД.

Если в распределенной БД хотя бы одна из баз данных работала в режиме NOARCHIVELOG, то восстановление всех баз данных производится из последней полной копии БД, работавшей в режиме NOARCHIVELOG. После установки Oracle db она работает в режиме NOARCHIVELOG. Для перевода БД в режим ARCHIVELOG нужно дать команду.

ALTER DATABASE ARCHIVELOG;

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

• 1) остановить экземпляр Oracle;
• 2) сделать копию БД. Это рекомендуется делать при каждом изменении режимов ее работы;
• 3) запустить экземпляр, но БД не открывать;
• 4) переключить режим архивирования;
• 5) открыть БД.

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

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

ALTER DATABASE ARCHIVELOG START;

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

ALTER DATABASE ARCHIVELOG STOP;

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

Важно!

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

После перезапуска экземпляра система установит режим архивирования в соответствии с настройками Oracle.

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

ALTER DATABASE ARCHIVELOG ALL;

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

Вернемся теперь к вопросам резервного копирования и восстановления данных.

Потеря данных может быть определена как физическая и как логическая. Физическая потеря данных — это потеря данных на уровне операционной системы (утрата или повреждение файлов, в которых хранятся данные файлов оперативного или архивного журнала транзакций). Логическая потеря данных — эго потеря данных на уровне БД (случайное удаление данных оператором, удаление таблицы). В Oracle имеется возможность восстановления данных для обоих случаев потери данных.

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

Физическое копирование предполагает создание копий:

• • файлов данных;
• • контрольных файлов;
• • архивных файлов журнала транзакций.

Физические копии бывают двух видов: «холодные» и «горячие». «Холодное» копирование (онлайн-конирование) выполняется в момент остановки работы базы данных. «Горячее» копирование (офлайн-копирование) проводится, когда с базой данных работают пользователи. Оно происходит в случае, когда по производственным причинам невозможно остановить работу информационной системы. Если есть возможность остановить работу И С, то предпочтение нужно отдать «холодному» копированию.

База данных из физической копии должна восстанавливаться в той же версии Oracle db и в том же экземпляре, в которых она была создана. В противном случае данные нужно восстанавливать из логической копии.

Частота создания резервных копий определяется интенсивностью работы в информационной системе. Если в ней проводится интенсивная работа, то резервные копии нужно делать чаще — обычно их делают ежедневно в ночное время. Напомним, что для обеспечения дополнительной защиты данных (на случай повреждения последней копии) принято хранить три копии данных, предшествующие последней.

Перед началом «холодного» (полного) копирования базы данных нужно остановить экземпляр Oracle с нормальным приоритетом. Если экземпляр остановился из-за сбоя или по другой подобной причине, то копия получится неполной. В этом случае рекомендуется запустить его и остановить с нормальным приоритетом. Полное копирование можно проводить как в режиме работы ARCHIVELOG, так и в режиме NOARCHIVELOG.

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

Порядок создания полной копии базы данных:

• 1) остановить БД с нормальным приоритетом;
• 2) выполнить копирование файлов, составляющих БД;
• 3) перезапустить БД.

Копирование всех файлов выполняется средствами операционной системы.

Частичное «Горячее» копирование должно выполняться только для баз данных, работающих в режиме ARCHIVELOG, — использовать его для восстановления БД, работающей в режиме NOARCHIVELOG, нельзя.

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

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

• 1) идентифицировать файлы данных, которые необходимо скопировать (имена и места расположения файлов);
• 2) отметить факт начала копирования файлов табличного пространства. Для этого нужно дать команду

ALTER TABLESPACE AURORA BEGIN BACKUP;

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

• 3) выполнить копирование файлов данных. Оно производится средствами операционной системы;
• 4) отметить факт окончания копирования табличного пространства. Для этого нужно дать команду

ALTER TABLESPACE AURORA END BACKUP;

Если требуется скопировать файлы нескольких табличных пространств, то есть две стратегии поведения:

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

Второй метод является более предпочтительным, так как каждое табличное пространство на меньшее время переходит в состояние остановки записи данных.

Рассмотренный метод создания частичных копий применяется для активных табличных пространств.

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

Алгоритм действий при копировании неактивных табличных пространств следующий:

• 1) идентифицировать файлы данных, которые необходимо скопировать (имена и место расположения файлов);
• 2) перевести табличное пространство в неактивное состояние. Для этого нужно дать команду

ALTER TABLESPACE AURORA OFFLINE;

Файлы данных, входящие в табличное пространство, будут закрыты;

• 3) выполнить копирование файлов данных. Оно производится средствами операционной системы;
• 4) перевести табличное пространство в активное состояние. Для этого нужно дать команду

ALTER TABLESPACE AURORA ONLINE;