Потери данных в Oracle делятся на критические (существенные) и некритические.

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

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

Потеря временного файла:

Временной табличное пространство (например, TEMP) становится недоступным, когда теряется или повреждается принадлежащий ему файл. Эта проблема обнаруживается в ходе выполнения команд SQL, которым необходимо временное табличное  пространство для сортировки.

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

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

Например, пусть удален на уровне ОС файл temp01.dbf, принадлежащий временному табличному пространству по умолчанию TEMP. Чтобы выполнить восстановление в базе данных после такого удаления добавьте новый файл, а затем выполните операцию drop для удаленного файла:

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

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

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

чтобы пересоздать элементы этой группы.

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

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

При этом необходимо учесть следующие ограничения:

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

• Группу или элемент группы можно удалить только, когда группа неактивна (статус INACTIVE в представлении  V$LOG).

• Когда БД в архивном режиме, удалить элемент или группу можно, если оперативная журнальная группа заархивирована (YES в столбце ARCHIVED представления  V$LOG).

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

При существенных потерях могут использоваться различные типы восстановления, предлагаемые Oracle. Выбор зависит от конкретного типа сбоя и задач, которые необходимо решить при восстановлении.

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

• Неполное восстановление переносит БД к заданному времени в прошлом, предшествовавшему  моменту, в котором возникла  необходимость восстановления.

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

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

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

1. Поврежденные и потерянные файлы восстанавливаются из резервных объектов.

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

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

4. База данных открывается перед применением данных отмены. Это делается для предоставления высокого уровня доступности.

5. Блоки отмены используются для отката назад любых незафиксированных изменений. Этот шаг принято называть откатом назад или восстановлением транзакции.

6. Файлы данных теперь в восстановленном состоянии и согласованы с другими файлами данных БД.

shut immediate-остановка БД

startup mount-старт в режиме монтирования

restore database-восстановление БД

recover database-накат логов до текущего состояния

alter database open-открытие БД для работы

Последовательность действий при неполном восстановлении:

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

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

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

4. База данных открывается со сбросом оперативных журналов перед тем, как применяется информация отмены. Таким образом достигается более высокая доступность.

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

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

Типы неполного восстановления:

Восстановление по времени:

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

зафиксированы все изменения, внесенные до указанного момента времени. Этот подход используется, когда в данные были внесены нежелательные изменения либо удалены важные таблицы, и известно приблизительное время ошибки. Перед восстановлением необходимо убедиться, что переменные среды NLS_LANG и NLS_DATE_FORMAT установлены!

С помощью фразы UNTIL SCN задается системный номер изменений (system change number – SCN) последнего зафиксированного изменения, до которого необходимо восстановиться. Восстановление согласно этому методу прекращается после того, как в базе данных зафиксированы все изменения, внесенные до указанного системного номера изменения (SCN). Данный подход используется при восстановлении баз данных, работающих в распределенной среде. Вы можете также воспользоваться фразой UNTIL RESTORE POINT и задать псевдоним для SCN, называемый точкой восстановления (restore point).

Используя резервные объекты, сопровождаемые RMAN, можно задать номер последнего журнала, используемого для восстановления базы данных с помощью фразы UNTIL SEQUENCE. Восстановление согласно этому методу прекращается после того, как были применены все журналы до, но не включая журнал с заданным порядковым номером.

В RMAN имеется возможность восстановления отдельных блоков файлов БД без остановки работы БД. Если известен файл и номер сбойного блока, то можно его восстановить следующей командой:

blockrecover datafile <file> block <block>;

Если сбойных блоков много, то можно произвести восстановление по списку. Для этого выполняется валидация БД и при этом заполняется представление v$database_block_corruption, после чего можно производить восстановление блоков: