Firebird backup restore расстраивает, есть ли способ избежать этого?
Я использую Firebird, но в последнее время база данных растет очень серьезно. Существует действительно много операторов delete, а также update / inserts, и размер файла базы данных растет очень быстро. После тонны удаления записей размер базы данных не уменьшается, и что еще хуже, у меня такое чувство, что на самом деле запрос немного замедляется. Чтобы исправить это, был задействован ежедневный процесс резервного копирования/восстановления, но из-за этого пришло время завершить - я мог бы сказать, что это действительно разочаровывает использование Firebird.
любые идеи по обходным путям или решению по этому вопросу будут приветствоваться.
кроме того, я рассматриваю возможность перехода на Interbase, потому что я слышал от друга, что у него нет этой проблемы - это так ?
3 ответов
У нас много огромных баз данных на Firebird в производстве, но с ростом базы данных. Да, каждый раз, когда запись удаляется или обновляется, старая версия будет храниться в файле. Но рано или поздно его сметет мусорщик. Как только оба процесса сбалансируют друг друга, файл базы данных будет расти только для размера новых данных и индексов.
в качестве общей меры предосторожности для предотвращения огромного роста базы данных попробуйте сделать ваши транзакции как как можно короче. В наших приложениях мы используем одну транзакцию только для чтения для чтения всех данных. Эта транзакция открыта в течение всего срока службы приложения. Для каждого пакета инструкций insert/update / delete мы используем короткие отдельные транзакции.
замедление работы базы данных может быть вызвано устаревшими индексами статистики. Здесь вы можете найти пример того, как пересчитать статистику по всем индексам:http://www.firebirdfaq.org/faq167/
проверьте, есть ли у вас незавершенные транзакции в ваших приложениях. Если транзакция запущена, но не зафиксирована или откатана, база данных будет иметь собственную ревизию для каждой транзакции после самой старой активной транзакции.
вы можете проверить статистику базы данных (gstat или внешний инструмент), есть самая старая транзакция и следующая транзакция. Если разница между этими числами продолжает расти, у вас есть проблема застрявшей транзакции.
есть также мониторинга инструменты ситуация проверки, я использовал Sinatica Monitor для Firebird.
Edit: кроме того, файл базы данных не сжимается автоматически никогда. Части отмечены как неиспользуемые (после зачистки) и будет использоваться. http://www.firebirdfaq.org/faq41/
пространство, занимаемое удаленными записями, будет повторно использовано, как только это мусор, собранный Firebird. Если GC не происходит (проблемы с транзакциями?), DB будет продолжать расти, пока GC не сможет выполнить свою работу.
кроме того, существует проблема, когда вы делаете массовое удаление в таблице (например, миллионы записей), следующий выбор в этой таблице "вызовет" сборку мусора, и производительность упадет до завершения GC. Единственный способ обойти это - сделать массивный удаляет в то время, когда сервер не очень привыкли, и работать после этого, убедившись, что нет застрял сделок.
кроме того, имейте в виду, что если вы используете "стандартные" таблицы для хранения временных данных (т. е. информация вставляется и удаляется несколько раз), вы можете получить поврежденную базу данных в некоторых случаях. Я настоятельно рекомендую вам начать использовать функцию глобальных временных таблиц.