Наталья87Так как вызвать backup&restore?
Или сборщик мусора sweep?
Или дефрагментацию/переиндексацию?
вы на IBX, и про services api ничего не слышали? Фантастика.
http://www.ibase.ru/ibx#servapi

я этот документ написал и опубликовал 15 лет назад.

Наталья87разница стала в пределах пары сотен
вас должна интересовать разница между Next transaction и Oldest Active. А она свипом не "убирается". И у вас ее (разницы Next-OAT) практически нет.
С другой стороны, если вы массово обновили данные, а потом запустили отчет - да, отчет будет "собирать" мусор, но это не значит, что свип надо запускать перед каждым отчетом.
Наталья87 уменьшить всё равно
да забудьте вы про "уменьшение базы", пожалуйста. Вы не представляете себе как организована БД внутри, и беспокоитесь об ее уменьшении...

К примеру, тут как-то была жалоба от пользователя - почему при базе в 100мб при выполнении отчета в программе генерится временный файл размером 1 гигабайт. Ну, такой дурацкий запрос написан.

Наталья87существенно ускорить работу с базой данных
существенно - это как? Например, дайте select count по вашей самой большой таблице в 600мб или 2 гиг базах, и приведите сюда сколько запрос выполняется, и сколько page reads.
Наталья87Pentium 4 с 1-2 Гб оперативы это нормально
где нормально - на таком компе нынче даже в браузере тяжело работать, тупо медленно.

Наталья87а по мере наполнения базы начинает замедляться.
дык. например, сумма по продажам. Сегодня их 100, завтра 200, к концу года 36500. Через 3 года - в 3-4 раза больше.
Если каждый раз считать сумму по этим одним и тем же данным, то к гадалке не ходи - будет медленнее и медленнее.
Поэтому... что? надо менять схему подсчета по сырым данным - добавлять хранимые агрегаты, и прочее.
Например, зачем делается в бухгалтерском ПО "закрытие месяца"? Как минимум, чтобы не считать всю эту фигню каждый раз.

Насчет памяти - база не обязана "влезать в ОЗУ", конечно. Но если у вас запросы с сортировками, то на 2гиг RAM они могут "вышибать" (кэшем ОС) память приложений (и ФБ), в результате чего начинается свопирование и прочие тормоза. И их причина - не в FB, а банально в том, что 2 гиг памяти уже давно даже не минимум, а я не знаю что.
Продумайте минимальные требования к железу для вашего ПО. Если клиент такой нищий, что не может докупить 2-6 гиг памяти, то зачем он вам нужен? Более того, подавляющее количество контор скорее заплатит за апгрейд железа, чем за какой-то софт (и тем более его поддержку).

Наталья87,

Тут проблема в том, что если
- в однопользовательском варианте вы можете и свип запускать из приложения (не через гфикс), и бэкап делать тоже (не через гбак).
- в многопользовательском приложении запускать гбак или гфикс, или пересчитывать статистику через какие-то интервалы - значит у вас в КАЖДОМ приложении такое возможно, а значит вы будете "долбить" сервер этими задачами, причем только в момент работы пользователей. В многопользовательском случае по любому нужен админ, и настройка бэкапов и свипов именно на сервере.

p.s. так что там с 22397719