powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
156 сообщений из 156, показаны все 7 страниц
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33569684
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На news://news.gmane.org/gmane.comp.db.firebird.russian я увидел любопытную тему "Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)". Попытка написать туда не удалась - я получил письмо от Gmane Autoauthorizer, ответил на него, но на этом всё заглохло. На работе у меня интернет ограничен, и более подробные исследования я не могу сейчас произвести.

Люди там насобирали кучу результатов с кучи баз, и это в некоторой степени любопытно. Но ценность этих цифр, мягко говоря, сомнительна. В частности, я не понимаю, почему у DB2 получился такой слабый результат, но не могу посмотреть ни скриптов, ни свойств/настроек базы. Вообще, у "тяжелых" СУБД есть много рукояток, за которые можно повертеть, а что навертели тестировщики, неизвестно. Итак, ценность тех цифр (для постороннего читателя) только в подтверждении факта, что люди сумели установить некие СУБД и что-то на них запустить.

С другой стороны, сами по себе тесты интересны, если запускать их у себя. Интересны в плане тренировок "кручения ручек".

На сайте TPC-R я нашёл некие "исходники" на C, но, как я понял, они негодны для непосредственного использования. Надо писать свой код для коннекта к базе. На ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось). Нет ли чего-то готового для других СУБД в других местах?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33569724
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что-то я там увидел тока новый начинающий какой-то форум по БД. Значительно уступающий данному. Таких "тестов" наверняка полно и здесь.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33569748
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хуже этого форума я ещё не видел. Но меня интересует ответ на конкретный вопрос, и не буду пренебрегать даже мизерным шансом.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33569768
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite//
Это open-source тестилка на SAP DB, правда.
http://www.quest.com/benchmark_factory/index.asp
Очень хорошая тестилка, одна проблема - глючная очень. :( И дорогая, кстати, безумно.
А тот тест, что Вы упомянули - я пробовал, но создать хоть сколько-нибудь серьезную нагрузку на железо им не удалось :(
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33569867
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_shats
А тот тест, что Вы упомянули - я пробовал
Как именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570244
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa пишет:

> Вообще, у
> "тяжелых" СУБД есть много рукояток, за которые можно повертеть,

Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570387
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.


Ну зачем Вы так говорите?
1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - вопрос времени.
2) Если по бизнесу хорошо, чтобы медленно работало, то нихай себе медленно что-то работает. Чего тогда вообще что-то тестить?
3) Если система не позволяет и с самыми продвинутыми DBA добиться нужного, то с точки зрения реального бизнеса (для которого позиция DBA в штатном расписнии не критично мягко говоря) это, возможно, тоже плохо.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570508
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo пишет:

> 1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности -
> вопрос времени.

Разница между "хоть какого-то DBA" и выделенного DBA может составлять от
2-3 тыс $ в месяц на инсталляцию.

> 2) Если по бизнесу хорошо, чтобы медленно работало, то нихай себе
> медленно что-то работает. Чего тогда вообще что-то тестить?

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

> то с точки зрения
> реального бизнеса (для которого позиция DBA в
> штатном расписнии не критично мягко говоря)

Т.е. все что не нефть, газ и т.п. - не реальный бизнес?
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570799
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Разница между "хоть какого-то DBA" и выделенного DBA может составлять от
2-3 тыс $ в месяц на инсталляцию

Многие вопросы решит и хоть какой-то DBA. Я не знаю тада о каких системах Вы говорите, где нужен выделенный DBA на инстоляцию. Наверное, на таких по важности и ценности инфы и 2-3 тыс $ - дешево.

Александр Гoлдун
а кто сказал, что медленно? Если уж ведем речь про бизнес, то тестить
нужно не абстрактные запросы, а решения.

Ну это может быть взаимосвязано. Все таки РМД расчитана и на произвольные запросы. Да и данные меняются по объему и содержанию со временем. Но я не говорил ниче против тестирования решений. Просты Вы сказали о стоимости кручения. И так понял, что якобы без DBA можно, ну помедленнее чем с DBA.

Александр Гoлдун
Т.е. все что не нефть, газ и т.п. - не реальный бизнес?
В нефти и газе - 2-3 тыс $ в месяц DBA смертельно?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570882
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570931
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Victor Metelitsa пишет:
> Вообще, у
> "тяжелых" СУБД есть много рукояток, за которые можно повертеть,
Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.


А чего нам, спецам, плакать о бизнесе? Это "их" задача - заплатить поменьше, а наша задача - получить побольше. Поэтому, например, спецы по Oracle молодцы, а по Firebird/Interbase - вредители, рубящие сук, на котором сидят они сами и их коллеги. К счастью, у них пока не очень получается.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33570958
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad Victor MetelitsaНа ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).Как вариант можно сгенерить БД в FB и перегнать данные в DB2

Разумеется. Хотя из текстовых файлов проще. Но вот если мне захочется повертеть в руках что-то незнакомое, типа MS SQL/Sybase/Informix/etc, лучше было бы иметь более удобное решение. Также и кому-то с DB2.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33571583
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 записей вставить, получив переполнение циклического лога ;)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33571864
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaКак именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader?
Насчет TPC-R не знаю, но dbgen для TPC-H я с сайта www.tpc.org утянул и с помощью него базу сгенерировал. Правда для MS SQL. Там в ней define'ы насколько я помню есть чего под какую базу генерить. Правда почему-то тот архив, который я скачал у меня под VC не собрался, пришлось пару строчек в коде править. И генератор запросов там же есть, насколько я помню. Если, конечно, Вы имеете ввиду тоже, что и я. :)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572258
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ.

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

Специалист по ASA пусть объяснит почему другие специалисты из Sybase установили интервал допустимого восстановления базы после сбоя по умолчанию что update указанные мной в комментариях выполнялся так долго.
(Для справки я изменил этот параметр и уложился в час)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572263
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUSIMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем

Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572269
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa
Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)

Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть. Пожалуста, скажите здесь кем ставился тест. Все его награды, грамоты опишите. А если не трудно и про результат скажите теста скажите. Как он соотносится с TPC, где, насколько я слышал настраивают представители фирм производителей. А то что один Оракл обгоняет другого я наблюдал, хотя парни не первый день с Ораклом работали.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572280
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaГоспода DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите.

Ну, смотря на сколько простых. Если настройки могут повлиять на план, выдаваемый оптимайзером, то иногда можно и в разы. За примерами ходить далеко не надо, гляда на ваши же с Димой обсуждения запросов, кажется 14-16. ASA возможно тоже мог бы улучшить свой результат, если поиграться опциями OPTIMIZATION_GOAL и OPTIMIZATION_LEVEL и выставить OPTIMIZATION_WORKLOAD в OLAP вместо дефолтного Mixed. Плюс если все-таки перед тестом на базе были сделаны массовые изменения, я бы на всякий случай пересоздал гистограммы. Это то, что пришло в голову уже после того - меня смутили запросы 7 и 12, в к-рых повторные выполнения оказались заметно дольше первого. Интересно было бы планы сравнить. Ну да ладно, не ASA меряли и не за золотой кубок боролись, тем более что я то потребитель, а не разработчик сервера, и даже не держатель акций ianywhere solutions :)
olegloa
Специалист по ASA пусть объяснит почему другие специалисты из Sybase установили интервал допустимого восстановления базы после сбоя по умолчанию что update указанные мной в комментариях выполнялся так долго.
(Для справки я изменил этот параметр и уложился в час)
Очевидно, уменьшение возможных потерь при сбое. Ну согласись, что запрос не из тех, что нужны повседневно за исключением каких-либо специфических задач. И к TPC-R он не имеет отношения. А если уж и припрет раз в год, то можно и индексы дропнуть :)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572286
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo
Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть.

Кусаются?
vadiminfo
Все его награды, грамоты опишите
Не стоит беспокойства, Oracle в сумме выиграл у всех, даже у ASA, проиграв ему всего лишь в 6 запросах из 22
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572365
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa ASCRUSIMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем

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

P.S. Ну а почему дефолтные настройки в ASA выставлены на 2 минуты восстановления базы после запуска при обнаружении случая аварийного завершения - так это правильно. Кто знает - тот и поставит столько, сколько нужно. Кто не знает - значит сервер сам должен обеспечить максимальную скорость поднятия базы с откатом транзакций. Тем более что это не влияет на вставки, удаления и короткие апдейты, только на длинные апдейты, где апдейтом захватываются миллионы записей и это порождает много грязных страниц и переноса оригинальных страниц в Checkpoint log. Вот для таких случаев как раз параметрами и можно перевести БД в режим снижения частоты записи грязных страниц, увеличив скорость апдейта и соотвествующе увеличив время восстановления состояния БД, если бы на момент длинного апдейта сервер уронили. Кстати в ASA много чего установлено по умолчанию на скоростную загрузку БД при старте сервера - к примеру кэш часто используемых данных и наилучших планов запросов так же в БД по мере минимальной загрузки сервера пишется - то есть при перезапуске сервера он поднимет последние лучшие планы запросов и страницы данных в кэш, таким образом сразу же начав эффективно работать без повторного набора в кэш данных и с нуля вычислений всех планов запросов - этакий аналог режима hypernate. Тоже можно отключить, если скорость максимальной отдачи сразу с запуска БД не важна.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572416
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaГоспода DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ.

Да у DB2 и статистику можно собирать по-разному. Табличные пространства могут быть SMS и DMS, с разными размерами префетча, с разрешением кеширования средствами ОС или запрещением. Распределение памяти между буферным пулом и памятью для сортировки (которая используется также для хешджойнов). Специфичные настройки оптимизатора через db2set.

Я собираюсь написать скрипт на REXX'е для перебора (естественно, не всех параметров, а по одному).

Хотелось бы видеть, что именно вы запускали.

Ну и, конечно, если вас не интересуют "специфичные веще типа кластерных индексов, секционирования и т.п.", то меня очень даже.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572426
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест >заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в >стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я >бы вообще столько индексов в структуре не стал создавать для ASA.

Никаких SP и прочей шелухи. Все запросы переписаны на view, и были приведены в первом сообщении с результатами. Так что никаких заточек под IB. Индексов не куча, а ровно столько, сколько было бы создано большинстовм при таких запросах. Могу оставить одни PK :-) и повторить тест для ASA, тока боюсь он его вообще не закончит никогда.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572429
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Да у DB2 и статистику можно собирать по-разному. Табличные пространства >могут быть SMS и DMS, с разными размерами префетча, с разрешением >кеширования средствами ОС или запрещением. Распределение памяти между >буферным пулом и памятью для сортировки (которая используется также для >хешджойнов). Специфичные настройки оптимизатора через db2set.

Никто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572448
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaНикто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже

Приведите ваши скрипты, пожалуйста.

Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках. Запросы 2, 3, 10, 21 содержат ограничение количества строк - а вы в курсе, что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма желательно писать OPTIMIZE FOR n ROWS?

Кроме того, зачем вообще существуют настройки, если не настраивать?

Кроме того, наш с вами интерес к этим тестам имеет разную природу.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572473
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чёйта я не понял, чё такое этот TPCR. TPC-H знаю, dbgen к нему есть. 22 запроса.

Это оно и есть?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572485
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa
Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках.
Имею в виду результат замены SMS на DMS и т.п.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33572819
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наверное, я всё же нифига не понимаю сути этого теста...

Там писали ( http://article.gmane.org/gmane.comp.db.firebird.russian/2156/match=dbgen)

"Тот самый update lineitem set l_comment = trim(l_comment)
- 251 секунда."

Я использовал вместо trim rtrim (ну нету в DB2 просто trim) -
time db2 "update lineitem set l_comment = rtrim(l_comment)"
DB20000I The SQL command completed successfully.

real 0m45.509s

При том, что машинка у меня заметно слабее - Athlon XP 1800+, памяти 384МБ, и база и её логи находятся на одном древнем IBMовском IDE диске.

Что я делаю не так?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573289
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Наверное, я всё же нифига не понимаю сути этого теста...

Потому что читать нужно всё ветку было. Это запрос вообще никакого отношения к тестам не имеет, а возник из-за трудностей с этим запросом на ASA в силу определённых настроек.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573303
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста. Точно также как и ручное планирование в IB7.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573304
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А.
Ну извиняйте, как говорится-не осилил потому что много букв.
И ещё раз извините.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573323
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Архив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573346
Gold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ребята, вы только не забывайте про то, что тесты эти Олег проводил на своём энтузиазме прежде всего для себя и для узкой группы людей, которые тусуются в известной конференции.

Изначально хотели сравнить IB/FB/Ya разных версий между собой, а потом ради интереса захотелось померяться письками с ораклом и т.д.

Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать.

А вобще-то на тестах никто не обделался особо кроме IB.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573371
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста.

Это не одно и то же.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573373
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это время выполнения запроса?
Тогда с запросом 2 как-то плохо.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573399
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaАрхив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.
DB2 оказалась хуже Oracle. Чем не проблема?

;-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573433
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Это не одно и то же

Что не одно и тоже?

C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей.

Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений.

Если бы мне требовалось быстрее отобрать n записей из x, где n существенно меньше чем x то одновременное указание обоих конструкций для одного запроса имело бы смылс. У меня отбирались все x записей, т.е. n = x. Следовательно OPTIMIZE FOR n ROWS мне нафиг не нужно. Если логика DB2 иная, то сами буратины :-).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573447
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Это время выполнения запроса?

