file 1 needs more recovery

на созданном при переезде с 10.2.0.4  на 11.2.0.3. стендбае


получил неприятное состояние с накатом архивов (v$log_history)

видимо из-за этого имею проблему с ORA-01110:


[SRC HTML]


SQL> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production






SQL> recover standby database until cancel;
ORA-00279: change 68787009728 generated at 12/17/2012 11:11:00 needed for
thread 1
ORA-00289: suggestion :
/ORACLE_DEST/DXWK/arch/XW64/archivelog/2012_12_17/o1_mf_1_576_%u_.arc
ORA-00280: change 68787009728 for thread 1 is in sequence #576


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/mnt/HITACHIs0/XW64/oradb/system01XWK.dbf'


ORA-01112: media recovery not started


SQL> select max(sequence#) from v$log_history;

MAX(SEQUENCE#)
--------------
          1070

SQL> @inst

System altered.


Session altered.


HOST       INSTANCE   STATUS
---------- ---------- ------------
euro       DXWK       MOUNTED

SQL> select sequence# from v$log_history where recid = (select max (recid) from v$log_history);

 SEQUENCE#
----------
       575

perf


да вот ещё такая неприятносить на prod

SQL> l
1* SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#
SQL>

       594 09-DEC-12 09-DEC-12
       594 17-DEC-12 17-DEC-12
       595 17-DEC-12 17-DEC-12
       595 09-DEC-12 09-DEC-12
       596 17-DEC-12 17-DEC-12
       596 09-DEC-12 09-DEC-12
       597 17-DEC-12 17-DEC-12
       597 09-DEC-12 09-DEC-12
       598 09-DEC-12 09-DEC-12
       598 17-DEC-12 17-DEC-12
       599 09-DEC-12 09-DEC-12
       599 17-DEC-12 17-DEC-12
       600 09-DEC-12 09-DEC-12
       600 17-DEC-12 17-DEC-12
       601 09-DEC-12 09-DEC-12
       602 09-DEC-12 09-DEC-12
       603 09-DEC-12 09-DEC-12

видимо могу подняться с бэкапным управляющим файлом и с resetlogs на стендбайном хосте и потом уже поменять роли
но всеж может и в этой ситуации чтото можно сделать?


С уважением.

1) Насколько я помню по доке - стендбай разрешён только на одинаковых версиях. Апгрейд вида как вы сделали - помоему не описывается в доке.
Вы вообще тестили такой апгрейд до внедрения в продакш?
2) А чего у вас так странно сиквенсы логов на проде идут? То 17, то 09 декабря...

Что делали то? Что за @inst?

ну и тип стендбая покажите уж, чтоб не гадать во что вы вляпались.

Dgordeenko
ну и тип стендбая покажите уж, чтоб не гадать во что вы вляпались.

версии баз данных одинаковы

Dgordeenko
1) Насколько я помню по доке - стендбай разрешён только на одинаковых версиях. Апгрейд вида как вы сделали - помоему не описывается в доке. Вы вообще тестили такой апгрейд до внедрения в продакш? 2) А чего у вас так странно сиквенсы логов на проде идут? То 17, то 09 декабря... Что делали то? Что за @inst?

вот про эту странность и вопрос .....

perf
Dgordeenko 1) Насколько я помню по доке - стендбай разрешён только на одинаковых версиях. Апгрейд вида как вы сделали - помоему не описывается в доке. Вы вообще тестили такой апгрейд до внедрения в продакш? 2) А чего у вас так странно сиквенсы логов на проде идут? То 17, то 09 декабря... Что делали то? Что за @inst? вот про эту странность и вопрос .....

пока я болел базу прорекаверили до exp/imp c параметром

_ALLOW_RESETLOGS_CORRUPTION=TRUE

к сожалению бэкапы от той инкарнации уже потерты - те что есть на настоящее время уже с этой последовательностью нумерации логов

perf,
0) Что значит

perf
базу прорекаверили до exp/imp

??

1) И вы после этого сделали апгрейд стендбая? А перед апгрейдом то - стендбай был близок к проду или не смотрели?
http://docs.oracle.com/cd/B19306_01/server.102/b14239/manage_ps.htm#SBYDB00206
Раздел 8.4 Правда я думаю, что в случае битого редо и _ALLOW_RESETLOGS_CORRUPTION=TRUE - пересоздание standby.
Базу проверяли на ошибки после такого восстановления?

2)
на стендбае:

select version from v$instance;
select resetlogs_time, database_role from v$database;

на проде:

select version from v$instance;
select resetlogs_time, database_role from v$database;

Dgordeenko,

я с кожалению только сейчас узнал про эту гнилую ситуация - каюсь сам виноват
прорекаверили имелось ввиду до того как сделали на нее импорт


ну собственно примерное решение для себя я уже понял - пересоздать контролы и подняться с noresetlogs .
потом сделать switchover

SQL> select version from v$instance;
select resetlogs_time, database_role from v$database;

VERSION
-----------------
11.2.0.3.0

SQL> 
RESETLOGS DATABASE_ROLE
--------- ----------------
12-DEC-12 PRIMARY

SQL> 


*************************************



SQL> select version from v$instance;
select resetlogs_time, database_role from v$database;

VERSION
-----------------
11.2.0.3.0

SQL> 
RESETLOGS DATABASE_ROLE
--------- ----------------
12-DEC-12 PHYSICAL STANDBY

perf,
и получите полную хрень :-)

Почему у вас с прода версия - 11.2.0.3 если вы еще не апгрейдили её?
И почему времена ресетлогов совпадают?

у вас стенд - боевой? Вы же данные потеряете....

Короче, вы либо объясните понормальному, что вы делали, что ожидали, что получили, зачем хотите свитчовер, либо жду вас через пару дней в новой теме ;)