Alex_E23Собственно вопрос вкратце в следующем:
Имеется решение для делопроизводства на DB2 Express 9.5. Идея хорошая, но реализация настолько глюкавая, что аж дух захватывает! При объеме БД - ТРИДЦАТЬ ТЫСЯЧ (специально написал прописью) записей в главной таблице восьмиядерный сервер с 16 гектарами памяти

!!!

Увы, для Express-C и 888-ядерный сервер с 16 терабайтами ОЗУ особого смысла не имеет, ввиду внутренних ограничений (2 ядра и два гига ОЗУ).

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

И тут возникает вопрос - что значит "вешается". Что имеется в виду? Например, "вешается" весь сервер вместе с ОС, или СУБД перестаёт всем отвечать на любые запросы и к ней невозможно приконнектиться, или это касается только пользователей приложения.

Директор фирмы - разработчика говорит примерно следующее: "А шо вы хотели от бесплатного сервера! Вот если-б на лицензионном Оракле - тогда-б работало нормально."

Ну, такими заявлениями он себя позорит, конечно, однако надо также иметь в виду, что даже у самого дешёвого лицензионного Oracle лимиты будут куда выше, чем у DB2 Express-C, двухсокетный сервер с 16 гигами ОЗУ может использовать на все 100. Однако и стоить это будет...


DB2 в качестве SQL- сервера выбирали тоже они, но я не хочу обсуждать эту моральную проблему, потому что прекрасно понимаю, что такой объем БД - пыль для практически любого SQL сервера. Его объяснения, что т.к. сервер бесплатный, то в нем не возможно нормально развести не то что читателей и писателей, но даже читатели НАМЕРТВО (система не тормозит, а виснет) блокируют друг-друга, не кажутся мне убедительными.


Express-C отличается лимитированием использования ресурсов (количества ядер и ОЗУ), техподдержкой, но в прочем это нормальная DB2.

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

В таком случае для начала неплохо было бы убедиться, что регулярно собирается статистика. (Лично я предпочитаю запускать скрипт с runstats on table ... with distribution and detailed indexes all - старая привычка; так что даже не знаю, насколько хороша automaintenance...). Далее имеет смысл поинтересоваться индексами. Разница между наличием и отсутствием нужного набора индексов может быть ошеломляющей (сотни и тысячи раз по скорости). А если Пан Директор позволяет себе такие замечания, то я не удивлюсь, если с индексами там "не всё в порядке". Для индивидуальных, заранее известных SQL-запросов я пользуюсь Index Adviser (утилита db2advis.exe в Windows). А для вашей ситуации должен быть полезен Design Advisor в Control Center.

Конечно, это всё общие и умозрительные рассуждения. Мало ли, что там у вас на самом деле. Может, дикое количество подключённых юзеров с чем-нибудь таким, что на них 2 гиг памяти реально не хватает. Или даже саботаж.