Восстановление резервной копии Firebird разочаровывает, есть ли способ избежать этого?

Я использую Firebird, но в последнее время база данных очень сильно разрослась. На самом деле выполняется много операторов удаления, а также операций обновления/вставки, и размер файла базы данных растет очень быстро. После тонны удаления записей размер базы данных не уменьшается, и, что еще хуже, у меня такое ощущение, что на самом деле запрос немного замедляется. Чтобы исправить это, был задействован ежедневный процесс резервного копирования/восстановления, но из-за того, что пришло время его завершить, я могу сказать, что использование Firebird действительно разочаровывает.

  • Любые идеи по обходным путям или решениям по этому поводу будут приветствоваться.

  • Кроме того, я рассматриваю возможность перехода на Interbase, потому что я слышал от друга, что у него нет этой проблемы - это так?


sql database backup firebird interbase
person Yordan Yanakiev    schedule 03.06.2011    source источник
comment
@Yordan Я согласен, это одна из самых неприятных проблем в Firebird.   -  person JustMe    schedule 03.06.2011
comment
@JustMe, скорее всего, он работает так, как задумано. Будьте осторожны с вашими транзакциями.   -  person Harriv    schedule 03.06.2011
comment
с транзакциями все в порядке - все оптимизировано, как мы проверяли и перепроверяли, но с транзакциями данных более 200 ГБ в день - мусор растет так высоко, что в последнее время он стал действительно уродливым.   -  person Yordan Yanakiev    schedule 03.06.2011
comment
Можете ли вы опубликовать статистику базы данных перед резервным копированием/восстановлением?   -  person Harriv    schedule 06.06.2011
comment
200 ГБ в день? Какую часть этих данных вы удаляете? Файл базы данных, который не сжимается, — это особенность, а не ошибка. Это предотвращает отправку сервером места на диск только для того, чтобы снова запросить больше места на диске. Это работает для вас, не против вас. Вероятно, вы боретесь с этим и должны вместо этого работать с ним. Пожалуйста, прокомментируйте ответы ниже, так как они дадут нам больше информации в вашем случае. Кроме того, предоставьте статистику базы данных по запросу.   -  person EMBarbosa    schedule 06.06.2011
comment
@Harriv - у меня нет никакой статистики, это все, что происходит в процессе и средстве просмотра ресурсов. Просто отметим, что сервер не загружается ничем, кроме самой базы данных.   -  person Yordan Yanakiev    schedule 07.06.2011
comment
@EMBarbosa - обычно мы удаляем до 0,5-1 ГБ данных напрямую ... в то время как пользователи удаляют тот же размер ... это немного случайно, но иногда это много.   -  person Yordan Yanakiev    schedule 07.06.2011
comment
Правда, 0,5 ГБ кажутся ничем иным, как 200 ГБ. Но это все еще много данных, и, как сказал ниже WarmBooter, это может запустить (запустить) сборщик мусора (GC). Вы должны получить статистику базы данных с помощью gstat. Минимальную статистику можно получить с помощью gstat -h пример использования gstat Кроме того, я хотел бы знать, какая версия Firebird? Какой сервер? (Classic, Super Server или SuperClassic?) Какие у вас транзакции? Как много? Как долго они длятся? Сколько пользователей?   -  person EMBarbosa    schedule 07.06.2011
comment
Firebird 2.5, Classic, транзакции длятся до нескольких секунд (в основном), около 20 пользователей.   -  person Yordan Yanakiev    schedule 07.06.2011
comment
@Yordan: Вы можете создать статистику с помощью инструмента gstat. Документация здесь: firebirdsql.org/manual/gstat.html Однако я вижу, что вы отметили мой ответ как принятый, вы нашли какие-либо проблемы? Сообщите нам, какова была настоящая причина, чтобы кто-то еще мог воспользоваться вашим вопросом.   -  person Harriv    schedule 08.06.2011
comment
ну - ничего не изменилось - все как было. мы сделали все, что предлагается, но база данных по-прежнему нуждается в процедуре резервного копирования/восстановления. это все. похоже, мы прокляты этой жар-птицей :|. Надеюсь, скоро выйдет Firebird 3, иначе биться головой о стену сейчас кажется хорошим решением :D   -  person Yordan Yanakiev    schedule 08.06.2011
comment
мы сделали все то, что предлагает ИДК... Я все еще думаю, что вам следует обсудить это подробнее. Как сказал Харрив, когда-нибудь кто-то другой сможет извлечь пользу из вашей проблемы. Я знаю некоторые вещи, которые вы уже пробовали, и, возможно, вы устали от этого. Но мы не знаем, что именно ты сделал, пока ты не скажешь. Итак, мы пытаемся помочь... статистика gstat поможет получить более полную картину. Также выйдет FB 3, но как вы будете уверены в этом изменении, если у большей части пользователей это вообще не проблема? Если вы уже не просили об этой функции, чего я не знаю...   -  person EMBarbosa    schedule 08.06.2011
comment
Ну хорошо. Я удалил принятый ответ. Я надеюсь, что мы углубимся и перейдем к решению проблемы полностью. :|   -  person Yordan Yanakiev    schedule 08.06.2011
comment
:|(эта улыбка не очень радостная знаете ли...) Ну, я прочитал ваш очередной вопрос. Теперь вижу, что это не новая тема. stackoverflow.com/questions/6134899/ Вы проанализировали статистику gstat, как было предложено? Вы использовали Sinatica Monitor, как предложил Мариуз в другой теме? Если вы уже сделали все, что считаете возможным, возможно, вы хотели бы обратиться за помощью в список группы поддержки Firebird или список разработчиков. Это может помочь им настроить FB3, чтобы помочь вам. :)   -  person EMBarbosa    schedule 08.06.2011
comment
да - Firebird 3 принесет много нового, что является РОЖДЕСТВЕНСКИМ ЖЕЛАНИЕМ в нашу разработку. но дата выхода Firebird 3 - самая большая загадка после большого взрыва... :D   -  person Yordan Yanakiev    schedule 08.06.2011
comment
Вот некоторые результаты тестов с базой данных 1 ТБ: ib-aid.com/articles/item104   -  person Harriv    schedule 10.06.2011