Угу

>Тогда с запросом 2 как-то плохо.

У кого? :-), там их много.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573500
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573511
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa>
C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей.

Когда я говрю серверу FETCH FIRST x ROWS ONLY, я уже подразумеваю что сервер будет оптимизировать мне выборку именно x значений.


Логично ожидать именно такого поведения. Беда в том, что реализовано это не так. Об этом говорили сами ibm-еры в их ньюсгруппе.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573603
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573613
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeУ DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.

Порядок тот же, что и требовалось доказать. Так что притензии не ко мне а к IBM :-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573636
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gold
Тесты неофициальные, Олег широкой общественности ничего никому громогласно не заявлял, вы сами нашли этот тест и раздули этот топик. Так что вы с ним помягче - не может человек всё знать.
А вобще-то на тестах никто не обделался особо кроме IB.

Собственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать.

Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573743
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaТогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте.

Видите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573767
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaСобственно я сразу и сказал что специально ничего затачивать в серверах под эти 22 запроса не буду. Цель исследования общая оценка эффективности движков на простых sql запросах без ручной доводки до максимального быстродействия прежде всего на IB движках, а уж потом я добавил прочие сервера чтобы было понятно где находится FB2 и что делать.

Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.

Как я понимаю, опубликовать скрипты и настройки базы вы отказываетесь.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573829
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573874
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaВидите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.

Т.е. мне как разработчику нуджно говорить DB2: дай мне только 100 записей, не ты меня поняла, только 100 запсей... что непонятно, щас пну если не дашь только 100 записей ;-)

Уже не смешно. Нахрена тогда байки про навороченность оптимизатора DB2 сочинять, если он не в состоянии сам сооброзить что если сказали отбирать только 100 записей, так и оптимизировать запрос нужно под 100 записей. Ты сам то вдумайся в то что пишешь. И зачем тогда приводить ссылку на обсуждение этой пробемы с разработчиками DB2, когджа это только подтвержадает её существование, т.к. в противном случае на это обратил внимание только я, а выходит и другие товарищи уже обращали внимание на эту проблему.

Подсказка оптимизатору нужна тогда, когда явные критерии отбора данных указанные в запросе не позволяют однозначно выбрать оптимальный план. Какая неоднозначность может быть в конструкции "Отобрать только первые 100 записей и ВСЁ." Это уже не подсказка, а ручное планирование запроса, что условиями теста не допускалосось.... занавес.

P.S. Начёнм лепить хинты к DB2, я прилеплю хинты к ORA/MS/IB-клонам и что тогда?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573935
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рассмотрим запрос:
Код: plaintext
1.
   select * from tbl order by b fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b fetch first  100  rows only optimize  10  rows only


И вот такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b optimize for  10  rows

во всех приведенных случаях планы доступа будут разными с зависимости от наличия нужных индексов и правильности сбора статистики. Вариантов - просто миллион... мне чета даже лень писать все...
нет определенно лень... ((

optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях).
fetch first - определяет размер этого самого результирующего набора.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33573997
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.

По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574085
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
select
        s_acctbal,
        s_name,
        n_name,
        p_partkey,
        p_mfgr,
        s_address,
        s_phone,
        s_comment
from
        part p,
        supplier,
        partsupp,
        nation,
        region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size =  15 
        and p_type like '%BRASS'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'EUROPE'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from
                        partsupp,
                        supplier,
                        nation,
                        region
                where
                        p.p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'EUROPE'
        )
order by
        s_acctbal desc,
        n_name,
        s_name,
    p_partkey
FETCH FIRST  100  rows ONLY
OPTIMIZE FOR  100  ROWS
;



execution started at timestamp  2006 - 03 - 01 - 17 . 04 . 24 . 613000 
found [ 1 ] SQL statements from the input file
Recommending indexes...
total disk space needed for initial set [   77 , 779 ] MB
total disk space constrained to         [  337 , 398 ] MB
Trying variations of the solution set.
Optimization finished.
   9   indexes in current solution
 [ 660810 , 3125 ] timerons  (without recommendations)
 [ 1702 , 1033 ] timerons  (with current solution)
 [ 99 , 74 %] improvement


