ээээ...
кооперативная сборка мусора - это сборка мусора при его обнаружении. Мусор обнаруживается в основном при чтении данных.
gbak, это такая программа, которая стартует транзакцию snapshot, и читает ВСЕ данные в БД. Следовательно, gbak как и любая другая программа, работающая с БД, будет заниматься кооперативной сборкой мусора.
Но, gbak как обычная программа, не может делать действия, которые выполняет gfix -sweep. Как минимум - подвигать вперед OIT.
почему?
потому что если вызывать gbak без ключа -g, то это приведет к кооперативной сборке мусора, что ЗАМЕДЛИТ работу сервера вообще и gbak в частности. На разных версиях серверов это действует по разному, особенно влияет сборка мусора в неуникальных индексах. Но и это побеждено в IB 7.1/FB 2.0.
Вообще, лично я смысла запускать gbak без -g вообще не вижу. Есть мусор, нет мусора - задача gbak сделать резервную копию.
Можно, конечно, опосредованно возложить на него запуск кооперативной сборки мусора, но на старых версиях сервера (см. выше) это все будет происходить значительно медленнее, чем просто запустить gfix -sweep.
Можно самостоятельно произвести эксперимент: отрубить автоматический sweep в базе, и мониторить накопление мусора ibanalys-ом. Если мусора наберется много, то
1. остановить сервер
2. скопировать БД
3. запустить gbak -b
посмотреть на загрузку сервера, и время выполнения.
4. затем остановить сервер, подсунуть серверу копию БД
5. запустить gbak -b -g
сравнить время и загрузку с пунктом 3
обязательно надо иметь в виду, что кооперативная фоновая (а не явная) сборка мусора в IB 6 и выше имела слишком низкий приоритет, поэтому когда она начиналась по всей базе, невозможно было предсказать момент ее окончания. А тушить сервер при работающей сборке мусора - опасно для базы.
Вот собственно, аргументы, которые и изложены в упомянутых статьях.
