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

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


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

Откуда:
Сообщений: 252
gardenman
Рассмотрим запрос:
   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 - определяет размер этого самого результирующего набора.



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

Есто возразить к тем логическим рассуждениям которые я привёл? Если я прошу отдать мне 100 записей и я их все 100 забираю, то какого я должен ещё делать какие-то телодвижения?
1 мар 06, 15:33    [2404496]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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

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


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


Я вначале подозревал именно это, но потом решил, что Олег, должно быть, делал базу из CC, а CC после создания предлагает вызвать Configuration Assistant, который буферный пул всё-таки таким маленьким не оставит. Но он секрета так и не выдал.
1 мар 06, 15:34    [2404509]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Ну, будем считать, что Configuration Adviser использовался. Хотя он вряд ли дал оптимальные настройки. Я тут на другое наткнулся, и ошизел (описание в следущем письме).
1 мар 06, 15:37    [2404538]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Александр Гoлдун
Member

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

Victor Metelitsa пишет:
> Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов

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

Posted via ActualForum NNTP Server 1.3

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

Откуда:
Сообщений: 252
80% отдавал. Если мне укажут отптимальные параметры для DB2 при условии невыхода за рамки теста(т.е. никаких подсказок и доп индексов), то я протестирую заного. Так же я готов оттестить DB2 vs ORA если будут конкретные рекомендации по доп. оптимизации указанного теста для DB2, разумеется с доп оптимизацией ORA c моей стороны. Надеюсь, что после этого все стороны будут довольны ;-);-);-)
1 мар 06, 15:41    [2404578]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

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

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


Именно так. Все сервера работали на одинаковых метаданных.
1 мар 06, 15:43    [2404597]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Да 80% ОЗУ не получил тока PG. Т.к. он на Win32 крутился по классической архитектуре - у него 20МБ было на кэш.
1 мар 06, 15:46    [2404617]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Итак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM, на ней DB2 ESE FP10 (не думаю, что с Express'ом должна быть какая-то разница).

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

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

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

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

начало

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,

конец

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

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

Victor Metelitsa пишет:
> Кстати, если кому-то интересно, Design Advisor насоветовал мне индексов
О, у меня тоже была идея для ASA проверить что насоветует Index
Consultant, но почему-то думал, что набор индексов жестко
регламентирован в TCP-R

Поэтому я создавать не стал. Но резервами поинтересовался.
1 мар 06, 15:53    [2404661]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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


Ну так что в итоге. Какой результат на 2-м запросе на исходных метаданных. Как у тебя влияет хинт optimize. Какие ещё настройки можно крутить для этого запроса.

Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу.
1 мар 06, 15:56    [2404682]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
А DFT_QUERYOPT считается настройкой?
Собрал статистику, переткнул DFT_QUERYOPT в 7.
real 0m1.663s
real 0m0.333s
real 0m0.320s

"Что это было?" :[ ]
1 мар 06, 15:57    [2404690]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
ASCRUS
Member

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

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

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

Victor Metelitsa

начало
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,

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

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

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

P.S. Может ты с данными прошибся - не тот объём влил. Потом есть одно но, у тебя другой набор сгенерированных данных :-), я же использовал один и тот же для всех серверов.
1 мар 06, 16:01    [2404724]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
paper
Member

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

Откуда: Тюмень
Сообщений: 2559
Источники таковы:

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

Откуда: Тюмень
Сообщений: 2559
И результат (не весь, но несколько в начале и конце, первую колонку) я сравнивал с эталонным. Вроде совпадает.
1 мар 06, 16:09    [2404779]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
kmike
Member

Откуда:
Сообщений: 286
Я понял, в чём у меня был косяк-я использовал скрипты для создания индексов из архива tpcrFB20.zip, поскольку не был уверен, что они совпадают с TPC-H.
Ну и в итоге не создал primary keys :)

Сейчас для чистоты эксперимента опробую Express на виндах.
1 мар 06, 16:15    [2404818]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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

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

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

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);

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

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;

Сперва создавал базу и таблицы, затем грузил данные, затем создавал индексы, затем собирал статистику.
1 мар 06, 16:19    [2404835]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Victor Metelitsa
Member

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

Optimize никак не повлиял, а судя по наличию hsjoin, может быть важен размер памяти для сортировок. Я помню, что для DSS они советовали его делать равным буферному пулу.

Кстати, есть SORTHEAP у базы и есть SHEAPTHRES у СУБД. Совет, как я помню, был поставить SHEAPTHRES = буферному пулу, а SORTHEAP в 4 раза меньше. Но я это не проверял.
1 мар 06, 16:24    [2404873]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Victor Metelitsa
Итак, я сейчас на работе, за машиной с Pentium3-850, диском WD 120 гиг, 512 мег RAM,

Кстати, а не считаетели Вы что для DSS теста это слишком много памяти (или слишком маленькая база)? Для базы со scalefactor = 1 (кажется так называется), оставьте хотя бы 128 метров, а то у вас самая большая таблица как бы вся в ОЗУ не поместилась.
1 мар 06, 16:25    [2404881]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
Про 18 символов не напоминай, матерился их обрезая что есть мочи.

Сount в таблицах выдай сюда. В приципе я могу повторно его прогнать - может и в правду что-то накосячил с параметрами БД.
1 мар 06, 16:29    [2404903]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
olegloa
Member

Откуда:
Сообщений: 252
[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей"[/quot]

Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)
1 мар 06, 16:37    [2404951]     Ответить | Цитировать Сообщить модератору
 Re: Предварительные результаты по тесту TPCR (YA/FB/ORA/MS/PG)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
olegloa
[quot ASCRUS"это явный косяк ASA с индексами при апдейте большого кол-ва записей"


Угу при тех настройках что он предлагает по умолчанию для чекпоинтов. Так что всё нормально, это действительно косяк. Т.к. ты же сам писал что или быстрое обновление или надёжность при сбоях :-). А статья нужна, ибо явной крреляции между обновлением индексированных столбцов и 2-х минутным интервалом как-то на глаз не просматривается. Или я плохо прищурился рассматривая ASA? :-):-):-)[/quot]
В BOL очень красиво и подробно расписан механизм чекпойнтов, действий сервера по восстановлению БД в случае аварийного завершения, но нет ни слова о том, как это коррелировано с производительностью (да и надежностью при сбоях тоже кстати). Так что будет чем заняться, когда свободное время появиться :)
1 мар 06, 16:39    [2404962]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить