rdb_dev,

- сборка мусора работает всегда. не работает она только если в коннекте включить no_garbage_collect, причем только для этого коннекта. Соответственно, сборку мусора "для базы" или на уровне сервера выключить невозможно.
- sweep interval - да, это автосрабатывание sweep, не более того.

собственно, а зачем понадобилось менять сборку мусора с background на cooperative?

rdb_dev,

я добавлю, что как то был топик, про "фазы луны".
http://www.sql.ru/forum/377919-1/firebird-i-fazy-luny
С тех пор у меня в нескольких презентациях про транзакции есть слайд, который объясняет разницу между cooperative и background.

Идея такая. Есть таблица с 10к (100к и т.д.) записей. Приложение по кнопке
стартует транзакцию
делает update 10к записей (всегда одних и тех же)
commit

время от старта до коммита замеряется и выводится. Кнопку нажимаем то часто, то редко (с интервалом от 0.5 до 10 секунд).
В "некоторых случаях" время от старта до коммита сильно плавает, в зависимости от частоты нажатия на кнопку. Так вот
(напомню, что мусор собирается при select или update)

- cooperative - время update будет всегда одним и тем же. Кооперативная явная сборка мусора собирает мусор "принудительно" именно для этого запроса.
- background - время update будет зависеть от паузы между нажатиями. Фоновая сборка мусора при select/update не собирает мусор, а сигнализирует сборщику. Если пауза большая, то сборщик успевает собрать мусор. Если пауза меньше, то сборщик не успевает, и select/update с каждым разом будут все медленнее и медленнее.

rdb_dev,

никак. одна надежда на forced writes = on. И еще на то, что при сборке мусора мусор как бы не удаляется, а на него убирается ссылка, а вместо старых записей создается новая версия, которая помещается на пустое место.
Ну и бэкапы регулярно.

Если нет, то такой пользователь - потенциальный клиент нашего ремонта БД, с неизвестным результатом ремонта.