powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Map
Форумы / Informix [игнор отключен] [закрыт для гостей] / Сыпанулся индекс на фрагментированной таблице
25 сообщений из 51, страница 1 из 3
Сыпанулся индекс на фрагментированной таблице
    #38991395
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сыпанулся индекс на фрагментированной таблице (oncheck –cI <имя индекса>.)
Таблица большая 550 Гб, почти 600 млн. строк. Обращения к этой таблице (insert, update, delete) происходят в режиме 24 Х 7. Заблокировать доступ к таблице не представляется возможным.
Разворачивание БД из бэкапа займет около 8 часов. Проверка всех данных таблицы и индексов еще часов 12.
Посоветуйте пожалуйста как исправить эту ситуацию с наименьшими потерями по времени?
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991403
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Забыл написать. Версия 11.70.FC6
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991443
DrGonzo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991500
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
online то конечно хорошо, хоть он online токо по тому, что не нужна блокировка таблицы, блокировки строк все-равно будут
нужно также учитывать специфику приложений
не забывайте про PDQ при построении индекса
последний раз когда делал online вылилось нехорошими последствиями и пришлось тупо перезапускать
сервер из-за малюсенького индекса.
Если у вас есть репликация - не факт что на DR сервере битый индекс, возможно стоит перейти туда.
Проверить битый ли там индекс достаточно запросом, который будет использовать данный индекс на проблемных значениях.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991546
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за советы.
База без реплики.
Индекс по полю c типом DATE. Индекс чуть более 10 Гб
Пока пришел к решению, что надо сделать на бэкапе (проверить сколько по времени, один ли индекс поврежден и т.д)
drop index
create index ... online.


1. Можно по-подробнее, что может быть плохого?
2. PDQ выставить в 0 ? Учитывая что в этой таблице в течении всего дня (без перерывов делаются вставки и удаления строк)
Т.е. отдать приоритет всем DML операциям, а затем созданию индекса.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991693
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PDQ нужно использовать(включить) при создании индекса.
т.е. помимо конф. параметра MAX_PDQPRIORITY
нужно выставить переменную PDQPRIORITY или через оператор set ...
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38991705
яфшуеі
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сергей Б1. Можно по-подробнее, что может быть плохого?



1. Некое замедление в работе, местами м.б. значительное
2. Если приложение при старте парсит а потом по мере надобности візівает запросі - после удаления
индекса возможно будет нужен перезапуск приложения.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38992082
Сергей БСпасибо за советы.
База без реплики.
Индекс по полю c типом DATE. Индекс чуть более 10 Гб
Пока пришел к решению, что надо сделать на бэкапе (проверить сколько по времени, один ли индекс поврежден и т.д)
drop index
create index ... online.


1. Можно по-подробнее, что может быть плохого?
2. PDQ выставить в 0 ? Учитывая что в этой таблице в течении всего дня (без перерывов делаются вставки и удаления строк)
Т.е. отдать приоритет всем DML операциям, а затем созданию индекса.

Блииин !!! Ну зачем же дроп-то сначала ?!!!!

Останетесь без индекса (хоть и битого) - прощай производительность (возможно в разы - сиквенс скан на 600 миллионов строк на каждый раз когда был нужен индекс вы себе представили да ?)

Сначала создайте новый на тоже поле. Что бы создался - desc добавьте.

А потом уже старый удаляйте.

Обеспечте что бы новый индекс лез в логи без "длинной транзакции" (база ведь с логированием ?). При типичных настройках это значит что сумма всех логов лучше что бы была равна двум размерам операции ((получается 20Г).

Из неожиданного - проверьте что бы место под бэкап этих 10Г логов неожиданно не кончилось :)
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38992170
Выбегалло
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Век живи, век учись. Это я по поводу создания второго индекса на том же поле при помощи DESC. Тонко, тонко...
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38992468
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за совет.
Павел, а как отключить логирование при создании индекса?
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38993134
Сергей БСпасибо за совет.
Павел, а как отключить логирование при создании индекса?

# LOG_INDEX_BUILDS - Enable (1) or disable (0) index page logging.
# Required for RSS. Optional for HDR and SDS.

Возможно у вас и не включён.

Для изменения параметра требуется перезапуск.

Выше я немного лишнего нагнал написав так, что получилось "база с логированием - индекс логируется".

Верно: база с логированием - индекс как в LOG_INDEX_BUILDS

У меня-то RSS всегда как бесплатный бэкап включён, по этому LOG_INDEX_BUILDS то же всегда 1.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38993331
cpr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
cpr
Гость
Бэкап ты можешь не любить,
но HADR ты иметь обязан!
Ведь индекс
(быть или не быть)
наш ДБА спасти обязан!
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38993413
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Яковлев ПавелСергей БСпасибо за совет.
Павел, а как отключить логирование при создании индекса?

