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

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

Отличие табличных пространств DMS от SMS, кеширование ОС и ряд других вещей таково, что вы минимум не ухудшите выполнение пресловутого 23-го запроса на любых настройках.

Имею в виду результат замены SMS на DMS и т.п.
1 мар 06, 09:16    [2401884]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
Наверное, я всё же нифига не понимаю сути этого теста...

Там писали ( 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 диске.

Что я делаю не так?
1 мар 06, 10:53    [2402401]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
>Наверное, я всё же нифига не понимаю сути этого теста...

Потому что читать нужно всё ветку было. Это запрос вообще никакого отношения к тестам не имеет, а возник из-за трудностей с этим запросом на ASA в силу определённых настроек.
1 мар 06, 12:30    [2403151]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

В курсе, применительно к этому тесту особого эффекта не имели. Потом два раза одно и тоже говорить серверу выходило за рамки теста. Точно также как и ручное планирование в IB7.
1 мар 06, 12:33    [2403172]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
А.
Ну извиняйте, как говорится-не осилил потому что много букв.
И ещё раз извините.
1 мар 06, 12:33    [2403173]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Архив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.

К сообщению приложен файл (log.rar - 11Kb) cкачать
1 мар 06, 12:36    [2403198]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Ребята, вы только не забывайте про то, что тесты эти Олег проводил на своём энтузиазме прежде всего для себя и для узкой группы людей, которые тусуются в известной конференции.

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

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

А вобще-то на тестах никто не обделался особо кроме IB.
1 мар 06, 12:40    [2403239]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
>что кроме FETCH FIRST x ROWS ONLY внутри таких запросов весьма >желательно писать OPTIMIZE FOR n ROWS?

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


Это не одно и то же.
1 мар 06, 12:45    [2403277]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
Это время выполнения запроса?
Тогда с запросом 2 как-то плохо.
1 мар 06, 12:46    [2403281]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
Архив с результатами. Где здесь люди увидели явные проблемы у DB2 мне не понятно.

DB2 оказалась хуже Oracle. Чем не проблема?

;-)
1 мар 06, 12:51    [2403322]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
>Это не одно и то же

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

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 иная, то сами буратины :-).
1 мар 06, 12:56    [2403382]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
>Это время выполнения запроса?

Угу

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

У кого? :-), там их много.
1 мар 06, 12:58    [2403399]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
У DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.
1 мар 06, 13:07    [2403498]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
>
C точки зрения разработчика OPTIMIZE FOR n ROWS должно использоваться в обычных select когда требуется быстрый отклик при выборке первых n записей.

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


Логично ожидать именно такого поведения. Беда в том, что реализовано это не так. Об этом говорили сами ibm-еры в их ньюсгруппе.
1 мар 06, 13:10    [2403516]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Тогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

Согласись, что я не должен был проверять что термин "белое" в DB2 на самом деле означает "серое", и выяснить это можно в news-группе от разработчиков DB2. Написал "белое", так делайте его "белым", я прочее оставляйте для маркетинга и рекламы. Радует что "серость" наверно проявляется при обработке существенно больших объёмов данных чем у меня в тесте.
1 мар 06, 13:37    [2403672]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
kmike
У DB2.
План там красивый получается, что и говорить. У меня получилось 3m32.118 на этом запросе.


Порядок тот же, что и требовалось доказать. Так что притензии не ко мне а к IBM :-)
1 мар 06, 13:39    [2403686]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

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

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


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

Потом как только у меня возник косяк с ASA, я после того как один вечер пытался решить проблему сам спросил у общественности - "Где у меня кривизна в руках, а не заявил что ASA кривой в усмерть". Аналогично было и с другими серверами - мелкие проблемы решались изучением документации.
1 мар 06, 13:44    [2403719]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
olegloa
Тогда это ЯВНЫЙ косяк в DB2. Если он ещё и сильно влиял бы на таких небольших объёмах данных как в тесте, то это вообще было бы плохо.

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


Видите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.
1 мар 06, 14:08    [2403851]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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

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


Как я понимаю, опубликовать скрипты и настройки базы вы отказываетесь.
1 мар 06, 14:13    [2403880]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Здесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

Настройки - дефолтные для DB2. Поставил, настроил ODBC - работаю.
1 мар 06, 14:26    [2403954]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Victor Metelitsa
Видите ли, в документации сказано, что OPTIMIZE для подсказки оптимизатору, а FETCH FIRST для получения не более чем ... строк. То, что FETCH FIRST должен влечь OPTIMIZE - это всего лишь догадки. Фактически, никто этого не обещал.


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

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

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

P.S. Начёнм лепить хинты к DB2, я прилеплю хинты к ORA/MS/IB-клонам и что тогда?
1 мар 06, 14:35    [2404011]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Рассмотрим запрос:
   select * from tbl order by b fetch first 100 rows only

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

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


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

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

optimize for - говорит по скольку записей будет попадать на станцию из результирующего набора, который находится на сервере. Набор будет достраиваться динамически (в некоторых случаях).
fetch first - определяет размер этого самого результирующего набора.
1 мар 06, 14:46    [2404087]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
olegloa
Здесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

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


По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.
1 мар 06, 14:55    [2404180]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

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
1 мар 06, 15:08    [2404291]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
gardenman
[quot olegloa]По умолчанию у DB2 for Win размер буферпула 250 страниц (4КБ) , т.е. 1 мегабайт. Что там существенного вы можете намерять - я не знаю.


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

Если не в курсе подробностей, то пишите в оригинальную конфу.
1 мар 06, 15:27    [2404451]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить