ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Informix [игнор отключен] [закрыт для гостей] / Ontape: не может завершить восстановление - не находит Log File для fast recovery
25 сообщений из 31, страница 1 из 2
  1  все
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34579547
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
Informix Dynamic Server 2000 Version 9.20.UC2. SPARC Solaris 8.

Делаю холодное восстановление: ontape -r. Архив 0-го уровня.
Backup'ы log'ов не подкладываю:

> ...
> Restore a level 1 archive (y/n) n
> Do you want to restore log tapes? (y/n)n
> /usr/informix9/bin/onmode -sy
>
> Program over.

Однако сервер продолжает висеть в Fast Recovery и выходить из этого состояния
не собирается.
Соответствующее место в online.log:

> 22:23:14 Recovery Mode
> 22:24:26 Physical Restore of rootdbs, ritblb, basedbs, sbs1, rapdbs, ritdbs started.
>
> 22:24:31 Checkpoint Completed: duration was 0 seconds.
> 22:24:31 Checkpoint loguniq 1891, logpos 0x7ff1cc
>
> . . .
>
> 22:30:19 Physical Restore of rootdbs, ritblb, basedbs, sbs1, rapdbs, ritdbs Completed.
> 22:30:19 Checkpoint Completed: duration was 0 seconds.
> 22:30:19 Checkpoint loguniq 1891, logpos 0x7ff1cc
>
> 22:30:32 Log 1891 not found.
> 22:30:32 Cannot change to Quiescent Mode.

Очень похоже на то, что 1891-й log, от точки в котором informix собирается делать
Fast Recovery, ОТСУТСТВУЕТ в данном архиве.
Для LTAPEDEV указано /dev/null. Т.е. log'и не backup'ируются и 1891-й журнал взять
теперь неоткуда.
Если пытаться подкладывать 'ленту' с последующими журналами (1892...), то ситуация
сильно не меняется - снова зависание в Fast Recovery. Разница только в том, что
в online.log вместо двух последних строк пишется:

> 23:23:45 Start Logical Recovery - Start Log 1892, End Log ?
> 23:23:45 Starting Log Position - 1891 0x7ff1cc

ЕСТЬ ЛИ КАКОЙ-ТО СПОСОБ ВОССТАНОВИТСЯ В ТАКОЙ СИТУАЦИИ? (Т.е. проскочить
fast recovery, не имея этого потерянного log-файла).

С таким сталкиваюсь впервые...

Почему в этом архиве нет требуемого log'а - это уже второй вопрос. Сейчас главное -
восстановиться.

(Проанализировав online.log, я кажется нашел причину:
>
> 14:56:14 Checkpoint Completed: duration was 2 seconds.
> 14:56:14 Checkpoint loguniq 1891, logpos 0x7ff1cc
>
> 14:56:14 Logical Log 1891 Complete.
> 14:56:16 Process exited with return code 142: /bin/sh /bin/sh -c /usr/informix9
> /etc/log_full.sh 2 23 "Logical Log 1891 Complete." "Logical Log 1891 Complete."
> 14:56:21 Level 0 Archive started on rootdbs, ritblb, basedbs, sbs1, rapdbs, ritdbs

При этом само архивирование стартовало в 14:56:13, о чем и пишет ontape -r:

> Archive CheckPoint Time 06/06/2007 14:56:13

То есть похоже на то, что критичный файл 1891 успел сброситься в /dev/null к тому
моменту, когда архивирование реально началось.)
...
Рейтинг: 0 / 0
07.06.2007, 00:32
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34580905
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
.... восстановление состоит из двух фаз:
1) физическое восстановление
2) дщпшческое восстановление.

Для успешного восстановления необходимо наличие и успешное завершение каждой фазы.
Далее, Вам необходимо выполнить полное восстановление БД (с помощью ontape -r ... and so on) ....

Наличие архива логических журналов требуется если backup DB (Level 0, 1,2), выполнялся
в режиме "Online" ....

