Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 ORA-322, помер redo что делать?  [new]
OlegCool
Member

Откуда:
Сообщений: 7
noarchivelog, что-то можете посоветовать?
SVRMGR> alter database open;
alter database open
*
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'

SVRMGR> alter system switch logfile;
ORA-01109: database not open

Dump file C:\ORACLE\admin\kondv\bdump\kondvALRT.LOG
Tue Jan 11 13:19:40 2005
ORACLE V8.1.6.3.0 - Production vsnsta=0
vsnsql=e vsnxtr=3
Windows 2000 Version 5.1 Service Pack 2, CPU type 586
Tue Jan 11 13:19:40 2005
alter database open
Tue Jan 11 13:19:41 2005
Beginning crash recovery of 1 threads
Tue Jan 11 13:19:41 2005
Thread recovery: start rolling forward thread 1
Tue Jan 11 13:19:41 2005
Errors in file C:\ORACLE\admin\kondv\udump\ORA03160.TRC:
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'

ORA-322 signalled during: alter database open...
11 янв 05, 13:23    [1235248]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
а что произошло до открытия БД - что делал с журналами?
11 янв 05, 13:26    [1235267]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
OlegCool
Member

Откуда:
Сообщений: 7
Да не я делал, говорят электричество вырубали.. В группе по одному файлу журнала..
11 янв 05, 13:28    [1235292]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
попробуй

ALTER DATABASE CLEAR LOGFILE 'filename';
11 янв 05, 13:33    [1235328]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
11 янв 05, 13:34    [1235336]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Oleg Afanasiev
Member

Откуда: Киев
Сообщений: 3742
и вот пришла лягужка .....

какая версия базы?

тынц

И

тынц
11 янв 05, 13:35    [1235344]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
OlegCool
Member

Откуда:
Сообщений: 7
SVRMGR> ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
2> /
ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
*
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
11 янв 05, 13:38    [1235356]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
значит это CURRENT или ACTIVE группа
посмотри

select * from v$log;

дело пахнет incomplete recovery
11 янв 05, 13:40    [1235367]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
Восстановление после потери CURRENT группы
(Incomplete Recovery)



1. Восстановить все файлы из последней резервной копии
2. SQL> startup mount;
3. SQL> select * from v$log;

Определить номер последовательности для потерянного CURRENT журнала

GROUP#| THREAD#| SEQUENCE#| BYTES| MEMBERS|ARC|STATUS
----------|----------|----------|----------|----------|---|---------------
1| 1| 8| 16777216| 1|YES|ACTIVE
2| 1| 9| 16777216| 1|NO |CURRENT
3| 1| 7| 16777216| 1|YES|INACTIVE

4. Выполнить неполное восстновление

SQL> recover database until cancel;

применить все архив. файлы повторов кроме файла с номером потерянного CURRENT журн.

ORA-00279: change 72167914 generated at 04/19/2004 11:37:37 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\ADMIN\SLY\ARCH\ARCH_001_00008.LOG
ORA-00280: change 72167914 for thread 1 is in sequence #8


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

ORA-00279: change 72170463 generated at 04/19/2004 13:37:29 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\ADMIN\SLY\ARCH\ARCH_001_00009.LOG
ORA-00280: change 72170463 for thread 1 is in sequence #9
ORA-00278: log file 'C:\ORACLE\ADMIN\SLY\ARCH\ARCH_001_00008.LOG' no longer needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.


5. Открыть базу с опцией RESETLOGS

SQL> alter database open resetlogs;
Database altered.
11 янв 05, 13:41    [1235377]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
перед recovery сделай холодный бакап того что есть сейчас
11 янв 05, 13:43    [1235387]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
OlegCool
Member

Откуда:
Сообщений: 7
На самом деле, как уже говорил - noarchivelog
добавил группу, пересоздал конрольник,заменив глючную группу на новую:
SVRMGR> RECOVER DATABASE
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

о чем это он?

скрипт был такой