Ответы (3)


arrow_upward
9
arrow_downward

У нас есть много огромных баз данных на Firebird в производстве, но у нас никогда не было проблем с ростом базы данных. Да, каждый раз, когда запись удаляется или обновляется, в файле сохраняется ее старая версия. Но рано или поздно сборщик мусора выметет его. Как только оба процесса сбалансируют друг друга, файл базы данных будет расти только на размер новых данных и индексов.

В качестве общей меры предосторожности, чтобы предотвратить огромный рост базы данных, постарайтесь сделать ваши транзакции как можно короче. В наших приложениях мы используем одну транзакцию READ ONLY для чтения всех данных. Эта транзакция открыта на протяжении всего времени жизни приложения. Для каждого пакета операторов вставки/обновления/удаления мы используем короткие отдельные транзакции.

Замедление работы базы данных могло быть вызвано устаревшей статистикой индексов. Здесь вы можете найти пример пересчета статистики для всех индексов: http://www.firebirdfaq.org/faq167/

person Andrej Kirejeŭ    schedule 03.06.2011
comment
Иногда я запускаю плановую проверку один раз в день, и это, кажется, поддерживает базы данных Firebird в первозданном виде. - person Andre Van Zuydam; 19.12.2017

arrow_upward
8
arrow_downward

Проверьте, есть ли у вас незавершенные транзакции в ваших приложениях. Если транзакция запущена, но не зафиксирована или не отменена, база данных будет иметь собственную версию для каждой транзакции после самой старой активной транзакции.

Вы можете проверить статистику базы данных (gstat или внешний инструмент), есть самая старая транзакция и следующая транзакция. Если разница между этими числами продолжает расти, у вас проблема с зависшей транзакцией.

Существуют также инструменты мониторинга ситуации проверки, один из которых я использовал, это Sinatica Monitor for Firebird.

Редактировать. Кроме того, файл базы данных никогда не сжимается автоматически. Его части помечаются как неиспользуемые (после операции очистки) и будут использоваться повторно. http://www.firebirdfaq.org/faq41/

person Harriv    schedule 03.06.2011

arrow_upward
7
arrow_downward

Пространство, занятое удаленными записями, будет повторно использовано, как только оно будет удалено Firebird. Если GC не происходит (проблемы с транзакциями?), БД будет продолжать расти, пока GC не сможет выполнять свою работу.

Кроме того, существует проблема, когда вы выполняете массовое удаление в таблице (например, миллионы записей), следующий выбор в этой таблице «запускает» сборку мусора, и производительность падает до тех пор, пока сборка мусора не завершится. Единственный способ обойти это — выполнять массовые удаления в то время, когда сервер не очень используется, и после этого запускать проверку, чтобы убедиться, что нет застрявших транзакций.

Кроме того, имейте в виду, что если вы используете «стандартные» таблицы для хранения временных данных (например, информация вставляется и удаляется несколько раз), вы можете получить поврежденную базу данных в некоторых случаях. Я настоятельно рекомендую вам начать использовать функцию Global Temporary Tables.

person WarmBooter    schedule 05.06.2011
comment
Вы также можете отключить автоматическую сборку мусора и выполнять ее вручную, когда другие виды использования невелики. - person Harriv; 08.06.2011
comment
@Harriv, вы также можете отключить его в базе соединений, как объяснил Дмитрий К. в IBDeveloper. блог. Это не обычно... но можно. (: - person EMBarbosa; 18.06.2011