Dimitry SibiryakovЗачем мне цитировать такую чушь? Sweep interval сравнивается с OIT-OAT, а не NT-OIT.Про то, что это чушь расскажи тому, кто написал это в мануале на сайте firebirdsql.org .

Симонов Денисзначит там эту чушь до сих пор не исправили :(Тогда я не понимаю возмущения некоторых от употребления на форуме некорректных определений.

Dimitry SibiryakovРассказал: http://tracker.firebirdsql.org/browse/WEB-152 Спасибо!

kdv- cooperative - время update будет всегда одним и тем же. Кооперативная явная сборка мусора собирает мусор "принудительно" именно для этого запроса.
- background - время update будет зависеть от паузы между нажатиями. Фоновая сборка мусора при select/update не собирает мусор, а сигнализирует сборщику. Если пауза большая, то сборщик успевает собрать мусор. Если пауза меньше, то сборщик не успевает, и select/update с каждым разом будут все медленнее и медленнее.Сие мне, теперь уже, понятно, но вдруг начала беспокоить фраза в одной из статей - "Необходимо отметить, что наиболее опасным сбоем для БД является сбой в момент сборки мусора." . Как-то можно уменьшить риски, если с большой долей вероятности можно утверждать, что заказчик не следит за состоянием аккумуляторов и штатной работой ИБП в целом?

kdv, ясно, спасибо!

Господа, у меня возник еще вопрос по теме:
Если мы имеем базу, в которую, преимущественно, осуществляется вставка записей, с некоторой регулярностью осуществляется изменение данных одной таблицы (причем, изменение данных осуществляется в отдельной транзакции и может быть вынесено в отдельный коннект) и еще реже осуществляется чтение. Иными словами, "мусор" хоть и возникает, но не интенсивно и вполне можно было бы "собирать" его раз в сутки через backup/restore. Будут ли увеличиваться "тормоза" при работе с базой и накопления в ней мусора, если всем рабочим соединениям задать no_garbage_collect ?

Симонов Денис, да, поздновато я подумал о том, что меня сейчас "закидают шапками" за употребление (хоть и в кавычках) фразы "сбор мусора" в отношении gbak backup... Я в курсе, что gbak никакой мусор не собирает, а лишь сохраняет в резервную копию актуальные записи. Конечно же, я имел ввиду избавление от мусора в базе через gbak restore/backup.

Симонов Денисобновление всегда требует чтения записей. Если ты несколько раз обновляешь одни и те же записи, то чтение реже быть не может.Ну, это понятно... Рассматривая вариант, когда коннект, изменяющий данные в одной и той же таблице, имеет свойство no_garbage_collect, а "мусорные" версии появляются каждый раз при изменении данных в таблице - будут ли увеличиваться "тормоза" при каждом следующем изменении данных или же no_garbage_collect позволяет это избежать?

Гаджимурадов Рустам, считай, что sweep interval = 0 , а также никакой gfix -sweep к базе не применяется.

Симонов Денис, база не вырастет настолько сильно, так как устаревшие данные периодически вычищаются, а вот с обломавшимся restore посложнее будет... Конечно, restore будет делаться в другую БД и при его успешном завершении база будет переименовываться, но надо подумать, что делать при неуспешном.

Симонов Денис, но вопрос не столько про gbak backup/restore, сколько про то, будут ли увеличиваться "тормоза" при каждом следующем изменении данных, если соединение с no_garbage_collect.