Здравствуйте, уважаемые!

Никак не могу понять одну вещь про сборку мусора в базе.

Дано: FB 2.5. SS или FB 3.0 SS, один коннект, две таблицы Tbl1 и Tbl2, три транзакции Tr1 (пишущая), Tr2 и Tr3 (только чтение)

Действия:
1. в Tr3 делаем select * from Tbl2, транзакция остается висеть.
2. В Tr1 пишем много записей в таблицу Tbl1, коммитим Tr1
3. Делаем много разных чтений из Tbl1 в Tr2
4. Удаляем из нее все записи опять в Tr1, коммитим Tr1
5. Коммитим Tr2. Для очистки мусора делаем select * from Tbl1 в Tr2, снова коммитим Tr2

Теперь если повторять шаги 2-5, то с каждым циклом они выполняются все медленнее и медленнее, из-за чего делаю вывод, что мусор не собирается.
Но почему? Единственная незакомиченная транзакция в базе - Tr3 и ее таблица Tbl1 никак не интересует

И дело явно в Tr3, так как если ее закоммитить в первом шаге или вообще первый шаг не делать, то сколько бы не было циклов 2-5 они выполняются примерно за одно и то же время.

Не знаю, важно или нет:
1. Tbl1 - таблица временная на коннект, Tbl2 - постоянная.
2. Наличие/отсутствие запросов select * from Tbl2 в незакомиченных транзакциях из другого коннекта никак не влияют на скорость выполнения цикла.

bsv9VerLeon,Но почему? Единственная незакомиченная транзакция в базе - Tr3 и ее таблица Tbl1 никак не интересует

Судя по всему, Вы думаете будто транзакции "привязаны" к конкретным таблицам (, которые были в них прочитаны ил изменены). Это не верно. Транзакции оказывают влияние на все без исключения таблицы базы. Даже если бы вы в просто стартовали Tr3 и ничего в ней не читали, то мусор бы точно так же накапливался.

Очевидно, что я что-то недопонимаю в сборке мусора, но если бы Tr3 была пишущей или snapshot, но она read и read_committed - с чего ее должны интересовать старые версии записей всех таблиц в базе?

выдал по этой таблице

Average version length: 0.00, total versions: 0, max versions: 0

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

Симонов ДенисVerLeon5. Коммитим Tr2. Для очистки мусора делаем select * from Tbl1 в Tr2, снова коммитим Tr2

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

Да дело не в этом точно (кстати, вроде как раз count(*) теперь мусор не собирает, так как собственно в записи не лезет)
Сборка мусора прекрасно происходит запросом и select *, если при этом не висит Tr3

Симонов ДенисVerLeonДа дело не в этом точно (кстати, вроде как раз count(*) теперь мусор не собирает, так как собственно в записи не лезет)

собирает. count просто в некоторых случаях не распаковывает запись, но видимость версий проверяется в любом случае. Если версия не видна и её можно удалить, то она удаляется


VerLeonСборка мусора прекрасно происходит запросом и select *

в данном случае да, ибо перед этим делается delete всех записей

Да, согласен, не учел, что мне надо собрать мусор по полностью пустой таблице.
Но в данном случае без разницы.

Что-то мне кажется, что проблема именно в том, что Tbl1 - временная на коннект, вот только почему от этого такой эффект...

hvladVerLeonОчевидно, что я что-то недопонимаю в сборке мусора, но если бы Tr3 была пишущей или snapshot, но она read и read_committed - с чего ее должны интересовать старые версии записей всех таблиц в базе?Для GTT это не имеет значения, ибо в них можно писать и в RO тр-циях.

О как.. Т.е. чтобы собрать мусор в GTT нужно сначала завершить вообще все транзакции в коннекте?
Печально...
Придется видимо операции с ними выносить в отдельный коннект

hvladВ данном сценарии не вижу - зачем GTT создана как ON COMMIT PRESERVE ROWS

Ну это упрощенное описание, на самом деле на шагах 2-4 делается много всего и долго и не хотелось иметь длинную пишущую транзакцию, поэтому делалось по классике: писалось все короткими транзакциями, а читалось другой, RO
Но не учитывался вот этот факт:

hvlad ибо в них можно писать и в RO тр-циях

Сейчас попробую выделить всю работу с GTT (и запись и чтение) в одну RO-транзакцию и сделать их DELETE ROWS.

bsv9Да, я тестировал на версии 3.0.5.

У меня 3.0.2 и 2.5.7 - поведение одинаковое. Да и вряд ли что-то в 3.0.5 поменялось, раз Влад говорит, что это нормально.

Переделал все на DELETE ROWS с чтением/записью в них в RO транзакции - проблемы больше нет.
Ну и не удивительно, с такими GTT проблемы с мусором быть и не может, главное что RO транзакция отработала.

Влад, спасибо за наставление на путь истинный! :)

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

Влад не сказал, что это нормально. Он намекнул, что если ты в Tr1 только пишешь во временную таблицу и не пишешь в постоянные, то смысла делать транзакцию write нет.

Ну логично, что если RO может писать в GTT, то и мусор из нее не соберется, даже если висит только эта RO

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

Хм, а всё же - нормально это или нет?
Не окажется ли, что это в ближайших релизах FB посчитают ненормальным и моя схема с писанием в GTT c помощью RO транзакции накроется?

Ivan_PisarevskyVerLeonНе окажется ли, что это в ближайших релизах FB посчитают ненормальнымВсе идет у тому, что пишущая ридкоммитед транзакция перестанет копить мусор и RO перестанет быть столь актуальной. Так что, если перестанет писать в RO (что мне не кажется правильным, вполне нормально в RO режиме сделать некие "пометки на полях" база же не меняется) сменишь на RW.

Ну не все так просто. В большом приложении транзакций много и в частности в том, которое досталось мне, долго выстраивали классику (пишем в коротких пишущих, читаем только в RO) . А потом часть таблиц перевели на GTT. А потом... И потом.. На что я и напоролося. Собственно не проблема конечно сделать RW - в плане трудоемкости, но чем это аукнется в плане скорости - хз, а это очень критичный сегмент приложения и боюсь придется переписывать заново.