--
--
-- LIST OF RECOMMENDED INDEXES
-- ===========================
-- index[1],   19,329MB
   CREATE INDEX "VVM     "."IDX603011205030000" ON "VVM     "."PART" ("P_SIZE" ASC, "P_MFGR" ASC, "P_TYPE" ASC, "P_PARTKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PART" FOR INDEX "VVM     "."IDX603011205030000" ;
   COMMIT WORK ;
-- index[2],   27,493MB
   CREATE INDEX "VVM     "."IDX603011204410000" ON "VVM     "."PARTSUPP" ("PS_PARTKEY" ASC, "PS_SUPPLYCOST" ASC, "PS_SUPPKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."IDX603011204410000" ;
   COMMIT WORK ;
-- index[3],    0,196MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011204390000" ON "VVM     "."SUPPLIER" ("S_SUPPKEY" ASC) INCLUDE ("S_NATIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."IDX603011204390000" ;
   COMMIT WORK ;
-- index[4],    0,013MB
   CREATE INDEX "VVM     "."IDX603011204270000" ON "VVM     "."REGION" ("R_NAME" ASC, "R_REGIONKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."REGION" FOR INDEX "VVM     "."IDX603011204270000" ;
   COMMIT WORK ;
-- index[5],    0,013MB
   CREATE INDEX "VVM     "."IDX603011204310000" ON "VVM     "."NATION" ("N_REGIONKEY" ASC, "N_NATIONKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."IDX603011204310000" ;
   COMMIT WORK ;
-- index[6],   27,493MB
   CREATE INDEX "VVM     "."IDX603011204430000" ON "VVM     "."PARTSUPP" ("PS_SUPPLYCOST" ASC, "PS_PARTKEY" ASC, "PS_SUPPKEY" ASC) ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."IDX603011204430000" ;
   COMMIT WORK ;
-- index[7],    3,216MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011205400000" ON "VVM     "."SUPPLIER" ("S_SUPPKEY" ASC) INCLUDE ("S_ACCTBAL", "S_COMMENT", "S_PHONE", "S_ADDRESS", "S_NAME", "S_NATIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."IDX603011205400000" ;
   COMMIT WORK ;
-- index[8],    0,013MB
   CREATE UNIQUE INDEX "VVM     "."IDX603011205350000" ON "VVM     "."NATION" ("N_NATIONKEY" ASC) INCLUDE ("N_NAME", "N_REGIONKEY") ALLOW REVERSE SCANS ;
   COMMIT WORK ;
   RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."IDX603011205350000" ;
   COMMIT WORK ;


--
--
-- RECOMMENDED EXISTING INDEXES
-- ============================
-- RUNSTATS ON TABLE "VVM     "."NATION" FOR INDEX "VVM     "."NATION_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."PARTSUPP" FOR INDEX "VVM     "."PARTSUPP_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."REGION" FOR INDEX "VVM     "."REGION_PK" ;
-- COMMIT WORK ;
-- RUNSTATS ON TABLE "VVM     "."SUPPLIER" FOR INDEX "VVM     "."SUPPLIER_PK" ;
-- COMMIT WORK ;


--
--
-- UNUSED EXISTING INDEXES
-- ============================
-- DROP INDEX "VVM     "."PART_BRAND_CONTAIN";
-- DROP INDEX "VVM     "."PART_NAME";
-- DROP INDEX "VVM     "."PARTSUPP_SUPPKEY";
-- DROP INDEX "VVM     "."SUPPLIER_NATIONKEY";
-- ===========================
--

 31  solutions were evaluated by the advisor
DB2 Workload Performance Advisor tool is finished.

Using user id as default schema name. Use -n option to specify schema
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574202
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman[quot olegloa]По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.

Для тех кто не в теме. От меня был комментарий, что те кто мог получали 80% от ОЗУ под свои нужды, в том числе и от DB2 и размер кэшей пулов и пр у всех серверов настраивался.

Если не в курсе подробностей, то пишите в оригинальную конфу.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574220
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574235
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanРассмотрим запрос:
Код: plaintext
1.
   select * from tbl order by b fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c fetch first  100  rows only

И такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b fetch first  100  rows only optimize  10  rows only


И вот такой:
Код: plaintext
1.
   select * from tbl where b>=:c order by b optimize for  10  rows

во всех приведенных случаях планы доступа будут разными с зависимости от наличия нужных индексов и правильности сбора статистики. Вариантов - просто миллион... мне чета даже лень писать все...
нет определенно лень... ((

optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях).
fetch first - определяет размер этого самого результирующего набора.


И при чём тут наш тест? У нас все записи уходят на клиента. Спосили 100 все 100 и забираем. К чему все эти рассуждения о разных планах при разных индексах?

Есто возразить к тем логическим рассуждениям которые я привёл? Если я прошу отдать мне 100 записей и я их все 100 забираю, то какого я должен ещё делать какие-то телодвижения?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574245
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.

По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.

Я вначале подозревал именно это, но потом решил, что Олег, должно быть, делал базу из CC, а CC после создания предлагает вызвать Configuration Assistant, который буферный пул всё-таки таким маленьким не оставит. Но он секрета так и не выдал.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574269
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, будем считать, что Configuration Adviser использовался. Хотя он вряд ли дал оптимальные настройки. Я тут на другое наткнулся, и ошизел (описание в следущем письме).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574288
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa пишет:
> Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов

О, у меня тоже была идея для ASA проверить что насоветует Index
Consultant, но почему-то думал, что набор индексов жестко
регламентирован в TCP-R

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574301
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
80% отдавал. Если мне укажут отптимальные параметры для DB2 при условии невыхода за рамки теста(т.е. никаких подсказок и доп индексов), то я протестирую заного. Так же я готов оттестить DB2 vs ORA если будут конкретные рекомендации по доп. оптимизации указанного теста для DB2, разумеется с доп оптимизацией ORA c моей стороны. Надеюсь, что после этого все стороны будут довольны ;-);-);-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574315
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Consultant, но почему-то думал, что набор индексов жестко
регламентирован в TCP-R

Именно так. Все сервера работали на одинаковых метаданных.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574327
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да 80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574348
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Итак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, на ней DB2 ESE FP10 (не думаю, что с Express'ом должна быть какая-то разница).

Создал базу с самыми что ни на есть плохими настройками. Табличные пространства SMS. Кстати, если кому интересно, размер оказался менее 1,7 гига. Configuration Adviser я не запускал, буферный пул остался в 250 страниц. Посоветованные мне индексы не создавал.

Выполнил второй запрос, который в Excel приводится как потребовавший 412,59 секунд в первый раз и 412,59 в третий.

У меня это заняло 10 секунд при первом прогоне и менее секунды во втором.

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

начало
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
Current Timestamp:   Wed Mar 01 17:21:58 2006

---------------------------------------------

Statement number: 1

select
s_acctbal,
s_name,
n_name,
p_partkey,
p_mfgr,
s_address,
s_phone,
s_comment
from
part p,
supplier,
partsupp,
nation,
region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size = 15
and p_type like '%BRASS'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
and ps_supplycost = (
select
min(ps_supplycost)
from
partsupp,
supplier,
nation,
region
where
p.p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
)
order by
s_acctbal desc,
n_name,
s_name,
p_partkey
FETCH FIRST 100 rows ONLY
OPTIMIZE FOR 100 ROWS


S_ACCTBAL              S_NAME                    N_NAME                    P_PARTKEY    P_MFGR                    S_ADDRESS                                S_PHONE         S_COMMENT                                                                                             
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
               9938.53;Supplier#000005359       ;UNITED KINGDOM           ;      185358;Manufacturer#4           ;QKuHYh,vZGiwu2FWEJoLDx04                ;33-429-790-6131;blithely silent pinto beans are furiously. slyly final deposits acros
               9937.84;Supplier#000005969       ;ROMANIA                  ;      108438;Manufacturer#1           ;ANDENSOSmk,miq23Xfb5RWt6dvUcvt6Qa       ;29-520-692-3537;carefully slow deposits use furiously. slyly ironic platelets above the ironic
               9936.22;Supplier#000005250       ;UNITED KINGDOM           ;         249;Manufacturer#4           ;B3rqp0xbSEim4Mpy2RH J                   ;33-320-228-2957;blithely special packages are. stealthily express deposits across the closely final instructi
               9923.77;Supplier#000002324       ;GERMANY                  ;       29821;Manufacturer#4           ;y3OD9UywSTOk                            ;17-779-299-1839;quickly express packages breach quiet pinto beans. requ
               9871.22;Supplier#000006373       ;GERMANY                  ;       43868;Manufacturer#5           ;J8fcXWsTqM                              ;17-813-485-8637;never silent deposits integrate furiously blit
               9870.78;Supplier#000001286       ;GERMANY                  ;       81285;Manufacturer#2           ;YKA,E2fjiVd7eUrzp2Ef8j1QxGo2DFnosaTEH   ;17-516-924-4574;final theodolites cajole slyly special,

конец
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
               7912.91;Supplier#000004211       ;GERMANY                  ;      184210;Manufacturer#4           ;2wQRVovHrm3,v03IKzfTd,1PYsFXQFFOG       ;17-266-947-7315;final requests integrate slyly above the silent, even
               7894.56;Supplier#000007981       ;GERMANY                  ;       85472;Manufacturer#4           ;NSJ96vMROAbeXP                          ;17-963-404-3760;regular, even theodolites integrate carefully. bold, special theodolites are slyly fluffily iron
               7887.08;Supplier#000009792       ;GERMANY                  ;      164759;Manufacturer#3           ;Y28ITVeYriT3kIGdV2K8fSZ V2UqT5H1Otz     ;17-988-938-4296;pending, ironic packages sleep among the carefully ironic accounts. quickly final accounts
               7871.50;Supplier#000007206       ;RUSSIA                   ;      104695;Manufacturer#1           ;3w fNCnrVmvJjE95sgWZzvW                 ;32-432-452-7731;furiously dogged pinto beans cajole. bold, express notornis until the slyly pending
               7852.45;Supplier#000005864       ;RUSSIA                   ;        8363;Manufacturer#4           ;WCNfBPZeSXh3h,c                         ;32-454-883-3821;blithely regular deposits
               7850.66;Supplier#000001518       ;UNITED KINGDOM           ;       86501;Manufacturer#1           ;ONda3YJiHKJOC                           ;33-730-383-3892;furiously final accounts wake carefully idle requests. even dolphins wake acc
               7843.52;Supplier#000006683       ;FRANCE                   ;       11680;Manufacturer#4           ;2Z0JGkiv01Y00oCFwUGfviIbhzCdy           ;16-464-517-8943;carefully bold accounts doub


Number of rows retrieved is:      100
Number of rows sent to output is:   100

Elapsed Time is:           0,721      seconds  

---------------------------------------------

Current Timestamp:   Wed Mar 01 17:21:59 2006
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574356
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Victor Metelitsa пишет:
> Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов
О, у меня тоже была идея для ASA проверить что насоветует Index
Consultant, но почему-то думал, что набор индексов жестко
регламентирован в TCP-R
Поэтому я создавать не стал. Но резервами поинтересовался.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574371
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса.
Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574377
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А DFT_QUERYOPT считается настройкой?
Собрал статистику, переткнул DFT_QUERYOPT в 7.
real 0m1.663s
real 0m0.333s
real 0m0.320s

"Что это было?" :[ ]
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574378
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaПотом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.
В том то и дело, что Вы заявили, "это явный косяк ASA с индексами при апдейте большого кол-ва записей". Пришлось качать тест и доказывать, что это неявный и тем более не косяк, так бы и заморачиваться не пришлось. Одно доброе дело - решился таки написать статью по чекпойнтам под ASA, не первый раз тема всплывает даже у наших, а момент как оказалось достаточно важный не только с точки зрения надежности хранения данных, но и скорости, так что Вам Олег большое спасибо за толчок
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574382
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так посимпатишнее:

Victor Metelitsa
начало
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
Current Timestamp:   Wed Mar  01   17 : 21 : 58   2006 

---------------------------------------------

Statement number:  1 

select
s_acctbal,
s_name,
n_name,
p_partkey,
p_mfgr,
s_address,
s_phone,
s_comment
from
part p,
supplier,
partsupp,
nation,
region
where
p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and p_size =  15 
and p_type like '%BRASS'
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
and ps_supplycost = (
select
min(ps_supplycost)
from
partsupp,
supplier,
nation,
region
where
p.p_partkey = ps_partkey
and s_suppkey = ps_suppkey
and s_nationkey = n_nationkey
and n_regionkey = r_regionkey
and r_name = 'EUROPE'
)
order by
s_acctbal desc,
n_name,
s_name,
p_partkey
FETCH FIRST  100  rows ONLY
OPTIMIZE FOR  100  ROWS


S_ACCTBAL              S_NAME                    N_NAME                    P_PARTKEY    P_MFGR                    S_ADDRESS                                S_PHONE         S_COMMENT                                                                                             
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
                9938 . 53 ;Supplier# 000005359        ;UNITED KINGDOM           ;       185358 ;Manufacturer# 4            ;QKuHYh,vZGiwu2FWEJoLDx04                ; 33 - 429 - 790 - 6131 ;blithely silent pinto beans are furiously. slyly final deposits acros
                9937 . 84 ;Supplier# 000005969        ;ROMANIA                  ;       108438 ;Manufacturer# 1            ;ANDENSOSmk,miq23Xfb5RWt6dvUcvt6Qa       ; 29 - 520 - 692 - 3537 ;carefully slow deposits use furiously. slyly ironic platelets above the ironic
                9936 . 22 ;Supplier# 000005250        ;UNITED KINGDOM           ;          249 ;Manufacturer# 4            ;B3rqp0xbSEim4Mpy2RH J                   ; 33 - 320 - 228 - 2957 ;blithely special packages are. stealthily express deposits across the closely final instructi
                9923 . 77 ;Supplier# 000002324        ;GERMANY                  ;        29821 ;Manufacturer# 4            ;y3OD9UywSTOk                            ; 17 - 779 - 299 - 1839 ;quickly express packages breach quiet pinto beans. requ
                9871 . 22 ;Supplier# 000006373        ;GERMANY                  ;        43868 ;Manufacturer# 5            ;J8fcXWsTqM                              ; 17 - 813 - 485 - 8637 ;never silent deposits integrate furiously blit
                9870 . 78 ;Supplier# 000001286        ;GERMANY                  ;        81285 ;Manufacturer# 2            ;YKA,E2fjiVd7eUrzp2Ef8j1QxGo2DFnosaTEH   ; 17 - 516 - 924 - 4574 ;final theodolites cajole slyly special,

конец
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
                7912 . 91 ;Supplier# 000004211        ;GERMANY                  ;       184210 ;Manufacturer# 4            ;2wQRVovHrm3,v03IKzfTd,1PYsFXQFFOG       ; 17 - 266 - 947 - 7315 ;final requests integrate slyly above the silent, even
                7894 . 56 ;Supplier# 000007981        ;GERMANY                  ;        85472 ;Manufacturer# 4            ;NSJ96vMROAbeXP                          ; 17 - 963 - 404 - 3760 ;regular, even theodolites integrate carefully. bold, special theodolites are slyly fluffily iron
                7887 . 08 ;Supplier# 000009792        ;GERMANY                  ;       164759 ;Manufacturer# 3            ;Y28ITVeYriT3kIGdV2K8fSZ V2UqT5H1Otz     ; 17 - 988 - 938 - 4296 ;pending, ironic packages sleep among the carefully ironic accounts. quickly final accounts
                7871 . 50 ;Supplier# 000007206        ;RUSSIA                   ;       104695 ;Manufacturer# 1            ;3w fNCnrVmvJjE95sgWZzvW                 ; 32 - 432 - 452 - 7731 ;furiously dogged pinto beans cajole. bold, express notornis until the slyly pending
                7852 . 45 ;Supplier# 000005864        ;RUSSIA                   ;         8363 ;Manufacturer# 4            ;WCNfBPZeSXh3h,c                         ; 32 - 454 - 883 - 3821 ;blithely regular deposits
                7850 . 66 ;Supplier# 000001518        ;UNITED KINGDOM           ;        86501 ;Manufacturer# 1            ;ONda3YJiHKJOC                           ; 33 - 730 - 383 - 3892 ;furiously final accounts wake carefully idle requests. even dolphins wake acc
                7843 . 52 ;Supplier# 000006683        ;FRANCE                   ;        11680 ;Manufacturer# 4            ;2Z0JGkiv01Y00oCFwUGfviIbhzCdy           ; 16 - 464 - 517 - 8943 ;carefully bold accounts doub


Number of rows retrieved is:       100 
Number of rows sent to output is:    100 

Elapsed Time is:            0 , 721       seconds  

---------------------------------------------

Current Timestamp:   Wed Mar  01   17 : 21 : 59   2006 
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574402
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Привожу кусок лога (второго прогона). Прошу проверить, потому что не верю >собственным глазам и думаю, что где-то глюканул:

Я думаю что глюканул именно Express. Так как этот запрос действительно выбивается из всех остальных. Что там за проблемы я не разбирался, т.к. такой задачи не ставил. Как я уже и сказал - будут оптимальные настройки для Express - будет повторный прогон теста.

P.S. Может ты с данными прошибся - не тот объём влил. Потом есть одно но, у тебя другой набор сгенерированных данных :-), я же использовал один и тот же для всех серверов.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574412
paper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaНа news://news.gmane.org/gmane.comp.db.firebird.russian я увидел любопытную тему "Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)". Попытка написать туда не удалась - я получил письмо от Gmane Autoauthorizer, ответил на него, но на этом всё заглохло. На работе у меня интернет ограничен, и более подробные исследования я не могу сейчас произвести.
На всякий случай (если еще актуально) эту конференцию можно читать/писать через веб или мыло: http://groups.google.com/group/ru-firebird
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574425
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Источники таковы:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
 01 . 03 . 2006    15 : 29          24   507   279  customer.tbl
 01 . 03 . 2006    15 : 29         765   862   581  lineitem.tbl
 01 . 03 . 2006    15 : 29               2   128  nation.tbl
 01 . 03 . 2006    15 : 29         173   415   496  orders.tbl
 01 . 03 . 2006    15 : 29          24   407   151  part.tbl
 01 . 03 . 2006    15 : 29         119   612   986  partsupp.tbl
 01 . 03 . 2006    15 : 29                 401  region.tbl
 01 . 03 . 2006    15 : 29           1   418   798  supplier.tbl
                8  File(s)   1   109   226   820  bytes
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574442
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И результат (не весь, но несколько в начале и конце, первую колонку) я сравнивал с эталонным. Вроде совпадает.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574467
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я понял, в чём у меня был косяк-я использовал скрипты для создания индексов из архива tpcrFB20.zip, поскольку не был уверен, что они совпадают с TPC-H.
Ну и в итоге не создал primary keys :)

Сейчас для чистоты эксперимента опробую Express на виндах.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574476
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa
Я думаю что глюканул именно Express. Так как этот запрос действительно выбивается из всех остальных. Что там за проблемы я не разбирался, т.к. такой задачи не ставил. Как я уже и сказал - будут оптимальные настройки для Express - будет повторный прогон теста.

Я абсолютно не верю, что Expess хоть чем-то хуже ESE на данной задаче в наших конфигурациях. Пока нет исходников реальных исполняемых скриптов, у меня возникают самые мрачные подозрения. На всякий случай обращу внимание, что длина имени индекса у DB2 ограничена всего 18-ю символами, и скрипт создания индексов у меня такой:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create index lineitem_shipdate  on lineitem(l_shipdate);
create index lineitem_partkey_s on lineitem(l_partkey, l_suppkey);
create index part_brand_contain on part(p_brand, p_container, p_size);
create index lineitem_quantity_ on lineitem(l_quantity, l_shipmode, l_shipinstruct);
create index lineitem_shipmode_ on lineitem(l_shipmode, l_receiptdate);
create index part_name          on part(p_name);
create index supplier_nationkey on supplier(s_nationkey);
create index partsupp_suppkey   on partsupp(ps_suppkey);
create index customer_nationkey on customer(c_nationkey);
create index orders_custkey     on orders(o_custkey);
create index orders_orderdate   on orders(o_orderdate);

Статистику собирал так (имя схемы здесь обязательно):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
runstats on table vvm.PART with distribution and detailed indexes all;
runstats on table vvm.SUPPLIER with distribution and detailed indexes all;
runstats on table vvm.PARTSUPP with distribution and detailed indexes all;
runstats on table vvm.CUSTOMER with distribution and detailed indexes all;
runstats on table vvm.ORDERS with distribution and detailed indexes all;
runstats on table vvm.LINEITEM with distribution and detailed indexes all;
runstats on table vvm.NATION with distribution and detailed indexes all;
runstats on table vvm.REGION with distribution and detailed indexes all;

Сперва создавал базу и таблицы, затем грузил данные, затем создавал индексы, затем собирал статистику.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574502
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa
Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу.
Кстати, есть SORTHEAP у базы и есть SHEAPTHRES у СУБД. Совет, как я помню, был поставить SHEAPTHRES = буферному пулу, а SORTHEAP в 4 раза меньше. Но я это не проверял.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574507
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM,
Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574526
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про 18 символов не напоминай, матерился их обрезая что есть мочи.

Сount в таблицах выдай сюда. В приципе я могу повторно его прогнать - может и в правду что-то накосячил с параметрами БД.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574568
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей"[/quot]

Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574576
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloa[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей"

Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)[/quot]
В BOL очень красиво и подробно расписан механизм чекпойнтов, действий сервера по восстановлению БД в случае аварийного завершения, но нет ни слова о том, как это коррелировано с производительностью (да и надежностью при сбоях тоже кстати). Так что будет чем заняться, когда свободное время появиться :)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574916
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
насчет индексов. если в метаданных есть например индекс supplier_nationkey, то на самом деле это я виновник появления этих индексов :-)
я начал интересоваться tpc-r в плане его прогона на IB еще в 2000 году, и специально добавил ряд индексов, "для ускорения". Так что если есть желание проводить тест без "лишних" индексов, то вот они:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create index lineitem_shipdate on lineitem(l_shipdate);
create index lineitem_partkey_suppkey on lineitem(l_partkey, l_suppkey);
create index part_brand_container_size on part(p_brand, p_container, p_size);
create index lineitem_quantity_sm_si on lineitem(l_quantity, l_shipmode, l_shipinstruct);
create index lineitem_shipmode_rd on lineitem(l_shipmode, l_receiptdate);
create index part_name on part(p_name);
create index supplier_nationkey on supplier(s_nationkey);
create index partsupp_suppkey on partsupp(ps_suppkey);
create index customer_nationkey on customer(c_nationkey);
create index orders_custkey on orders(o_custkey);
create index orders_orderdate on orders(o_orderdate);

