Ошибка при запуске БД Oracle ORA-00205

ORA-00205: error in identifying control file, check alert log for more info

Причина:
Эта ошибка имеет несколько причин, в моём случае причиной стало отсутствие подключения к партициям Oracle (/oradata2, /oradata3), и как следствие невозможность обращения к контрольным файлам, что и вызывает данную ошибку.


Для решения было сделано следующее:
1) Выполнить команду SQL> show parameter control_files
2) Смотрим где находятся файлы
3) Идем на сервер с правами супер пользвоателя (у нас АИКС 5.3)
4) Проверяем подключения файловых систем
5) Пробуем подключить и следуем инструкции (mount /oradata2)
5.1) fsck /oradata2
5.2) fsck /oradata3
5.3) mount /oradata2
5.4) mount /oradata3
6) Заходим под пользователем oracle
7) Заходим в SQLPLUS
8) Запускаем базу

Oracle Backup and Repository Maintenance

ORACLE  рекомендует для стратегии сохранения резервного копирования реализовать (сконфигурировать) следующие политики:
   - область быстрого восстановления (fast recovery area)
   - политика хранения резервных копий (время жизни) (backup retention policy)
   - политика удаления архивных логов (archived redo log deletion policy)
В этом случае БД самостоятельно сохраняет, удаляет резервные копии и архивные логи. Однако, иногда необходимо выполнение этих операций вручную.

Управление резервными копиями RMAN  включает в себя следующие задачи:
   - управление резервными копия баз данных которые хранятся на дисках или лентах
   - управление записями этих бэкапов в репозитории RMAN

Oracle RMAN

Лучшая, на мой взгляд, логика бэкапов в Oracle (сравнивая нативный бэкапер Microsoft'a):

1) Есть дифференциальный инкрементальный бэкап со следующей логикой:
копия Level0 делается в Sun затем делаются инкременты на инкременты :) (Level1), в следующий Sunday делает опять копия Level0 со всеми изменениями за неделю. Т.е. копия Level0 это по сути Full-бэкап только его можно использовать в расписании инкрементов!! Это должно здорово уменьшать объем хранения резервных копий. Правда, это увеличивает время восстановления с резервной копии.

 

2) Есть кумулятивный инкрементальный бэкап с другой логикой:
В Sunday делаем бэкап Level0 (типа Full) и каждый последующий день к нему прибавляем инкремент, в следующий Synday опять делаем бэкап Level0 и процесс начинается сначала. В этой схеме время восстановления должно быть минимальным - ведь каждую резервную копию восстанавливаем из двух: требуемая дата+Sunday. Однако место должно быть побольше... Насколько больше? Для моего сервера это около 400-500 Мб в день... Журналы транзакций мать так их так :).

А еще можно включить Block Change Tracking и тогда, RMAN не будет тратить время на сканирование каждого бита - у него просто будет актуальная инфа по каждому биту, измененному после последнего бэкапа... Ващщеее... Значит уменьшается время резервного копирования.