Восстановление Oracle DB из резервных копий

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

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

Рассмотрим возможные проблемы и имеющиеся способы восстановления данных oracle системы в работоспособный вид.

  1. Отказ аппаратного обеспечения

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

А вот проблемы с хранилищами данных, HDD, SSD накопителями – все это повлечет за собой достаточно серьезны проблемы потери данных. В правильно настроенных системах предусмотрена некоторая избыточность в виде зеркалирования, RAID систем, ASM интеграции с дублированием данных, что практически полностью освобождает от возможных последствий потери одной копии данных, так как в системе присутствует дополнительная, и возможно и не одна копия, которая абсолютно прозрачно встает на место первичной.

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

Процедура восстановления базы/файлов данных для Oracle RDBMS в общем виде имеет следующую последовательность:

Restore — процедура физического восстановления копии файлов данных, в общем случае имеющих отчасти устаревшую информацию;

Recover — процедура накатывания вектора изменений, прошедших в базе данных с момента текущей копии, полученной в процессе процедуры Restore, до ближайшей к настоящему точки во времени.

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

  • Файлы данных;
  • Контрольные файлы;
  • Журналы повторного выполнения.

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

Run{
Restore database;
Recover database;
}

  1. Повреждение бинарных, файлов данных или системных файлов БД

Бинарные файлы

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

Системные файлы БД

К таким файлам относятся:

Инициализационные файлы (pfile, spfile);

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

Контрольные файлы (control files);

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

Журналы повторного выполнения (redo logs);

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

Файлы временных табличных пространств (temp tablespace):

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

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

Файлы данных табличных пространств отката (undo tablespace).

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

Файлы данных

Файлы данных в рамках Oracle DB хранятся группами – табличными пространствами. Разделяются системные и пользовательские табличные пространства. В системных табличных пространствах хранится информация о логической и физической структуре база данных, а также системные пакеты, информация для системных утилит и дополнений. В рамках системных табличных пространств можно выделить SYSTEM, SYSAUX, UNDO табличные пространства. Без них работа база данных невозможно, а именно не получится запустить базу данных при повреждении или отсутствии файлов из соответствующих табличных пространств.

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

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

  1. Логические повреждения

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

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

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

Описанная выше логика восстановления Oracle DB носит универсальный характер. Очень много зависит от логики резервирования. Имея регулярную процедуру резервирования, придерживаясь всем рекомендациям по хранению и распределению физической структуры базы данных, восстановить потерянные данные можно в 99.99% случаев. К сожалению, необходимые процедуры резервирования часто игнорируются, что приводит к плачевным последствиям.

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

Oracle Database — Backup and Recovery Reference

Oracle Database — Backup and Recovery User’s Guide

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*