Не могу определиться, то ли это беда самого IBE, то ли от моего незнания true способа.
Ситуация: база с "мясорубкой" данных: куча коротких транзакций на запись и чтение, постоянно чистка таблиц от устаревших записей. Иногда есть потребность просматривать живую базу через IBE. Но он, если открыть вкладку данных, стартует транзакцию и не закрывает ее - а значит, Oldest Tran. тормозится, сборка мусора задерживается, база пухнет, а в итоге приходит грозный sweep и подвешивает базу на полминуты. Можно в параметрах подключения сделать транзакции рид-онли, но это неудобно на тот случай, если вдруг понадобится что-то изменить. Настройки IBE облазил, ничего по теме не нашел.
Это известная беда? Есть ли способы ее решения?
FB 2.5, fb_inet_server.exe -s

Параметры транзакций - дефолтные
isc_tpb_read_committed
isc_tpb_rec_version
isc_tpb_nowait

Симонов Денис,

яМожно в параметрах подключения сделать транзакции рид-онли, но это неудобно на тот случай, если вдруг понадобится что-то изменить

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

Просто мне любопытно, удержание транзакции IBE-ом - это нормальное поведение?

ТаблоидА решение простое, как 3 коп
Ага, что-то вроде этого приходило на ум, спасибо за конкретный скрипт!
IBExpertВ SQL редакторе уровень изоляции транзакции меняется из выпадающей менюшки на тулбаре.
Это хорошо, но я смотрю просто таблицы. Select * from %tablename%, конечно, вариант, но иногда хочется и разные таблицы посмотреть
hvladНе оставлять открытые окна с данными. Накой они нужны ?
Ну, может, кто-то и способен охватить всю инфу за 5 сек, а потом подгружать ее из мозгового свопа, но мне до такого сатори далеко :) На изучение данных уходит приличное время, за которое next tr успевает сильно оторваться от oldest tr

Таблоида нельзя ли добавить в св-ва базы / узел "транзакции" окошко с таймаутом, по истечению которого будет делаться автоматически коммит RW-транзакции, но только если в ней не было изменений (и рядом - второе окошко с таймаутом и роллбаком для RW-транзакции, СДЕЛАВШЕЙ изменения и не завершённой).
А нельзя ли вообще принудительно сделать транзакции просмотра таблиц read only? Это ведь, насколько я успел понять, базовые требования к БД-программам, которые гуру талдычат уже лет десять: длинная RO для селекта и короткие RW для модификаций.

IBExpert,

см. один пост выше

Dimitry SibiryakovС чего ты взял, что он приходит?

Не претендую на истину. Скорее, не совсем корректно выразился: тормозит не sweeper, а "команда сборки мусора", а именно select count(*) from %table_to_clean%

Таблоида какой размер у этой базейки ? может, есть смысл просто "живую копию" периодически делать ?
30 мегов. Ну, тоже вариант, хотя зависит от частоты использования. Пока что она невелика, и легче что-то намутить на собственной машине, чем тягать бэкапы
Dimitry SibiryakovНет, это workaround для дебилов, которые не в состоянии научиться управлять транзакциями
грамотно.

Окей, а как надо управлять транзакциями грамотно?

Dimitry Sibiryakov,

ну забыл, с кем не бывает

Таблоид,

как раз после удаления сразу выполняю select count. Удаление происходит через определенное количество инсертов. Собственно, если базу не трогать, то все крутится замечательно, с кол-вом транзакций порядка 5-6 в секунду

Dimitry SibiryakovНе делать их больше, чем необходимо по бизнес-правилам.

Холмс и Ватсон летят на воздушном шаре, их снесло ветром и они не
знают, где находятся.
Ватсон:
- Холмс, там внизу человек!
Холмс:
- Ватсон, спросите его, где мы находимся.
- Эй, человек, где мы находимся?
Человек смотрит вверх и кричит:
- На воздушном шаре!
Холмс:
- Это программист.
- Черт возьми Холмс, как вы догадались?
- Элементарно, Ватсон. Он дал абсолютно точный, но совершенно бесполезный ответ.

ТаблоидНастораживает. Какое-то "легкомысленное" отношение к данным: вставили - поглядели (а зачем еще их тогда вставляли ?) - грохнули. Там GTT случайно не подойдёт ?
Не-не, там все нормально. В базе фактически поток, соответственно хранится буфер самых свежих данных, а устаревшее чистится. GTT, к сожалению, не подходят, т.к. transaction-bound or connection-bound

Собственно, инфу о том, что проблема не только у меня, я получил, пару решений разной степени костыльности тоже нашлось. Всем спасибо за внимание :) Отдельный респект Таблоиду за конкретику!

kdvпро это написано во второй половине http://www.ibase.ru/devinfo/ibx.htm
Читаю
статьяТранзакции должны быть максимально короткими, независимо от условий задачи. Вы можете спросить - а как же просмотр данных, или ввод большой "карточки"? Здесь есть два исключения - в Firebird с 1.0 и InterBase с 6.0 транзакции read read_committed rec_version - они стартуют сразу в "завершенном" состоянии, поэтому могут длиться вечно (без необходимости commit/rollback и без влияния на накопление или сборку мусора).

...

Многие разработчики уже поняли этот недостаток, и действуют не по следующей схеме
StartTransaction;
IBDataSet.Edit; // вход в режим редактирования
ожидание ввода пользователя
IBDataSet.Post; // отправка результатов редактирования на сервер
Commit;

А по другой:

получаем данные из DataSet, прицепленного к читающей транзакции ожидаем ввод пользователя в компонентах TEdit и т.п. по нажатию кнопки "Сохранить"
StartTransaction
IBDataSet.Edit;
// заполняем столбцы или параметры запроса данными из обычных контролов
IBDataSet.Post;
Commit;

Собственно, это же я говорил ранее
ядлинная RO для селекта и короткие RW для модификаций.
что сударь ДС заклеймил обидными словами. На предложение поделиться мудростью он, впрочем, ответил невразумительной отпиской.
kdvчешуя. Ибо если есть активная транзакция, стартовавшая до удаления, select count не поможет. См. выше о том, что читать.
Отнюдь не чешуя. ХП не знает, есть ли в данный момент активная транзакция или нет (для формалистов: ХП не из-под sysdba) - да это и не нужно. И select count выполняется для обеспечения нормального режима работы, тогда как наличие тормозной активной транзакции - случай нештатный.