iBase.ru Forum

Периодически (раз в 2 часа) в табличку переливаются данные из внешних OLTP-систем (делается с помощью IBPump-а). Предварительно удаляются из таблицы записи, датированные текущим месяцем и заливаются обновленные, тоже за текущий месяц (положим 100 тыс. записей). Таким образом осуществляется поддержание актуального состояния записей. Затем из этой таблички запросами делаются отчеты (запросы простые select * from Table) очередность выполнения запросов, формирующих отчеты фиксирована, и записана в BAT-файле. Выборок много, с разными фильтрами, есть выборки, пролетающие за секунды есть и подольше. Есть пара выборок (возвращают 300-500 тыс записей) с числом полей до 30, по которым происходит странная ситуация (систематически!):

После заливки данных первый раз запрос возвращает записи очень долго, примерно около часа, Затем выполняются более мелкие запросы, а если запустить повторно запрос (после всех остальных), который долго выполнялся, то возвращает все записи уже за 2-3 минуты. Так же помечено, что если в запросе поменять условия фильтрации, то отработает он тоже очень быстро.

Подскажите пожалуйста как побороть эту напасть и сделать так, чтобы запрос выборки не провисал на час?
Подскажите где собака порылась. Такое впечатление что первое выполнение длинного запроса происходит без использования индексов.

Условия: FB 1,5. Заливка :Ibpump 3,4, выборки для создания отчетов при помощи ODBC 1.02.00.69 Phoenix. таблица индексирована по полям, используемым в фильтрах, изменение очередности выполнения запросов не влияет на скорость их выполнения.

Может таки это мусор?
У меня тоже после больших заливок/апдейтов/удалений долго большой подсчет выполняется.

В пятницу утром подняли базу из ночного бекапа, сразу попробовали сформировать эти большие отчеты – пролетели за 3 минуты, потом запустили переливку данных за последний месяц, после этого сразу повторили генерацию больших отчетов – шла примерно 1 час…

IBAnalist-ом посмотреть состояние после загрузки, но перед формированием отчета.

neuro писал(а):...потом запустили переливку данных за последний месяц, после этого сразу повторили генерацию больших отчетов – шла примерно 1 час…

Типичное поведение после массовых update/delete при кооперативной сборке мусора. Соответственно читать про неё любимую. Кстати, стоило бы указать, в каком режиме (CS/SS) используется сервер.

neuro писал(а):Предварительно удаляются из таблицы записи, датированные текущим месяцем и заливаются обновленные, тоже за текущий месяц (положим 100 тыс. записей).

Мусор, однозначно.
Во-первых, советую не убить/залить заново, а update. При условии, что меняется не всё, даст выигрышь.
Во-вторых, можно отчёты пускать в транзакции no_garbage_collect, а собирать его sweep'ом в специально выделенное ночером время.

Коллеги, спасибо за подсказки,
Прочитал и про мусор в базе и про кооперативную сборку этого мусора.
Для чистоты эксперимента поднял базу из бекапа, отчеты на этой базу сгенерилась очень быстро (мусора – то нет), затем запустил полный цикл, с перекачкой данных за текущий месяц и затем обновление отчетов, заняло все примерно 2 часа (отчеты генерились уже меденно, так как мусор уже появился после первой же перекачки).
В соответствии с тем, что прочитал про мусор, в цикл после перекачки данных добавил запрос вида select count(*) from tab и вот что получилось: перекачка данных прошла как обычно, затем о-очень долго выполнялся запрос select count(*) from tab и затем быстро сгенерились отчеты. Итого весь цикл > 2 часов.

Ps сервер работает в режиме CS

несколько рекомендаций, можно попробовать, возможно где-то будет выигрыш:
1. попробовать двойку, со времен полуторки механизм сбора мусора сильно правили.
2. собирать мусор gfix-ом
3. заблокировать сбор мусора, версий, конечно, наплодится, но возможно это будет меньшее зло. Или не удалять записи, а только метить на удаление и отбрасывать такие записи фильтром в селектах.
4. купить рэйд адаптор с набортным кэшем включить его на запись и решить проблему ломовым железом. При сборке мусора упор явно идет в диски.
5. drop/create table или b/r хотя это изврат полнейший.

заитересовал параметр no_garbage_collect
подскажите пожалуйста, можно ли его как-нить использовать если коннект к базе идет через ODBC?

можно ли его как-нить использовать если коннект к базе идет через ODBC?

нет.

NB: И с использованием BDE тоже нет