Ibase тормоза

← →
SasaR (2004-01-19 17:54) [0]

Не сказал бы, что процедура моя возвращает много данных (20 -30 тыс.строк), но несколько первых тысяч видны в гриде, но при попытке "ехать" вниз или в цикле while not eof do Next сильнейшие тормоза, длящиеся часами...
Что я такого наделал (в смысле может совершил к-ть распространённую ошибку ?)
Как избежать подобного ?

← →
Term (2004-01-19 17:57) [1]

а скоко тогда по твоему много данных???
20-30 млн.?

к тому же чтобы ответить на твой вопрос слишком мало сведений представил

← →
SasaR (2004-01-19 18:09) [2]

есть процедура, в ней делается запрос по "здоровенной" таблице.
Результаты выполнения этой процедуры я вижу сразу, но если я не дай бог нажму в гриде Ctrl-End (в конец) или в цикле захочу пробежаться по данным запроса (напр. чтобы экспортировать в Excel) всё замерзает на часы. В конце-концов в лучш. случае через пару часов пропадают песочные часы и можно свободно лазить по гриду вверх-вниз.
Каким образом тогда Ibase отдает записи в клиентское приложение ?
Частями ? Как это контролировать (типа OnAfterFethRecord есть ли такое)
Пользую FIBDataSet....
Заранее спасибо....

← →
}|{yk (2004-01-19 18:51) [3]

А индексы сделать слабо?

← →
jack128 (2004-01-19 19:04) [4]

> Результаты выполнения этой процедуры я вижу сразу
Значит сама процедура отрабатывает быстро.

> но если я не дай бог нажму в гриде Ctrl-End (в конец) или
> в цикле захочу пробежаться по данным запроса (напр. чтобы
> экспортировать в Excel) всё замерзает на часы.
Вывод - очень долгий фетч. Либо данных ОЧЕНЬ много(гораздо больше, чем несколько тысяч записей), либо очень тонкий канал связи(модем???)

← →
Desdechado (2004-01-19 19:55) [5]

20-30 тыс записей для нормальной работы на клиенте не очень-то и нужны. Обычно 100-200 записей уже не в состоянии человек воспринять сразу.
А тормоза оттого, что идет закачка этих данных на клиент. Сервер-то их отделяет быстро, но затолкать их на клиент ему тяжело. Причины: тонкий канал (не пропускает много сразу) или слабый клиент (не может принять то, что сервер готов дать и канал - пропустить).
Рекомендую обходиться без таких выборок. А если хочешь делать экспорт, то делай это в пакетном режиме (без отображения), на однонаправленных курсорах и фоновой задачей.

← →
Desdechado (2004-01-19 20:21) [6]

да, если у тебя строки по 50-100 полей и с блобами, то вообще дрова :)

← →
SasaR (2004-01-20 10:39) [7]

To Desdechado - сервер IB6.0 здесь же, на моей машине, клиентской. Полей - понты. Должно получится ~30 тыс строк из таблицы в 80 тыс.Такое впечатление (прокручиваю в гриде), что сервер отфетчил ~50 записей и замер на 30 сек. кручу вниз - опять 30 сек и т.д... Может где не там suspend ставлю ?
На клиенте делаю фетч в однонаправленном-"невизуальном" TFIBquery ("зелёненкий") в MemoryDataSet из Rx-ов. Внутри цикла - Application.ProcessMessages....
Вы это имели ввиду ?
Кстати запрос там типа "поле <> 9"... может быстрее будет поле in [....] ?

← →
Danilka (2004-01-20 10:49) [8]

А зачем в гриде столько записей?
30тыс записей, это примерно 500 листов формата А4, то-есть юзеру чтива не на одну неделю.
Ненадо работать с клиент-сервером также как и с файл-сервером, всегда можно уточнить запрос, чтобы он вернул не тысячи/мильены записей, а 100-200, тем более, что на самом деле из этих 100-200 записей юзеру реально надо не больше 10-и.

← →
Academic (2004-01-20 10:50) [9]

Оцени скорость работы своей процедуры в стандартном iSQL
InterBase.

← →
Sergey13 (2004-01-20 10:54) [10]

Я бы пошел по такому пути:
1. Ответил бы на вопрос - 30000 записей сразу надо? Сомнительно чтой то шибко.
2. Если ответ на вопрос 1 - все таки "Да", то вылизывать процедуру на предмет оптимизации. Например, на поле которое <>9 индекс есть?

>может быстрее будет поле in [....] ?
Вряд ли.

← →
Term (2004-01-20 10:59) [11]

а и зачем для такой задачи писать ХП, если из 80тыс, вибирается 30тыш, попробуй сделать тоже самое запросом, создай индексы, может так скорость увеличится, да и кому надо 30000 записей в Excel, тут тормоза будут еще большие!!!

