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

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

8 голосов
/ 03 июня 2011

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

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

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

Ответы [ 3 ]

9 голосов
/ 03 июня 2011

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

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

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

8 голосов
/ 03 июня 2011

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

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

Есть также инструменты мониторинга ситуации проверки, я использовал Sinatica Monitor for Firebird.

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

7 голосов
/ 05 июня 2011

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

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

...