кстати. для некоторых запросов в IB фатальным оказался именно lineitem_shipdate, и решением в одном случае являлся именно хинт для исключения этого индекса.
но сейчас я не знаю, имеет ли смысл перепроверять тесты...
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575153
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну вот, "лошадь тут была непричём, совершенно".
Поставил специально DB2 Express на винды. Худшее время - 4.750. А последующие, когда уже всё в кэше-гораздо быстрее:
Код: plaintext
1.
2.
3.
4.
5.
Summary of Results
==================
                Elapsed             Agent CPU         Rows      Rows
Statement #     Time (s)            Time (s)          Fetched   Printed
 1                       0 , 281        Not Collected        100         100 
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575211
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
До оракла всё равно не дотянул ;-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575244
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Фигня.
Зато в 5м тесте - 38с, 10 - 37.9, 11 - 3.36, что заметно лучше оракла.

Табличные пространства все дефолтные SMS, объём кэша тоже дефолтный

По-моему, неплохо в любом случае.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575369
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У ora 5-й хапрос 12 сек ;-). Расслабтесь я заного ставлю DB2 EE и буду снова прогонять тест, возможно я когда менял размеры журнала транзакций случайно ткнул какой-то параметр.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575387
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Локшин Марк Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM,
Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась.

Во-первых, в обсуждаемых тестах "основная" конфигурация была с двумя гигами (см. приложенный к одному из предыдущих олеговых писем excel-файл).

Во-вторых, я использовал дефолтные настройки, в том числе буферный пул в 250 страниц, а каждая страница в 4 кило.

Ах, вот оно что. По дефолту SMS-пространства (каждая таблица в отдельном файле) кешируются ОС, а я про это забыл, так как обычно ими не пользуюсь. Так что да, для ухудшения результатов надо было это отключить ;-).

С другой стороны, Interbase, Oracle, MS SQL используют DMS-пространства (т.е., грубо говоря, много таблиц в файле или на raw device), так что и для DB2 стоило бы создавать именно такую базу (т.е. задать для данных именно DMS-табличное пространство, тогда как прочие два, системное и временное, IBM рекомендует делать SMS).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575403
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Локшин Марк Victor MetelitsaИтак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM,
Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась.

В принципе да, согласен. Но исходные параметры тестов были не мои, а как это Oracle может выигрывать у DB2, не укладывается в моей голове ;-). Несколько позже я буду делать свои (DB2 и пара-тройка версий Oracle), для своего собственного развлечения, возьму scale factor побольше (настолько большой, настолько смогу; у меня теперь на домашней машине теперь на дисках больше терабайта, но ведь может не хватить терпения дожидаться результатов) и постараюсь выжать как можно больше скорости, не ограничиваясь ничем.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575413
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaПро 18 символов не напоминай, матерился их обрезая что есть мочи.

Сount в таблицах выдай сюда. В приципе я могу повторно его прогнать - может и в правду что-то накосячил с параметрами БД.

Count завтра, а сейчас скажу, что у меня есть опасение насчёт сбора статистики. Возможно, вы просто выбираете в Control Center схему, выбираете в меню "собрать статистику" и жмёте ОК. Но там важно правильно расставить галочки, или лучше вместо этого запустить мой скрипт (исправив имя схемы). По дефолту там статистика по индексам и distribution не собираются.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575421
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaи буду снова прогонять тест

Ура! Шоу продолжается!
Линтер, кстати, забыл добавить в коллекцию.

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

Victor Metelitsaдля своего собственного развлечения, возьму scale factor побольше (настолько большой, настолько смогу; у меня теперь на домашней машине теперь на дисках больше терабайта, но ведь может не хватить терпения дожидаться результатов) и постараюсь выжать как можно больше скорости, не ограничиваясь ничем.
Для чего тест понадобился Олегу, я представляю. Но вот потратить личное время на такое...
Хотя, по крайней мере, это развлечение безопасно, в отличие от многих других. Например взять бочонок пива побольше и постараться выжать как можно больше скорости на дорогах общего пользования, не ограничиваясь ничем: ни знаками, ни дорожными условиями
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575612
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Александр Гoлдун
Для чего тест понадобился Олегу, я представляю. Но вот потратить личное время на такое...
Хотя, по крайней мере, это развлечение безопасно, в отличие от многих других. Например взять бочонок пива побольше и постараться выжать как можно больше скорости на дорогах общего пользования, не ограничиваясь ничем: ни знаками, ни дорожными условиями

А я вот не понимаю пивопийц на футбольных трибунах (и вообще всех спортивных болельщиков разом), женщин, получающих кайф от шоппинга, и кучу другого народа.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575653
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Некоторые граждане, пишущие под именем "Victor Metelitsa" вовсе не предполагали, что задача теста получить максимальную производительность. Но некоторые граждане предполагали, что, тем не менее, некоторые другие граждане будут на этот "тест" ссылаться, и хотели, например, получить от некоторых "третьих" граждан скрипт, чтобы понять, что пошло не так, потому что то получилось что-то странное - то, чего не должно было быть, по мнению некоторых граждан. Имеются также некоторые граждане, (часть которых пишет под именем "Victor Metelitsa") которые считают, что тесты полезны, чтобы искать "узкие места" у себя в голове, заниматься самообразованием (этот процесс бесконечный), а соревнования делают этот процесс веселее. Наконец, если некие граждане не ощущают себя вредителями, это ещё не означает, что они таковыми не являются фактически.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33575958
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мой тест имел направленность одну - улучшение функционала FB2. Что и бло сделано, т.к. пару недоработок устранили. Максимальную производительнсоть никто и не искал, поэтому всё и по дифолтам.

А теперь самое интересное. Я опять создал базу, влил данные собрал статистику твоим скриптом и опять время выполнения 2-го запроса - минут 7. При этом 100 загрузка проца и никакой нагрузки на диск.

Вот так. Что может ещё влиять, на что грешить. Может HT отрубить?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576006
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пока никаких идей, разве что и правда HT обвинить. На выходных напишу свой полный скрипт, как это сделано для FB/IB.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576058
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaПока никаких идей, разве что и правда HT обвинить. На выходных напишу свой полный скрипт, как это сделано для FB/IB.
Ну вот, Вам спортивного интересу больше. А я, глядя на скрипты создания индексов и самих запросов и так знаю, где и почему тесты отработались плохо для ASA9 и что нужно сделать, чтобы они летали. Тут даже консультант индексов и граф. план запросов не нужен, поэтому пущай остается в тестах как есть, лениво тестить то, что и так знаешь, как можно ускорить - никакого млин спортивного интереса.

IMHO как оказалось, в DB2 есть свои тонкие ньюансы, коих немалое множество, хотя прикола с FIRST я так и не понял честно говоря.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576082
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvнасчет индексов. если в метаданных есть например индекс supplier_nationkey, то на самом деле это я виновник появления этих индексов :-)
я начал интересоваться tpc-r в плане его прогона на IB еще в 2000 году, и специально добавил ряд индексов, "для ускорения". Так что если есть желание проводить тест без "лишних" индексов, то вот они:

На самом деле, судя по описанию на tpc.org, нет ограничений на индексы и другие ухищрения. И странно было бы иное. Я надеюсь как-нибудь попробовать это на GemStone/S, которая вовсе даже не SQL-СУБД.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576091
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
блин да не прикол это, и не хинты, а документированные SQL Statements.
Как говорится, документированный баг == фича :)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576166
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, OPTIMIZE это всё-таки хинт, даже если официально он так не называется. Подсказка компилеру и клиентскому обеспечению, как надо выполнять запрос и передавать по сети.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576268
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПодсказка компилеру и клиентскому обеспечению

клиентское обеспечение парсит sql-запросы, передаваемые на сервер?

а по поводу оптимизации first, я все-таки не врубаюсь, какие вообще хинты могут быть для "оптимизации выборки первых записей":
select first 100 *
from table
order by last_name

order by так или иначе должен отсортировать таблицу? должен.
select first 100 должен прекратить выдачу данных клиенту после 100-го fetch? должен.
Где тут может быть оптимизация??? И оптимизация чего, собственно?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576294
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
кроме fetch first 100
может быть optimize for 10 rows
то есть первые 10 будут вернуты мгновенно, для их извлечения будет оптимизирован запрос.
Пока пользователь их изучит, там и остальные будут извлечены, а ему может уже и не понадобится.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576373
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
optimize for n rows - говрит, что результирующий набор (результат работы курсора, или запроса) будет достраиваться динамически. Т.е. не сразу , а по мере прихода FETCH. Если кому-то это не понятно зачем это нужно, или кто-то хочет пощупать "как это работает" могу выслать маленькое тестовое приложение.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576413
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нее, товарищи, HT не виноват. Я до кучи сравнивал свой "подстольный" компьютер с Athlon XP с P4 w/HT под Ораклом и DB2 - ухудшения не заметил. Тем более в какие-то жуткие разы.

А вообще-тест полезен хотя бы тем, что поневоле придётся подучить матчасть, расширить кругозор ;) Гораздо полезнее пресловутого питья пива на стадионе.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576439
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Скажем, у Oracle есть хинты
/*+ ALL_ROWS */ The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption).
и
/*+ FIRST_ROWS */ The FIRST_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row).

This hint causes the optimizer to make the following choices:

If an index scan is available, then the optimizer may choose it over a full table scan.

If an index scan is available, then the optimizer may choose a nested loops join over a sort-merge join whenever the associated table is the potential inner table of the nested loops.

If an index scan is made available by an ORDER BY clause, then the optimizer may choose it to avoid a sort operation.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576487
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Про что я ещё забыл, так это про ACTIVATE DATABASE, хотя на 2-й запрос это повлиять не должно, коль скоро 100%-я загрузка процессора.

DB2, если нет ни одного коннекта, освобождает память базы данных. Если вы сделали коннект к базе, прогнали тесты в первый раз, сделали дисконнект, затем коннект и прогнали тесты во второй раз, результаты могут оказаться, как в первом, если коннект был единственный. Чтобы содержимое буферных пулов не пропало, надо либо постоянно держать ещё один коннект, либо выполнить ACTIVATE DATABASE <имя>.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576525
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
select count(*) from  vvm.PART 
--------------
       200000 

select count(*) from  vvm.SUPPLIER 
--------------
        10000 

select count(*) from  vvm.PARTSUPP 
--------------
       800000 

select count(*) from  vvm.CUSTOMER 
--------------
       150000 

select count(*) from  vvm.ORDERS 
--------------
      1500000 

select count(*) from  vvm.LINEITEM 
--------------
      6001215 

select count(*) from  vvm.NATION 
--------------
           25 

select count(*) from  vvm.REGION 
--------------
            5 
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576535
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Отключил кеширование ОС командой
db2set DB2NTNOCACHE=ON
и прогнал Configuration Adviser.

10 сек в первый раз, 0.4 во второй.

Сейчас ещё данные перегенерю.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33576619
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчёт разных данных. Я генерирую их как

dbgen -s 1 -v -F

Сегодня сгенерировал ещё один набор файлов и сравнил со вчерашними. Они одинаковые.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577018
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
HT выключил, результаты неизменны 100% загрузка проца и отсутствие нагрузки на диск.

Танцы с бубном прекращаю, желающие могут сваять сами тестовую систему и натестировать DB2 vs ORA, у меня таких целей нет.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577032
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 olegloa
сделайте такую фигню:
db2admin stop
и повторите тест.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577306
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторoptimize for n rows - говрит, что результирующий набор (результат работы курсора, или запроса) будет достраиваться динамически. Т.е. не сразу , а по мере прихода FETCH

