andre.vorob,

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

1. Закройте доступ к базе (потушите инстанс) или выполните операцию "SET WRITE SUSPEND FOR DATABASE" (заблокирует запись в базу).
2. Через файловую систему скопируйте все файлы базы на другой сервер (скорее всего тут столкнётесь с доступностью тех или иных файлов).
3. Откройте доступ к исходной базе - "SET WRITE RESUME FOR DATABASE".
4. Закаталогизируйте cкопированную базу (при необходимости воспользовавшись db2relocatedb).
5. "db2inidb <dbname> as snapshot" (или "db2inidb <dbname> as snapshot relocate using relocatedb.cfg")

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

Дальнейшие действия - по результатам. Вытащить данные из битой таблицы может помочь тот же db2dart (/DDEL опция). Если недоступен индекс, то просто его пересоздать.

Вообще ещё хорошо бы db2diag.log посмотреть на предмет ошибок доступа к дискам.

andre.vorob,

Ну, Марк всё написал.

В дополнение:
Хорошая и одновременно плохая новость состоит в том, что битая таблица - какая-то из таблиц системного каталога (tablespace id - 0).
Т.е. с одной стороны первая ошибка, с которой сталкивается база - не в бизнес-данных базы, с другой стороны восстановить работоспособность пересозданием таблицы не получится.

Всё-таки сделайте копию БД на другой сервер по приведённой схеме.
"SET WRITE SUSPEND ..."/"SET WRITE RESUME ..." можно опустить, если потушите на это время инстанс (например в период обслуживания - тогда, когда вы пробуете сделать бэкап).
Ничего в базе это не нарушит. Это штатная, описанная в документации операция, никак не затрагивающая основную копию базы - Using a split mirror to clone a database .

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


Вероятнее всего будет достаточно E:\DB2\NODE0000\SQL00005
LOCAL_DB_DIRECTORY можно не копировать (и провести каталогизирование путём "db2 catalog db dbname on E:")


По скопированной базе пройдитесь db2dart'ом:
db2dart dbname /RPTF Y /RPT <path_to_report_files>

То же самое вы можете сделать и на основном сервере (предварительно потушив инстанс/базу), только неизвестно, сколько это займёт времени.

Посмотреть, какая именно табличка побилась:
db2dart dbname /T /OI 34 /TSI 0 /RPTF Y /RPT <path_to_report_files>


Бэкап делается офф-лайновый, скорее всего логирование циркулярное и восстановить SYSCATSPACE из архива донакатыванием скорее всего не получится.
А вот можно ли попробовать "в лоб" подменить E:\DB2\NODE0000\SQL00005\SQLT0000.0\SQL00034.DAT, подняв базу (где-либо ещё) из последнего бэкапа, - вопрос (прежде всего к support'у IBM'а и к Марку, в частности).
В любом случае полезно узнать имя объекта, чтобы понять, с чем имеем дело, и сделать бинарный diff этого SQL00034.DAT из бэкапа и его текущего состояния.
Все эти развлечения, конечно же, удобней всего проводить на тестовом стенде.

andre.vorob,

BTW А что выдаёт запрос:

andre.vorob,

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

Полный DDL текущей базы без грантов:

Далее - создание пустой базы (на время создания стоит выставить AUTO_REVAL в DEFERRED_FORCE, но и тут могут быть хитрости) и export/load. Будет "новая-хорошая".