# LOG_INDEX_BUILDS - Enable (1) or disable (0) index page logging.
# Required for RSS. Optional for HDR and SDS.

Верно: база с логированием - индекс как в LOG_INDEX_BUILDS


Параметр LOG_INDEX_BUILDS действует для случаев RSS,HDR,SDS.
Автор вроде ничего такого не говорил.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38993859
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще раз спасибо.
БД без RSS,HDR,SDS.
Часто используемый запрос стал выполняться очень долго. Судить, что запрос работает, можно только по onstat –u –r. (поле nreads). Может привести скрин или строку???
Поля reg_paym_dt , reg_date, recv_code , p.pm_state, p.paym_ord проиндексированы.
Update statistic high по всей таблицы сделан.

На всякий случай, таблица фрагментирована по выражению by round robin in. Почти все чанки зеркалируются
Вот запрос
Код: plsql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0



Если запустить запрос без min ( ), то в выборке окажутся св среднем 300000 – 700000 записей и время выполнения около 30 сек
Если время выборки установить в пределах 2-3 часов, запрос тоже отрабатывает быстро (2-3 сек), не зависимо от выбранной даты и месяца.
Следующая конструкция выполняется менее 2 секунд. Нет оператора min ( )
1.

QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:31:41)
------
SELECT p.reg_date
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0

Estimated Cost: 449280
Estimated # of Rows Returned: 71534

1) informix.p: INDEX PATH

Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 )

(1) Index Name: informix.paym__ix_reg_paym_dt
Index Keys: reg_paym_dt (Serial, fragments: ALL)
Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second
Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 81901 71534 464778 00:01.38 449281

2. Создаю по этому запросу темповую таблицу и по ней ищу min (date). Время выполнения менее 2 сек
QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:36:46)
------
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
SELECT p.reg_date 
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0
into temp tmp_r_d;



Estimated Cost: 449280
Estimated # of Rows Returned: 71534

1) informix.p: INDEX PATH

Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 )

(1) Index Name: informix.paym__ix_reg_paym_dt
Index Keys: reg_paym_dt (Serial, fragments: ALL)
Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second
Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p
t2 tmp_r_d

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 81901 71534 464778 00:00.80 449281

type table rows_ins time
-----------------------------------
insert t2 81901 00:00.99


QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:36:47)
------
select min (reg_date) from tmp_r_d;

Estimated Cost: 2946
Estimated # of Rows Returned: 1

1) informix.tmp_r_d: SEQUENTIAL SCAN


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 tmp_r_d

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 81901 81901 81901 00:00.04 2946

type rows_prod est_rows rows_cons time
-------------------------------------------------
group 1 1 81901 00:00.04

3. Делаю запрос с оператором min, но интервал выборки 2 часа

QUERY: (OPTIMIZATION TIMESTAMP: 06-26-2015 14:40:37)
------
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date) 
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 01:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0



Estimated Cost: 9689
Estimated # of Rows Returned: 1

1) informix.p: INDEX PATH

Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 )

(1) Index Name: informix.paym__ix_reg_paym_dt
Index Keys: reg_paym_dt (Serial, fragments: ALL)
Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second
Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 01:59:59) year to second


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 2108 5961 8619 00:00.02 9689

type rows_prod est_rows rows_cons time
-------------------------------------------------
group 1 1 2108 00:00.02


5. делаю запрос с min(p.reg_date) за интервал 1 день.
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date) 
FROM paym p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0 



О том, что он не висит видно из команды (колонка nreads)
onstat -r -u | grep 1599044 > /tmp/tmp.log
nreads
182f12df58 ---PR-- 1599044 informix - 0 0 2 6905200 17408
182f12df58 ---PR-- 1599044 informix - 0 0 2 6905920 17408
182f12df58 ---P--- 1599044 informix - 0 0 2 6906576 17408
…………………………………………………………………………………………
182f12df58 B--PR-- 1599044 informix - 19ed5cda0 0 2 7232992 17408
182f12df58 B--PR-- 1599044 informix - 19f61d160 0 2 7233696 17408


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 1 71534 552110204 55:12.79 1059

type rows_prod est_rows rows_cons time
-------------------------------------------------
group 1 1 1 55:12.79


за каким х.. запрос сканирует всю таблицу rows_scan = 552110204
Как отвадить информикс от этого?















Не пойму, почему стало так долго выполняться. Как
Вот план его выполнения
-- execution plan at /home/informix/sqexplain.out at
QUERY: (OPTIMIZATION TIMESTAMP: 06-25-2015 15:04:51)
------
SELECT min (reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'

Estimated Cost: 133
Estimated # of Rows Returned: 1

1) informix.p: INDEX PATH

Filters: (informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second AND informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second )

(1) Index Name: informix.paym__ix_reg_date
Index Keys: reg_date (Aggregate) (Serial, fragments: ALL)
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38993948
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Б,

