Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
 Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
На 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 мне приконнектиться не удалось). Нет ли чего-то готового для других СУБД в других местах?
28 фев 06, 09:38    [2397414]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Что-то я там увидел тока новый начинающий какой-то форум по БД. Значительно уступающий данному. Таких "тестов" наверняка полно и здесь.
28 фев 06, 09:50    [2397465]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Хуже этого форума я ещё не видел. Но меня интересует ответ на конкретный вопрос, и не буду пренебрегать даже мизерным шансом.
28 фев 06, 09:56    [2397499]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
http://www.osdl.org/lab_activities/kernel_testing/osdl_database_test_suite//
Это open-source тестилка на SAP DB, правда.
http://www.quest.com/benchmark_factory/index.asp
Очень хорошая тестилка, одна проблема - глючная очень. :( И дорогая, кстати, безумно.
А тот тест, что Вы упомянули - я пробовал, но создать хоть сколько-нибудь серьезную нагрузку на железо им не удалось :(
28 фев 06, 10:02    [2397528]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
a_shats

А тот тест, что Вы упомянули - я пробовал

Как именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader?
28 фев 06, 10:32    [2397680]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Victor Metelitsa пишет:

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

Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.

Posted via ActualForum NNTP Server 1.3

28 фев 06, 12:04    [2398283]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.


Ну зачем Вы так говорите?
1) Если нет DBA хоть какого-то, то потеря БД не вопрос вероятности - вопрос времени.
2) Если по бизнесу хорошо, чтобы медленно работало, то нихай себе медленно что-то работает. Чего тогда вообще что-то тестить?
3) Если система не позволяет и с самыми продвинутыми DBA добиться нужного, то с точки зрения реального бизнеса (для которого позиция DBA в штатном расписнии не критично мягко говоря) это, возможно, тоже плохо.
28 фев 06, 12:37    [2398509]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

vadiminfo пишет:

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

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

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

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

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

Т.е. все что не нефть, газ и т.п. - не реальный бизнес?

Posted via ActualForum NNTP Server 1.3

28 фев 06, 13:03    [2398702]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Гoлдун

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

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

Александр Гoлдун

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

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

Александр Гoлдун

Т.е. все что не нефть, газ и т.п. - не реальный бизнес?

В нефти и газе - 2-3 тыс $ в месяц DBA смертельно?
28 фев 06, 14:10    [2399122]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
hvlad
Guest
Victor Metelitsa
На ibdeveloper.com я видел скомпилёное, но оно на вид годится только для Interbase/Firebird (во всяком случае, к DB2 мне приконнектиться не удалось).
Как вариант можно сгенерить БД в FB и перегнать данные в DB2
28 фев 06, 14:28    [2399245]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун

Victor Metelitsa пишет:
> Вообще, у
> "тяжелых" СУБД есть много рукояток, за которые можно повертеть,
Есть. Только стимость кручения этих ручек может вылиться в цифры
зарплаты отдельной позиции ххх-DBA в штатном расписании. Что может быть
и хорошо с локальной точки зрения спеца по этой самой ххх, а вот с точки
зрения бизнеса уже не так здорово.


А чего нам, спецам, плакать о бизнесе? Это "их" задача - заплатить поменьше, а наша задача - получить побольше. Поэтому, например, спецы по Oracle молодцы, а по Firebird/Interbase - вредители, рубящие сук, на котором сидят они сами и их коллеги. К счастью, у них пока не очень получается.
28 фев 06, 14:38    [2399311]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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


Разумеется. Хотя из текстовых файлов проще. Но вот если мне захочется повертеть в руках что-то незнакомое, типа MS SQL/Sybase/Informix/etc, лучше было бы иметь более удобное решение. Также и кому-то с DB2.
28 фев 06, 14:43    [2399346]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
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 записей вставить, получив переполнение циклического лога ;)
28 фев 06, 17:15    [2400328]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Victor Metelitsa
Как именно? нашёлся dbgen for Oracle, или вы просто воспользовались сгенерированными файлами и грузили через sqlloader?

Насчет TPC-R не знаю, но dbgen для TPC-H я с сайта www.tpc.org утянул и с помощью него базу сгенерировал. Правда для MS SQL. Там в ней define'ы насколько я помню есть чего под какую базу генерить. Правда почему-то тот архив, который я скачал у меня под VC не собрался, пришлось пару строчек в коде править. И генератор запросов там же есть, насколько я помню. Если, конечно, Вы имеете ввиду тоже, что и я. :)
28 фев 06, 18:39    [2400732]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Господа DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ.

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

