Привет Всем !
IDS 9.21
Решил уйти от фрагментации таблицы BY ROUND ROBIN.
Сделал фрагментацию по выражению.
Перевел данные и индексы на разные диски.
Индексы заработали намного быстрее, но только если передавать в запрос константу.
В случае , когда процедура работает с переменными, она, похоже, индексов не видит вообще !
Выполняется более 30 сек !
А, если внутри этой же процедуры в конкретном запросе подставляю постоянные значения,
то процедура отрабатывает за доли секунды.

Где- то говорили, что можно ввести эти переменные во временные таблицы,
но для этого надо менять все процедуры (их около 100).
Что предложите, кроме как изменять все хранимые процедуры ?

Так ведь хинты проставлять - это надо все процедуры перелопатить !!!!
Как ускорить процесс ?
-------------------------------------
структура Таблицы:

create table 'informix'.ihzv (
idzv SERIAL not null,
.
.
.

)
fragment by expression ((MONTH (data ) >= 1 ) AND (MONTH (data ) <= 3 ) ) in data_dbs1, ((MONTH (data ) >= 4 ) AND (MONTH (data ) <= 6 ) ) in data_dbs2, ((MONTH (data ) >= 7 ) AND (MONTH (data ) <= 9 ) ) in data_dbs3, ((MONTH (data ) >= 10 ) AND (MONTH (data ) <= 12 ) ) in data_dbs4
extent size 512000 next size 640
lock mode row;
create index 'informix'.ihzv_data on 'informix'.ihzv
(
data
)
in i_dbs;
create cluster index 'informix'.ihzv_kodka_ndog on 'informix'.ihzv
(
kodka,
ndog
)
in i_dbs;
create unique index 'informix'.ihzv_unique_i on 'informix'.ihzv
(
idzv
)
in i_dbs;
alter table 'informix'.ihzv add constraint unique
(idzv)
constraint ihzv_unic_i;




------------------------------------------
Процедура:


create procedure date_tmp(_kodka int,_ndog int,
_data_1_intr datetime year to second,_data_2_intr datetime year to second)

returning int,int,datetime year to second,char(32),char(64)

define _kodus,_nrm int;

define _data datetime year to second;

define _number char(32);

define _id char(64);

foreach select kodus,nrm,data,number,h323_incoming_conf_id
into _kodus,_nrm,_data,_number,_id
from ihzv
where kodka = _kodka and ndog = _ndog
and data between _data_1_intr and _data_2_intr

return _kodus,_nrm,_data,_number,_id with resume;
end foreach;

end procedure;


---------------------------------------

set explain ON;

update statistics for procedure date_tmp

----------
Procedure: informix.date_tmp
select x0.kodus ,x0.nrm ,x0.data ,x0.number ,x0.h323_incoming_conf_id from "informix".ihzv x0 where
(((x0.kodka = ? ) AND (x0.ndog = ? ) ) AND ((x0.data >= ? ) AND (x0.data <= ? ) ) )

QUERY:
------


Estimated Cost: 3
Estimated # of Rows Returned: 1

1) informix.ihzv: INDEX PATH

Filters: (informix.ihzv.ndog = '<VAR>' AND informix.ihzv.kodka = '<VAR>' )

(1) Index Keys: data (Serial, fragments: ALL)
Lower Index Filter: informix.ihzv.data >= '<VAR>'
Upper Index Filter: informix.ihzv.data <= '<VAR>'



-----------------------------------
И план для Запроса,который в процедуре, но только с конкретными значениями:
(запрос выполняется моментально !)
-----------------------------------


QUERY:
------
select kodus,nrm,data,number,h323_incoming_conf_id
from ihzv
where kodka = 3323 and ndog = 6237
and data between datetime(2008-01-01 0:00:00)year to second
and datetime(2008-02-01 0:00:00)year to second

Estimated Cost: 1
Estimated # of Rows Returned: 1
Maximum Threads: 1

1) informix.ihzv: INDEX PATH

Filters: (informix.ihzv.data <= datetime(2008-02-01 00:00:00) year to second AND informix.ih
zv.data >= datetime(2008-01-01 00:00:00) year to second )

(1) Index Keys: kodka ndog (Parallel, fragments: ALL)
Lower Index Filter: (informix.ihzv.ndog = 6237 AND informix.ihzv.kodka = 3323 )

Что именно неправильно ?
И в каких _обоих_ случаях?
В том то и суть, что при выполнении одиночного запроса всё отрабатывает моментально !!!

Спасибо большое !

Конечно, отключение индекса по дате помогает.
Но отключить индекс никак не могу - он тоже активно используется в других запросах.

Только вопрос у меня остался такой:
Почему уход от стратегии фрагментирования ROUND ROBIN повлияла так на работу оптимизатора?

Или на это влияет что-то еще?


А план запроса до изменения фрагментирования(со схемой ROUND ROBIN ) был такой :

-----------------
Estimated Cost: 132
Estimated # of Rows Returned: 6

1) informix.ihzv: INDEX PATH

Filters: ((informix.ihzv.data <= '<VAR>' AND informix.ihzv.data >= '<VAR>' ) AND informix.ih

(1) Index Keys: kodka ndog (Serial, fragments: ALL)
Lower Index Filter: (informix.ihzv.kodka = '<VAR>' AND informix.ihzv.ndog = '<VAR>' )

------------------------------

И еще хотел бы, чтоб кто-то поделился со мной знаниями о всех
преемуществах и недостатках схемы фрагментирования ROUND ROBIN.
Как я понял, индексы в случае ее использования не самые скоростные?

Помогли 2 варианта:
1) Просто Создал индекс по полям kodka,ndog,data
Оптимизатор увидел его.

2) И второй вариант
Я сэмулировал ситуацию на другом сервере

В итоге, помог возврат к статистике LOW:
update statistics LOW for table ihzv drop distributions;
Update statistics LOW for table ihzv;

То есть оптимизатор заработал по другому из-за того, что
всю жизнь статистика делалась как LOW, а в этот раз, после заливки таблицы,
я сделал её как HIGH.
Поэтому и пострадали некоторые планы выполнения.

В общем, пока-что я за второй вариант, как за более глобальный, хотя и менее правильный

А вот интересно, чем плохо выполнение всегда Update statistics LOW,
а не HIGH?. (Вообще и в частности в моём случае, когда многие процедуры создавались
на фоне статистики LOW ?)

Спасибо ВСЕМ ОГРОМНОЕ !!!
Очень и Очень ПОМОГЛИ