я извиняюсь, но для меня это абракадабра. Почему - изложил в тексте вопроса.
То есть, результат так или иначе перед fetch уже должен быть в отсортированном виде. КАК это будет делать сервер - левой или правой рукой, меня абсолютно не волнует. Возможно, вся эта оптимизация состоит именно в том, чтобы не аллокировать сразу большой буфер под фетчи, или еще что, но на мой взгляд, я еще раз повторю - ХИНТ ОПТИМИЗАЦИИ уже сразу заложен в самом запросе - это и есть указание FIRST 100. Про optimize for n rows БЕЗ FIRST 100 я не спрашивал.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577338
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 kdv
Если стоит FETCH FIRST а по плану запроса перед тем как выдать первую сотню записей нужно перелопатить (пересортировать) всю таблицу, то не ждите мгновенного ответа.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577431
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaDB2, если нет ни одного коннекта, освобождает память базы данных. Интересно... А зачем?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577439
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это было ещё минимум с v2.1 for OS/2, и до сих пор не знаю ;-).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577523
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman2 olegloa
сделайте такую фигню:
db2admin stop
и повторите тест.
Ну так как? результат после остановки сервера администрирования?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33577575
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
затем, что если есть какие изменения в распределении памяти, то после отсоединения последнего клиента они вступят в силу. Опять же - а зачем память держать, если она не нужна? А если не надо освобождать - то пжалста, укажите принудительно, то есть выбор есть, а выбор есть гууд
все imho
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33578580
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenman gardenman2 olegloa
сделайте такую фигню:
db2admin stop
и повторите тест.
Ну так как? результат после остановки сервера администрирования?

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

Я бы подумал, что все нужные данные закешированы, но сервер почему-то не использует hash join и проводит fullscan. Отсюда отсутствие обращение к диску, 100%-я загрузка процессора и большое время выполнения.

Но зачем ему это надо? И как этого можно было добиться?

По умолчанию в v8 использование hash join включено (в отличие от v7? или v6? уже не помню, когда дефолт сменился, но в v8 точно включено, а DB2 Express C это v8, а точнее, v8.2fp3), на дефолтном уровне оптимизации hj должны использоваться. Рекомендуют держать пропорцию между sheapthres и sortheap (минимум 2:1), но Configuration Adviser должен был её соблюсть. Ещё можно было испортить схему разными типами данных у primary и foreign keys, но делать это надо было нарочно.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33578589
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ggvзатем, что если есть какие изменения в распределении памяти, то после отсоединения последнего клиента они вступят в силу. Опять же - а зачем память держать, если она не нужна? А если не надо освобождать - то пжалста, укажите принудительно, то есть выбор есть, а выбор есть гууд
все imho

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

Но всё же это не такой большой минус, чтобы из-за него ломать копья.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33578780
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я чувствую себя в роли автомеханика-гинеколога из анекдота (который ремонтировал двигатели через выхлопную трубу).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33578871
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
ну поскольку мне больше приходилось иметь дело с системами автоматической обработки данных, а не с пользователями, то с моей точки зрения это плюс, и я никогда не использовал activate.
А вот по поводу новичков - неубедительно. Это какие такие новички, которые читать не любят? Дык им все фичи 'дезорганизирующие'
IMHO
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579266
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Victor Metelitsa
Я много раз наблюдал, как DAS ни с того ни с сего вдруг начинает грузить процессор и ниче не шевелится. Все руки не доходят разобраться что к чему.
поэтому я как правило устанавливаю DAS так, чтобы он запускался мануально.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579310
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
у меня тоже пару раз DAS чудил.
gardenman, надо бы как-то поймать момент, зафиксировать ошибку. Опишем, откроем PMR
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579349
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Виктор, пользоваться
db2set DB2NTNOCHACHE не кошерно с версии 8.2
db2 alter tablespace userspace1 no file system caching
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579825
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Создание на DB2 базы с нуля
1. Машинка - Athlon 850, чипсет kt133a, 768RAM, новенький диск Samsung 250G
2. Поставил Windows 2003 SE
3. Поставил DB2 сервер с ftp://ftp.software.ibm.com/ps/products/db2/fixes2/english-us/db2winIA32v8/fixpak/FP11_WR21365/FP11_WR21365_ESE.exe
при установке -
Typical,
Single Partition Environment,
только English, в C:\SQLLIB\ (по старой привычке)
do not prepare db2 tools catalog...
4. Создал каталог C:\DATA

5. В Control Center создал базу данных через adviser:
5.1 Закладка Name. Задал TPCR
5.2 Закладка User Tables. Выбрал High Performance. Нажал кнопку Add.
Описал контейнер типа File, размер 5000, имя c:\data\userdata.dat
5.3 Теперь сразу в Summary. Кнопка Show Command показывает
CREATE DATABASE tpcr ON 'C:' USING CODESET 1251 TERRITORY RU COLLATE USING SYSTEM USER TABLESPACE MANAGED BY DATABASE USING ( FILE 'C:\DATA\userdata.dat' 1280000 ) ;
6. База данных создалась за 40 секунд. Мне предложили запустить Configuration Adviser, я отказался (сперва загружу данные и соберу статистику).
7. Щёлкнул 4-ю круглую кнопку (Command Editor). Приконнектился к TPCR (target add).
8. Вклеил в окно и исполнил скрипт:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
create table PART (
 P_PARTKEY integer not null,
 P_NAME  varchar( 55 ),
 P_MFGR  char( 25 ),
 P_BRAND  char( 10 ),
 P_TYPE  varchar( 25 ),
 P_SIZE  integer,
 P_CONTAINER char( 10 ),
 P_RETAILPRICE numeric( 18 , 2 ),
 P_COMMENT varchar( 23 )
);
alter table PART add constraint PART_PK primary key (P_PARTKEY);

create table SUPPLIER (
 S_SUPPKEY integer not null,
 S_NAME  char( 25 ),
 S_ADDRESS varchar( 40 ),
 S_NATIONKEY integer not null,
 S_PHONE  char( 15 ),
 S_ACCTBAL numeric( 18 , 2 ),
 S_COMMENT varchar( 101 )
);
alter table SUPPLIER add constraint SUPPLIER_PK primary key (S_SUPPKEY);

create table PARTSUPP (
 PS_PARTKEY integer not null,
 PS_SUPPKEY integer not null,
 PS_AVAILQTY integer,
 PS_SUPPLYCOST numeric( 18 , 2 ),
 PS_COMMENT varchar( 199 )
);
alter table PARTSUPP add constraint PARTSUPP_PK primary key (PS_PARTKEY, PS_SUPPKEY);

create table CUSTOMER (
 C_CUSTKEY integer not null,
 C_NAME  varchar( 25 ),
 C_ADDRESS varchar( 40 ),
 C_NATIONKEY integer not null,
 C_PHONE  char( 15 ),
 C_ACCTBAL numeric( 18 , 2 ),
 C_MKTSEGMENT char( 10 ),
 C_COMMENT varchar( 117 )
);
alter table CUSTOMER add constraint CUSTOMER_PK primary key (C_CUSTKEY);

create table ORDERS (
 O_ORDERKEY integer not null,
 O_CUSTKEY integer not null,
 O_ORDERSTATUS char( 1 ),
 O_TOTALPRICE numeric( 18 , 2 ),
 O_ORDERDATE date,
 O_ORDERPRIORITY char( 15 ),
 O_CLERK  char( 15 ),
 O_SHIPPRIORITY integer,
 O_COMMENT varchar( 79 )
);
alter table ORDERS add constraint ORDERS_PK primary key (O_ORDERKEY);

create table LINEITEM (
 L_ORDERKEY integer not null,
 L_PARTKEY integer not null,
 L_SUPPKEY integer not null,
 L_LINENUMBER integer not null,
 L_QUANTITY numeric( 18 , 2 ),
 L_EXTENDEDPRICE numeric( 18 , 2 ),
 L_DISCOUNT numeric( 18 , 2 ),
 L_TAX  numeric( 18 , 2 ),
 L_RETURNFLAG char( 1 ),
 L_LINESTATUS char( 1 ),
 L_SHIPDATE date,
 L_COMMITDATE date,
 L_RECEIPTDATE date,
 L_SHIPINSTRUCT char( 25 ),
 L_SHIPMODE char( 10 ),
 L_COMMENT varchar( 44 )
);
alter table LINEITEM add constraint LINEITEM_PK primary key (L_ORDERKEY, L_LINENUMBER);

create table NATION (
 N_NATIONKEY integer not null,
 N_NAME  char( 25 ),
 N_REGIONKEY integer not null,
 N_COMMENT varchar( 125 )
);
alter table NATION add constraint NATION_PK primary key (N_NATIONKEY);

create table REGION (
 R_REGIONKEY integer not null,
 R_NAME  char( 25 ),
 R_COMMENT varchar( 152 )
);
alter table REGION add constraint REGION_PK primary key (R_REGIONKEY);
9. Создал данные при помощи
dbgen -s 1 -v -F
в каталоге c:\tpc-r\db2

10. Выполнил скрипт загрузки
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
load from c:\tpc-r\db2\PART.tbl     of del modified by coldel| datesiso REPLACE into vvm.PART;
load from c:\tpc-r\db2\SUPPLIER.tbl of del modified by coldel| datesiso REPLACE into vvm.SUPPLIER;
load from c:\tpc-r\db2\PARTSUPP.tbl of del modified by coldel| datesiso REPLACE into vvm.PARTSUPP;
load from c:\tpc-r\db2\CUSTOMER.tbl of del modified by coldel| datesiso REPLACE into vvm.CUSTOMER;
load from c:\tpc-r\db2\ORDERS.tbl   of del modified by coldel| datesiso REPLACE into vvm.ORDERS;
load from c:\tpc-r\db2\LINEITEM.tbl of del modified by coldel| datesiso REPLACE into vvm.LINEITEM;
load from c:\tpc-r\db2\NATION.tbl   of del modified by coldel| datesiso REPLACE into vvm.NATION;
load from c:\tpc-r\db2\REGION.tbl   of del modified by coldel| datesiso REPLACE into vvm.REGION;
(замените vvm на имя своей схемы).

11. Выполнил скрипт создания индексов (минут 10).
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
create index lineitem_shipdate  on lineitem(l_shipdate);
create index lineitem_partkey_s on lineitem(l_partkey, l_suppkey);
create index part_brand_contain on part(p_brand, p_container, p_size);
create index lineitem_quantity_ on lineitem(l_quantity, l_shipmode, l_shipinstruct);
create index lineitem_shipmode_ on lineitem(l_shipmode, l_receiptdate);
create index part_name          on part(p_name);
create index supplier_nationkey on supplier(s_nationkey);
create index partsupp_suppkey   on partsupp(ps_suppkey);
create index customer_nationkey on customer(c_nationkey);
create index orders_custkey     on orders(o_custkey);
create index orders_orderdate   on orders(o_orderdate);
12. Собрал статистику
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
runstats on table vvm.PART with distribution and detailed indexes all;
runstats on table vvm.SUPPLIER with distribution and detailed indexes all;
runstats on table vvm.PARTSUPP with distribution and detailed indexes all;
runstats on table vvm.CUSTOMER with distribution and detailed indexes all;
runstats on table vvm.ORDERS with distribution and detailed indexes all;
runstats on table vvm.LINEITEM with distribution and detailed indexes all;
runstats on table vvm.NATION with distribution and detailed indexes all;
runstats on table vvm.REGION with distribution and detailed indexes all;
(замените vvm на имя своей схемы).

13. Запустил на базе Configuration Advisor, 80% память, под workload: Queries( Warehouse). Получил и выполнил скрипт:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
UPDATE DATABASE CONFIGURATION FOR TPCR USING APP_CTL_HEAP_SZ  128 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING APPGROUP_MEM_SZ         10462 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING CATALOGCACHE_SZ  260 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING CHNGPGS_THRESH   70 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DBHEAP           600 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOCKLIST         50 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGBUFSZ         131 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGFILSIZ        1024 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGPRIMARY       3 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGSECOND        0 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING MAXAPPLS         40    MAXLOCKS     15 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING MINCOMMIT        1 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING NUM_IOCLEANERS   1 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING NUM_IOSERVERS    5 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING PCKCACHESZ       1114 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING SOFTMAX          150 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING SORTHEAP         682 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING STMTHEAP         2048 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DFT_DEGREE      ANY;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DFT_PREFETCH_SZ  64 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING UTIL_HEAP_SZ     24837 ;
UPDATE DATABASE MANAGER CONFIGURATION USING SHEAPTHRES          20478 ;
UPDATE DATABASE MANAGER CONFIGURATION USING INTRA_PARALLEL     OFF;
UPDATE DATABASE MANAGER CONFIGURATION USING MAX_QUERYDEGREE     1 ;
UPDATE DATABASE MANAGER CONFIGURATION USING MAXAGENTS           400 ;
UPDATE DATABASE MANAGER CONFIGURATION USING NUM_POOLAGENTS      400 ;
UPDATE DATABASE MANAGER CONFIGURATION USING NUM_INITAGENTS      0 ;
UPDATE DATABASE MANAGER CONFIGURATION USING FCM_NUM_BUFFERS     4096 ;
UPDATE DATABASE MANAGER CONFIGURATION USING PRIV_MEM_THRESH         32767 ;
CONNECT TO TPCR;
ALTER BUFFERPOOL IBMDEFAULTBP SIZE  74513 ;
SET CURRENT QUERY OPTIMIZATION =  7 ;
COMMIT;
CONNECT RESET;