CREATE CONTROLFILE REUSE DATABASE "KONDV" RESETLOGS NOARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 254
MAXINSTANCES 1
MAXLOGHISTORY 7941
LOGFILE
GROUP 2 'C:\ORACLE\ORADATA\KONDV\REDO02.LOG' SIZE 5M,
GROUP 3 'C:\ORACLE\ORADATA\KONDV\REDO03.LOG' SIZE 5M,
GROUP 4 'C:\ORACLE\ORADATA\KONDV\REDO00.LOG' SIZE 5000K
DATAFILE
'C:\ORACLE\ORADATA\KONDV\SYSTEM01.DBF',
'C:\ORACLE\ORADATA\KONDV\RBS01.DBF',
'C:\ORACLE\ORADATA\KONDV\USERS01.DBF',
'C:\ORACLE\ORADATA\KONDV\TEMP01.DBF',
'C:\ORACLE\ORADATA\KONDV\TOOLS01.DBF',
'C:\ORACLE\ORADATA\KONDV\INDX01.DBF'
CHARACTER SET CL8MSWIN1251
;
11 янв 05, 14:10    [1235542]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
OlegCool
Member

Откуда:
Сообщений: 7
Забегая вперед скажу, что без опции RESETLOGS
CREATE CONTROLFILE REUSE DATABASE "KONDV" NORESETLOGS NOARCHIVELOG
*
ORA-01503: CREATE CONTROLFILE failed
ORA-01192: must have at least one enabled thread
11 янв 05, 14:11    [1235549]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
tru55
Member

Откуда: СПб
Сообщений: 19790
Да никто же не говорил про пересоздание Control file. Говорилось об иммитации неполного восстановления (slywebmaster). После RESETLOGS недостающие redo пересоздаются
11 янв 05, 14:23    [1235613]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
OlegCool
На самом деле, как уже говорил - noarchivelog


ну если у тебя база в NOARCHIVELOG то попробуй имитировать неполное
восстановление чтобы пересоздать журналы повтора

RECOVER DATABASE UNTIL CANCEL
calcel
ALTER DATABASE OPENRESETLOGS
11 янв 05, 15:19    [1235938]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
slywebmaster
Member

Откуда:
Сообщений: 759
tru55
Да никто же не говорил про пересоздание Control file. Говорилось об иммитации неполного восстановления (slywebmaster). После RESETLOGS недостающие redo пересоздаются


да действительно зачем он пересоздавал контрольный файл - он же в нормальном состоянии согласно логам - база же монтируе6тся
11 янв 05, 15:20    [1235945]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Oleg Afanasiev
Member

Откуда: Киев
Сообщений: 3742
видимо недочитал до конца по тем ссылкам,
которые я постил :)
11 янв 05, 16:13    [1236274]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: ORA-322, помер redo что делать?  [new]
вку
Guest
OlegCool
Забегая вперед скажу, что без опции RESETLOGS
CREATE CONTROLFILE REUSE DATABASE "KONDV" NORESETLOGS NOARCHIVELOG
*
ORA-01503: CREATE CONTROLFILE failed
ORA-01192: must have at least one enabled thread


Ну так чем закончилось? Как базу подняли? У меня сейчас точно такая же ситуация.
4 янв 07, 05:19    [3606023]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
evostr
Member

Откуда: Екатеринбург
Сообщений: 1278
вку
Ну так чем закончилось? Как базу подняли? У меня сейчас точно такая же ситуация.

Приведенные ссылки прочитайте (особенно первую). Только до конца.
4 янв 07, 08:45    [3606100]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
вку
OlegCool
Забегая вперед скажу, что без опции RESETLOGS
CREATE CONTROLFILE REUSE DATABASE "KONDV" NORESETLOGS NOARCHIVELOG
*
ORA-01503: CREATE CONTROLFILE failed
ORA-01192: must have at least one enabled thread


Ну так чем закончилось? Как базу подняли? У меня сейчас точно такая же ситуация.


