На сервере DB2 8.1.0.36 две базы, с одной все нормально, при обращении к другой церез Центр управления (и соотв-но другими способами):

[IBM][CLI Driver]SQL1042C Произошла непредвиденная системная ошибка SQLSTATE=58004

Разработчики сказали в морг. Но я как-то не верю, что сервер СУБД может так уж напрочь лечь, вот и хочу альтернативное мнение.


------------------
ASE 12.5.3/EBF 13331

Пропало электричество, после этого при любом обращении (посредством ПО, при раскрытии "плюса" из Центра управления) к одной из баз:

[IBM][CLI Driver] SQL1042C Произошла непредвиденная системная
ошибка. SQLSTATE=58004

Объяснение:

Произошла системная ошибка. Одна из возможных причин данной
ошибки - неправильная установка менеджера баз данных или
неправильная настройка среды.

На системах OS/2 при попытке загрузить менеджер баз данных
весьма частая причина данной ошибки - испорченный файл NET.ACC.

Команду невозможно выполнить.

Действия пользователя:

Если ошибка возникла на системе OS/2 при попытке загрузить
менеджер баз данных и вероятно повреждение файла NET.ACC,
замените файлы NET.ACC в системе теми же файлами с установочной
дискеты 1 DB2 для OS/2.

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

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

Повторите команду.

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

Если ошибка все равно повторится, установите менеджер баз данных
снова.

Если трассировка активна, вызовите независимую утилиту
трассировки из командной строки операционной системы. Обратитесь
к представителю IBM по технической поддержке со следующей
информацией:

Необходимая информация:

o Описание ошибки

o Код SQLCODE или номер сообщения

o Содержимое SQLCA (если возможно)

o Файл трассировки (если возможно).



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

sqlcode : -1042

sqlstate : 58004

Самому проанализировать лог-файл знаний не хватило :(

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

Прикрепляю файл отчета DB2_7250.RPT
К сожалению опять для меня не особо информативны :(

db2_7250.txt
UNCATALOG DATABASE DB2_7250
CATALOG DATABASE DB2_7250 AS DB2_7250 ON D WITH '_   ¤ --ле и<о ';

DART.INF
File Line DART Error DB Engn Function Called
Number (Dec) Error(HEX)
==========================================================================
drtpool.C 1019 -75 70F00CB sqloopenp( poolTable
drtpool.C 1041 -75 70F00CB sqloopenp( poolTable
drtpool.C 1106 -75 870F0009
drtpool.C 1118 -75 870F0009

Забыл сказать. Запуск указанной команды сопровождается сообщением, что db2dart.exe вызвала недопустимую операцию и будет закрыта :(
Видимо, это и есть причина того, что файл неполный.
По второй базе - сообщение об ошибке не выдается.

Спасибо за такую точную помощь, помогло.

После того, как индекс был помечен как плохой, удалось подключиться к базе и выгрузить данные (далее пошли действия для интереса). Тем не менее, db2dart.exe все равно выдавало ошибку. После некоторых экспериментов, после reorg table ..., содержащей данный индекс уже и db2dart.exe отработала без ошибок.

Несколько странной мне кажется ситуация, при которой испорченный индекс ломает всю базу. Ограничился бы хоть своей таблицей.

Для общего развития повторил процесс восстановления втором HDD из зеркала. Остались непонятны два момента.
Как по db2diag.log вы определили, что проблема в индексах? Я нашел лишь информативного 'An index manager programming error occurred' - это ключевой момент?
Как вы определили проблемность 32-го индекса, если на 19-м db2dart.exe вылетала? Соответственно DB2_7250.RPT заканчивался на 'ошибка в индексе 19'