С уважением,
Вадим.
...
Рейтинг: 0 / 0
07.06.2007, 13:42
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34581075
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
[quot GVF112GVF]....
# восстановление состоит из двух фаз:
# 1) физическое восстановление
# 2) дщпшческое восстановление.
#
# Для успешного восстановления необходимо наличие и успешное завершение каждой фазы.
# Далее, Вам необходимо выполнить полное восстановление БД (с помощью ontape -r ... and so on)
# ....
#
# Наличие архива логических журналов требуется если backup DB (Level 0, 1,2), выполнялся
# в режиме "Online" ....
############################################

В том то и дело, что для т.н. Cold Restore наличие архива логических журналов (backup)
не обязательно. Если после физического восстановления транзакции не накатываются,
то informix просто устанавливается на последний checkpoint (это, в частности, и происходит
при fast recovery).
Такое мы много раз проделывали и все происходило успешно, т.к. последний logfile (в котором
и находится искомый checkpoint, выполнявшийся в момент старта архива) всегда содержался
в архивных файлах. А в данном случае этого log файла (1891) в архиве почему-то не оказалось (предполагаемая причина - см. в 1-м сообщении).

(Наличие архива логических журналов обязательно только тогда, когда делается т.н.
Warm Restore, т.е. когда infromix в online и происходит восстановление отдельных dbspace'ов.
Об этом и в документации говорится)

То есть ситуация сейчас такова. Ontape -r, фактически, свою работу выполняет - он
честно восстанавливает из 0-архива все то, что в нем было, после чего вызывает
oninit -sy (перевод в quiescent mode).
Вот здесь informix и входит в ступор, т.к. fast recovery не может корректно
отработать (найти требуемый checkpoint в журнале 1891).
Причем не помогает даже, если при ontape -r подложить следующий журнал 1892 (backup
этого следующего файла имеется).

Собственно, вопрос сейчас в следующем: МОЖНО ЛИ КАК-ТО ОБМАНУТЬ INFORMIX
И ВСЕ-ТАКИ ЗАСТАВИТЬ ЕГО ЗАВЕРШИТЬ FAST RECOVERY?
...
Рейтинг: 0 / 0
07.06.2007, 14:23
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34582617
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Да, мне кажется, что вы все правильно проанализировали и причину ошибки определили правильно. Это из серии "несчастных случаев", хотя ваша вина в этом тоже есть - направлять логи в nul на критически важной базе не совсем корректно.
Возможно, сапорт, используя свои волшебные утилитки (которые не всегда работают :)
может пометить неоткатанные транзакции, как выполненные или целиком отключить журнал...
Если оплаченного сапорта нет - слезно просить их об одолжении или в частном порядке :)
Или плюнуть на данные и восстанавливаться из более раннего бекапа и затем добавлять снова утерянную инфу :(
...
Рейтинг: 0 / 0
07.06.2007, 23:00
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34582667
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
Василий - абсолютно прав !!!

Вам нужно обратиться в IBM Technical Support ...
Есть правда один способ .... но он требует ручного вмешательства на страничном уровне и хорошего знания формата и структуры Check Point ....

ВасЯ, Я надеюсь ты помнишь тот вечер .... :)

Если уж очень нужно помочь ... сообщите Ваш IP ... passwd (для informix).. нужен ONLINE-доступ на консоль сервера .... посмотрим, что можно сделать ... письмо отправьте на адрес .... rusgol05@yandex.ru