Когда быстро - у вас используется индекс: informix.paym__ix_reg_paym_dt
Когда медленно - informix.paym__ix_reg_date. Наверно он битый.
Попробуйте хинтом выключить индекс informix.paym__ix_reg_date.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994246
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IkirСергей Б,

Когда быстро - у вас используется индекс: informix.paym__ix_reg_paym_dt
Когда медленно - informix.paym__ix_reg_date. Наверно он битый .
Попробуйте хинтом выключить индекс informix.paym__ix_reg_date.
Причём тут битость индекса?! План выполнения оптимизатор выбирает неэффективно.
Основных вариантов 3:
1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь.
2. Ой, всё.

Независимо от возможности или невозможности решения проблемы со статистикой простым решением является создание индекса
reg_paym_dt, reg_date.
И прочтите хоть что-то про оптимизацию запросов
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994251
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойОсновных вариантов 3:
1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь.
2. Ой, всё.


А сообщение пятая строка сверху вас не смущает?
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994273
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IkirАнатоЛойОсновных вариантов 3:
1. Статистика такова. что не отражает суровую реальность. И есть вариант, что лучше её не соберёшь.
2. Ой, всё.


А сообщение пятая строка сверху вас не смущает?
Нет, не смущает. Потому-что статистика не молот Тора. Статистика помогает оптимизатору выбрать оптимальное решение, но не гарантирует его САМА ПО СЕБЕ. Я написал: "есть вариант", но не утверждал, что 100% в данном случае мы на него наткнулись.

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

А ещё поможет понимание, что оптимизатор для каждого запроса получает (не всегда отображаеиое явно в плане, к сожалению) цель запроса: получить все записи или пользователю достаточно первой.

И у меня ошушение, что настройки сервера или сессии в последнем запросе указывают на получение первой записи. Вот оптимизатор с текущей статистикой и ошибается.....

Так что помочь должно ещё указание оптимизации ALL_ROWS или выгрузка INTO TEMP :)
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994391
Сергей БЕще раз спасибо.
БД без RSS,HDR,SDS.
Часто используемый запрос стал выполняться очень долго.


Так в итоге проблемный индекс перестроили ? А его битую версию прибили ?
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994567
Ikir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойПоможет индекс, по двум полям, поможет хинт с указанием выбора нужого индекса или указаним игнорирования ненужного индекса.


Согласен.
Первый вариант затратный, но скорее всего и более оптимальный будет с точки зрения быстродействия.
Второй вариант НЕ затратный, пригоден для экспериментов прямо сейчас, но и скорее всего менее оптимальный.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38994978
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за советы. Извините, что так долго не отвечал, база большая. Все делается долго.
Сейчас временно запросы делаются через темповые таблицы
На текущий момент провожу эксперименты на тестовой базе, плюс параллельно на бою .

Бой
Отключил индекс по полю. Время выполнения запроса менее секунды
Код: sql
1.
SELECT {+AVOID_INDEX (plat paym__ix_reg_date)} min (p.reg_date) FROM plat



Бэкап (виртуалка)


На бэкапе (на ругань про ISAM error: no free disk space for sort пока не обращаю внимания) Смотрю индексы paym__ix_reg_date, paym__ix_reg_paym_dt.
Они не «битые»

Запустил на выходные
oncheck -cI ok_arch:plat
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Validating indexes for ok_arch:informix.plat..
                Index paym__ix_reg_paym_dt_n
                  Index  fragment partition pm_dbs1 in DBspace pm_dbs1
    ………………………..
                Index  fragment partition pm_dbs8 in DBspace pm_dbs8
                Index paym_ix_ppnt_tool_dscr
                  Index  fragment partition datadbs2 in DBspace datadbs2
Could not check rowids and perform data<->index check
ISAM error: no free disk space for sort
                Index  754_1846
                  Index  fragment partition pm_inddbs1 in DBspace pm_inddbs1
                Index paym__ix_param0
                  Index  fragment partition pm_inddbs2 in DBspace pm_inddbs2
Could not check rowids and perform data<->index check
ISAM error: no free disk space for sort
……………………………………………..
                Index  fragment partition pm_inddbs5 in DBspace pm_inddbs5        Index paym__ix_reg_date
                Index  fragment partition pm_inddbs5 in DBspace pm_inddbs5        Index paym__ix_reg_paym_dt
…………………………………………..
Please Drop and ReCreate Index paym_ix_ppnt_tool_dscr for ok_arch:informix.plat.
Please Drop and ReCreate Index paym__ix_param0 for ok_arch:informix.plat.



Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0



QUERY: (OPTIMIZATION TIMESTAMP: 06-29-2015 13:33:18)
------
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0



Estimated Cost: 4
Estimated # of Rows Returned: 1

