наш человек в гаване1. Потеря управляющего файла (control.ctl)
2. Потеря файла данных (datafile.dbf)
3. Потеря REDO при отсутствии мультиплексирования
4. Заполнение FRA на 100% при его использовании
5. Достижение размера лога листнера в 4 Gb


Согласен, всё это может привести к недоступности и неработоспособности БД, к простою в нормальной работе пользователей с БД.

5. Сталкивался, но когда лог достигал 2Gb. Зависит от версии БД и версии ОС
4. Думаю что нужно говорить не о FRA, а об архивировании журналов вообще, независимо используется ли FRA или нет.

Вообще причин может быть много.
- Например, останов primary при недоступности единственного standby в режиме real-time aplpy;
- Нехватка PGA(ora-4030);
- Невозможность получить разделяемую память ora-4031, как следствие её отсутствия или как следствие её фрагментированности;
- checkpoint not complete - при высокой DML-нагрузке и неправильно настроенных размеров и количестве redo-групп;
- Случайный кил фоновых процессов;
- Невозможность расширить табличные пространства или сегменты;
- популярные запросы, у которых поехали планы;
- сдохла батарейка в контроллере;
- у сетевиков слетели рабочие настройки сетевого оборудования;
- выставлен parallel_max_server в большое значение, а в запросах с хинтом parallel, степень не указана(тогда oracle назначает автоматом, как правило очень большое значение и если таких запросов много и их часто выполняют - нормальной работе базы конец);
- сессии с незакоммиченными транзакциями(по причине того, что COMMIT не был сделан или указан или сетевой сбой), могут приводить к тому, что другие сессии не могут получить блокировку и как следствие не могут например выполнить важные задачи - копятся какие-нибудь очереди документов, которые должны быть обработаны, переданы в архив итд итп. При этом это никак не мониторится;
- сбои в работе шлюзов при работе с гетерогенными базами;
- случайный drop, truncate таблиц, drop индексов;
- неосторожное выполненние команд delete, update, у которых условие фильтра было указано в другой строке, а в базу ушла только первая строка, типа:
delete tabl1
where field1='sdw'
в результате было всё удалено или изменено в таблице, в которой хранились глобальные настройки;
- наличие большого количества баз как тестовых так и продуктивных, ошибка при выборе окна приводит к печальным последствим, когда критичная операция предполагалась для тестовой среды, а выполнилась в продуктивной;
- не выполнение резервирования БД по глупости или по сбою, что было не замечено;
- сбор статистики в нагруженной БД в неподходящее время;
- удаление TS UNDO и TEMP на лету;

Всё это может приводить к значительным простоям в работе БД.