...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579830
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тест

1. Создал x.bat с содержимым
Код: plaintext
1.
2.
3.
db2stop force
db2start
db2batch -d tpcr -f  2 - 2 - 2 .sql  -r  2 - 2 - 2 .log1, 2 - 2 - 2 .log2 -v on -t ;

2. Создал 2-2-2.sql с три раза повторяющимся запросом
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
select
        s_acctbal,
        s_name,
        n_name,
        p_partkey,
        p_mfgr,
        s_address,
        s_phone,
        s_comment
from
        part p,
        supplier,
        partsupp,
        nation,
        region
where
        p_partkey = ps_partkey
        and s_suppkey = ps_suppkey
        and p_size =  15 
        and p_type like '%BRASS'
        and s_nationkey = n_nationkey
        and n_regionkey = r_regionkey
        and r_name = 'EUROPE'
        and ps_supplycost = (
                select
                        min(ps_supplycost)
                from
                        partsupp,
                        supplier,
                        nation,
                        region
                where
                        p.p_partkey = ps_partkey
                        and s_suppkey = ps_suppkey
                        and s_nationkey = n_nationkey
                        and n_regionkey = r_regionkey
                        and r_name = 'EUROPE'
        )
order by
        s_acctbal desc,
        n_name,
        s_name,
        p_partkey
FETCH FIRST  100  rows ONLY
OPTIMIZE FOR  100  ROWS
;
3. Запустил. В 2-2-2.log получилось

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
Summary of Results
==================
                Elapsed             Agent CPU         Rows      Rows
Statement #     Time (s)            Time (s)          Fetched   Printed
 1                       7 , 540        Not Collected        100         100 
 2                       0 , 401        Not Collected        100         100 
 3                       0 , 400        Not Collected        100         100 
Arith. mean 2,780
Geom. mean 1,065
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579837
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay KulikovВиктор, пользоваться
db2set DB2NTNOCHACHE не кошерно с версии 8.2
db2 alter tablespace userspace1 no file system caching
Насколько я понимаю, DB2NTNOCHACHE всё-таки должно работать, хоть и obsolete.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579866
a_shats
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaКак именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader?
Нет, я попробовал только IB/FB ;) Просто тут есть свой хинт - мне по роду работы нужны тесты. загружающие железо по самое немогу, а этим тестом сколь-нибудь заметно нагрузить даже минимальные серверы (по входящему железу) не удалось. :(
Тот же ТРС-С в приведенном мной Quest Benchmark Factory интересовал меня в плане нагрузки при 500-1000 коннектов - а при этом количестве BF попросту вылетала (дело было не в ограничении до 20 коннектов :) )
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579881
pavelvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay KulikovВиктор, пользоваться
db2set DB2NTNOCHACHE не кошерно с версии 8.2
db2 alter tablespace userspace1 no file system caching Что-то я пропустил тот пост Виктора, такие интересные вещи выясняются :-)
Значит в DB2 есть возможность работать через кеш файловой системы. А зачем??? Неужели в каких-то случаях это может дать положительный эффект? Особенно на винде.
Пока в голову приходит только один ответ - чтобы хоть как-то работало, если засранец админ оставил дефолтный размер буферного пула...
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579942
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Раньше SMS всегда кешировались, DMS нет. Потом появилась возможность управлять этим. Насколько я понимаю, SMS для крошечных базулек, где админ/юзер действительно не утруждает себя никакими настройками, а DMS для больших "серьёзных" баз. Кроме того, IBM советует держать в SMS LOB'ы - наверное, это древний workaround древней проблемы (ибо LOB'ы не кешируются буферным пулом).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579966
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaЯ чувствую себя в роли автомеханика-гинеколога из анекдота (который ремонтировал двигатели через выхлопную трубу).

Проверили ещё одну машину, на этот раз Pentium4 3.2 гигагерца с гигом ОЗУ, и наконец на что-то "интересное" наткнулись.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33579989
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторЗначит в DB2 есть возможность работать через кеш файловой системы. А зачем???
гм. когда в Yaffil ввели в конфиг флажок отключения файлового кэша виндов, то сервер стал работать используя только свой собственный кэш.
При этом, как оказалось (я делал тесты), производительность зависит
1. от размера страницы БД
2. от размера кластера файловой системы

в итоге получилось, что нужна какая-то специальная софтина, которая бы перед вот таким отключением кэша ФС показала варианты производительности для разных размеров страниц. То есть, для работы как embedded и вообще как "сервер без администирования и настроек", это не годится.

С другой стороны, у Firebird происходит конфликт между его кэшем и кэшем файловой системы, если для БД задан кэш на грани наличия свободной памяти - производительность ухудшается.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33580253
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, на Pentium 3.2 тормозить стало чудовищно. Но, похоже, что мы (с Антоном) уже знаем, что за проблемы с DB2 оказались у Олега. Предполагаем, что дело именно именно в HT. Это повлияло на параметр CPUSPEED, который DB2 вычислила неверно, и на этой основе стали генерироваться плохие планы.

Предложение:
1. Выключить HT.
2. Выполнить UPDATE DBM CFG USING CPUSPEED -1 IMMEDIATE;
3. На всякий случай рестартовать DB2.

db2stop force
db2start

На 2-й и 3-й раз результаты получились примерно те же, что и у Oracle 9 (0.157, 0.140), хотя первый результат 20 (приписываем медленному винчестеру).

Короче, HT давить.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33580690
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Странно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33580755
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
говорю вам - вся проблема в DAS. Не запускайте его - и все будет ОК.
Во всяком случае в винде можно глянуть какой процесс жрет процессорные ресурсы, и это скорее всего db2dasrrm
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33580969
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanговорю вам - вся проблема в DAS. Не запускайте его - и все будет ОК.
Во всяком случае в винде можно глянуть какой процесс жрет процессорные ресурсы, и это скорее всего db2dasrrm

Всегда запускал, и всегда было ОК.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33580992
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я думаю такое поведение DAS OS-specific. На WinXP - довольно частое явление. И, что интерсно DAS начинает тормозить процессы DB2, однако на другие процессы это действует не так сильно.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581043
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeСтранно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста).

Воспользуйтесь Configuration Adviser ;-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581070
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa kmikeСтранно, у меня на P4 2.8 с HT нет никаких проблем с DB2 (по крайней мере, по результатам этого теста).

Воспользуйтесь Configuration Adviser ;-)
А что будет? Всё накроется?
Я в общем-то этими явовскими тулзами не пользуюсь-памяти они жрут слишком дофига, да ещё db2cc частенько требует наличия DAS, который у меня послу установки FP11 перестал запускаться.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581162
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, запустите пункт 13, хотя бы.

HT, может, и не причём. Сейчас на AMD64 сокет 754 2.4 гигагерц пробую. По дефолту cpuspeed = примерно 2.7e-07. На втором запросе получились такие:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Summary of Results
==================
                Elapsed             Agent CPU         Rows      Rows
Statement #     Time (s)            Time (s)          Fetched   Printed
 1                     331 , 922        Not Collected        100         100 
 2                     331 , 921        Not Collected        100         100 
 3                     325 , 375        Not Collected        100         100 

Arith. mean      329 , 739         
Geom.  mean      329 , 725         

Попробовал cpuspeed=5e-07. Примерно также.

Попробовал cpuspeed=6e-07. Скачок:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Summary of Results
==================
                Elapsed             Agent CPU         Rows      Rows
Statement #     Time (s)            Time (s)          Fetched   Printed
 1                       8 , 234        Not Collected        100         100 
 2                       0 , 109        Not Collected        100         100 
 3                       0 , 110        Not Collected        100         100 

Arith. mean      2 , 818           
Geom.  mean      0 , 462           

Как-то совсем не радует меня такая история...
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581166
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor MetelitsaНу, запустите пункт 13, хотя бы.
одного из моих предыдущих писем (результат моего Configuration Advisor).
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581424
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как я понял проблема в некорректном определении скорости процессора на определённых конфигурациях железо/софт? Это только у Express или вообще в реализации DB2 под Win32? Я так пологая что нужно ответственным товарищам за DB2 сделать соответствующую запись в FAQ иначе подобные грабли будут всплывать регулярно.

P.S. Ссылка на первонаступившего на грабли обязательна :-):-):-):-)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581471
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно, на _каких_ конфигурациях скорость определяется неверно?
У меня определилось 1.89e-07
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581857
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaКак я понял проблема в некорректном определении скорости процессора на определённых конфигурациях железо/софт? Это только у Express или вообще в реализации DB2 под Win32?

У меня только ESE. Я проверил бы Express, хотя и не верю в какую-либо разницу, но: что моя контора, что я по ADSL, потребляем инет по ценам 24 р за 10 мег и, естественно, жлобимся.

Для FAQ ещё рано хотя бы потому, что я проверил только 2-й запрос. Может, другим запросам от моего изменения CPUSPEED не получшеет, а даже похужеет. Я сегодня-завтра проверю несколько CPUSPEED на всех запросах. Надо ещё проследить, на каких запросах меняются планы.

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

В общем, это нехорошая история. На грабли, наверное, наступило уже множество народу, просто они об этом не догадываются.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33581858
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeИнтересно, на _каких_ конфигурациях скорость определяется неверно?
У меня определилось 1.89e-07

Я поторопился про "неверную". Сперва надо узнать, есть ли "верная".
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582034
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa,
я проверял именно Express на виндах.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582048
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa
И что, если бы у меня процессор был в несколько раз быстрее? Неужто от этого тот нехороший план стал бы хорошим?
Именно. Оптимизатор бы предпочитал "процессороёмкие" планы планам с множеством I/O.

Кстати, раз уж поставил на винду DB2, провёл небольшой эксперимент. Мне всегда было интересно, как сжатие файловой системы влияет на работу СУБД.
Дык вот, стандартное NTёвое сжатие директорий даёт примерно 2-2.5 раза выигрыша по месту - я сжимал только SQLT0002.0 , т.е. USERSPACE1 (SMS). В общем, вполне ожидаемо, скорость загрузки в таблицу уменьшилась раза в два.
Зато при запросах к большим таблицам с full scan'ами - наоборот, выигрыш в 2.5 раза.
Т.е. наверное, для всяких систем с преобладанием чтения - имеет смысл, тем более, что при использовании SMS можно указывать сжатие для отдельных таблиц без всякого выноса в отдельное табличное пространство :) Очень удобно для лентяев :)
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582784
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Configuration Advisor, для Warehouse с одним удалённым и одним локальеым пользователем, 80% на 2 гигах даёт:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
UPDATE DATABASE CONFIGURATION FOR TPCR USING APP_CTL_HEAP_SZ  128 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING APPGROUP_MEM_SZ         11595 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING CATALOGCACHE_SZ  260 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING CHNGPGS_THRESH   70 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DBHEAP           600 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOCKLIST         50 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGBUFSZ         132 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGFILSIZ        1024 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGPRIMARY       12 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING LOGSECOND        0 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING MAXAPPLS         40    MAXLOCKS     17 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING MINCOMMIT        1 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING NUM_IOCLEANERS   1 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING NUM_IOSERVERS    4 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING PCKCACHESZ       1114 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING SOFTMAX          600 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING SORTHEAP         9552 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING STMTHEAP         2048 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DFT_DEGREE      ANY;
UPDATE DATABASE CONFIGURATION FOR TPCR USING DFT_PREFETCH_SZ  64 ;
UPDATE DATABASE CONFIGURATION FOR TPCR USING UTIL_HEAP_SZ     79032 ;
UPDATE DATABASE MANAGER CONFIGURATION USING SHEAPTHRES          57315 ;
UPDATE DATABASE MANAGER CONFIGURATION USING INTRA_PARALLEL     OFF;
UPDATE DATABASE MANAGER CONFIGURATION USING MAX_QUERYDEGREE     1 ;
UPDATE DATABASE MANAGER CONFIGURATION USING MAXAGENTS           400 ;
UPDATE DATABASE MANAGER CONFIGURATION USING NUM_POOLAGENTS      400 ;
UPDATE DATABASE MANAGER CONFIGURATION USING NUM_INITAGENTS      0 ;
UPDATE DATABASE MANAGER CONFIGURATION USING FCM_NUM_BUFFERS     4096 ;
UPDATE DATABASE MANAGER CONFIGURATION USING PRIV_MEM_THRESH         32767 ;
CONNECT TO TPCR;
ALTER BUFFERPOOL IBMDEFAULTBP SIZE  237098 ;
SET CURRENT QUERY OPTIMIZATION =  7 ;
COMMIT;
CONNECT RESET;
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582787
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где CPUSPEED = -1, это 3,306410e-007.
Попробовал CPUSPEED из 1E-003 1E-004 1E-005 1E-006 6E-007 5E-007 4E-007 -1.
Отложил на завтра 3E-007 2E-007 1E-007.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582788
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Получилось так:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
    1E- 003  _1      24 , 562        24 , 469        24 , 343  
    1E- 004  _1      24 , 390        24 , 485        24 , 375  
    1E- 005  _1      24 , 609        24 , 266        24 , 390  
    1E- 006  _1      24 , 578        24 , 453        24 , 437  
    6E- 007  _1      24 , 500        24 , 641        24 , 422  
    5E- 007  _1      25 , 156        25 , 172        25 , 141  
    4E- 007  _1      24 , 875        25 , 062        24 , 937  
        - 1  _1      25 , 125        24 , 968        25 , 125  
