399999 - Out of memory

Dynamic · Сообщение **Dynamic** » 10 май 2006, 08:05

FB 1.5 SS, SQL 3
Такая проблема. Есть таблица ~600000 записей. Надо выгрузить ее в DBF. В IBE запускаю экспорт дроходит до 399999 (иногда меньше) и валится с "Out of memory". Ваяю в дельфе экспортер: IBQuery + select = DBF - та же картина.

В чем может быть причина?

И еще. Как можно для таких случаев выбирать на клиента только одну запись, т.е. выбрал запись, обработал, удалил, взял следующую и т.д.?

Dimitry Sibiryakov

Или TIBSQL вместо TIBQuery или Unidirectional := true;

Dynamic · Сообщение **Dynamic** » 10 май 2006, 12:54

TIBSQL

не поможет, я делаю экспорт в DBF

Unidirectional - вот это похоже и есть

Сообщение **kdv** » 10 май 2006, 13:13

ну так КТО валится по out of memory. IBSQL не буферизирует считываемые записи.
короче,
www.ibase.ru/devinfo/impexp.htm

Dynamic · Сообщение **Dynamic** » 10 май 2006, 13:50

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

лоханулся, что и говорить...

Zhur · Сообщение **Zhur** » 10 май 2006, 15:14

Dynamic писал(а): лоханулся, что и говорить...

Дело в том, что я тоже тут похожую штику делаю. Тока наоборот - импорт из DBF. Тут дело обстоит посложнее.
Объясняю: в DBF-файлах используются свои уникальные поля (допустим CODE), а у меня в FB, естественно, свои. Конечно, в моих таблицах имеется соответствующее поле (CODE). А проблема в том, что при переборе записей в DBF-файле мне необходимо найти соответствующий ID в моей таблице. А для этого я использую хранимые процедуры. Короче... все так долго работает. Таблица в 400000 записей импортируется примерно за 8 часов. Может кто поделится опытом по решению такой задачки?

aaa3d · Сообщение **aaa3d** » 10 май 2006, 16:55

400000 записей за 8 часов - примерно 13 записей в секунду - неприятно медленно
приведи свои структуры пожалуйста
у меня на заливке данных с поисками и проверками получается 200-500 записей в секунду, попробую подсказать

Сообщение **kdv** » 10 май 2006, 17:19

DBF-файле мне необходимо найти соответствующий ID в моей таблице. А для этого я использую хранимые процедуры. Короче... все так долго работает.

www.ibase.ru/devinfo/testiu.htm

Dimitry Sibiryakov

Dynamic писал(а):самое интересное, что эту статью несколько раз перечитывал, но почему-то утвердился во мнении, что TIBSQL - только для быстрой вставки записей, не подумал, что им можно и выбирать на клиента.

TIBSQL - наиболее универсальный и вто же время легкий компонент. В-общем-то я уже давно ничего кроме его не использую.

Dynamic · Сообщение **Dynamic** » 11 май 2006, 08:52

Dimitry Sibiryakov писал(а):TIBSQL - наиболее универсальный и вто же время легкий компонент. В-общем-то я уже давно ничего кроме его не использую.

а для отображения данных что (если не секрет, конечно)? Обычные контролы?

Dimitry Sibiryakov

Dynamic писал(а):а для отображения данных что (если не секрет, конечно)? Обычные контролы?

Да. TStringGrid, TListView. Быстро и красиво. Самое сложное было сломать пользователей чтобы они не хотели видеть полный список.
Для редактирования - тоже соответствующие TEdit, TMemo, TDateTimePicker и т.д.

Dynamic · Сообщение **Dynamic** » 11 май 2006, 12:32

я тоже к этому подхожу, но это :

Dimitry Sibiryakov писал(а): Самое сложное было сломать пользователей чтобы они не хотели видеть полный список.

- самое сложное....
Вобщем-то давно хотел спросить об этом, но вот попутно получилось

Zhur · Сообщение **Zhur** » 11 май 2006, 14:56

aaa3d писал(а):400000 записей за 8 часов - примерно 13 записей в секунду - неприятно медленно
приведи свои структуры пожалуйста
у меня на заливке данных с поисками и проверками получается 200-500 записей в секунду, попробую подсказать

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