← →
Danilka (2004-01-20 11:05) [12]

> [10] Sergey13 © (20.01.04 10:54)
> 2. Если ответ на вопрос 1 - все таки "Да",

А есть какой-нибудь пример, когда ответ на вопрос 1 - все таки "Да"? Что-то не могу представить.

← →
Danilka (2004-01-20 11:06) [13]

в догонку: репликация и т.д. в качестве примера не предлагать, только такие примеры, где все это хозяйство вываливается в грид. :))

← →
Term (2004-01-20 11:09) [14]

> А есть какой-нибудь пример, когда ответ на вопрос 1 - все
> таки "Да"? Что-то не могу представить

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

← →
Desdechado (2004-01-20 11:11) [15]

MemoryDataSet тормознутый на таких объемах. Что, напрямую из TFIBquery слабо сделать экспорт?

← →
SasaR (2004-01-20 11:15) [16]

Я пользую IBExpert. Тормоза - в его гриде :))
Такие же тормоза в моей клиентской программе (там нет грида), но есть фетч, как я выше описал :) Столько данных мне не нужно в гриде, но нужно периодически импортировать их в Эксель.
Индексы есть (IBExpert пишет "не натурал" и всё не красненькое).
Процедура разбита на 4-участка:
Курсоры по:
1. select поля from store where (CROSS_CLI=9)and(CLARICHEV is not null)

2. select поля from store where (CROSS_CLI<>9)and(TOV_COD is not null)

3. select поля from store where ((cross_cli=9)and(clarichev is null))or((cross_cli<>9)and(tov_cod is null))

4. select count(*) from store where (CROSS_CLI is null)
Работало такое сутками.
Тогда я таблицу store дублировал 4-е раза под каждый из случаев
И теперь 2-й запрос(вернее там FOR select CROSS_CLI, TOV_COD from store_2 group by CROSS_CLI, TOV_COD
into :out_cross_cli, :out_tov_cod
do... дальше еще всякие вычисления) фетчит всё такими дикими рывками. Хотя в остальных всех всё плавно, довольно быстро, хотя используются подобные запросы (group by)... может потому, что в первом случае group by по 9-ке и чему угодно, а во втором разные комбинации....

← →
Sergey13 (2004-01-20 11:16) [17]

2Danilka © (20.01.04 11:05) [12]
>А есть какой-нибудь пример, когда ответ на вопрос 1 - все таки "Да"? Что-то не могу представить.
Ты меня спрашиваешь?
Я могу предположить только отчет. Но в грид... Это за рамками моего понимания. 8-)

← →
Карелин Артем (2004-01-20 11:16) [18]

Только не надо насчет медленного вывода в ексель!! У меня вывод 60 000 записей 20 полей идет 5 минут. Это при том, что набор данных однонаправленный и занимает в памяти полгига.

← →
Term (2004-01-20 11:19) [19]

> Только не надо насчет медленного вывода в ексель!! У меня
> вывод 60 000 записей 20 полей идет 5 минут. Это при том,
> что набор данных однонаправленный и занимает в памяти полгига.

а ты какими компонентами пользуешся???

← →
Карелин Артем (2004-01-20 11:24) [20]

← →
SasaR (2004-01-20 11:25) [21]

To Term и мне интересно...
Кстати Автор выражает всем благодарность и посыпает голову песком. Проблема была в лишнем индексе по ненужным в данном случае полям и его Ibase брал первым.... Каюсь :))

← →
Карелин Артем (2004-01-20 11:28) [22]

В программулине от EMS есть возможность просмотра плана. Без плана жить нельзя :)

← →
Term (2004-01-20 11:34) [23]

> 2 Карелин Артем © (20.01.04 11:24) [20]

ну я тоже в принципе OLE использую, и макросы которые в экселе создаются, применяю к делфовым COM-объектам... или может у тебя комп навороченный судя по этому:

> и занимает в памяти полгига

у меня оперативы существенно меньше, или ты по другому делаеш, тогда хоть в общих чертах просвети

← →
Danilka (2004-01-20 11:40) [24]

Есть FlexCel - компонент, который умеет сам "рисовать" экселевские файлы на основе шаблонов, без ОЛЕ, по-идее, должно быть быстрее и менее прожорливо, чем через ОЛЕ.
До версии 2.5.3 он шел бесплатно с исходниками, сечай его прибрала к рукам TMS Group и он стал платным, могу выслать версию 2.5.3

← →
Term (2004-01-20 11:49) [25]

← →
Danilka (2004-01-20 11:54) [26]

← →
Term (2004-01-20 12:08) [27]

Ibase тормоза Найти похожие ветки