alter system checkpoint
А потом открытие с alter system clear logfiles и resetlogs

Но, естественно, мультиплексировать оперативные логфайлы, даже если они на одном девайсе

helgisboxDВАЧем отличается порча активного лога при работающем инстансе от порчи не активного? ))
ну и разумеется не текущего.

Сразу перед тем как на клиента приходит подтверждение от отработке коммита на диск сбрасывается логбуфер (в активный файл). Именно это и гарантирует в случае сбоя восстановление и согласованность данных. А вот в датафайлах на момент коммита еще нет согласованные данных. Если нагрузка невысокая, то велика вероятность, что DBWR успеет тоже быстро все записать. Но если транзакций под сотни в секунду и вдруг стал "испорчен" (физически не читается пишется, или проблемы на уровне файловой системы), то еще не закоммиченные транзакции и не закоммитятся, а вот те, которые уже получили подтверждения по коммиту - потенциально потеряны, из-за асинхронной работы DBWR и порчи того самого активного логфайла. Все, что в неактивном журнале после переключения журнала гарантировано сбрасывается DBWR-ром.На самом деле, если экземпляр работает, то абсолютно пофиг, активный лог запортился или неактивный -- для сброса данных DBWR-у логи не нужны (за исключением записи с текущий лог)
И данные он когда-нибудь да сбросит
Другой вопрос, что журнал перейдет в статус FAILED (по-моему) и перестанет использоваться
При сломанном текущем журнале (всех членов), экземпляр, естественно, аварийно ляжет, и тогда если были поломаны активные логи, то накатится по ним будет нельзя -- тут, как правило, восстановление из бэкапа и накат до лога

Кстати, насчет RESETLOGS я наврал, это немножко другой сценарий (с битыми текущими логами)

irbis_alВячеслав ЛюбомудровНо, естественно, мультиплексировать оперативные логфайлы, даже если они на одном девайсе
Вот у меня из опыта восстановления и падения :-) ...Всегда если испорчен один из группы...всегда испорчен и второй(У меня два..и на разных dev...и на одном и т.д)...
Ну вот хоть бы раз повезло...Неоднократно бывало на не [очень] важных девелоперских БД при отключении питания -- на одном диске из двух мультиплексированных логов с одним можно было открыться, а с другим нет

Если мы переходим к сбою таки не активных, а текущего лога, то поломка-поломке рознь

Одно дело, отвалился диск и не прошла целиком запись (то же самое, что аварийный останов экземпляра) -- после примонтирования диска БД прекрасно докатится по всем активным и сколько можно по текущему журналу, откроется и откатит незавершенные транзакции
И совсем другое, когда диск отвалился в момент записи, т.е. redo record неконсистентна. После примонтирвания диска БД попробует автоматом накатиться по активным/текущему логам и сломается на применении кривой записи -- и вот из этого ступора ее стандартными путями не выведешь -- только восстановление из бэкапа (или откат по FLASHBACK) и докат до последнего нетекущего журнала (ну или сделать дамп текущего лога и узнать SCN последней нормальной redo record). И RESETLOGS, конечно
В этом случае (когда есть вероятность неконсистентной записи) как раз есть смысл сделать дамп текущего лога и если он прошел без ошибок, то запустить обычное/полное восстановление, иначе -- см.выше.
Но, как правило, никто этим не занимается, ибо над душой стоят и кричат "открывай скорей"