Всем привет!
Помогите пожалуйста разобраться со сборкой мусора.

Описываю ситуацию.
Firebird 2.5. Embeded версия
Ibexpert для мониторинга статистики таблицы

Есть приложение, есть таблица в которой происходит update/insert.

Через IbExpert вижу что таблица замусоривается. Закрываю программу, в IbExpert делаю
select count(*) из таблицы, вижу что мусор очистился. Делаю тоже самое в программе, мусор не чиститься. Понимаю, что в программе остались "Заинтересованные транзакции".
У меня вопрос, как найти транзакции в моём приложении которые мешают сборке мусора?
Я смотрел в таблицы mon$transaction, mon$statements, mon$atachments но ничего нужного не нашёл, может не так смотрел конечно.

kdvMandarinЯ смотрел в таблицы mon$transaction, ... но ничего нужного не нашёл
как это?

1. я не очень понимаю, зачем "чистить мусор" в Embedded. У вас что, приложение держит много транзакций?
2. версии чистятся только когда они становится мусором. То есть, например, в "монопольном" режиме
update
commit - если других транзакций нет, предыдущие версии стали мусором
start trans
select count - тут мусор соберется.
Если параллельно с той транзакцией, которая делала update, есть еще какая-то активная read/write транзакция, и она активна на момент select count, то версии в мусор не превращаются.

1. Чистить мусор в Embed нужно, т.к. он появляется и сильно замедляет работу :). приложение держит много активных транзакций, т.к. это большое сложное приложение с множеством модулей, которые работают с одной БД.
2. Вы говорите про транзакции которые работают с той же таблицей которую мне надо почистить, или вообще транзакции в БД?

Гаджимурадов РустамЗачем ты всё это делаешь? Стандартные режимы чем-то
не устраивают? Если да, то чем не устраивает gfix sweep?

Mandarin> Делаю тоже самое в программе, мусор не чиститься.
Mandarin> Понимаю, что в программе остались "Заинтересованные транзакции".

Какие компоненты доступа, как настроены транзакции?

> Я смотрел в таблицы mon$transaction, mon$statements, mon$atachments
> но ничего нужного не нашёл, может не так смотрел конечно.

Показывай, как смотрел. delete from mon$transactions пробовал?


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

gfix sweep очень даже подходит НО требует монопольного доступа к БД, а это очень сложно организовать

У меня в программе предусмотрел backup/restor при старте, с определённым интервалом, в этом случае мусор чистить, но на дохлых компьютерах это может занимать 10-15 минут и пользователи отказываются ждать. Надо настроить сборку в фоновом режиме.

Dimitry SibiryakovMandarinиз-за замусоривания запросы работают медленнее.

Вообще-то нет. Обычно оно не оказывает заметного влияния на скорость запросов. Разве что в
случаях когда из-за недостатка места на страницах идёт сильная фрагментация записей.


К гадалке не ходи, как говорится :)

kdvMandarinприложение держит много активных транзакций, т.к. это большое сложное приложение с множеством модулей, которые работают с одной БД.
есть же правила - длинную транзакцию делать read read_committed rec_version, она не будет "удерживать версии".
А если не хотите исправлять "много активных транзакций", то тогда не надо страдать по поводу мусора. Одно следует из другого - исправляете транзакции, пропадает проблема мусора.

Хватай специалиста!!! Держи его :) Вот золотой человек! :) Спасибо! То, что нужно!
З.Ы. Дайте ему премию :)

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

неужели исправил?
Исправил. Как посоветовал kdv я поменял параметры долгоиграющей транзакции и сборка мусора начала работать после select count(*)

Dimitry SibiryakovСимонов Дениснеужели исправил?

Скорее замёл под коврик названным костылём.

Спасибо за критику :) именно она не даёт расслабиться и даёт стимул двигаться в перёд :)