--------------------------------------------
    1E- 003  _2       7 , 672         0 , 094         0 , 094  
    1E- 004  _2       7 , 938         0 , 109         0 , 094  
    1E- 005  _2       6 , 860         0 , 125         0 , 109  
    1E- 006  _2       6 , 812         0 , 109         0 , 110  
    6E- 007  _2       6 , 610         0 , 110         0 , 110  
    5E- 007  _2       6 , 718         0 , 110         0 , 125  
    4E- 007  _2     357 , 125       357 , 610       360 , 016  
        - 1  _2     360 , 687       361 , 031       361 , 688  
--------------------------------------------
    1E- 003  _3      17 , 782        14 , 984        14 , 938  
    1E- 004  _3      17 , 828        15 , 000        15 , 047  
    1E- 005  _3      17 , 875        15 , 172        15 , 140  
    1E- 006  _3      20 , 562        18 , 906        19 , 828  
    6E- 007  _3      21 , 281        19 , 938        20 , 390  
    5E- 007  _3      21 , 172        19 , 829        20 , 718  
    4E- 007  _3      20 , 547        19 , 515        19 , 938  
        - 1  _3      20 , 531        18 , 891        19 , 828  
--------------------------------------------
    1E- 003  _4      22 , 968        20 , 797        22 , 438  
    1E- 004  _4      22 , 750        21 , 469        22 , 141  
    1E- 005  _4      22 , 797        20 , 750        22 , 250  
    1E- 006  _4      22 , 688        21 , 531        22 , 078  
    6E- 007  _4      22 , 797        20 , 531        22 , 328  
    5E- 007  _4      22 , 844        20 , 468        22 , 313  
    4E- 007  _4      22 , 828        20 , 704        22 , 328  
        - 1  _4      22 , 765        20 , 578        22 , 250  
--------------------------------------------
    1E- 003  _5     224 , 687        27 , 922        28 , 219  
    1E- 004  _5      22 , 890        20 , 860        21 , 968  
    1E- 005  _5      23 , 360        21 , 828        22 , 172  
    1E- 006  _5      22 , 625        21 , 515        21 , 828  
    6E- 007  _5      22 , 766        20 , 656        21 , 953  
    5E- 007  _5      22 , 734        21 , 469        21 , 750  
    4E- 007  _5      22 , 594        21 , 359        21 , 797  
        - 1  _5      22 , 641        21 , 437        21 , 906  
--------------------------------------------
    1E- 003  _6     858 , 500         1 , 343         1 , 344  
    1E- 004  _6      17 , 250         1 , 125         1 , 110  
    1E- 005  _6      20 , 609         1 , 954         1 , 953  
    1E- 006  _6      20 , 516         1 , 969         2 , 000  
    6E- 007  _6      20 , 640         1 , 985         1 , 969  
    5E- 007  _6      20 , 437         1 , 969         1 , 937  
    4E- 007  _6      20 , 265         1 , 954         1 , 938  
        - 1  _6      20 , 062         1 , 953         1 , 985  
--------------------------------------------
    1E- 003  _7    1170 , 547       884 , 156       965 , 016  
    1E- 004  _7      22 , 469        20 , 188        21 , 093  
    1E- 005  _7      17 , 938        15 , 125        15 , 078  
    1E- 006  _7      20 , 844        16 , 422        16 , 031  
    6E- 007  _7      21 , 469        17 , 125        15 , 766  
    5E- 007  _7      21 , 859        16 , 953        15 , 828  
    4E- 007  _7      20 , 593        15 , 953        15 , 204  
        - 1  _7      20 , 688        16 , 453        15 , 234  
--------------------------------------------
    1E- 003  _8     280 , 578         0 , 391         0 , 422  
    1E- 004  _8     280 , 875         0 , 391         0 , 422  
    1E- 005  _8     278 , 062         0 , 766         0 , 797  
    1E- 006  _8     280 , 078         0 , 781         0 , 812  
    6E- 007  _8     280 , 453         0 , 734         0 , 766  
    5E- 007  _8     277 , 156         0 , 766         0 , 828  
    4E- 007  _8     276 , 062         0 , 750         0 , 734  
        - 1  _8     276 , 594         0 , 765         0 , 766  
--------------------------------------------
    1E- 003  _9      20 , 484        15 , 938        15 , 843  
    1E- 004  _9      20 , 484        15 , 907        15 , 859  
    1E- 005  _9      20 , 797        16 , 297        16 , 281  
    1E- 006  _9      20 , 625        16 , 313        16 , 265  
    6E- 007  _9      20 , 766        16 , 328        16 , 297  
    5E- 007  _9      20 , 750        16 , 360        16 , 234  
    4E- 007  _9      20 , 625        16 , 250        16 , 235  
        - 1  _9      20 , 640        16 , 281        16 , 250  
--------------------------------------------
    1E- 003   10       44 , 625         1 , 047         1 , 015  
    1E- 004   10       40 , 266         1 , 031         1 , 047  
    1E- 005   10       29 , 859         1 , 157         1 , 109  
    1E- 006   10       29 , 938         1 , 125         1 , 156  
    6E- 007   10       30 , 453         1 , 094         1 , 109  
    5E- 007   10       30 , 453         1 , 156         1 , 156  
    4E- 007   10       30 , 547         1 , 110         1 , 109  
        - 1   10       29 , 203         1 , 125         1 , 125  
--------------------------------------------
    1E- 003   11      149 , 578         0 , 125         0 , 125  
    1E- 004   11      150 , 344         0 , 125         0 , 141  
    1E- 005   11      128 , 406         0 , 156         0 , 204  
    1E- 006   11      128 , 578         0 , 172         0 , 172  
    6E- 007   11      128 , 703         0 , 141         0 , 140  
    5E- 007   11      128 , 547         0 , 157         0 , 140  
    4E- 007   11      128 , 172         0 , 156         0 , 172  
        - 1   11      128 , 766         0 , 171         0 , 235  
--------------------------------------------
    1E- 003   12       26 , 235         0 , 453         0 , 468  
    1E- 004   12       26 , 313         0 , 468         0 , 485  
    1E- 005   12       26 , 437         0 , 500         0 , 516  
    1E- 006   12       26 , 500         0 , 547         0 , 515  
    6E- 007   12       26 , 484         0 , 516         0 , 500  
    5E- 007   12       27 , 235         0 , 469         0 , 515  
    4E- 007   12       26 , 390         0 , 485         0 , 500  
        - 1   12       26 , 516         0 , 484         0 , 547  
--------------------------------------------
    1E- 003   13      283 , 015         2 , 313         2 , 297  
    1E- 004   13        4 , 781         2 , 609         2 , 625  
    1E- 005   13        4 , 875         2 , 812         2 , 844  
    1E- 006   13        4 , 828         2 , 860         2 , 844  
    6E- 007   13        4 , 859         2 , 860         2 , 781  
    5E- 007   13        5 , 141         2 , 891         3 , 093  
    4E- 007   13        4 , 735         2 , 844         2 , 859  
        - 1   13        4 , 797         2 , 828         2 , 813  
--------------------------------------------
    1E- 003   14       32 , 719         0 , 359         0 , 375  
    1E- 004   14       32 , 453         0 , 375         0 , 375  
    1E- 005   14       32 , 563         0 , 406         0 , 406  
    1E- 006   14       32 , 891         0 , 406         0 , 422  
    6E- 007   14       32 , 906         0 , 391         0 , 422  
    5E- 007   14       32 , 719         0 , 421         0 , 391  
    4E- 007   14       33 , 313         0 , 375         0 , 437  
        - 1   14       33 , 266         0 , 391         0 , 422  
--------------------------------------------
    1E- 003   15       26 , 843         0 , 672         0 , 688  
    1E- 004   15       26 , 718         0 , 719         0 , 688  
    1E- 005   15       27 , 032         0 , 750         0 , 750  
    1E- 006   15       26 , 672         0 , 797         0 , 750  
    6E- 007   15       26 , 891         0 , 719         0 , 750  
    5E- 007   15       26 , 937         0 , 719         0 , 750  
    4E- 007   15       26 , 672         0 , 735         0 , 718  
        - 1   15       26 , 890         0 , 750         0 , 735  
--------------------------------------------
    1E- 003   16        2 , 266         0 , 719         0 , 718  
    1E- 004   16        2 , 297         0 , 735         0 , 734  
    1E- 005   16        2 , 453         0 , 812         0 , 797  
    1E- 006   16        1 , 344         0 , 797         0 , 797  
    6E- 007   16        1 , 391         0 , 781         0 , 813  
    5E- 007   16        1 , 343         0 , 797         0 , 782  
    4E- 007   16        1 , 328         0 , 782         0 , 797  
        - 1   16        1 , 344         0 , 781         0 , 781  
--------------------------------------------
    1E- 003   17       42 , 062         0 , 079         0 , 078  
    1E- 004   17       42 , 812         0 , 094         0 , 078  
    1E- 005   17       42 , 078         0 , 078         0 , 079  
    1E- 006   17       42 , 453         0 , 438         0 , 453  
    6E- 007   17       42 , 485         0 , 422         0 , 500  
    5E- 007   17       42 , 282         0 , 421         0 , 454  
    4E- 007   17       42 , 344         0 , 437         0 , 422  
        - 1   17       42 , 047         0 , 422         0 , 438  
--------------------------------------------
    1E- 003   18       18 , 969        14 , 344        13 , 703  
    1E- 004   18       18 , 906        14 , 797        13 , 937  
    1E- 005   18       18 , 953        13 , 359        13 , 828  
    1E- 006   18       16 , 234        16 , 094        16 , 203  
    6E- 007   18       16 , 328        16 , 094        16 , 109  
    5E- 007   18       16 , 313        16 , 125        16 , 125  
    4E- 007   18       16 , 125        16 , 140        16 , 094  
        - 1   18       16 , 219        16 , 250        16 , 047  
--------------------------------------------
    1E- 003   19       96 , 844         0 , 031         0 , 031  
    1E- 004   19       97 , 406         0 , 047         0 , 031  
    1E- 005   19       97 , 312         0 , 031         0 , 031  
    1E- 006   19       97 , 390         0 , 047         0 , 031  
    6E- 007   19       97 , 141         0 , 031         0 , 031  
    5E- 007   19       96 , 891         0 , 031         0 , 031  
    4E- 007   19       96 , 703         0 , 031         0 , 031  
        - 1   19       95 , 828         0 , 016         0 , 031  
--------------------------------------------
    1E- 003   20       68 , 125         0 , 063         0 , 078  
    1E- 004   20       69 , 766         0 , 078         0 , 063  
    1E- 005   20       69 , 578         0 , 094         0 , 078  
    1E- 006   20       43 , 516         0 , 094         0 , 109  
    6E- 007   20       43 , 047         0 , 078         0 , 094  
    5E- 007   20       45 , 062         0 , 078         0 , 078  
    4E- 007   20       46 , 140         0 , 078         0 , 078  
        - 1   20       45 , 969         0 , 109         0 , 078  
--------------------------------------------
    1E- 003   21       29 , 937        21 , 594        21 , 531  
    1E- 004   21       28 , 109        21 , 703        21 , 610  
    1E- 005   21       27 , 812        21 , 829        21 , 750  
    1E- 006   21       27 , 703        21 , 750        21 , 672  
    6E- 007   21       28 , 015        21 , 641        21 , 703  
    5E- 007   21       28 , 031        21 , 672        21 , 562  
    4E- 007   21       27 , 781        21 , 656        21 , 609  
        - 1   21       27 , 750        21 , 640        21 , 594  
--------------------------------------------
    1E- 003   22        2 , 766         1 , 859         1 , 844  
    1E- 004   22        2 , 953         2 , 016         2 , 000  
    1E- 005   22        2 , 984         2 , 032         2 , 000  
    1E- 006   22        2 , 718         2 , 312         2 , 282  
    6E- 007   22        2 , 734         2 , 266         2 , 359  
    5E- 007   22        2 , 750         2 , 281         2 , 313  
    4E- 007   22        2 , 719         2 , 266         2 , 328  
        - 1   22        2 , 718         2 , 297         2 , 297  
--------------------------------------------
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582792
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я также генерировал планы, вырезая из них Estimated Cost.

main.rex
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
p = '1E-003 1E-004 1E-005 1E-006 6E-007 5E-007 4E-007 -1'
do q= 1  to words(p)
  w = word(p, q)
  cmd = 'db2 UPDATE DBM CFG USING CPUSPEED 'w' IMMEDIATE'
  cmd
  call test.rex w
