По мне, это больше похоже на проблему оборудования, чем DB2. К примеру, отключения электроэнергии в отсутствие UPS, ошибки ОЗУ, бэдблоки на дисках, ошибки в прошивках дисках, драйверах контроллеров, ...

Честно говоря, большого смысла в проверке целостности базы не вижу. Положим, можно найти битые индексы и пометить их как инвалидов, и, если не обнаружится битых таблиц или других объектов, база поднимется (в противном случае дела обстоят хуже). Разумнее всё равно поднять из бекапа, коли он есть. Если бекап цел, но такие ошибки вновь и вновь, это заставляет задуматься о дисковой подсистеме. В самом деле, DB2 пыталась прочитать страницу с диска (которую сама же когда-то записала) и либо не смогла, либо после прочтения обнаружила не то, что ожидала найти. Для очистки совести, можно поинтересоваться у поставщика оборудования, нет ли каких-нибудь новых прошивок дисков, прошивок контроллеров, новых драйверов. (Это, кроме всего прочего). А может, контроллер заглючил и его надо поменять, но как это продиагностировать - не скажу (scandisk ни разу не помог, например). Ну, кроме известного универсального, но долгого и дорогого способа - менять железки (от контроллеров до целых серверов) и смотреть, не перестало ли оно глючить.

Также, это мне напоминает о четырёх инцидентах. Три из них были совсем древние - когда только-только в продаже начали появляться SATA-контроллеры и диски, а мы хотели сэкономить. Оказалось, что DB2 в принципе не желала работать с Promise-контроллером (писала кучу загадочных ошибок в лог и падала), а также вдруг стала падать при достижении базы 64гб на SATA-дисках WD (несколько дисков перепробовал; причём на нескольких Seagate было всё нормально!). Ну, мы очень быстро перебрались тогда на SCSI.