WildSery · Сообщение **WildSery** » 15 июн 2006, 18:40

kdv писал(а):www.ibase.ru/devinfo/testiu.htm

Этот тест неполный, и учитывает только вставку процедурную. Реально же наиболее быстр может быть алгоритм вставки с клиента (!) insert и update с использованием "баланса" вставок/обновлений.
Поясню идею. Начинаем с insert, если эксепшн, увеличиваем счётчик ошибок, делаем update. Если ошибок накопилось, скажем, 5 подряд, то первое действие для следующей записи не insert, а update, и соответственно, проверяем RowsAffected на 0. Удачные вставки (обновления) изменяют баланс в свою сторону. Соотношение 1:5 наиболее подходяще (по моим тестам, с клиента update+проверка+insert занимает в 5 раз больше времени, чем insert+эксепшн+update, как это ни странно).

Данный механизм работает на любом % наложения быстрее процедур, вплоть до 15-20%, в моей конкретной базе, по крайней мере. В DBF порядка 130000 записей каждый раз.

CyberMax · Сообщение **CyberMax** » 16 июн 2006, 02:36

Dimitry Sibiryakov писал(а):TStringGrid, TListView. Быстро и красиво. Самое сложное было сломать пользователей чтобы они не хотели видеть полный список. Для редактирования - тоже соответствующие TEdit, TMemo, TDateTimePicker и т.д.

Регресс однако. Мучились Борланды, TDataSet, TDataSource и прочие DB-Aware компоненты придумывали... А в итоге все в корзину

. Имхо, современные компьютеры позволяют не смотреть на потерю пары тысяч тактов...

Dimitry Sibiryakov

Кроме тактов есть еще и другие невосполнимые ресурсы. ОЗУ и пропускная способность сети, например. Кроме того это в компонентах такты теряются тысячами, а на сервере - уже миллионами и миллиардами. И так для каждого пользователя. В результате этот форум переполнен криками "отчего у меня так все тормозит?"...

CyberMax · Сообщение **CyberMax** » 16 июн 2006, 08:17

Dimitry Sibiryakov писал(а):Кроме тактов есть еще и другие невосполнимые ресурсы. ОЗУ и пропускная способность сети, например.

Хорошо. Тогда чем отличается фетч записей с сервера SQL и DataSet'а? И там и там по сети будут переданы одни и те же данные. Это первое. Второе - поставить на сервер еще 128/256/512/1024 метров - не проблема. Зато всем будет проще жить (и программисту, и пользователю). Первому - за счет упрощения кодирования, простоте рефакторинга и прочего, вторым - за счет уменьшения глючности продукта и легкости его модификации по его просьбам.

Dimitry Sibiryakov писал(а):Кроме того это в компонентах такты теряются тысячами, а на сервере - уже миллионами и миллиардами. И так для каждого пользователя. В результате этот форум переполнен криками "отчего у меня так все тормозит?"...

Тормозит при причине криворукости программистов (95%) и админов (4%), а не из-за того, что теряются такты. А сколько тактов теряется в самом Firebird'е, никто не считал?

Dimitry Sibiryakov

CyberMax писал(а):Тогда чем отличается фетч записей с сервера SQL и DataSet'а? И там и там по сети будут переданы одни и те же данные. Это первое. Второе - поставить на сервер еще 128/256/512/1024 метров - не проблема. Зато всем будет проще жить (и программисту, и пользователю).

Вот. А теперь внимательно перечитываем название темы и первый пост. У человека не хватает памяти под ненужное ему кэширование.

CyberMax · Сообщение **CyberMax** » 19 июн 2006, 08:46

Dimitry Sibiryakov писал(а):А теперь внимательно перечитываем название темы и первый пост. У человека не хватает памяти под ненужное ему кэширование.

TIBQuery тут ни при чем. Извините за резкость, это криворукость программиста, который использует его для задач, для которых он не предназначен. Те самые 95%, о которых я писал...

Ivan_Pisarevsky

Для таких вещей есть продуманый механизм внешних таблиц "external table", почему бы не воспользоваться им? Есть готовые конверторы форматов внешних таблиц и дбф-ов.
А то ведь велосипед изобретаете...