Victor Metelitsa hvlad Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2

Разумеется. Хотя из текстовых файлов проще. Но вот если мне захочется повертеть в руках что-то незнакомое, типа MS SQL/Sybase/Informix/etc, лучше было бы иметь более удобное решение. Также и кому-то с DB2.
Не надо БД генерить. Качаете тест на FB2, ставите клиента FB2, запускаете генерилку DBGEN, она выплюнет TLB файлы, которые на самом деле просто CSV файлы с разделителем "|". Скрипты создания таблиц, индексов и сами запросы в тесте в виде скриптов присутствуют.

IMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем, ни один сервер не будет в настройках по умолчанию держать нормальные настройки, так как, не зная даже задачи, он будет в ущерб скорости повышать надежность и дубовость работы. Так что настройки и без DBA могут самой инсталяцией уже ставиться конечного продукта, дальше уже от конкретного сервера зависит, насколько легко ему будет еще самому к железу привязаться и что он позволяет при инсталяции и настройке определить программным способом.

P.S. Хотя в принципе нам асашникам грех на тесты жаловаться, не смотря на дефотный запуск прямо на демо БД, сервак отработал вполне шустро, что и следовало ожидать. Много траблов было с обновлением в одной транзакции 6,5 миллионной таблицы, вот здесь как раз настройки по умолчанию совершенно не прокатывали и у автора теста обновление заняло пару суток, а у меня на менее мощной машине один час. Поэтому совершенно не удивляюсь, что DB2 показала не сильно большие результаты - в этот сервере есть где и за что покрутить и это при таких нагрузках неплохо бы делать - я там вообще на демо базе при ее первом юзанье не смог больше 40 000 записей вставить, получив переполнение циклического лога ;)

olegloa ASCRUSIMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем

Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)
Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я бы вообще столько индексов в структуре не стал создавать для ASA.

P.S. Ну а почему дефолтные настройки в ASA выставлены на 2 минуты восстановления базы после запуска при обнаружении случая аварийного завершения - так это правильно. Кто знает - тот и поставит столько, сколько нужно. Кто не знает - значит сервер сам должен обеспечить максимальную скорость поднятия базы с откатом транзакций. Тем более что это не влияет на вставки, удаления и короткие апдейты, только на длинные апдейты, где апдейтом захватываются миллионы записей и это порождает много грязных страниц и переноса оригинальных страниц в Checkpoint log. Вот для таких случаев как раз параметрами и можно перевести БД в режим снижения частоты записи грязных страниц, увеличив скорость апдейта и соотвествующе увеличив время восстановления состояния БД, если бы на момент длинного апдейта сервер уронили. Кстати в ASA много чего установлено по умолчанию на скоростную загрузку БД при старте сервера - к примеру кэш часто используемых данных и наилучших планов запросов так же в БД по мере минимальной загрузки сервера пишется - то есть при перезапуске сервера он поднимет последние лучшие планы запросов и страницы данных в кэш, таким образом сразу же начав эффективно работать без повторного набора в кэш данных и с нуля вычислений всех планов запросов - этакий аналог режима hypernate. Тоже можно отключить, если скорость максимальной отдачи сразу с запуска БД не важна.