А чем вам помогают архивлоги при порче реду логов? Собственно, единственная с них радость - это возможность, имея бэкап, восстановить базу до текущего состояния - а на собственно разные рикавери упавшей базы архивлог - не архив лог влияет слабо. Или я чего то не понимаю?

И чего все пытаются делать с контролфайлами?
5 янв 07, 05:37    [3608351]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
OlegCool
SVRMGR> ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
2> /
ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
*
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'


Похоже, что в контролфайл изменения попали, а в реду лог не совсем. Кривизна операционки, надо понимать?

Пушной зверек пришел автору, или как? Если какие то изменения не попали в реду (физически), то у базы нет никакого способа прийти в согласованное состояние, по всем теориям.
5 янв 07, 05:39    [3608352]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Alex Roudnev
Member

Откуда: Валнут Крик, Калифорния
Сообщений: 5547
А вообще я так понимаю, что все эти хитрые методы полностью эквивалентны открытию на чтение с секретной опцией _разрешить oper даже при недоделанном рекавери_ - база будет не консистентной, и кроме как _экспорт, пересоздать, сделать импорт и смотреть, что не пройдет в оном_ - нормальных способов починки нету? Так как _нет данных_ это _нет данных_ - а каких там данных нету, импорт и подскажет (если экспорт не попадает).

А базу лучше вообще открывать только на чтение, и сразу экспортировать. Так как там что то точно недописалось (какие то блоки неверные), и работать на запись на ней точно нельзя.
5 янв 07, 05:48    [3608355]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Vertigo
Member

Откуда:
Сообщений: 610
Я тоже не понял этих фокусов с контролфайлами
6 янв 07, 23:51    [3611360]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
.....
Guest
Alex Roudnev
OlegCool
SVRMGR> ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
2> /
ALTER DATABASE CLEAR LOGFILE 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'
*
ORA-01624: log 1 needed for crash recovery of thread 1
ORA-00312: online log 1 thread 1: 'C:\ORACLE\ORADATA\KONDV\REDO01.LOG'


Похоже, что в контролфайл изменения попали, а в реду лог не совсем. Кривизна операционки, надо понимать?

Пушной зверек пришел автору, или как? Если какие то изменения не попали в реду (физически), то у базы нет никакого способа прийти в согласованное состояние, по всем теориям.


Это говорит о том, что redo01 необходим для восстановления т.е. скорее всего active и все. Зачем афтор пересоздал контрол - вопрос риторический :). и никаких тебе скрытых парамтеров.

Что означает фраза
автор
при недоделанном рекавери_ - база будет не консистентной
- неполное всстановление != недоделанном рекавери_
7 янв 07, 17:31    [3612129]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Ааз
Member

Откуда: Москва/Протвино
Сообщений: 4274
Alex Roudnev
А чем вам помогают архивлоги при порче реду логов? Собственно, единственная с них радость - это возможность, имея бэкап, восстановить базу до текущего состояния - а на собственно разные рикавери упавшей базы архивлог - не архив лог влияет слабо. Или я чего то не понимаю?
Леш, у оракеля есть особенности работы с журналом:
- опережающая по отношению к блокам БД запись журнального потока (маркетинговое название "fast commit"). Правда, в этом оракель не одинок :-)
- отличительная особенность в том, что журнал, на самом деле, состоит из двух частей. Вторая - undo - пишется в блоки БД и сохраняется на диск обычным порядком
- сами блоки (в т.ч. undo) пишутся DBWR'ом неупорядоченно (в первом приближении). Одно правило - сначала redo (инструкции по изменению всех блоков, в т.ч. undo, а не только данных/индексов/...), потом блоки. Типа "А можно...? Можно, только деньги вперед" :-).

В результате:
1. Если после падения удалось накатить redo, то реконструировались не только блоки таблиц/индексов, содержащих зафиксированные и незафиксированные изменения, но и - принципиальный момент - undo (часть журнала, размещенная в файлах данных БД). Т.е. файлы согласовались. Дохлые незафиксированные транзакции в файлах имеют право быть. При работающей БД это сплошь и рядом :). Undo есть и в достаточном количестве - значит есть возможность все корректно откатить.
2. Если последнее активное (redo ACTIVE+CURRENT) не накатилось, то в актуальном на момент сбоя наборе файлов имеется потенциально кривой внутренний журнал (undo), помимо непонятно какой свежести блоков таблиц/индексов/... Соответственно, различить в блоке таблицы/индекса кто там есть who (зафиксировано или нет), а также восстановить хронологию изменений невозможно.

