Описание длинное. Хочется разобраться что бы это могло быть.

DB2 9.1.2 под CentOS 5 на виртуальной машине с очень медленным вводом-выводом.

Сегодня в четыре наступил коллапс. Все стало работать ужасно медленно. Кое как получалось работать только от рута. Результат любых команд к DB2, даже db2 list applications дождаться было невозможно. Поэтому не удалось ничего помониторить кроме того что записалось в db2diag.log

С причиной разобрались быстро - активный ввод-вывод.

Остановили все сервера приложений.
Отрубили на уровне операционной системы все обращения к серверу.
СУБД по прежнему висит.

Первая мысль - логи какие-то бакапит. Посмотрели db2diag.log - пытался архивировать логи базы для которой не существует пути LOGARCHMETH1 (восстановлена с другого сервера). Путь создали. Один лог заархивировался. Больше не требовалось. Сервер такой же мертвый.

В db2diag.log больше ничего нового не пишет.

Начали стопать db2stop force.

Висит. Ввод-вывод по прежнему бешеный. Увеличивается объем одной базы (PBMAX, не та где логи пытались архивироваться). C 7Гб выросла до 8,3Гб. Потом директория уменьшилась до копеек. DB2 остановился и наступило счастие. Полчаса с момента стопа прошло где-то. После запуска все работает нормально. Позже определили что после запуска db2stop росла по объему директория с временным табличным пространством.

Чтобы это могло быть? SA сделал предположение (пока DB2 не остановился) что у DB2 сьехала крыша и он в цикле сам добавляет данные. Ведь все коннекты обрублены :-)

На базе логи транзакций циклические.

Диаг-лог весь не выложить. Там почти все забито попытками архивировать логи.

В db2diag.log накопал из стоящего такие вещи.
Несколько раз в разное время с 12 часов. Последний раз в 15-58:


и еще

...

Насчет коллапса ко мне обратился SA в 16-09.

Судя по данным БД в 16-03 была запущена и закрыта последняя сессия.

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

Транзакции все короткие. На несколько гигов никак не тянут.

С этой базой тренировались запускать нового робота которые добавляет в базу информацию. Это так на всякий случай.

На уровне логов системы ничего интересного нет.

Что с базой нужно делать чтобы так получилось ?

Марк, табличное пространство системное временное.

А рост временного системного табличного простраства при сортировках, хеш-соединениях возможен после запуска db2stop force ?

Свопа точно не было - смотрели.

По опыту заметил, что запросы выполняются несколько секунд после force. Ну может минут.
А вот десятки минут и часы после force занимают только жизненно важные для целостности данных операции с точки зрения DB2. Например:
1. Бакап архивных логов.
2. Попытка сделать бакап логов если не готово устройство (ждет пока вставят новый картридж например).
3. Rollback для длинной транзакции.
4. Commit для длинной транзакции. Не совсем уверен что DB2 будет завершать транзакцию. Скорее всего откатит.

Виктор, я правильно понимаю, что Select на пару часов с большими сортировками не будет выполняться до конца при db2 force ?

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

Из всех вариантов наиболее правдоподобным кажется списание проблемы на неверный план доступа, выбранный DB2. Минус ситуации в том что такая болезнь не лечится...
Хотя официально можно заявить что лечится сбором статистики. Но у меня сбор статистики настроен автоматический и проблем быть не должно. Это скорее риторика...

Достоверного объяснения проблеме пока нет. А значит не ясно как избежать такой проблемы в дальнейшем. Но это уже скорее риторика.

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

Таблички маленькие, выполнялись короткие транзакции, которые помещаются в журнал размером 4Мб.

В этом контексте говорить о реорганизации данных, индексировании, MDC смысла нет.

Оптимизатор выбирает не "средний" план доступа а в соответствии с указанным классом оптимизации. Хотя это тоже не важно в данном случае.

Марк говорит о сбое СУБД:
Mark Barinstein Я видел такой рост системного временного пространства, когда оптимизатор выбирал неправильный план. Причем в одном случае в несложном запросе причина была в отсутствии статистики на маленькую справочную таблицу.

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

Сейчас причина непонятна. Объяснения аварии нет. А это есть плохо.

Подобное поведение DB2 при длинных транзакциях у меня было.

Оно легко объясняется - целостность данных превыше всего. Поэтому при попытке остановить DB2 начинается длинный Rollback.

Мои первые мысли были как раз про длинную транзакцию, но..

У меня как и было по дефолту для базы 3 архивных лога по 4 метра.
По опыту знаю что длинная транзакция забьет такие логи очень быстро. И так же быстро откатится с ошибкой что в логи не поместилась.

Тут что-то другое...