1) informix.p: INDEX PATH

Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 )

(1) Index Name: informix.paym__ix_reg_paym_dt
Index Keys: reg_paym_dt (Serial, fragments: ALL)
Lower Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second
Upper Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p

type table rows_prod est_rows rows_scan ti me est_cost
-------------------------------------------------------------------
scan t1 81901 1 464778 00:09.44 5

type rows_prod est_rows rows_cons time
-------------------------------------------------
group 1 1 81901 00:09.53

Создал индекс (не убивая старого, время создания 8 часов)
create index paym__ix_reg_paym_dt_n on .plat (reg_paym_dt desc) online;
Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT min(p.reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0




QUERY: (OPTIMIZATION TIMESTAMP: 06-29-2015 08:32:11)
------
SELECT min(p.reg_date)
FROM plat p
WHERE p.reg_paym_dt >= '2015-06-13 00:00:00'
AND p.reg_paym_dt <= '2015-06-13 23:59:59'
AND p.recv_code in (110,101,510,810,403,72101,11101)
AND p.pm_state = 3
AND p.paym_ord > 0

Estimated Cost: 3
Estimated # of Rows Returned: 1

1) informix.p: INDEX PATH

Filters: ((informix.p.recv_code IN (110 , 101 , 510 , 810 , 403 , 72101 , 11101 )AND informix.p.pm_state = 3 ) AND informix.p.paym_ord > 0 )

(1) Index Name: informix.paym__ix_reg_paym_dt_n
Index Keys: reg_paym_dt (desc) (Serial, fragments: ALL)
Lower Index Filter: informix.p.reg_paym_dt <= datetime(2015-06-13 23:59:59) year to second
Upper Index Filter: informix.p.reg_paym_dt >= datetime(2015-06-13 00:00:00) year to second


Query statistics:
-----------------

Table map :
----------------------------
Internal name Table name
----------------------------
t1 p

type table rows_prod est_rows rows_scan time est_cost
-------------------------------------------------------------------
scan t1 81901 1 464778 00:23.71 4

type rows_prod est_rows rows_cons time
-------------------------------------------------
group 1 1 81901 00:23.85


Запрос отработал за 23.85 секунды, по старому индексу работает 09.53.
Пока никаких мыслей, что делать с таблицей на бою. Напоминаю, как временный вариант, сейчас запрос работает через временную таблицу
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38995479
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Б, надеюсь вы в курсе что время не всегда идеальный показатель производительности. Возможно что индекс по двум полям пока не был востребован, и грузился с диска для вашего запроса, а для индекса по одному полю уже находился в памяти...
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38995634
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
АнатоЛойСергей Б, надеюсь вы в курсе что время не всегда идеальный показатель производительности. Возможно что индекс по двум полям пока не был востребован, и грузился с диска для вашего запроса, а для индекса по одному полю уже находился в памяти...
1. Пардон, был недостаточно внимателен. Вышесказанное относится к индексу reg_paym_dt ASC и reg_paym_dt DESC.
2. По поводу моего совета с индексом по (reg_paym_dt, reg_date) забейте, я был неправ - для вашего запроса c фильтрами он не поможет.
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38995713
Сергей Б
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Еще раз спасибо за ответы.
АнатоЛой, это запрос работал раньше очень быстро. Мне показали логи, выполнявшие этот запрос и ранее. Просто в какой-то момент времени (пару недель назад, начал «дурить» запрос. На эмоциях я и создал тему, что полетел индекс.
После восстановления бэкапа на тестовой среде (виртуалка) оказалось, что
А) индексы не битые (сейчас проверяю индексы varchar (255,16) когда выдавалось сообщениеno free disk space for sort)
Б) в трейсе на обоих серверах выборка идет по одному и тому же индексу (только на бою работает около часа, а на тестовом сервере пару минут)
В) update statistics high - не помог
Из-за чего это произошло – пока не понятно. И как "вылечить" это тоже ясности нет. Дня через 3 попробую содать индекс как советовал Павел (запрос не массовый).
...
Рейтинг: 0 / 0
Сыпанулся индекс на фрагментированной таблице
    #38996109
АнатоЛой
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей Б, как минимум на боевой другая нагрузка, степень загруженности дисков и памяти и степень разнообразности запросов. Проблема на боевом может быть не в этом запросе, он мог и не измениться. Просто выросла нагрузка в другом месте или появилась новая, а именно этот запрос оказался на границе своей производительности и первым обратил на себя внимание. Сравните общую производительности сервера раньше и сейчас.
Смотрите в статистике запросов и сравнивайте dskreads и bufreads.
...
Рейтинг: 0 / 0
25 сообщений из 51, страница 1 из 3
Форумы / Informix [игнор отключен] [закрыт для гостей] / Сыпанулся индекс на фрагментированной таблице
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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