Время доброе!
Есть большая БД, с недавних пор на ней при выполнении скрипта с запуском RUNSTATS и REORG стали появляться сообщения об ошибках.
Например, при выполнении сбора статистики SQL2310N The utility could not generate statistics. Error "-1477" was returned, а при выполнении реорганизации SQL2216N SQL Error "-1477" occurred while reorganizing a database table or its indexes.
Путём применения db2dart выяснилось, что на некоторой таблице более чем в 500 тыс. записей (кол-во записей смотрели на аналогичной базе отстающей от боевой на 8 дней) имеется предупреждение: Data object in drop-penting (unavailable) stat, errors reported for this object may be due to this state.
И далее сообщение об ошибке в индексах:
Error: Unable to read pool page 0, object page 0, from pool 2,
Error: parent pool2, object ID 54, object type index.
Error: Page 0 of index object does not exist. This invalid invalid index object will be rebuilt...
Проверили в каком табличном пространтсве находятся табличка и её индексы SMS
Вытащили описание индексов, начинаем отбрасывать сломавшийся индекс через drop index И практически сразу получаем SQL1477N Table "схема.имя" cannot be accessed. SQLSTATE=55019
Вот такая засада, таблицу уничтожать нельзя. Как получить доступ к сломавшейся табличке для того что бы перестроить её индексы?

Ага вот и я про то же. Справочник SQL есть и да же по-русски, что делать с ошибкой?

Вопрос то стоит в другом плане! Все бы было ничего если бы у нас таблица не заблокировалась. Есть ли какая-то возможность разблокировать ее ручками?

Mark Barinstein Anka_SВот такая засада, таблицу уничтожать нельзя. Как получить доступ к сломавшейся табличке для того что бы перестроить её индексы?Из вашего поста непонятно - у вас селекты идут на эту таблицу или нет?
Если да, то db2dart может пометить этот индекс как инвалидный (db2dart <your_base> /MI) и после этого можно его дропнуть будет.
Если нет, то содержимое таблицы можно выгрузить в текстовый файл с разделителями (db2dart <your_base> /DDEL). Начальная страница - 0, число страниц задавайте какое-нибудь побольше.
Пытались открыть таблицу через центр управления, не получилось вываливалась ошибка что-то типа нед доступа, точнее сейчас не скажу, но из этого следует что select уже не проходит. Поэтому, наверное, придётся пробовать второй вариант c db2dart <my_base> /DDEL.
Можно вопрос по параметрам утилиты db2dart? Знаю, что для полной проверки базы необходимо запустить db2dart <base> /DB. Здесь Вы ещё упомянули /MI и /DDEL, а ещё какие наиболее часто используются?

Mark Barinstein Anka_SМожно вопрос по параметрам утилиты db2dart? Знаю, что для полной проверки базы необходимо запустить db2dart <base> /DB. Здесь Вы ещё упомянули /MI и /DDEL, а ещё какие наиболее часто используются? db2dart . Добрый вечер! Я, когда рыскала в поисках параметров для db2dart'а, искала в pdf-никах к версии, а там как то не особо густо, но всё уже нашлось db2dart <name> /H :)
Теперь по результатам после запуска db2dart <name> /MI было предложено ввести index object ID and tablespace с эти всё в порядке (т.к. при прогоне db2dart' ом с параметром /DB улилита вывела необходимые мне Index obj:XX in pool:X в лог) после этого пошла строчка Attempting to mark index (p=x; o=xx) as bad. В подробностях <NAME>.RPT есть:
Error: unable to read poole 0 (кажется так, распечатку забыла), object page 0, from pool x
Error: parent pool x, object ID XX, object type index, наверное, из этого следует сделать вывод, что пометить индекс как сбойный улилите не удалось, вообщем- то косвено об этом говорит отрицательный результат последующей попытки удаления сбойного индекса в сообщении об ошибке [IBM][CLI Driver][DB2/LINUX] SQL1477N не удаётся получить доступ к таблице <схема.имя> SQLSTATE=55019
Сдвинуться с места пока не удалось, что я делаю ни так?

DB2Adventurer_А что случилось? пытались восстановиться с момента времени до notlogged операции или сделать роллбак за нее? Mark когда-то говорил, что после такого таблица может быть только дропнута. После коммита с не журналируемой операцией лучше сразу делать резервную копию. Хотите верьте, хотите нет, но я так и не поняла как таблица оказалась в состоянии drop-pending (unavailable), нашли её, работая совсем над другой проблемой случайно. МЫ обкатываем новое ПО и соответственно проводим всякие тестирования, настройки по оптимизации производительности и прочая.
На сегодняшний день установили, только то, что в ПО пошёл глюк одном из режимов, штатно он должен работать так- есть некоторый список из него нужно удалить одну из записей, тестеровщик встаёт на запись жмёт пиктограммку удалить, программа спрашивает Вы уверены? далше следует выбрать Да и всё, удаляемая запись с экрана исчезает -хэппи энд, но после восстановления базы из бэкапа при всех тех же действиях запись остаётся на своём месте, ничего не происходит-тишина. У меня это всё вызвало подозрение, когда я сама проделала этот фокус и полезла в просмотр "яко бы только что грохнутой записи" из интерфейса прграммы и нарваласть на отсутствие доступа к ней. До этого приходилось это делать пару раз и всё было хоккей, а тут засада, вот и начала копать.
Бэкапную копию сворачивает скрипт еженочно, до этого днём никто не жаловался на проблемы, перед, тем как развернуть бэкап была выполнена задача, целью, которой являлась максимальная нагрузка по коннектам и работа пользователей в наиболее сложных режимах с выполнением предложенного сценария, после её завершения, сделали восстановление с ночного бэкапа, на нём пошёл этот осяк с удалением, начали копать и нашли эту самую таблицу в drop-pending. Бэкап я делаю так (скрипт примерно так же): отрубаю все приложения db2 force application all затем db2 backup database <name> user <blablabla> using <bububu> to <path> whith 1 buffers buffer 1024 parallelism 1 compress without prompting скорее всего в тот раз было то же самое. С восстановлением то же без особых хитростей db2 force application all потом db2 restor database <name> user <blablabla> using <bububu> from <path> taken at <метка создания> without prompting ну и плюс стартуем БД и перестартуем WebSpher'у что здесь могло произойти и как? Нужно будет ещё раз пройтись по Журналу в ЦУ мб там есть следы какой-нибудь гадости. Если бы сервак был виндовый объязательно бы полезла в Администрировании посмотрела журнал событий, но это Linux, увы я его совсем не знаю.
Я не поняла, что такое восстановиться с момента времени до notlogged операции или сделать роллбак за нее- это как?

DB2Adventurer[quot Anka_S ]
Но для этого вы должны знать, когда все было хорошо, например, до начала тестов.
Хороший вопрос :)
Так насчёт выгрузки наверное всёравно я её сделаю, а что насчёт внешних ключей как оказалось они там так же присутствуют как проверить внешиний ключ 016-0814?

Mark Barinstein Anka_SСдвинуться с места пока не удалось, что я делаю ни так?Видимо, вы сделали либо неудачную нелогируемую операцию изменения таблицы, либо эта нелогируемая операция с таблицей (load into ... nonrecoverable, alter table ... activate not logged initially) встретилась при накате по логам после restore database.
Вечер добрый! Нелогируемая операция...по идее WebSphere пришет всё подряд правильно, вот и возникает такой вопрос если взять SystemOut.log можно в нём что то найти или это так же как с db2diag.log который стоит анализировать только в случае описанного где то ранее колапса?
Да и ещё у меня рядом с этм логом лежит SystemErr.log и SystemOut_"'date'"_"'time'".log это нормально, для чего сфера создаёт два последних?

Выгрузили и дропнули таблицу, но вот мой вопрос отностительно логов неужели никто не сталкивался?

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

-Выгружаем из таблицы в drop-penting состоянии через db2dart <my_base> /DDEL в текстовик содержимое ч/з (,).
-Вытаскивем с помощью db2look -d <my_base> -t <my_table> -a -e -l -x -c -f (надо будет с параметрами разобраться поподробнее) стр-ру сломавшейся таблицы.
-Дропаем инвалидную табличку,
-Стоим её заново по стр-ре, что вытянули через db2look, у меня через sql-запрос постоить не получилось, через ЦУ ручками вполне вменяемо, с триггером была какая-то возня (он никак стоиться не хотел, хотя, наверное его вообще можно было и не бить ?)
-Дальше импортируем из текстовика в пустую таблицу данные, предварительно сделав
RUNSTATS и REORG , поскольку в командах db2 разбираюсь плохо, предпочла сделать импорт ч/з опцию ЦУ, и в конце ещё раз проехалась по DB RUNSTATS и REORG (мб это и перебор не знаю).

Интересно насколько теперь это правильно будет работать...

Mark Barinsteinwebsphere - это, образно говоря, запускалка приложений.
Можно написать в приложении чего угодно, а потом запустить его с помощью websphere... Да, действительно, чего угодно и как угодно :)
Спасибо за наводку на монитор событий, попробую как-нибудь разобраться.
Но всё же меня не покидает вопрос насколько нормально, то что у меня три лога и почему сфера их создаёт или это какие то настройки в WSAS?

gals Anka_S
Но всё же меня не покидает вопрос насколько нормально, то что у меня три лога и почему сфера их создаёт или это какие то настройки в WSAS?
Не мучайтесь. Логи создаваемые в WSAS, это дело Java программ. Этих логов может быть гораздо больше.
Вам эти логи могут помочь или помешать при разборе - чем занималась программа.
Конкретно ваши SystemOut - стандартный поток вывода. SystemErr - стандартный поток ошибок. Обычно, при разборе полётов интересен последний журнал.Да это понятно, что если пошли косяки error искать нужно, у нас разработчик прикольный, собирает скриптом всё информацию о системе, метров по пять в архиве получается, но анализировать как оказалось не анализирует вот я и поинтересовалась м.б. кто утилитку какую юзает для разборов полётов что для SystemOut, что для DB2 db2diag.log IBM хвалилось что спецалально структурировало форму лога. Может кто что слышал?

Спасибо всем, за помощь, базу подняли, будем следующую версию ПО тестить пришло в аккурат под ёлочку. С наступившим всех.
Веточку можно закрыть.