ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
25 сообщений из 156, страница 3 из 7
  3  все
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574220
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olegloa
Участник
Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса.
...
Рейтинг: 0 / 0
01.03.2006, 15:30
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574235
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
01.03.2006, 15:33
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574245
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
gardenman olegloaЗдесь уже привели ссылки на таблицы и метод генерации данных. Если есть трудности, то приду домой скопирую сюда одним скриптом метаданные.

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

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

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

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

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

Именно так. Все сервера работали на одинаковых метаданных.
...
Рейтинг: 0 / 0
01.03.2006, 15:43
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574327
olegloa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
olegloa
Участник
Да 80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш.
...
Рейтинг: 0 / 0
01.03.2006, 15:46
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574348
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
01.03.2006, 15:51
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574356
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Александр Гoлдун
Victor Metelitsa пишет:
> Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов
О, у меня тоже была идея для ASA проверить что насоветует Index
Consultant, но почему-то думал, что набор индексов жестко
регламентирован в TCP-R
Поэтому я создавать не стал. Но резервами поинтересовался.
...
Рейтинг: 0 / 0
01.03.2006, 15:53
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574371
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
olegloa Victor MetelitsaКстати, если кому-то интересно, Design Advisor насоветовал мне индексов для запроса #2 (но я их делать не буду, чтобы не выходить за рамки).

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

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

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

P.S. Может ты с данными прошибся - не тот объём влил. Потом есть одно но, у тебя другой набор сгенерированных данных :-), я же использовал один и тот же для всех серверов.
...
Рейтинг: 0 / 0
01.03.2006, 16:01
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574412
paper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
01.03.2006, 16:04
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574425
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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
01.03.2006, 16:07
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574442
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
И результат (не весь, но несколько в начале и конце, первую колонку) я сравнивал с эталонным. Вроде совпадает.
...
Рейтинг: 0 / 0
01.03.2006, 16:09
| Ответить | Цитировать | Написать  
Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
    #33574467
kmike
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kmike
Участник
Я понял, в чём у меня был косяк-я использовал скрипты для создания индексов из архива tpcrFB20.zip, поскольку не был уверен, что они совпадают с TPC-H.
Ну и в итоге не создал primary keys :)

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

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

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

Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)[/quot]
В BOL очень красиво и подробно расписан механизм чекпойнтов, действий сервера по восстановлению БД в случае аварийного завершения, но нет ни слова о том, как это коррелировано с производительностью (да и надежностью при сбоях тоже кстати). Так что будет чем заняться, когда свободное время появиться :)
...
Рейтинг: 0 / 0
01.03.2006, 16:39
| Ответить | Цитировать | Написать  
25 сообщений из 156, страница 3 из 7
  3  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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