Назад | Перейти на главную страницу

Причины повреждения базы данных Firebird

Я использую несколько разных версий Firebird (2.0, 2.1) на нескольких серверах начального уровня под управлением Windows с сильно различающимся оборудованием. Единственное совпадение между ними заключается в том, что они запускают одно и то же домашнее приложение с одинаковой структурой базы данных.

В последнее время я наблюдал резкое замедление работы нескольких серверов. Оказывается, эта база данных повреждается, поэтому каждый раз, когда она ломается, мне приходится чинить, резервировать и восстанавливать базу данных, и в течение некоторого времени (1-2 недели) все в порядке, а затем это повторяется снова. К счастью, я не видел потери или повреждения данных ... пока. Дело в том, что каждое такое время простоя приводит к снижению производительности, и зачастую мне это помогает, поскольку некоторые базы данных находятся в удаленных местах.

Я пытался выяснить, что вызывает коррупцию, но не смог. Тот факт, что он работает на другом оборудовании, намекает, что это не должно быть аппаратной проблемой.

Если мы исключаем проблемы с оборудованием, у меня плохое предчувствие, что это ошибка Firebird, поскольку я не делаю ничего особенного с помощью SQL. Есть ли у вас идеи, как точно определить, что вызывает повреждение, и, надеюсь, решить проблему?

[править] Согласно первому ответу: у меня несколько разных проблем в firebird.log:

INET/inet_error: read errno = 10054
INET/inet_error: select in packet_receive errno = 10038
Relation has 12 orphan backversions (5 in use) in table LIMITAI (139)
Index 1 is corrupt on page 61700 level 1. File: ..\..\..\src\jrd\validation.cpp, line: 1659 (repeats for multiple pages and index numbers)
Page 50801 is an orphan (repeats for multiple pages)

Проверьте firebird.log. Он может содержать важную информацию о том, что происходит не так.
Проверьте, как ваше приложение обрабатывает транзакции. Firebird не любит длительные транзакции. Они приводят к замедлению работы и, в конечном итоге (в зависимости от нагрузки и т. Д.) К сбою сервера.

По вопросам производительности рекомендую Sinática Monitor.

hth

Проверьте свои серверы по следующему списку:

  1. Установлена ​​последняя версия Firebird
  2. Включен режим принудительной записи для базы данных
  3. Файловая система NTFS используется
  4. В системе есть ИБП (если нет - выключить кеш записи HDD)
  5. Оборудование надежное (система не зависает из-за плохой памяти, нет битых секторов и т. Д.)
  6. Рекомендуется использование RAID с защищенным кешем памяти.

Следуя этим простым правилам, у нас есть серверы, которые работают годами без каких-либо побочных эффектов.