Наталья87Например, за полгода работы размер может вырасти до 600 мегабайт.
не смешите меня, пожалуйста. Мы сопровождаем десятки серверов с Firebird где базы по 400-500 ГИГАБАЙТ. Остальные сопровождаемые сотни серверов меньше 400 гиг, и единицы серверов с трерабайтными БД.
Наталья87При этом если сделать backup&restore - скорость работы программы возвращается к нормальной, размер базы становится в несколько раз меньше (например, был 600 Мб, стал 150 Мб).
а потом ФБ и операционная система будут пыжиться, опять расширяя базу до 600мб. Пустое место в базе используется повторно.
Не надо сожалеть о "впустую потраченных мегабайтах", их просто не существует.
Наталья87Но Firebird - насколько я знаю - не поддерживает горячее восстановление баз данных.
встроенная репликация поддерживается для 2.5 и 3.0 в HQbird, и есть в стандартном Firebird 4. Можно сделать standby кластер.
Наталья87Вопрос - что делать - можно ли встроить в программу функционал - чтобы пользователи могли сами делать backup&restore
для однопользовательских приложений - ОДНОЗНАЧНО. Не можно, а нужно. К нам регулярно такие пользователи обращаются за ремонтом БД, починить можно процентов 70 баз, но часть данных теряется всегда, а 30% баз в мусорку отправляются.
Наталья87можно было ускорить работу базы данных, проведя её дефрагментацию и возможно, переиндексацию?
извините, чушь какая-то. База данных это файл с random access, принципиально. Поэтому никакая "дефрагментация" ему не нужна, и "переиндексация" тем более. Зачем "переиндексация" вообще?

Наталья87alter index .... inactive
alter index .... active

для каждого индекса помогло - хоть и меньше чем backup&restore - но ускорение есть
alter index inactive не нужно, потому что active и так индекс перестроит.
То, что "помогло" - видимо статистика по индексам не пересчитывается. А перестраивать индексы было необязательно.
Насчет того, что backup/restore "помогает" - это только кажется. Тем более при вашей микроскопической базе в 600мб это вообще ни о чем. Если у вас при такой базе б/р помогает ускорить что-то, то или у вас база на древнем hdd, или запросы настолько КРИВЫЕ (или нет нужных индексов), что бороться надо (как тут уже сказали) именно за планы запросов.

Ну и см. 22397640 . Правда, опять же - база 600мб, и влияние "мусора" - это что-то невообразимое. Но да - транзакциями надо управлять. А в однопользовательских базах проблем с "мусором" не должно быть по определению.

Наталья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

X11пишущая транзакция - для записи данных и она - максимально короткая.
а потом приходит какой-нибудь чел, лезет ИБЭкспертом в промышленную базу с 500 одновременных пользователей, выполняет там какой-нибудь запрос и бросает ИБЭксперт на пару суток.
И через сутки-двое начинаются вопли "у нас всё тормозит". Если в конторе есть кто-то умный, который знает про mon$ - смотрит и находит негодяя по IP, ИБэксперт отрубают, и дают тому канделябром по башке.
Иногда после этого пишут скрипт, который раз в 1-2 часа отрубает все коннекты, где имя процесса - ibexpert.exe.
Как-то так.