log corruption на standby

Есть оракл 8.1.7.4 на solaris 9 - два сервера основной и standby. Архивлоги передаются автоматом а накатываются скриптом (раз в 2 часа).

Вчера на standby появилась ошибка:

ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Tue May 30 21:50:24 2006
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /exp/dep/LOG/arc1_8091.log
Tue May 30 21:51:31 2006
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Tue May 30 21:51:31 2006
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /exp/dep/LOG/arc1_8092.log
Tue May 30 21:52:21 2006
Media recovery buffers written to disk due to log corruption.
Some changes at scn 625339966 may be on disk
Media Recovery failed with error 368
ORA-283 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Tue May 30 21:52:21 2006
ALTER DATABASE RECOVER CANCEL
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Tue May 30 23:00:02 2006
ALTER DATABASE RECOVER standby database

дальше все вроде нормально. утром (когда обнаружили) руками обновили standby из ночного бэкапа. Затем в 11 часов на standby такая же ошибка:

ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /exp/dep/LOG/arc1_8161.log
Wed May 31 11:26:36 2006
Media recovery buffers written to disk due to log corruption.
Some changes at scn 627258057 may be on disk
Media Recovery failed with error 368
ORA-283 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Wed May 31 11:26:36 2006
ALTER DATABASE RECOVER CANCEL
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Wed May 31 13:00:01 2006
ALTER DATABASE RECOVER standby database

сижу вот делаю бэкап, чтобы снова накатывать, а что и почему не понятно. Искал на металинке: все сводится к тому что "открывайте запрос или пишите в support", но standby обновите свежим бэкапом.

Проверил дисковые системы на обоих серверах: везде раиды и ошибок нигде нет.
а теперь вопросы:

1. нужно ли обновлять standby из свежего бэкапа? или по другому: standby вообще нарушился?
2. где происходит ошибка: сбойнул оракл при записи online redolog или при записи online в archive log или при передаче копии на standby (но md5sum вроде совпадают)? Мне кажется первое.
3.что можно сделать на будущее?

PS кстати online redolog на основном по 2 в группе и размещены на soft partition на разных дисках.

может не в тему - сделайте полный экспорт БД в дев нуль

аля
exp full=y file=/dev/null log=file.log


и почитайте лог импорта может найдете что нибуть интересное. Если найдете пишите если не найдете то не знаю. Ни разу не встречал такой ошибки на стендбае.

сделайте полный экспорт БД в дев нуль

а я гадал, чем заняться пока идет бэкап? :-)

Начал делать, но он после второй ошибки ORA-01555 вывалился - ругался на больших пользовательских таблицах, да и работа сейчас идет довольно активно. Больше запускать не стал. Суть в том, что ночью (после первой ошибки) был экспорт и он прошел без ошибок , правда не full.

Я тут к своему удивлению обнаружил что ошибка "Media recovery buffers written to disk due to log corruption." на standby частый гость. Как-то раньше не замечали 8-( (типа удивление).

Все больше склоняюсь что дело в redolog на soft partitions (SF v240). Хотя рядом работает с такими же redolog 10G (SF v480) и ничего похожего на том standby нет.

Посмотри параметр _corrupt_blocks_on_stuck_recovery = n (10,25,30...)
Она может возникать при использование LOB объектов на основной базе (подробнее посмотри баг 2322620). В 9-ке эта проблема решена.

Параметр _corrupt_blocks_on_stuck_recovery должен выставляться в init.ora на стендбае.

--xxx--

Параметр _corrupt_blocks_on_stuck_recovery должен выставляться в init.ora на стендбае.

Чушь.

Обоснуй.

Возможно вот это заинтересует?
http://www.oracle.com/global/ru/oramag/june2001/standby.html

--xxx--

Обоснуй.

ну хотя бы факт что это скрытый параметр (что видно из имени)...этого достаточно чтоб не рассматривать его применение как нормальное стандартное решение этой проблемы

--xxx--

Обоснуй.

теперь читаем описание параметра:

number of times to corrupt a block when media recovery stuck

Вспоминаем для чего создаётся обычно стэндбай. И очевидно не для того чтоб в случае падения продакшена базы получать непонятно что с какими-то битыми блоками и с призрачными надеждами что база откроется.

Имхо, этого достаточно