Например, в блоке таблицы есть след незафиксированной транзакции, указывающий на блок undo. Идем в undo и видим, что там вообще нет данных про эту транзакцию. И вот тут возникает неоднозначность:
- при накаченном redo вывод был бы ясный - раз наших тута нету, значит их перезаписали. Раз перезаписали, значит можно было. А можно было потому, что транзакция пофиксилась. Правило такое. Ну и не проблема, фиксим транзакцию в блоке таблицы и поехали дальше. Фирма гарантирует.
- при ненакаченном redo - ХЗ, т-щ полковник. Либо блок undo погиб в кеше и до диска не доехал, либо все честно, типа доехал... И никаких критериев, по которым можно сделать верный выбор. Подозрения-то (т.е. различить) иногда сохраняются в БД. Типа, рассогласование SCN в блоке таблицы и те SCN'ы, что в undo. Если больше - скорее всего перезаписано, если меньше - скорее всего не доехало... Но кому нах. нужны в транзакционной системе такие гадания? Потому вот вам одна из ORA-00600 [4xxx] и наслаждайтесь общением с суппортом ;-)

Аналогично, но более жестко в обратном направлении, т.е. когда пляшем не от таблицы, а от undo, как это делает SMON. Этот перец - крут по определению. Ежели он чего вычитал в блоке undo и, полезши с этим в блок таблицы/индекса, не нашел соответствующих данных - сразу нах. Какая-нить ORA-00600 (дабы таки был повод отослать логи в суппорт) и abort инстансу.

Про _allow_resetlogs_corruption и/или _allow_readonly_corruption ты верно подметил - открыть БД можно, но фирма никуя не гарантирует :-). Это уже не база, а гнусное скопище файлов.

И далеко не факт, что инстанс долго после такого открытия простоит. Чаще всего SMON кирдыкается, либо пользователь напорется, и будет дуля вместо exp. Правда, SMON'а можно всякими event'ами усмирить, дабы не дергался. Что обычно в таких случаях и делают. А фигли, раз уж нету претензий на получение корректных данных, тут уж хоть шерсти клок урвать.

Чтобы избавиться от гнусностей, следует достать из широких штанин дубликат (aka backup) и накатить то redo (из архивных и оперативных журналов), которое нагенерилось с момента упрятывания дубликатов в широкие штанины. Т.е. актуальные на момент сбоя файлы (aka гнусь) для этой цели не годятся - слишком далеко вперед по времени убежали, а в обратную сторону оракель откатываться не умеет. Типа, сдать чуток назад - ну никак. Тока прыжок в прошлое и все заново :-).

Понятно, что ежели redo не все (конец потока, последние redo, или где-то посередке архивный журнал потеряны) - то да, части зафиксированных транзакций - пушной зверек. Я бы даже сказал, полный кирдык. Зато к уцелевшему претензий нету. Фирма гарантирует.

HTH
Всего
7 янв 07, 20:18    [3612254]     Ответить | Цитировать Сообщить модератору
 Re: ORA-322, помер redo что делать?  [new]
Vertigo
Member

Откуда:
Сообщений: 610
.....
Зачем афтор пересоздал контрол - вопрос риторический :). и никаких тебе скрытых парамтеров.

Ну, пересоздание контрола нужно только для хоть какого-нибудь возможного рекавера, без скрытых параметров все равно не откроется :)
Мне непонятна чехарда с подменой вновь созданного лога на потерянный

Ааз, все хочу к Вам на курсы, может в этом году таки получится. Сильно стиль изложения импонирует :)
7 янв 07, 23:09    [3612438]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Oracle Ответить