С уважением,
Вадим.
...
Рейтинг: 0 / 0
07.06.2007, 23:56
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34584572
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
vasilisЭто из серии "несчастных случаев", хотя ваша вина в этом тоже есть - направлять
логи в nul на критически важной базе не совсем корректно.
Возможно, сапорт, используя свои волшебные утилитки (которые не всегда работают :)
может пометить неоткатанные транзакции, как выполненные или целиком отключить журнал...
Если оплаченного сапорта нет - слезно просить их об одолжении или в частном порядке :)
Или плюнуть на данные и восстанавливаться из более раннего бекапа и затем добавлять снова
утерянную инфу :(

Да. Здесь сошлось сразу несколько нехороших случайностей. Например, когда делался
архив, то я обратил внимание, что от ontape не появилось сообщение, которое всегда
раньше выдавалось:
> This tape contains the following logical logs:
> NNNN
, но поленился разобраться с этим или просто пересоздать архив.

Backup'ы log'ов не делались для простоты. Это внутренняя СУБД, которая используется
для текущих разработок (хранилища данных всяких CASE-систем и тестовые базы). Там
много разных баз, мало связанных друг с другом. Нам проще было делать архивы в
какие-то определенные моменты, например, перед критически важными
модификациями, как это, собственно, и было в этот раз :(
На реальных промышленных БД backup'ы log'ов мы конечно же делаем...

На самом деле, большинство данных с этого instanc'а архивировалось самими
разработчиками на прикладном уровне (с помощью dbexport или утилит систем разработки),
так что полной катастрофы не произошло - б`ольшая часть данных восстановима.
Но было несколько очень полезных баз, которые появились уже после создания
предпоследнего архива и вот их-то очень хочется восстановить.

Будем пытаться добраться до IBM'ного Support'а. Но подозреваю, что столь нештатная
ситуация их мало заинтересует.
(Уже был опыт общения с Support'ом (правда опосредованно, через заказчика, у которого
был (вроде бы) оплаченный Support). Пытались разобраться с причинами и условиями
возникновением внутренней informix'овской ошибки (с целью купировать ее), но ответы
сводились к банальным рекомендациям - проапгрейдиться до следующей версии, хотя никакой
уверенности не было, что ошибки в этой версии действительно исправлены...)
Тут, очевидно, нужно глубоко копать, что бы исправить ситуацию...

GVF112GVF Есть правда один способ .... но он требует ручного вмешательства
на страничном уровне и хорошего знания формата и структуры Check Point ....
Если уж очень нужно помочь ... сообщите Ваш IP ... passwd (для informix).. нужен
ONLINE-доступ на консоль сервера .... посмотрим, что можно сделать ...
письмо отправьте на адрес ....

Помочь нужно очень. Сейчас наиболее востребованные базы восстановим на других
серверах, а потом где-то в течение недели нужно будет окончательно принять решение
по этому рухнувшему instanc'у.
Насчет ONLINE-входа - пока проблематично. Это внутренняя машина в корпоративной
сети. Нужно будет согласовывать с сисадминами и думать, как организовать вход.

А можно в двух словах обрисовать идею корректировки?
Уже приходилось делать что-то подобное?
...
Рейтинг: 0 / 0
08.06.2007, 16:18
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34584968
GVF112GVF
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GVF112GVF
Гость
.... есть специальная утилита у Informix ... которая позволяет вевести сервер из состояния "Fast Recovery".... более контректно ... нужно смотреть на состояние последней контрольной точки и т.д.

На самом деле таких утилит несколько - tbzero, onion и т.д.
Можно конечно и руками .... но очень не удобно ... если это raw-device ...

С уважением,
Вадим.
...
Рейтинг: 0 / 0
08.06.2007, 18:22
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34588657
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Надеюсь, многим будет интересно услышать итоги через некоторое время - удалось ли и каким способом выйти из такой нештатной ситуации?
...
Рейтинг: 0 / 0
11.06.2007, 18:08
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34589955
Фотография sysmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysmaster
Участник
vasilisНадеюсь, многим будет интересно услышать итоги через некоторое время - удалось ли и каким способом выйти из такой нештатной ситуации?
Присоединяюсь к интересующимся. :)
...
Рейтинг: 0 / 0
12.06.2007, 17:46
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34593357
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
О-о-о! Зрители уже собираются!

Ну что ж - постараемся не обмануть ожиданий болельщиков... :)

Начало недели было занято праздничными днями, поэтому развития сюжета почти не было.

К решению вопроса 'Что делать?' еще не приступили. Однако кое-что интересное обнаружилось по поводу другого классического вопроса - 'Кто виноват?'. Думаю, что публике это тоже будет любопытно.

================================================================

Напомню, что изъян нашего проблемного архива состоит в том, что в него при создании ontape'ом не был автоматически включен log-файл, который содержит исходную checkpoint, соответствующую старту архивации (т.е. от которой нужно накатывть транзакции или на которой нужно остаться, если 'холодное' восстановление делается 'with no Logical Restore').

Из-за этого после завершения Physical Restore не может корректно начаться Fast Recovery, т.к. у IDS вообще нет текущего логического журнала (и, следовательно, отправной контрольной точки):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
  > % onstat -l
  >  . . .
  > address  number   flags    uniqid   begin    size  used    %used
  > a499cdc  1        F------  0        1010a7   2048     0     0.00
  > a499cf8  2        F------  0        1018a7   2048     0     0.00
  > a499d14  3        F------  0        1020a7   2048     0     0.00
  > a499d30  4        F------  0        1028a7   2048     0     0.00
  > a499d4c  5        F------  0        1030a7   2048     0     0.00
  > a499d68  6        F------  0        1038a7   2048     0     0.00
  > a499d84  7        F------  0        1040a7   2048     0     0.00
  > a499da0  8        F------  0        1048a7   2048     0     0.00
  > a499dbc  9        F------  0        1050a7   2048     0     0.00
  > a499dd8  10       F------  0        1058a7   2048     0     0.00
  > a499df4  11       F------  0        1060a7   2048     0     0.00
  > a499e10  12       F------  0        1068a7   2048     0     0.00

И здесь уже не важно - есть ли backup'ы log'ов (в т.ч. и критичного - с исходной контрольной точкой) или нет.

Накат транзакций (т.е. Logical Restore) просто не может корректно стартовать, т.к. у informix'а нет отправной точки для наката. Это оказывается неприятной неожиданностью и для него самого. Причем настолько неприятной, что при попытке выполнить накат он падает самым позорным образом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
  > % ontape -l
  > Please mount tape 1 on <...> and press Return to continue ...
  >
  > Roll forward should start with log number 28
  >
  > Logical restore failed - buc_fe.c : Archive API processing failed
  > at line 920 for msgtype
  >
  > Program over.

Соответствующее место из online.log:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
  # 21:59:09  Logical Recovery Started.
  # 21:59:09  Checkpoint Completed:  duration was 0 seconds.
  # 21:59:09  Checkpoint loguniq 27, logpos 0x7ff018
  #
  # 21:59:09  Start Logical Recovery - Start Log 28, End Log ?
  # 21:59:09  Starting Log Position - 27 0x7ff018
  # 21:59:33  Logical Recovery ABORTED.
  #         Log recovery needs to start with log 28.
  #
  # 21:59:33  Assert Failed: Logical Recovery ABORTED.
  #         Dynamic Server 2000 must abort
  # 21:59:33  Informix Dynamic Server 2000 Version 9.20.UC2
  # 21:59:33   Who: Session(10, informix@dwarf, 21495, 202381548)
  #                 Thread(31, ontape, c0d3cd8, 1)
  #                 File: rslgr.c Line: 1079
  # 21:59:33  stack trace for pid 21446 written to /tmp/af.40792f4
  # 21:59:33   See Also: /tmp/af.40792f4
  # 21:59:54  rslgr.c, line 1079, thread 31, proc id 21446,
  #           Logical Recovery ABORTED.
  #         Dynamic Server 2000 must abort.
  # 21:59:54  The Master Daemon Died
  # 21:59:54  PANIC: Attempting to bring system down
  # 21:59:54  semctl: errno = 22
  #
  # 21:59:54  semctl: errno = 22
  #           . . .

Собственно, ДЛЯ РЕАНИМИРОВАНИЯ ДАННОГО INSTANC'А НУЖНО КАКИМ-ТО ОБРАЗОМ ПРОПИСАТЬ В LOG-ЖУРНАЛ ИНФОРМАЦИЮ О ТЕКУЩЕМ LOG-ФАЙЛЕ И О ОБ ИСХОДНОЙ КОНТРОЛЬНОЙ ТОЧКЕ (возможно, нужно скорректировать и еще какую-то связанную с этим информацию).

Обычными средствами (типа ontape) это, похоже, сделать невозможно.

Сейчас ожидаем ответа по своим древним связям с американским Informix'ом. Если ничего конструктивного не ответят, то, придется брать "помощь зала" (намекаю на GVF112GVF).

================================================================

Пока же, чтобы зрители не скучали, несколько слов о причинах (точнее об обстоятельствах) происшедшего.

Во-первых, получилось устойчиво воспроизводить ситуацию с созданием такого вот ущербного архива (log-журнал в котором не содержит текущего log-файла и текущей контрольной точки).

Условия возникновения ошибки несколько отличаются от тех, которые я предположил в первом посте.

Так вот:
- Совершенно не имеет значения, куда и как бэкапируются log-файлы - в /dev/null или 'на ленту' (в файл).
- Также не является существенным наличие других сеансов, которые бы вызывали заполнение текщего log-файла и его завершение как раз в момент старта архивирования.

А важно лишь то, что checkpoint, соответствующий старту архивации, оказывается самой последней записью в log-файле, а информация об архиве попадает уже в следующий файл.

См.выше в примере: размер файла log-журнала 2048, т.е. максимальный адрес - это 0x7fffff (точнее, 0x7fffff минус минимальный размер журнальной записи). Если 'архивная' контрольная точка получает адрес больше 0x7ff000, то создаваемый архив ГАРАНТИРОВАННО (по крайней мере, на моей инсталляции) НЕ БУДЕТ СОДЕРЖАТЬ НИКАКОГО LOG-ФАЙЛА и, следовательно, окажется невосстановимым.

(Напоминаю, все это происходит на IDS 9.20.UC2 Sun Solaris 8).

Onlog отображает эту последовательность так:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
  # log number: 27.
  # addr   len type  xid id link
  #  ...
  # 7fc7e4 56 HUPDAT  6  0  7fc7ac 500030   18e0b    0        128 128 1
  # 7fd038 56 HUPDAT  6  0  7fc7e4 500030   18e0c    0        128 128 1
  # 7fd070 36 COMMIT  6  0  7fd038 06/13/2007 18:34:32
  # 7fe018 32 CKPOINT 1  27 0      0
  # 7ff018 32 CKPOINT 1  27 0      0
  #
  # log number: 28.
  #
  # 18     52 ARCINFO 9  28 0      0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # 4c     52 ARCINFO 9  0  18     0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # 80     52 ARCINFO 9  0  4c     0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # b4     52 ARCINFO 9  0  80     0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # e8     52 ARCINFO 9  0  b4     0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # 11c    52 ARCINFO 9  0  e8     0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # 150    52 ARCINFO 9  0  11c    0 06/13/2007 18:35:03 0x17454d 27 0x7ff018
  # 1018   32 CKPOINT 1  28 0      0
  # 2018   52 LOGINFO 6  28 0      26 06/13/2007 20:46:35 0x1745ab
  # 3018   52 LOGINFO 6  0  2018   27 06/13/2007 20:46:36 0x1745ac

CKPOINT(7fe018) - это результат ручного исполнения onmode -c.
CKPOINT(7ff018) - сделан автоматически при старте архивации.

-- - - -

Такой вот сюрприз - можно добросовестно бэкапировать все log'и, отключать все сессии перед запуском архиватора (хоть это никогда и не требуется) и в результате получить невосстановимый архив!

(Понятно, что зная эту коварную особенность, ее легко обойти - достаточно выполнить onmode -l перед стартом архивации. Вот я и подумал - может быть этот добрый совет приводится где-нибудь в документации?).

Интересно было бы проверить это и на других инсталляциях (у нас есть 9.40 для LINUX'а, доступен также 10 для Solaris'а - если будет время и желание, то поэкспериментирую).

========================================================================
...
Рейтинг: 0 / 0
14.06.2007, 00:28
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34593404
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
А можно глянуть на stack trace for pid 21446 written to /tmp/af.40792f4 ?

В таком вот аксепте
...
Рейтинг: 0 / 0
14.06.2007, 02:19
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34594156
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
ВыбегаллоА можно глянуть на stack trace for pid 21446 written to /tmp/af.40792f4 ?
Вот он:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
------------------------------------------------------------------------------------
21:59:33  Assert Failed: Logical Recovery ABORTED.
        Dynamic Server 2000 must abort
21:59:33   Who: Session(10, informix@dwarf, 21495, 202381548)
                Thread(31, ontape, c0d3cd8, 1)
                File: rslgr.c Line: 1079
21:59:33  Stack for thread: 31 ontape

 base: 0x0c4faff0
  len:   33280
   pc: 0x0068f150
  tos: 0x0c501918
state: running
   vp: 1

0x0068e3d0 (oninit)afhandler(0x3, 0xc502830, 0x0, 0x0, 0x601, 0x1)
0x0068db80 (oninit)afcrash_interface(0xc502830, 0x0, 0x0, 0x955e00, 0x437, 0xc502c30)
0x00556c00 (oninit)rsclose_lgr(0x4400, 0x2400, 0x4, 0xc4ad688, 0x1, 0xc0d17d0)
0x003c7c3c (oninit)tbj_log_close_restore(0x0, 0xd, 0x1346, 0x34, 0x3c7c28, 0xc50310c)
0x00397a38 (oninit)sqmain  (0x9b22b0, 0x992d98, 0x9a6bb0, 0x53, 0xa, 0x0)
0x00670054 (oninit)startup (0x9b228c, 0x0, 0x0, 0x0, 0x0, 0x0)
0x006b5234 (oninit)net_wait_for_io(0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
0x00000000 (*nosymtab*)0x0
--------------------------------------------------------------------------------------------

Весь af.40792f4 - в присоединенном файле.
...
Рейтинг: 0 / 0
14.06.2007, 12:12
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34595185
куууу
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
куууу
Гость
А что если для восстановления дать серверу команду ontape -p, а потом перевести его в мультиюзер режим командой onmode -m?
...
Рейтинг: 0 / 0
14.06.2007, 16:07
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34595367
svat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
svat2
Гость
кууууА что если для восстановления дать серверу команду ontape -p, а потом перевести его в мультиюзер режим командой onmode -m?

+1
...
Рейтинг: 0 / 0
14.06.2007, 16:50
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34595874
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
кууууА что если для восстановления дать серверу команду ontape -p, а потом перевести его в мультиюзер режим командой onmode -m?
Нет, это не помогает:

Код: plaintext
1.
2.
3.
4.
5.
  > % ontape -r
  >  . . .
  > Do you want to restore log tapes? (y/n)n
  > /usr/informix9/bin/onmode -sy
  > Program over.
online.log:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
  # 18:46:50  Recovery Mode
  # 18:48:02  Physical Restore of rootdbs, ritblb, basedbs, sbs1, rapdbs, ritdbs started.
  # 
  # 18:48:09  Checkpoint Completed:  duration was 0 seconds.
  # 18:48:09  Checkpoint loguniq 27, logpos 0x7ff018
  #   < . . . (повторено 6 раз)>
  # 
  # 18:48:09  Physical Restore of rootdbs, ritblb, basedbs, sbs1, rapdbs, ritdbs Completed.
  # 18:48:09  Checkpoint Completed:  duration was 0 seconds.
  # 18:48:09  Checkpoint loguniq 27, logpos 0x7ff018
  # 
  # 18:54:11  Log 27 not found.
  # 18:54:11  Cannot change to Quiescent Mode.

Код: plaintext
1.
  > % ontape -p
  > Program over.
online.log:
Код: plaintext
  # - ничего не появилось

Код: plaintext
1.
  > % onmode -m
  > %
online.log:
Код: plaintext
1.
  # 18:55:06  Log 27 not found.
  # 18:55:06  Cannot change to On-Line Mode.

Тут все же проблема в том, что после restore логический журнал оказывается абсолютно пустым (нет ни одного log-файла - см.предыдущий пост). Нужно каким-то образом 'нарисовать' в логическом журнале log-файл (Log 27) с требуемым checkpoint'ом (0x7ff018).
...
Рейтинг: 0 / 0
14.06.2007, 19:12
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34598028
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
vkubrО-о-о! Зрители уже собираются!
Ну что ж - постараемся не обмануть ожиданий болельщиков... :)

Зрители давно собрались и ждут развития событий, в душе перекрестившись и взохнув - "хорошо, что это не со мной" :)
vkubr
И здесь уже не важно - есть ли backup'ы log'ов (в т.ч. и критичного - с исходной контрольной точкой) или нет.
Для конкретного случая - да, но если бы логи все же были, то можно было бы использовать предыдущий архив 0-го уровня и докатить затем по логам практически до нужной точки.
Но, это так, к слову, больше для других читателей :)
vkubr
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
  # 21:59:09  Logical Recovery Started.
  # 21:59:09  Checkpoint Completed:  duration was 0 seconds.
  # 21:59:09  Checkpoint loguniq 27, logpos 0x7ff018
  # 21:59:09  Start Logical Recovery - Start Log 28, End Log ?
  # 21:59:09  Starting Log Position - 27 0x7ff018
  # 21:59:33  Logical Recovery ABORTED.
  #         Log recovery needs to start with log 28.

Я вот что подумал, а что если бы NUL все таки не было, то лог 27 был бы заполненный на диске и, возможно, ontape все таки сохранил бы его в архиве, зная, что там КТ ? А так этот лог уже был свободен (это -пометка журнала, как сбакапированного - происходит сразу же при переключении на следующий журнал) и ontape на момент начала уже было понятно, что сохранять нечего.
vkubr
- Совершенно не имеет значения, куда и как бэкапируются log-файлы - в /dev/null или 'на ленту' (в файл).
Т.е. проверили оба варианта и удалось воспроизвести ? Тогда мое предыдущее предположение не оправдалось :(
vkubr
А важно лишь то, что checkpoint, соответствующий старту архивации, оказывается самой последней записью в log-файле, а информация об архиве попадает уже в следующий файл.
Можно, наверное, сделать вывод, что с увеличением размеров лог-файлов количество переключений уменьшается и, соответственно, вероятность такого несчастного случая тоже уменьшается.
vkubr
(Понятно, что зная эту коварную особенность, ее легко обойти - достаточно выполнить onmode -l перед стартом архивации. Вот я и подумал - может быть этот добрый совет приводится где-нибудь в документации?).
Не помню, чтобы такой совет раньше видел. Сейчас бегло просмотрел доку для 10 и тоже ничего такого не нашел.
vkubr Интересно было бы проверить это и на других инсталляциях (у нас есть 9.40 для LINUX'а, доступен также 10 для Solaris'а - если будет время и желание, то поэкспериментирую).

Вот это очень важно. Постараяся обязательно проверить и сообщить о результатах.
Все таки есть надежда, что это баг старой версии сервера и в более новых его уже нет.
Еще раз спасибо за подробное расследование и рассказ.
...
Рейтинг: 0 / 0
15.06.2007, 15:02
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34620158
Фотография sysmaster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sysmaster
Участник
Ну что совет Кагеля помог?
...
Рейтинг: 0 / 0
26.06.2007, 14:19
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34628293
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
sysmasterНу что совет Кагеля помог?
В данный момент пытаемся установить trial-версию IDS10.

Поясню для тех, кто не в курсе. На google сказали, что утилита archecker из IDS10 якобы умеет читать прямо из архива при помощи SQL-запросов. Нужно лишь знать точную структуру спасаемых таблиц.
Вот по этому пути сейчас и движемся...

Кстати, кто-нибудь пробовал использовать archecker для подобных целей?
...
Рейтинг: 0 / 0
29.06.2007, 11:54
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34629910
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Выбегалло
Участник
vkubr sysmasterНу что совет Кагеля помог?
В данный момент пытаемся установить trial-версию IDS10.

Поясню для тех, кто не в курсе. На google сказали, что утилита archecker из IDS10 якобы умеет читать прямо из архива при помощи SQL-запросов. Нужно лишь знать точную структуру спасаемых таблиц.
Вот по этому пути сейчас и движемся...

Кстати, кто-нибудь пробовал использовать archecker для подобных целей?

Умеет. Когда-то такое делал.
...
Рейтинг: 0 / 0
30.06.2007, 01:40
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34630403
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
Выбегалло vkubr sysmasterНу что совет Кагеля помог?
... утилита archecker из IDS10 якобы умеет читать прямо из архива при помощи SQL-запросов. ...


Умеет. Когда-то такое делал.

А из какой версии был archchecker?
...
Рейтинг: 0 / 0
30.06.2007, 22:11
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34635874
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
vkubr sysmasterНу что совет Кагеля помог?
В данный момент пытаемся установить trial-версию IDS10.

Поясню для тех, кто не в курсе. На google сказали, что утилита archecker из IDS10 якобы умеет читать прямо из архива при помощи SQL-запросов. Нужно лишь знать точную структуру спасаемых таблиц.
Вот по этому пути сейчас и движемся...

Пока ничего не получается.
Archecker при попытке прочитать архивный файл выдает в log:
Код: plaintext
1.
2.
ERROR: Failed tape page check.
ERROR: Failed tape header/sanity check.

Архивный файл создан ontape'ом на IDS 9.20.UC2, SunOS 5.7
(В самом первом посте ошибочно был указан 8-й Solaris).
Archecker запускаем на другой платформе: IDS 10.00.FC3, SunOS 5.9.

(К сожалению, поставить IDS 10 на 7-й Solaris не получается, поэтому приходится экспериментировать на сторонней машине. Если увидим, что данные действительно
вынимаются, то можно будет проапгрейдиться у себя до 8-го Solaris'а, установить IDS10
и уже вытащить всё, что нужно).

В чем может быть проблема? Несовместимость 9.20 и 10.00? Несовместимость по ОС?

Вадим
...
Рейтинг: 0 / 0
03.07.2007, 17:34
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34635933
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
vkubrПока ничего не получается. На одинаковые ленточные устр-а писали и читаете? Покажите со старого с нового сервера onstat -c|grep TAPEDEV
...
Рейтинг: 0 / 0
03.07.2007, 17:48
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34636023
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
Журавлев Денис vkubrПока ничего не получается. На одинаковые ленточные устр-а писали и читаете? Покажите со старого с нового сервера onstat -c|grep TAPEDEV
Нет, не одинаковые.
Но TAPEDEV из onconfig'а, где писали (/usr/informix9/Arc/A/ar) не обязан совпадать с названием устройства, из которого читает archecker (параметр AC_TAPEDEV из его конфига).

Есть подозрение, что проблема в том, что создавался архив на 32-битной ОС, а читать его пытаемся на 64-битной.
...
Рейтинг: 0 / 0
03.07.2007, 18:16
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34654571
up-s
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
up-s
Гость
Data archiving with Informix Dynamic Server table-level restore ....
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0704fraenkle/#useinteral

Может поможет.
...
Рейтинг: 0 / 0
11.07.2007, 18:32
| Ответить | Цитировать | Написать  
Ontape: не может завершить восстановление - не находит Log File для fast recovery
    #34654788
vkubr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vkubr
Гость
up-sData archiving with Informix Dynamic Server table-level restore ....
http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0704fraenkle/#useinteral

Может поможет.
К сожалению, там ничего не говорится про совместимость между различными версиями IDS, хотя косвенно на совместимость со старыми версиями указывает предисловие статьи. Написал вопрос автору. Может, ответит...

К сожалению, не удается пока поставить чистый эксперимент и попытаться ситать архив на той же ОС-платформе, на которой он был сделан.
Последняя попытка была прочитать на 64-битной Solaris 8 при помощи IDS10.00.UC6 (т.е. 32-битный archecker на 64-битной ОС).
Исходный архив, напомню, создан на 32-битном Solaris 7 IDS9.20.UC2.
...
Рейтинг: 0 / 0
11.07.2007, 20:23
| Ответить | Цитировать | Написать  
25 сообщений из 31, страница 1 из 2
  1  все
Форумы / Informix [игнор отключен] [закрыт для гостей] / Ontape: не может завершить восстановление - не находит Log File для fast recovery
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]