Специалист по ASA пусть объяснит почему другие специалисты из Sybase установили интервал допустимого восстановления базы после сбоя по умолчанию что update указанные мной в комментариях выполнялся так долго.
(Для справки я изменил этот параметр и уложился в час)
1 мар 06, 01:04    [2401542]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
ASCRUS
IMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем


Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)
1 мар 06, 01:11    [2401548]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
olegloa

Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)

Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть. Пожалуста, скажите здесь кем ставился тест. Все его награды, грамоты опишите. А если не трудно и про результат скажите теста скажите. Как он соотносится с TPC, где, насколько я слышал настраивают представители фирм производителей. А то что один Оракл обгоняет другого я наблюдал, хотя парни не первый день с Ораклом работали.
1 мар 06, 01:35    [2401558]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
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 он не имеет отношения. А если уж и припрет раз в год, то можно и индексы дропнуть :)
1 мар 06, 02:00    [2401571]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
vadiminfo

Где смотреть то? На news://news.gmane.org/gmane.comp.db.firebird.russian? Там стремно что-либо смотреть.

Кусаются?
vadiminfo

Все его награды, грамоты опишите

Не стоит беспокойства, Oracle в сумме выиграл у всех, даже у ASA, проиграв ему всего лишь в 6 запросах из 22
1 мар 06, 02:17    [2401577]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
olegloa
ASCRUS
IMHO мое мнение тесты конечно же некорректны, потому как запускались для СУБД не специалистами и DBA тут не при чем


Угу, особенно "неспециалистом" ставился тест над YA/FB/IB/ORA. Ты бы хоть посмотрел кто тест опубликовал :-) :-) :-)

Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я бы вообще столько индексов в структуре не стал создавать для ASA.

P.S. Ну а почему дефолтные настройки в ASA выставлены на 2 минуты восстановления базы после запуска при обнаружении случая аварийного завершения - так это правильно. Кто знает - тот и поставит столько, сколько нужно. Кто не знает - значит сервер сам должен обеспечить максимальную скорость поднятия базы с откатом транзакций. Тем более что это не влияет на вставки, удаления и короткие апдейты, только на длинные апдейты, где апдейтом захватываются миллионы записей и это порождает много грязных страниц и переноса оригинальных страниц в Checkpoint log. Вот для таких случаев как раз параметрами и можно перевести БД в режим снижения частоты записи грязных страниц, увеличив скорость апдейта и соотвествующе увеличив время восстановления состояния БД, если бы на момент длинного апдейта сервер уронили. Кстати в ASA много чего установлено по умолчанию на скоростную загрузку БД при старте сервера - к примеру кэш часто используемых данных и наилучших планов запросов так же в БД по мере минимальной загрузки сервера пишется - то есть при перезапуске сервера он поднимет последние лучшие планы запросов и страницы данных в кэш, таким образом сразу же начав эффективно работать без повторного набора в кэш данных и с нуля вычислений всех планов запросов - этакий аналог режима hypernate. Тоже можно отключить, если скорость максимальной отдачи сразу с запуска БД не важна.
1 мар 06, 07:05    [2401677]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
Господа DBA, не нужно думать что тест производил полный ламер :-). Настройками сервера вы результаты простых select в разы не увеличите. По условиям теста, никакие специфичные веще типа кластерных индексов, секционирования и т.п. не допускались. БД создавалсиь на выделеном разделе диска, т.е. железо было действительно одинаково для всех тестов. Данные заливались из эталонных таблиц, производился сбор статистики и прочие операции по минимальной оптимизации БД перед тестов индивидуально для каждого сервера. Кто мог использовал до 80% от ОЗУ.


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

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

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

Ну и, конечно, если вас не интересуют "специфичные веще типа кластерных индексов, секционирования и т.п.", то меня очень даже.
1 мар 06, 08:23    [2401765]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
>Я знаю, кто этот тест опубликовал. Но согласись Олег - изначально тест >заточен под IB сервера - достаточно простые запросы в ANSI, хранимки в >стиле IB, куча индексов, которая как раз для Rule-Based оптимизаторов - я >бы вообще столько индексов в структуре не стал создавать для ASA.

Никаких SP и прочей шелухи. Все запросы переписаны на view, и были приведены в первом сообщении с результатами. Так что никаких заточек под IB. Индексов не куча, а ровно столько, сколько было бы создано большинстовм при таких запросах. Могу оставить одни PK :-) и повторить тест для ASA, тока боюсь он его вообще не закончит никогда.
1 мар 06, 08:30    [2401780]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

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

Никто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже
1 мар 06, 08:32    [2401784]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
Никто не собирался специально подстраивать БД под 22 запроса которые выполнялись в тесте. Т.к. даже если ты специально задашь настройки которые оригинально будут улучшать раьботму серевера на этих 22-х запросах, я тут же выдам тебе 23 запрос который будут работать на твоих настройках хуже


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

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

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

Кроме того, наш с вами интерес к этим тестам имеет разную природу.
1 мар 06, 08:50    [2401822]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
Чёйта я не понял, чё такое этот TPCR. TPC-H знаю, dbgen к нему есть. 22 запроса.

Это оно и есть?
1 мар 06, 09:09    [2401863]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить