Вопросик по партицированию..

Ден

Дата: 02.12.2009 12:56:15

есть табличка ~50млн записей
это прайс лист и 99% это чтение 1ой строки с ценой по группе по дате
Система генерирует такой sql запрос для получения цены:

SELECT BPITM, BPMCU, BPLOCN, BPLOTN, BPAN8, BPIGID, BPCGID, BPLOTG, BPFRMP, BPCRCD, BPUOM, BPEFTJ, BPEXDJ, BPUPRC, 
BPACRD, BPBSCD, BPFRMN FROM PRODDTA.F4106  WHERE  ( BPITM = 8280.000000 AND BPMCU = '         101' AND
 BPLOCN = '  ' AND BPLOTN = '  ' AND BPAN8 = 0.000000 AND BPIGID = 0.000000 AND BPCGID = 4.000000 ) 
  AND  ( BPEXDJ >= 109145 AND BPEFTJ <= 109145 AND BPBSCD = ' ' AND BPCRCD = 'RUB' AND BPUOM = 'EA' )  
  ORDER BY BPITM ASC,BPMCU ASC,BPLOCN ASC,BPLOTN ASC,BPAN8 ASC,BPIGID ASC,BPCGID ASC,BPLOTG ASC,BPFRMP ASC,BPCRCD ASC,BPUOM ASC,BPEXDJ ASC,BPUPMJ DESC,BPTDAY DESC

Этот запрос отрабатывает очень быстро (0.01сек) по текущим датам ~неделя (как я понимаю все блоки просто в памяти загружены), кол-во вызовов этого запроса >1млн. в час
Но иногда, этот же запрос запрашивает данные за давний период времени и тогда время его работы уже 10-15 сек при первом обращении. повторный запуск, уже снова 0.01 сек.
Как я понимаю мне уже давно пора партицировать таблицу эту, благо кроме этого запроса, других туда нету практически. Но будет ли существенный выигрыш, если я разобью эту таблицу на партиции, но физически они будут на одном физ. диске, который выделен под эту таблицу отдельно? Опыта с партицированными таблицами нету, так как раньше лицензия не позволяла эту возможность использовать-))

suPPLer

Дата: 02.12.2009 13:05:25

Ден,

как согласуются "99% это чтение 1ой строки" и

автор

SELECT ...
...
  ORDER BY ...

? Покажите, пожалуйста, план выполнения для хорошего и плохого варианта запросов. Укажите версию Oracle DB.

Ден

Дата: 02.12.2009 13:17:11

ну это особенности ядра JD Edwards, при генерации sql запроса он всегда делает order by по PK

CREATE UNIQUE INDEX "PRODDTA"."F4106_0" ON "PRODDTA"."F4106" ("BPITM", "BPMCU", "BPLOCN", "BPLOTN", "BPAN8", "BPIGID", "BPCGID", "BPLOTG", "BPFRMP", "BPCRCD", "BPUOM", "BPEXDJ", "BPUPMJ", "BPTDAY") TABLESPACE "PRODDTAI"

План что по хорошему, что по плохому запросу - одинаковый..

Plan hash value: 4254410008                                                                         
                                                                                                    
----------------------------------------------------------------------------------------            
| Id  | Operation                    | Name    | Rows  | Bytes | Cost (%CPU)| Time     |            
----------------------------------------------------------------------------------------            
|   0 | SELECT STATEMENT             |         |     1 |   212 |     2  (50)| 00:00:01 |            
|   1 |  SORT ORDER BY               |         |     1 |   212 |     2  (50)| 00:00:01 |            
|*  2 |   TABLE ACCESS BY INDEX ROWID| F4106   |     1 |   212 |     1   (0)| 00:00:01 |            
|*  3 |    INDEX RANGE SCAN          | F4106_4 |     1 |       |     1   (0)| 00:00:01 |            
----------------------------------------------------------------------------------------            
                                                                                                    
Predicate Information (identified by operation id):                                                 
---------------------------------------------------                                                 
                                                                                                    
   2 - filter("BPEXDJ">=109145 AND "BPEFTJ"<=109145 AND "BPBSCD"=U' ')                              
   3 - access("BPITM"=8280.000000 AND "BPMCU"=U'         101' AND "BPLOCN"=U'                       
              ' AND "BPLOTN"=U'  ' AND "BPAN8"=0.000000 AND "BPIGID"=0.000000 AND                   
              "BPCGID"=4.000000 AND "BPCRCD"=U'RUB' AND "BPUOM"=U'EA')

