Вадим,

Повторив "задним чилом" на тестовом сервере работы по переходу на новую версию, пробовали делать и онлайновый, и оффлайный бэкап. Результат один и тот же. Режим ведения логов нециклический.
Точные комады и последовательность их выполнения, а также параметры конфигурации базы смогу выложить завтра.

ппм,

Мы указываем WITHOUT ROLLING FORWARD при восстанавлении базы. После воостановления подменяем папку с журналами транзакций и, если после этого даем команду
db2 rollforward db strah to end of logs and stop
получаем
SQL1261N База данных "strah" не находится в состоянии отложенного повтора на узлах "0", поэтому не требуется повтор транзакций на этих узлах.

Если даем команду
db2rfpen on strah
а затем

db2 rollforward db strah to end of logs and stop,

то получаем

SQL1265N Неправильный последовательный номер архивного файла журнала "S0006242.LOG" для базы данных "STRAH" на узле "0".

Вадим,

оказывается есть с собой информация о конфигурации базы

ппм,

Пробовали восстанавливаться и без WITHOUT ROLLING FORWARD, предавительно подменив папку с журналами. Информации из журналов в базе не попадает.

Вадим,

Подменив на тестовом сервере каталог с журналами транзакций пытаюсь восстановиться с offline копии командой
db2 restore db strah from /home/db2inst/20100629 to /home/db2inst/STRAH without prompting


SQL2540W Восстановление успешно, однако при
работе утилиты Database "2539".

Mark Barinstein,

Очень, очень жаль. Ведь мы на тестовом сервере до какого-то момента попадаем в такую же с виду логовую последовательность, она начинается с того имени, что и на основном, размеры файлов совпадают.... Важно было восстановить данные именно из сбойной базы, чтобы исключить последующие проблемы, которые возникнут после восстановления данных другим путем, т.к. это приложение оперативно обменивалось данными с 3-мя другими приложениями.

Mark Barinstein,

"Вы восстановили базу, произвели какие-то изменения в данных (что-то удалили, что-то изменили) или может быть, даже удалили таблицы"

Работы на старом сервере ( с предыдущей версией приложения) были остановлены 28 июня вечером. Было сделано архивное копирование и получен файл со штампом времени 10200628153342. Далее:
1)Архив10200628153342 по инструкции по установке новой версии приложения был восстановлен с ключом without rolling на новом сервере .
2)Была выполнена переустановка БД с сохранением данных (из скрипта).
3)Была выполнена установка приложения (тоже из скрипта).
Эти работы были завершены к вечеру 29 июня. На следующий день (30 июня) велись работы по настройке приложения и проверки его работы. И только 1 июля сервер был открыт для пользователей.
Сейчас мы на тестовом сервере проделываем последовательность действий 1-3, страраясь попасть в те же временные отметки, и как нам кажется, по отношению к журналам, сформированным с 30 июня на основном сервере, мы стоим на той же контрольной точке, на которой база на основном сервере была на эту дату.

"DB2 автоматически определяет, что ей подсовывают неправильную логовую последовательность, и отказывается накатывать изменения, что есть абсолютно правильно."

С этим спорить невозможно, но нам в нашей ситуации это так не подходит....

ппм,

И "породнить" базу с тестового сервера с логами сбойного сервера невозможно?
Очень жаль.

Anka_S,

К восстановлению по худшему сценарию подготовились. Восстановились на другом сервере по состоянию на 1 июля, загрузили платежи. Ждем помощи от Красноярка по синхронизации с АСВ. Надеемся, что завтра они нам что-нибудь предложат. Выписки из ЕГРИЛ имеются. Спасибо за подсказку по выгрузке классификатора страхователей и АДВ-11 для СПУ.

Причину сбоя не знаем. Представитель фирмы-разработчика ответил, что по db2diag установить причину сбоя невозможно. В субботу (24 июня) около 10 часов утра позвонили пользователи с тем, что не могут войти в приложение. Проверила. При попытке регистрации обычным пользователем выводилось сообщение о том, что сервер не может обобразить страницу, т.к занят обслуживанием, а при попытке регистации администторской учеткой вывелось сообщение
SRCE 0232E: Internal Server Error /
Exception Message: {RemoteException occured in server thead;
nested exception is: java.rmi.RemoteException;;
nested exception is: {code=ERR_INTERVAL_ERROR,messge=___
The error occured in ibatis_resources/Admin.xml.-
The error occured while applying a parametr map.___
Chek the Admin.userTerrDptPfrParamMap.
Check the result (failed to retrive results).
Cause: com.ibm.db2/jcc.am.SqlException:
DB2 SQL Error:
SQLCODE=-290, SQLSTATE=55038, SQLERRMC=null, DRIVER=3.58.82,

Перезапуск веб-сферы и db2 не поправили ситуацию. Тогда я решила восстановиться с последнего инкрементального архива, который был выполнен автоматически ночью 24-го июля в 00:01:02. В восстановлении мне было отказано. Причина отказа - база находится в несогласованном состоянии.

Если кто-то может помочь в выяснении причны сбоя, готова предложить необходимые логи.

Mark Barinstein,

Mark Barinstein,