end
'erase *xxx*'
fi. 0  = words(p)
do q= 1  to fi. 0 
  w = word(p, q)
  fi.q = w'\result.txt'
  call stream fi.q, 'c', 'open read'
  say fi.q
end
fo = 'result.txt'
'erase 'fo
call stream fo, 'c', 'open write'

do while lines(fi. 1 )> 0 
  do q= 1  to fi. 0 
    l = linein(fi.q)
    call lineout fo, right('     '||word(p,q),  10 ) l
  end
  call lineout fo, '--------------------------------------------'
end
do q= 1  to fi. 0 
  call stream fi.q, 'c', 'close'
end
call stream fo, 'c', 'close'

test.rex
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
parse arg exptgtdir

md exptgtdir
fo = exptgtdir'\result.txt'
'erase 'fo
call stream fo, 'c', 'open write'
do i= 1  to  22 
  say i i i i i i i i
  sql = i'.sql'
  targetn = '_'i'_xxx'
  'copy 'sql'+'sql'+'sql targetn'.sql'
  'db2stop force'
  'db2start'
  'db2batch -d tpcr -f 'targetn'.sql  -r 'targetn'.log1,'targetn'.log2 -v on -t ;'

  exp=targetn'.exp'
  exp1=exptgtdir'\'targetn'.exp'
  'erase 'exp
  'erase 'exp1

  'db2expln -d tpcr -f 'sql' -i -o 'exp' -z ;'
  call stream exp, 'c', 'open read'
  call stream exp1, 'c', 'open write'
  do while lines(exp)> 0 
    l = translate(linein(exp),'  ', '0d0a'x)
    if substr(l, 1 ,length('Estimated Cost'))\='Estimated Cost' then
      call lineout exp1, l
  end
  call stream exp, 'c', 'close'
  call stream exp1, 'c', 'close'
  

  fi = targetn'.log2'
  call stream fi, 'c', 'open read'
  do j =  1  to  6 
    l = linein(fi)
  end
  s = right('_'||i, 2 )
  do j =  1  to  3 
    l = linein(fi)
    s = s || substr(l, 17 , 12 )
  end
  call lineout fo, s
  call stream fi, 'c', 'close'
end
call stream fo, 'c', 'close'

...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582794
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Планы довольно часто разные, но результаты сходные. Видимых аномалий не так уж много...
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33582807
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33583911
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Резюме то какое?
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33584149
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А какое резюме вы ждёте? К тому же, я ещё для нескольких CPUSPEED прогон не сделал.

Ожидаю, что если вы поставите CPUSPEED в значение вроде 6E-007, второму запросу должно сильно получшеть, а остальным - практически без разницы, по сравнению с вашими результатами.

(Зато мои UPDATE CONFIGURATION повлияют на другие запросы, хотя они и сгенерированы Configuration Adviser'ом, а не подобраны вручную).

В общем, DB2 выступила хуже, чем я думал. Но у FB она, мне кажется, всё же должна выиграть практически везде, если сменить правила игры (напр., разрешить любые индексы, расположить базу на 4-х дисках..., ибо именно для того у "тяжёлых" СУБД столько "ручек"). Вот DB2 vs Oracle беспокоит больше.

Мне очень не нравятся, например, 8-й и 11-й запросы на первом прогоне. Надо попытаться понять, почему так получилось.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33584540
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да я и не собирался сравнивать Db2 с FB2, ясно что DB2 обладает большими возможностями и максимальной производительностью. А вот ORA/MS - есть смысл бодаться. Резюме я вижу в в виде заметки в факе и проблемах с CPUSPEED и способах решения.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33584685
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Victor Metelitsa, а что не так с 11м запросом?
~8с первое выполнение, и примерно .8-1.2 -последующие.
У оракла, вроде бы, не лучше.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33584819
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати, обратил внимание на разброс в 6-10 раз по времени выполнения на двух разных машинах с Ораклом.
Запрос #20 - я считаю, вообще ни в какие ворота не лезет :) Наверное, на второй (с 2ГБ) всё просто в памяти сидит. Хотя там и первое выполнение в 5 раз быстрее.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33585472
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
olegloaРезюме я вижу в в виде заметки в факе и проблемах с CPUSPEED и способах решения.

На самом деле, мне ещё непонятно, что писать (не говоря о том, что непонятно даже, куда писать). Да, мы видим цифры, но максимум, что я могу, это предложить админу погонять приведённые ранее тесты и посмотреть, как выполняется запрос номер два. По-хорошему, эти результаты надо было бы обсудить с людьми из Торонто.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33585478
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeVictor Metelitsa, а что не так с 11м запросом?
~8с первое выполнение, и примерно .8-1.2 -последующие.
У оракла, вроде бы, не лучше.

Вот что приводил я.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
    1E- 003   11      149 , 578         0 , 125         0 , 125  
    1E- 004   11      150 , 344         0 , 125         0 , 141  
    1E- 005   11      128 , 406         0 , 156         0 , 204  
    1E- 006   11      128 , 578         0 , 172         0 , 172  
    6E- 007   11      128 , 703         0 , 141         0 , 140  
    5E- 007   11      128 , 547         0 , 157         0 , 140  
    4E- 007   11      128 , 172         0 , 156         0 , 172  
        - 1   11      128 , 766         0 , 171         0 , 235  

Чем ваш конфиг отличается от моего? А если ссылаетесь на результаты Олега, то, наверное, там SMS tablespace с включённым кешированием ОС, а я, как вы могли видеть, использовал DMS.

Пока попробую поиграть с prefetch size - может, явное задание поменяет картину.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33585484
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kmikeКстати, обратил внимание на разброс в 6-10 раз по времени выполнения на двух разных машинах с Ораклом.
Запрос #20 - я считаю, вообще ни в какие ворота не лезет :) Наверное, на второй (с 2ГБ) всё просто в памяти сидит. Хотя там и первое выполнение в 5 раз быстрее.
Процессоры разные, диски разные, количество памяти разное. Если вы приглядитесь, то и у меня на одной и той же машине, одном и том же диске, хотя не на 100% совпадающими настройками, почему-то ускорился запрос #2 на первом проходе. Сперва я показал

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Summary of Results
==================
                Elapsed             Agent CPU         Rows      Rows
Statement #     Time (s)            Time (s)          Fetched   Printed
 1                       8 , 234        Not Collected        100         100 
 2                       0 , 109        Not Collected        100         100 
 3                       0 , 110        Not Collected        100         100 

Arith. mean      2 , 818           
Geom.  mean      0 , 462           
а потом
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
    1E- 003  _2       7 , 672         0 , 094         0 , 094  
    1E- 004  _2       7 , 938         0 , 109         0 , 094  
    1E- 005  _2       6 , 860         0 , 125         0 , 109  
    1E- 006  _2       6 , 812         0 , 109         0 , 110  
    6E- 007  _2       6 , 610         0 , 110         0 , 110  
    5E- 007  _2       6 , 718         0 , 110         0 , 125  
    4E- 007  _2     357 , 125       357 , 610       360 , 016  
        - 1  _2     360 , 687       361 , 031       361 , 688  

При этом в первый раз CPUSPEED=5E-007 был плох, а во второй раз - хорош.
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33585599
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Игры с префетчем многого не дают.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
          4  _1      25 , 625        27 , 265        26 , 547  
 AUTOMATIC _1      24 , 500        24 , 641        24 , 422  
       1024  _1      26 , 657        25 , 312        25 , 891  
--------------------------------------------
          4  _2      10 , 984         0 , 094         0 , 110  
 AUTOMATIC _2       6 , 610         0 , 110         0 , 110  
       1024  _2       6 , 562         0 , 109         0 , 093  
--------------------------------------------
          4  _3      39 , 296        35 , 125        38 , 438  
 AUTOMATIC _3      21 , 281        19 , 938        20 , 390  
       1024  _3      20 , 031        18 , 922        19 , 093  
--------------------------------------------
          4  _4      56 , 703         0 , 422         0 , 422  
 AUTOMATIC _4      22 , 797        20 , 531        22 , 328  
       1024  _4      20 , 109        19 , 516        19 , 734  
--------------------------------------------
          4  _5      57 , 640         1 , 016         1 , 000  
 AUTOMATIC _5      22 , 766        20 , 656        21 , 953  
       1024  _5      20 , 657        20 , 046        20 , 032  
--------------------------------------------
          4  _6      27 , 531         2 , 062         2 , 032  
 AUTOMATIC _6      20 , 640         1 , 985         1 , 969  
       1024  _6      17 , 110         1 , 968         1 , 954  
--------------------------------------------
          4  _7      33 , 781        23 , 454        23 , 703  
 AUTOMATIC _7      21 , 469        17 , 125        15 , 766  
       1024  _7      18 , 922        15 , 641        14 , 297  
--------------------------------------------
          4  _8     280 , 531         0 , 766         0 , 813  
 AUTOMATIC _8     280 , 453         0 , 734         0 , 766  
       1024  _8     283 , 047         0 , 782         0 , 796  
--------------------------------------------
          4  _9      23 , 610        18 , 609        17 , 969  
 AUTOMATIC _9      20 , 766        16 , 328        16 , 297  
       1024  _9      20 , 906        16 , 219        16 , 297  
--------------------------------------------
          4   10       33 , 718         1 , 125         1 , 157  
 AUTOMATIC  10       30 , 453         1 , 094         1 , 109  
       1024   10       30 , 250         1 , 094         1 , 156  
--------------------------------------------
          4   11      114 , 969         0 , 141         0 , 203  
 AUTOMATIC  11      128 , 703         0 , 141         0 , 140  
       1024   11      123 , 922         0 , 140         0 , 157  
--------------------------------------------
          4   12       24 , 781        16 , 063        15 , 890  
 AUTOMATIC  12       26 , 484         0 , 516         0 , 500  
       1024   12       20 , 516         0 , 484         0 , 531  
--------------------------------------------
          4   13        5 , 109         2 , 828         2 , 844  
 AUTOMATIC  13        4 , 859         2 , 860         2 , 781  
       1024   13        4 , 968         2 , 875         2 , 813  
--------------------------------------------
          4   14       16 , 828         0 , 407         0 , 407  
 AUTOMATIC  14       32 , 906         0 , 391         0 , 422  
       1024   14       24 , 375         0 , 375         0 , 453  
--------------------------------------------
          4   15       17 , 704         0 , 718         0 , 782  
 AUTOMATIC  15       26 , 891         0 , 719         0 , 750  
       1024   15       22 , 407         0 , 718         0 , 781  
--------------------------------------------
          4   16        1 , 875         0 , 782         0 , 813  
 AUTOMATIC  16        1 , 391         0 , 781         0 , 813  
       1024   16        1 , 391         0 , 812         0 , 781  
--------------------------------------------
          4   17       41 , 204         0 , 406         0 , 422  
 AUTOMATIC  17       42 , 485         0 , 422         0 , 500  
       1024   17       43 , 000         0 , 437         0 , 453  
--------------------------------------------
          4   18       18 , 110        18 , 218        17 , 531  
 AUTOMATIC  18       16 , 328        16 , 094        16 , 109  
       1024   18       16 , 469        16 , 172        15 , 984  
--------------------------------------------
          4   19       93 , 687         0 , 032         0 , 031  
 AUTOMATIC  19       97 , 141         0 , 031         0 , 031  
       1024   19       98 , 250         0 , 031         0 , 031  
--------------------------------------------
          4   20       46 , 484         0 , 078         0 , 078  
 AUTOMATIC  20       43 , 047         0 , 078         0 , 094  
       1024   20       45 , 578         0 , 079         0 , 078  
--------------------------------------------
          4   21       29 , 844        22 , 453        21 , 765  
 AUTOMATIC  21       28 , 015        21 , 641        21 , 703  
       1024   21       28 , 141        21 , 750        21 , 781  
--------------------------------------------
          4   22        3 , 125         2 , 265         2 , 344  
 AUTOMATIC  22        2 , 734         2 , 266         2 , 359  
       1024   22        2 , 687         2 , 265         2 , 344  
--------------------------------------------
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33972354
Фотография mv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfo
Ну зачем Вы так говорите?
1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - вопрос времени.
...

На днях был в одной конторе. Год назад обучал их админа делать бэкап/рестор для FireBird. Написал несложный bat - file и т.д. В общем, все получилось. Потом админ уволился, через какое-то время взяли нового. Который "ничего не трогал". Потом попытался рестор выполнить из бэкапа. Типа - вернуть данные на сутки назад. Ничего не изменилось. Оказалось, что база бэкапилась вовсе не рабочая, а та, что была рабочей полгода назад. Хорошо, что имена файлов у этой базы и у рабочей были разные, и данные не грохнулись..
Т.е. классно, конечно, что FireBird почти год крутился без присмотра и без проблем, но, с другой стороны, ничего хорошего...
...
Рейтинг: 0 / 0
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33993501
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И самое главное.... в тему к ветке
...
Рейтинг: 0 / 0
156 сообщений из 156, показаны все 7 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]