Всем здравствуйте. Ткните носом если этот вопрос уже обсуждался.

Картина следующая - имеется Firebird 2.5 в архитектуре CS и приложение из пары окон ввода данных. Все пишущие транзации короткие - стартуют вручную и завершаются жестким коммитом. Читающая транзация стартует в состоянии pre-commited. И вроде бы все хорошо, но в MON$STATEMENTS регулярно остаются записи я так понимаю подготовленных запросов вот такого вида:


В приложении эта инструкция выполняется компонентой IBSQL. Если после ExecSQL выполнить Unprepare, то запись в MON$STATEMENTS не остается. Непонятно почему сохраняются только некоторые из таких инструкций - все они одинкаово формируются, все параметризированны, все выполняются по одной схеме - старт транзации - выполнение инструкции - коммит. Получается что для некоторых курсор освебождается автоматически, а для некоторых только после уничтожения коннекта?

Но почему тогда я вижу только некоторые? Явного освобождения не делаю нигде

Dimitry SibiryakovЗначит, твоя программа работает совсем не так как ты о ней думаешь.

Спасибо ....
У меня-то формы уничтожаются по закрытию, а раз так - то вызывается деструктор TIBSQL, а раз вызывается - значит выполняется Unprepared в InternalFreeHandle. Вот и все объяснение.

Я тут подумала немножко и у меня назрело еще вопросов.

Если выполнять запрос в isql то после коммита подготовленные запросы исчезают. Хотя соединение остается активным. То же касается выполнения запросов в IBExpert. При коммите из клиентского приложения подготовленный запрос сохраняется либо до уничтожения компонента, связаного с ним, либо до разрыва соединения.

Я так понимаю что освобождение происходит при вызове isc_dsql_free_statement. По крайней мере судя по наблюдению в SQL мониторе. В трекере FB есть ссылка где разработчики говорят о том что в версии 2.5 добавлена специальная константа DSQL_unprepare, которая позволяет не только уничтожить сам дескриптор стэйтмента, но и сделать SQL инструкцию unprepared. Поковырявшись в исходниках IBX TIBSQL.pas (у меня версия 16.16 Delphi XE2) я не обнаружила нигде передачи этого параметра в вызов isc_dsql_free_statement. Только DSQL_close или DSQL_drop, причем передача DSQL_drop выполняется только в деструкторе и соответственно если явно не вызывать метод Unprepare - то это и даст наблюдаемую мной картину.

Так что я подозреваю что при работе isql и IBExpert вызывают isc_dsql_free_statement(DSQL_close|DSQL_unprepare) или isc_dsql_free_statement(DSQL_drop|DSQL_unprepare) что позволяет сразу освободить подготовленные запросы, в то время как IBX выполняет isc_dsql_free_statement(DSQL_close) и isc_dsql_free_statement(DSQL_drop).

Хотелось бы понять в правильную сторону ли я думаю?

На сегодяшний момент это лучший из бесплатных вариантов. Я особых претензий не высказываю им - просто хочу понимать - правильно ли я понимаю как это работает?

Гаджимурадов Рустам, вопрос в том почему при выполнении запросов через IBExpert и isql подготовленные запросы освобождаются, а при работе через IBX - без явного Unprepare - нет? Собственно и все получается

hvlad, не сложно конечно. Весь мучающий меня вопрос в 17942742

tanyxahvlad, не сложно конечно. Весь мучающий меня вопрос в 17942742
Футы.. на ночь глядя уже не то пишу. Вопрос в 17942752

Вот оно что. Спасибо большое за ответ. Я и не знала что isc_dsql_execute может так использоваться. В моем представлении сначала должен быть isc_dsql_execute ..... и потом в конце isc_commit_transaction

А еще совсем глупый вопрос - очень ли плохо если этих запросов много кэшируется? Например для одного коннекта их может быть 80-90 шт. А соединений таких около полусотни. Влияет ли это как-то на работу базы?

Гаджимурадов Рустамtanyxa> Я и не знала что isc_dsql_execute может так использоваться

Это тараканы isql. IBE (кроме скриптера) так не работает.

Но ведет себя похоже ))) Наверное использует DSQL_drop, судя по тому что каждый раз при выполнении запроса заново делает prepare

Гаджимурадов Рустамtanyxa> для одного коннекта их может быть 80-90 шт.
tanyxa> А соединений таких около полусотни.
tanyxa> Влияет ли это как-то на работу базы?

Господи, девушка, не смешите людей.

Я постараюсь :)

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

hvladtanyxaНаверное использует DSQL_drop, судя по тому что каждый раз при выполнении запроса заново делает prepareДля того, чтобы сделать prepare, не нужно делать DSQL_drop.
Извините, может косноязычно выражаюсь - я говорю о том что при выполнении запроса и последующего коммита - подготовленый запрос освобождается.

похоже мнения разделились и я теперь в некоторой растерянности)))

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

tanyxaили все-таки лучше делать явное освобождение ?
Хотя сейчас не вижу в этом особого смысла. Вот пользователь работает с каким-то окном, в зависимости от его действий могут выполняться разные инструкции до тех пор пока он не посчитает работу законченой и не сохранит документ. Тогда действительно - все подготовленные запросы можно считать уже ненужными и делать Uprepare. Но сразу после этого окно переходит в состояние готовности ко вводу следующего документа и следовательно теже инструкции опять подготавливаются.

hvlad
Есть клинические случаи, когда из-за не освобождённых запросов сервер выходил за лимит в 2GB вирт. памяти.
Достаточный аргумент ?
Вполне.

hvlad
У тебя два противоречивых варианта действий:


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

Мимопроходящий, я хочу понять как контролировать что пациент нуждается или не нуждается в лечении. Какие параметры должны меня насторожить?

В данный момент все нормально, запросы выполняются быстро, сервер расходует около 400 МБ памяти, активно около 40 соединений.

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

kdvp.s. и тут (на sql.ru) разработчиков таких систем мы НИКОГДА не видим, имею смелость это утверждать, имея массу реальных примеров. И у нас в саппорте практически никогда не видим.
Вы очень похоже описали ситуацию, с тем лишь отличием что мы пишем не ERP а постепенно мигрируя с файл-серверной СУБД пишем условно-отдельные проекты - когда обслуживается одно предприятие, база одна а проекты охватывают некоторые бизнес-процессы наиболее нуждающиеся в автоматизации.

Dimitry SibiryakovЗначит таникса - первый представитель своего вида, который таки появился здесь.

Я думала таких ситуаций предостаточно, особенно на крупных гос. объектах

o_v_a, Чем крупнее предприятие, тем оно инертнее имхо :)

Мимопроходящий, SAP нас уже третий год обхаживает

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