Но.. логи с сервера говорят, о другом времени выполнения плохого запроса..

Dec 02 09:42:42.479099 - 6864/5488 WRK:Starting jdeCallObject        	SELECT BPITM, BPMCU, BPLOCN, BPLOTN, BPAN8, BPIGID, BPCGID, BPLOTG, BPFRMP, BPCRCD, BPUOM, BPEFTJ, BPEXDJ, BPUPRC, BPACRD, BPBSCD, BPFRMN FROM PRODDTA.F4106  WHERE  ( BPITM = 8280.000000 AND BPMCU = '         101' AND BPLOCN = '  ' AND BPLOTN = '  ' AND BPAN8 = 0.000000 AND BPIGID = 0.000000 AND BPCGID = 4.000000 )  AND  ( BPEXDJ >= 109145 AND BPEFTJ <= 109145 AND BPBSCD = ' ' AND BPCRCD = 'RUB' AND BPUOM = 'EA' )  ORDER BY BPITM ASC,BPMCU ASC,BPLOCN ASC,BPLOTN ASC,BPAN8 ASC,BPIGID ASC,BPCGID ASC,BPLOTG ASC,BPFRMP ASC,BPCRCD ASC,BPUOM ASC,BPEXDJ ASC,BPUPMJ DESC,BPTDAY DESC 
Dec 02 09:42:54.604000 - 6864/5488 WRK:Starting jdeCallObject        	Exiting JDB_SelectKeyed with Success

видно что 12 сек выполнялся..

Ден

Дата: 02.12.2009 13:31:14

блин, версию забыл указать
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production Win2003 64bit

Добрый Э - Эх

Дата: 02.12.2009 13:41:08

Ден

Часто используемые блоки индексов и таблиц размешаются в кэше СУБД. Редко используемые или давно никому не нужные - вытесняются из кэша. Следовательно, если запрашиваются "оперативные" данные, то, скорее всего, они находятся в памяти и обращение за ними происходит быстро. Если же идет запрос "архивных" данных, то идет обращение к дисковой подсистеме, что и вызывает "тормоза" при первом обращении. При повторном обращении к этим же архивным данным уже происходит чтение из кэша - и запрос снова летает. Секционирование тут скорее всего не поможет. Проблема в том, что большую по размеру таблицу сервер один черт не сможет полностью держать в кэше. А уж цельная она будет или резанная на кусочки - дело десятое.

suPPLer

Дата: 02.12.2009 13:46:16

Ден,

а по какому полю Вы хотели партиционировать?

Ден

Дата: 02.12.2009 13:52:45

Добрый Э - Эх

ну всеравно, 12 сек, это очень долго, даже если блоки не в кэше.. при доступе по индексу к 1ой строке.. Ну а если разместить архивную партицию (данные старше 3мес) на другом канале и диске, то поидее запрос должен ускорится.. так как эти тормоза случаются в момент пиковой загрузки системы по утрам. сейчас этот запрос по архивным данным уже влет отрабатывает, все обедают. Просто если выносить партиции на различные диски, то нужно знать поможет ли, возможность объеденить 2 внешних дисковых массива в один есть , но это гемор, работа в выхи для админов. и если эффекта не будет, то обидно будет..

Ден

Дата: 02.12.2009 13:55:54

suPPLer

Ден,

а по какому полю Вы хотели партиционировать?

тоже вопрос -))
по дате, но там используется диапазон..
"BPEXDJ">=109145 AND "BPEFTJ"<=109145 дата начала действия цены и окончания..
скорее всего по BPEXDJ, так как BPEFTJ для текущих цен 2040 год, а для архивных= дате начала действия цены

andrey_anonymous

Дата: 02.12.2009 14:30:12

Ден

тормоза случаются в момент пиковой загрузки системы по утрам.
...
если эффекта не будет, то обидно будет..

Скорее всего не будет.
Снимите трассу 10046 level 8 с "плохого" запроса - есть мнение, что не ввода-вывода оно там ждет.

suPPLer

Дата: 02.12.2009 14:36:40

Ден

по дате, но там используется диапазон..
"BPEXDJ">=109145 AND "BPEFTJ"<=109145 дата начала действия цены и окончания..

Я в клингонских календарях не специалист... 109145 - это вроде число, не так ли?